When we use the term "Use Cases" on this site, we are probably referring to type of Use Case described by Allistar Cockburn ("co-burn") in his book Writing Effective Use Cases.
- Use cases are a stylized narrative that tell us how the system is suppose to behave.
- Use cases capture contracts between the various stakeholders of a system.
- Use cases describe how actors achieve goals.
- Use cases are requirements, but not all of the requirements.
|Log Facility Isssue||A typical case used to design a workflow in an intranet application.|
|Serialize Access to a Resource||A nuts-and-bolts case used by a development team to create an internal resource.|
|MailReader||A simple set of Use Cases for a simple application.|
- Define Actors and Goals
- Write Use Case Briefs (stories)
- Assign Priorities
- Write a Usage Narrative
- Describe the Main Success Scenario
- Define Failure Conditions
- Describe Failure Handling
- Use simple grammar.
- Show clearly "who has the ball".
- Write from the bird's eye view.
- Show the process moving forward.
- Show the Actor's intent, not the movements.
- Include a "reasonable" set of actions
- "Validate", don't "Check whether".
- Optionally, mention the timing.
- Idiom: "User has System A kick System B".
- Idiom: "Do Steps x-y until condition."
- If an extension simply returns to the next step, then "Return to MSS" can be omitted.
- Extensions can be nested one level deep.
- Extension steps can be numbered using the newer "dot" convention.
- The "System Under Design" can be referred to in the third person.
- If System is going to display the expected screen as the next step, and there are no extensions, a "System presents (expected) screen" step can be omitted.
- A brief one or two sentence description of what the system is trying to accomplish.
- A Vision Statement gives the use cases a "place to stand."
- Defining the design scope of a system is vital.
- A high-level UML drawing of the scope of the system under design can help keep the team on task.
- In any team effort, it's always challenging to keep everyone on topic.
- Keeping a topic board can help keep a group on task.
- Before discussing a topic, the team first needs to decide if the topic is In or Out.
- Before discussing an "Out" topic, the team has to decide to move it to the "In" column.
|Vetting water samples|
|Event driven architecture|
|Active Directory authorization|
- Structuring Use Cases with Goals (online article)
- Writing Effective Use Cases (printed book)