|
In Lean Use Cases: Part 2, I promised I would talk about documenting business rules and data items relevant to a use case. Here I am, fulfilling that promise. Imagine a holiday company requires a system that allows it to, among other things, take bookings for holidays. I have modelled a […] As a follow-on from Lean Use Cases: Part 2, please click on the link below to see a short tutorial on modelling use cases as activity diagrams. It is best viewed in full-screen mode. Activity diagram tutorial View more presentations from Declan Chellar See Lean Use Cases: Part 4 for documenting business rules […] I am fond of System Use Cases as a tool for documenting functional requirements, but I am not a big fan of use case specifications. I find the textual specifications result in the kind of weighty documents that everyone hates reviewing and I continue to be amazed that so many analysts […] Recently I was asked to take a look at some Software Use Case (SUC) specifications. What I found was actually a description of a screen flow crowbarred into a SUC specification template. There are two questions you might be asking. What’s wrong with that? How does it come about? April 22nd, 2010 | Tags: analysis, requirements, techniques | Category: Use Cases | Leave a comment I have had discussions with colleagues about use cases (and seen discussions on LinkedIn) where it is clear that some people do not understand that there are different types of use case, so I hope the following definitions help. Business Use Case A technique for describing (in technology-agnostic terms) a repeatable […] A visitor to my blog commented on the post “No favourites” saying that her solution to the problem of being asked multiple security questions (none of which might apply) is to use a single word as the answer to all such questions. So no matter whether they ask what your favourite […] Use cases are a good mechanism for modelling functional requirements. However, I have met many skilled developers in the BPM world who disdain them and I think I know why. Use cases were invented for Object Oriented development using an OO programming language and so have certain characteristics that facilitate that […] Here is a re-cap of my approach to modelling a To Be process: Part 1: we modelled the As Is change control process in order to understand the current business model. Part 2: we reminded ourselves to be sensitive to the fact that the customer owns the process.
A Tale Of Two Projects View more OpenOffice presentations from DeclanChellar. […] Adam Feldman of Bright Green Projects has an interesting discussion on whether to limit the number of characters available for composing a requirement within a requirements tool. Pop over to Adam’s blog and have a look. Test […] |