Hi Eric/Forum
Good points from Eric - just to clear up a few points I made in my original reply. The "one use case = one person year" is a guideline originally suggested by someone at Rational. This is definitely not a hard and fast rule - but usually helps people think of use case granularity at a better level than they normally do (people start at too low level - design-focussed, functional decomp, etc). The result is too many use cases for them to follow up with the rest of the process of design and implementation, confused reviewers of the use cases (they can't see the big picture, too much to review with very little useful content in each use case, lots of time spent flipping between different use cases to get the real flow of the system). Why is functional decomposition to be avoid with use cases? - my main reason is that functional decomposition (use cases daisy-chaining together) breaks the definition of use cases (the "sequence of events that deliver *real value* to an actor"), this means in practise that it is difficult to realize these use cases and drive them to design and code in an iterative fashion. This means (in turn) that you are not delivering useful functionality at the end of each iteration. This also results in systems whose architectures mimic the func decomp breakdown rather than a carefully crafted architecture - something you should be able to run the use cases across rather than inside the architectural layers (not sure of that makes sense - lots of hand waving in the explanation is difficult to convey in type :-). Finally, func decomp use cases are usually a symptom of other project problems. My favourite example is a 200+ use cases (which my colleagues eventually beat down to about 10 to 20 as I recall) - totally func decomp'ed, analysts felt they had done good work, felt overworked as they had all this use case specs to complete - developers totally confused as to the true purpose of the system, drowning in use cases but that was really the least of their problems in the end. In part - the problem was they had bought into the buzz words (iterative, use case driven, architecture) but just carried on as before. Apologies for not adding at least some reasoning to my original comments. regards anthony > -----Original Message----- > From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]] > Sent: 23 October 2001 21:50 > To: ROSE_FORUM > Subject: Re: (ROSE) Use Case-confusion > > > > The original question on this thread was about the granularity of use > cases. > > People are throwing guidelines without much reason or evidence that I > can see. Rational Corp., which is a powerful authority, is quoted as > saying that one use case should take about a man-year from idea to > tested code. We are told to avoid functional decomposition, but, as > usual, we are not told why. > > In the absence of good reasons, the advice of authorities may > be golden, > but we should be in search of good reasons, too. So, here's my > reasoning, for what it's worth. > > Stepping into design too early works against analysis. If you have a > design in mind, it is very difficult to stop yourself from > assimilating > every new fact about the requirements into your design. The design > becomes a requirement. > > Which is all dandy, if you had the right design in the first > place. The > problem is, it is very unlikely that you can produce a > requirement-driven design by imposing a design as a driver. This may > seem like an abstruse point to some, but it is one key to preventing > your becoming deaf to what your clients want. > > There are exceptions. You may be doing the fifth in a series of truly > very similar applications. That is a case in which you may > efficiently > start with a design and tweak it. > > Functional decomposition is design, and that is a good reason why you > should avoid it in allocating use cases. Use case analysis > is intended > to produce a description of the behavior of the system, in > other words, > the action of the system. System action is initiated by an actor, who > wants the system to do something, and it is completed when the actor's > goal is met (or has to be abandoned). > > Use case analysis comes in two parts (one of which has been > neglected in > the UML standard, I believe). One part is decomposing the system into > behaviors (which is not the same as functions), and the other part is > describing the network of activities that comprise each behavior. > > The UML gives a good diagram standard for showing the system as a > network of related behaviors. In use case diagrams, actors relate to > use cases by association, and use cases relate to use cases > in a number > of ways, chiefly <<include>> and <<extend>> dependencies. The OMG UML > Spec. gives sufficient definitions for immediate practical use. > > I am comfortable with the definition of an action as an atomic, > indivisible piece of behavior. A use case would then be a network of > actions, which will produce sequences of actions initiated by stimuli > from actors and determined by the network and by current > conditions. On > the face of it, this description suggests that the activity diagram > would be the natural representation of the use case. > > The activity diagram falls short, though, because there is no > clear path > from the semantics of ordinary language used by the client to > the shape > of the diagram. This factor makes perfectly logical activity diagrams > inadequate. In my opinion, the UML should contain a standard for > translating natural language to activity and back. > > One of my reasons for liking Visual Modeling with Rational > Rose 2000 and > UML, by Terry Quatrani, is the fact that Quatrani offers a standard > format for documenting use cases in natural language. The Quatrani > standard forces the developer to express behavior using a pattern of > activity that is applicable to every behavioral requirement > that I have > seen so far. It is not certain that Quatrani's pattern is > optimal, but > you get tremendous leverage by standardizing on any use case > description > standard that is serviceable. > > Describing use cases by using a very small number of generic activity > patterns makes a discipline out of the translation into diagrams of > natural language about system behavior. A discipline can be studied, > optimized, and tooled-up. > > If you know what sort of thing a use case contains, you are better > prepared to divide a system up into use cases. Despite all my > grumblings, it is pretty useful to say that a use case contains > something that is well represented by an activity diagram. > > This diagram should capture activity that is meaningful to > the user as a > single task or a specific goal within the workday. > > At the bottom line, this leads me to favor use cases like "Create > Purchase Order" and "Change Purchase Order," because both the > granularity and the meaning are right. It is artificial to > create a use > case to "Do Purchasing" in order to limit the number of use cases in > your system, but the "Create Purchase Order" granularity should not > produce hundreds of use cases per typical system, anyway. > > Last point: Behavioral decomposition of a system will sometimes > parallel an "obvious" functional decomposition. This parallelism does > not "restore" functional decomposition as a driver of analysis. > > -Eric > > "Kesterton, Anthony" wrote: > > > > I think Haydn has some good points here - I am sure you > will get many other > > comments about this. > > > > regards > > > > anthony > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Sent: 22 October 2001 13:44 > > > To: Manish Didwania > > > Cc: Kesterton, Anthony; [EMAIL PROTECTED]; ROSE_FORUM > > > Subject: Re: (ROSE) Use Case-confusion > > > > > > > > > > > > The naming of the use cases are crucial to the system. In > > > the first email > > > from you, a use case "Purchase Order" is given as an example. > > > However is > > > this "purchase an order" or an actual "purchase order"? Rule > > > of thumb I > > > use is that use cases should be "verb-noun" phrases. > > > > > > In the example with "Maintain Purchase Orders", this is also > > > badly named in > > > my opinion. Words like "Manage", "Maintain" and other vague > > > terminology > > > should really be avoided. A better version would be: > > > > > > > > > Purchase Administrator (Actor) ----> Create Purchase > Order (use case) > > > > > > Two possible alternate paths that could be considered use > > > cases in their > > > own rights could be: > > > Update Purchase Order (use case) -- <<extends>> --> Create > > > Purchase Order > > > Delete Purchase Order (use case) -- <<extends>> --> Create > > > Purchage Order > > > > > > As for "Maintain GatePass" this (from your description) would > > > be best as 2 > > > use cases: > > > > > > "Send Goods" and "Receive Goods". Common sections to these > > > use cases may > > > exist, like getting customer details, which could be pulled > > > out of both and > > > placed in another use case which is included by both of these. > > > > > > The main problem is definitely with the naming of the use > > > cases. We had a > > > use case called "Manage <<something>>", and off this were > > > many includes for > > > all the possibilities including add, delete, update, etc. > > > > > > Functional decomposition should be avoided at all costs. > There's a > > > document in the www.rational.net site that talks about > use cases and > > > functional decomposition. You may want to see this because > > > it certainly > > > turned our project around and many use cases were stripped > > > and renamed and > > > the whole use case diagram suddenly made sense. > > > > > > Haydn > > > > > > > > > > > > > > > > > > > > > "Manish Didwania" > > > > > > <mdidwania@amadeusi To: > > > "Kesterton, Anthony" > > > ndia.net> > > > <[EMAIL PROTECTED]>, "ROSE_FORUM" > > > Sent by: > > > <[EMAIL PROTECTED]> > > > owner-rose_forum@ra cc: > > > > > > tional.com Subject: > > > Re: (ROSE) Use Case-confusion > > > > > > > > > > > > > > > 22/10/2001 12:50 > > > > > > Please respond to > > > > > > "Manish Didwania" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > It is really helpful, but I still have few doubts as I am > > > novice to system > > > designing. I have am designing a module to my existing > > > application First > > > time I decided to do Design using Rational. > > > I am adding a stock control/inventory module. What I have > > > done so far is > > > that I have designed 5 user cases and 2 Actor. > > > > > > Actor 1 (Purchase Admin) > > > link to two user cases > > > Maintain Purchase Orders > > > Maintain Suppliers Data > > > Actor 2 (Store Admin) > > > link to three user cases > > > Maintain Goods Master > > > Maintain Gatepass (to basicly maintain documents for send > > > and receive > > > goods) > > > Execute GatePass (which basicly updates the stock master) > > > > > > And I have put all details like process for > > > updation,deletion, search etc > > > in > > > the documentation. I agree that one should not go in very > > > deep in Use Case. > > > But the approach I have used is correct???? > > > > > > Pls advise. > > > > > > Regards Manish > > > > > > ----- Original Message ----- > > > From: "Kesterton, Anthony" <[EMAIL PROTECTED]> > > > To: "Manish Didwania" <[EMAIL PROTECTED]>; "ROSE_FORUM" > > > <[EMAIL PROTECTED]> > > > Sent: Monday, October 22, 2001 4:03 PM > > > Subject: RE: (ROSE) Use Case-confusion > > > > > > > > > > > > > > Hi > > > > > > > > Different texts disagree about the level you should write > > > the use cases. > > > > General practise here at Rational (guided by people like > > > Ivar Jacobson, > > > our > > > > colleagues from the old Objectory company, and > Rational's general > > > > experience) is that you should keep to the one use case > for Purchase > > > Order, > > > > and not break it down into multiple use case as your > other example > > > suggests. > > > > This all depends on the system you are trying to build > of course :-) > > > > > > > > In general, you should have a small number of use cases for > > > an average > > > level > > > > of functionality system - say 10 use cases. The system > > > with hundreds of > > > use > > > > cases is almost always the wrong level of detail. > > > > > > > > You want to capture a useful end-to-end process in a use case. > > > > > > > > You do not want use cases where they are one step in a > > > daisy-chain of use > > > > cases - all of which need to happen before something > useful happens. > > > This > > > > "form" of use cases is better known as functional > > > decomposition - and is > > > not > > > > the purpose of use cases at all. > > > > > > > > One simple rule-of-thumb (that not everyone agrees with > - but really > > > makes > > > > you think about the level of your use cases) is that you > > > might expect a > > > use > > > > case to take a person-year to complete from idea to tested > > > code. At this > > > > point - the 200 usecase project start to panic until they > > > re-think their > > > use > > > > cases to the right level. > > > > > > > > Hope that helps a little. > > > > > > > > regards > > > > > > > > anthony > > > > > > > > > -----Original Message----- > > > > > From: Manish Didwania [mailto:[EMAIL PROTECTED]] > > > > > Sent: 22 October 2001 09:27 > > > > > To: ROSE_FORUM > > > > > Subject: (ROSE) Use Case-confusion > > > > > > > > > > > > > > > > > > > > I just want to know what is the common practice. In terms > > > of putting > > > > > Activity Diagram in Use Case. > > > > > And at what level one should specify a Use Case. As I was > > > > > reading a book on > > > > > UML it was dividing a Purchase Order Use Case in 4-5 diff use > > > > > case like > > > > > Placing an Order, Cancellation of order and so on. And in > > > rational few > > > > > examples that I had checked they define Use Case for purchase > > > > > Order as one > > > > > Use Case and then specify the activity in documentation. > > > > > > > > > > Thanks Manish > ************************************************************** > ********** > * Rose Forum is a public venue for ideas and discussions. > * For technical support, visit http://www.rational.com/support > * > * Admin.Subscription Requests: [EMAIL PROTECTED] > * Archive of messages: http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rose_forum * ************************************************************************* ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Admin.Subscription Requests: [EMAIL PROTECTED] * Archive of messages: http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rose_forum * *************************************************************************
