This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello folks, I have a question concerning use cases. I have seen that some people write only the user actions, and the system's reply (with the argument that requirements are defined from the view point of the actor), while others write the steps involved to "calculate" the reply, since the system usually requires several steps before generating the reply. (Both are from "professional people")- What is the standard way of doing it? I just want to have use cases in a school report and I would include the sequence diagram showing how the different objects in the system interact to solve the problem. Thanks you!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
Originally posted by Tonny Tssagovic: What is the standard way of doing it?
There is no standard way, because every project and every team has different needs. What formatlity you need depends on many things: what you are doing them for, on colaboration constraints, risk of the project etc. For some teams, a couple of words on an index card is all they need. Others feel they need to write pages of formal descriptions.
Sometimes you'll see a use case step reference other documents like a "business rules repository." You might see something like this: user selects "calculate total" system calculates total (See BR1234 for calculation rules) system displays total This is a neat way to keep your use case at a "consistent level of abstraction" and that's one of my criteria for easy communication in documents, code, IRS forms, etc.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I don't think anyone answered the original question. What appears to be the most commonly accepted narrative form for use cases is one that is in the form of "the user does this; then the [application] does this." For example, "the clerk scans an item; the POS station displays the scanned item name and price." Use cases answer the question, "How does the user interact with the system?" By only supplying the user actions, you would only be presenting half of the story. Be careful not to supply implementation details in the use case document. -Jeff- [ March 04, 2004: Message edited by: Jeff Langr ]