A use case defines a set of use case instances.
A use case models how a user or subsystem (AKA Actor) might use the system and is generally used to communicate with stakeholders.
Related, interestingly, to change cases.
The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. See: use case instances.
More detailed description:
A use case is a step-by-step description of the user's (actor's) actions (stimuli) and the software reactions. The beauty of use cases is that they describe the system in a great level of detail so they can be directly used to model the application, yet they are written in plain language so the every day user can understand them. In fact, users (customers) can approve whether a use case is correct and she can even work on the Use Case.
Sample Use Cases online: http://www.rational.com/products/rup/resource_center/use_cases_in.jtmpl
A collection of Use Case articles on the Web: http://www.pols.co.uk/use-case-zone/use-case-papers.html
Great collection of use case articles online: http://www.pols.co.uk/usecasezone/use-case-papers.htm
Use Cases Tutorial: http://www.parlezuml.com/tutorials/usecases.htm
Use cases transition to design
Use cases are always written using a use case template. This is one of several types of UML templates.
Note: Use cases are mostly for specifying functional requirements. They don't really help to spec non functional requirements. Non-functional requirements should probably live in their own dedicated document. -- Andre Payette
Change cases, a variant of use cases, are a decent way to capture some of the architectural non functional requirements.-- Steven Black
At the heart of it, a use case is a restatement of the functional requirements, authored by developers for review by stakeholders. They are a great way to make stakeholders feel that the developers know what to build.
Also: A use case describes how a system is used from an external point of view, but not how the system interacts with itself from an internal point of view.
See use case diagram
Why produce Use Cases?
- Customers use the use cases to understand the system, approve the use case's flow of events, and approve the result of use-case modeling.
- Users use the use case to understand the system.
- Architects use the use cases to identify architecturally significant functionality.
- Developers, use the use case to understand the required system behavior and to refine the system.
- Analysts use the use cases' flows of events to find classes.
- Testers use the use cases to plan testing.
- Documentation writers use the use cases to understand the sequence of descriptibe documentation.
So for just plain writing the individual use case descriptions, do you just use Word? Are there templates for that? Is there any link between this written text and the diagrams?
Yes, a number of templates are available for use cases and Rational Software has a product called Requisite Pro that does a good job of managing requirements that come out of use cases.-- Steven Black
When using use-cases, keep in mind that use cases are not object oriented. They are, for the most part, algorithmic oriented. Yet, because this very same reason, they are usually very clear to the stake holders. Stake holders are usually interested in "when will I be able to perform this particular function of the system" type of questions.
One you have your use cases you can start designing the system using an object oriented approach (e.g. define classes and responsibilities)
An advantage of using use cases is that you can carry them all the way through the software development process (no matter which one you are using.) For example, use cases can be used to estimate cost of the project, to plan iterations, to develop testing plan. Due to the fact that the stake holders feel very comfortable with use cases -i.e. they almost understand them :) -you can tell them that your team is testing this particular use case and they can relate to that piece of the software. -- Hector Correa
I haven't seen this book recommended that much but I think it is an excellent book that teaches much more than the title suggests. When it comes to OOA/D, Craig Larman is one smart dude.
'Applying UML and Patterns: An Introduction to Object - Oriented Analysis and Design and the Unified Process'
When writing use cases, it is important to keep in mind that you are not supposed to be writing steps that say what the user does and what the system does. Instead, you are supposed to be writting the user's intention and the system's visible response. The difference is subtle, but important. It is explained in my use case tutorial and templates: http://www.readysetpro.com/
Category UML, Category Use Case
( Topic last updated: 2005.03.21 04:09:54 AM )