Dashboard > Struts University > Home > Use Cases
Use Cases
Added by Ted Husted, last edited by Ted Husted on Apr 10, 2006  (view change)

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.

In general,

  • 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.

Use Case Development Lifecycle

  1. Define Actors and Goals
  2. Write Use Case Briefs (stories)
  3. Assign Priorities
  4. Write a Usage Narrative
  5. Describe the Main Success Scenario
  6. Define Failure Conditions
  7. Describe Failure Handling

Use Case Guidelines

  • 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.

Supplemental material

Vision Statement

  • 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."

Design Scope UML Drawing

  • 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.

Design Scope Topics (In/Out)

  • 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.
Topic In Out
Vetting water samples  
Event driven architecture  
Tracking reports  
Assembling documents  
Active Directory authorization  


  • Structuring Use Cases with Goals (online article)
  • Writing Effective Use Cases (printed book)
Log Facility Isssue (Struts University)
Requirements (Struts University)
Serialize Access to a Resource (Struts University)

Site running on a free Atlassian Confluence Open Source Project License granted to OSS. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.5 Build:#811 Jul 25, 2007) - Bug/feature request - Contact Administrators