Dashboard > Struts University > Home > Use Cases > Information > Page Comparison
Use Cases
Version 7 by Ted Husted
on Oct 14, 2005 12:10.


compared with
Current by Ted Husted
on Apr 10, 2006 03:47.

(show comment)
 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first 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|http://www.amazon.com/exec/obidos/tg/detail/-/0201702258/apachesoftwar-20/].
  
 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 describe how actors achieve goals.
 * Use cases are requirements, but not *all* of the [requirements|Requirements].
  
 h2. Examples
  
 ||[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|MailReader Use Cases]| A simple set of Use Cases for a simple application. |
  
 h2. Use Case Development Lifecycle
  
 # 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
  
 h2. 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."
  
 h2. Defaults
 * 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.
  
 h2. Supplemental material
  
 h3. 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."
  
 h3. 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.
  
 h3. 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 | |(*b)|
 |Event driven architecture |(*g)| |
 |Tracking reports |(*g)| |
 |Assembling documents |(*g)| |
 |Active Directory authorization | |(*b)|
  
 h2. References
 * [Structuring Use Cases with Goals|http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm] (online article)
 * [Writing Effective Use Cases|http://www.amazon.com/exec/obidos/tg/detail/-/0201702258/apachesoftwar-20/] (printed book)
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