Use Cases 

Jim'sPages => StoryProcess => UseCases

Overview

Use Cases are little changed from prior experience on the team.  They still contain narratives that describe user interactions with the system.  They still identify requirements and bridge the requirements into Requisite Pro.

Managing Expectations

While use case documents remain the same, the process changes in that use cases are not completed early.  Use cases start out nearly empty and grow as stories are articulated.  It is not practical to go through a lengthy use case sign-off process every time a story is added to the use case, so the use case review process must change.

Use case sign-off satisfies the customer's need to verify that IT knows what to do.  We replace that with frequent delivery of new features.  A few iterations should establish that domain experts are expressing the needs correctly and developers are meeting them correctly.  When customers trust this process, use case sign-off is not required.

Format

We recommend one essential change in use case format: Put requirements with the flows.  Options considered:

• Put them immediately after the flow.  Shown here.  Strongly recommended.
• Make the step the requirement. A theoretical ideal, but restricts the wording allowed in the steps.
• Put them immediately after the step. Visually disruptive to reading the flow.
• Put them at the end of the document. Very difficult to audit for compatibility with flows.  Strongly discouraged!  

The use case narrative (flows) and the requirements matrix must match!  Some participants in the project may focus on one format, while others focus on the other!

Wording

Why?  Describe the business need for a flow.  Don't just summarize what it does.

Who?  For brevity, just use "user" and "system".  There is an "Actors" section in the template to tell who the users are.  If a flow has different actors than the default flow, repeat an Actors bullet in the flow.

It Depends:  

• A flow may say "displays contract data depending on LOB" 
• Requirements must be specific: "For contract type x, the system displays fields a, b, c ..." 

If the next release adds a new contract type, add a new requirement "For contract type y the system displays fields p, q, r, s ..."

• A flow may say "user selects a referral type; system displays the referral form" 
• Requirements must be specific: "for referral type X the system displays fields a, b, c."  

For each new referral type, add a new requirement!

It Doesn't Depend:  Alternatively FORBID any weasel words like "depending on".  Make explicit LOB references in the flow and the requirements.

Example Flow

Alternate Flow:  Search For Callups

In this scenario, users search for call-ups they want to view or modify.  They may need to view or modify a particular call-up or review a set of call-ups matching some criteria.  For example, a user may update the status of a call-up after doing some work, or review a list of outstanding call-ups for a particular subordinate.  

1. The user selects to search for Call-ups
2. The user enters any one or more of the search fields (listed below.)
3. The system displays a list of matching call-ups sorted by Call-up date. (fields listed below.)
   [The following step is optional, and may be repeated any number of times]
4. The user sorts the results by any column.
   [The following steps are optional, and may be repeated any number of times]
5. The user selects a Call-up Item in the list.
6. If the user requests View the system displays the case for the selected call-up.  See Use Case xxxx.
7. If the user requests Activate the system activates the case for the selected call-up.  See Use Case yyyy.

The system displays a summary list of all call-ups meeting the search criteria.

Requirements

UC123.1 The user shall be able to initiate a call-up search. 

UC123.2 The user shall be able to search for call-ups by: Contract Number, Caller Name, Originating CSC, Assigned CSC, Case ID, and/or Call-up Date Range. 

UC123.3 The system shall display search results containing: Case ID, Contract Number, Product, type or call-up, Calling Party Name, user Name, assigned to user Name, Call-up date, Display Date, and Call-up Priority fields. 

UC123.4 The system shall initially sort the search results ascending by Call-Up Date

UC123.5 The user shall be able to sort the call-up search results in ascending or descending order by any column. 

UC123.6 The user shall be able to view a case selected in the search results.

UC123.7 The user shall be able to reactivate a case selected in the search results.

UC123.8 The system shall display or activate only one case at a time.