Identifying & Describing Use Cases

Prioritize the candidate list based on user input and importance to the release being built and begin describing the use cases.

Define the use case, considering the system as a black box, and focus on the interaction of the actors with the system. 

Use cases can be represented both textually and graphically. 

Focus on Main Use Cases

Describe the main interactions with the system.  Focus on the priority use cases and on the basic course.  These priority use cases are sequences of events and interactions that contain fundamental information about the system functions. Consider each primary function of the system to:

• document decisions made about the actions and sequence, with a granularity (detailed, high level) depending on the nature of the action (e.g., complexity) and stage of life cycle,
• provide an effective communication vehicle for requirements,
• serve as a set of instructions for the implementation.

Focus on the main interactions in the system.  Start with an external user's interactions with the system (e.g., for a bank, start with deposit cash, withdraw cash). Create a narrative that describes what happens as the system responds to the event. 

Checklist of Questions to use in Defining Use Cases 

 

CHECKLIST OF QUESTIONS TO USE IN DEFINING USE CASES
	Comments
Actors Who are the main actors for the use case?
Preconditions What preconditions must be satisfied before actors can execute their main tasks?
Basic Course What event initiates the use case? (This question is useful for beginning the basic course section.)
What are the main tasks for each actor?
What system information will actors need to access or modify?
Will the actor need to be informed of changes in the system state?
Alternative Courses What sorts of variations on the main tasks are possible?
Exceptions What sort of erroneous behaviour can occur while actors are executing their main tasks?
Postconditions How will the execution of the main tasks change the system state?

Assess your descriptions using the:

 

Guidelines for Discovering Use Cases

 

GUIDELINES FOR DISCOVERING USE CASES
	Yes	No	N/A	Remarks
Is each actor’s requirements documented in a use case? For each actor, human or not, ask yourself the following questions:
· What are the primary tasks that the actor wants the system to perform?
· Will the actor create, store, change, remove, or read data in the system?
· Will the actor need to inform the system about sudden external changes?
· Does the actor need to be informed of certain events in the system?
The answer to the above questions represent the flow of events that identify use case candidates.
Is the flow of events described in sufficient detail? Not all use case candidates constitute separate use cases; some of them may be modelled as variants of one and the same use case. However, sometimes it’s not easy to tell what is a variant and what is, in fact, a separate and distinct use case. As the flow is detailed use cases become clearer.
Have all sources of information been considered? For example, the company may have conducted an analysis of its enterprise, documented in some business processing engineering (BPE) deliverables. BPE documentation is a good source of use cases, since it identifies how the business process will run, and thus how the system should be used. Also, an information system embodies a set of rules that are used to run the business. These rules should be reviewed to discover potential use cases.
Have you tried constructing a state diagram for major objects? Most information systems being built have a few major objects upon which use cases can be based. For example, a Policy Writing System has client and policy, and a Claims System has policy and claim. When trying to discover use cases, it may be helpful to generate a state diagram for each major object. The state diagram views the object from a business perspective and determines the business events that cause the object to change from state to state.
Have you reviewed the use case model, considered other structures for the use case models, iterated and compared the use case model with the object model? There is not one single use case model possible for a system. Indeed, there may be several feasible use case models for the same system. Try developing two or three alternative models, then choose the one you prefer and develop it further. Developing several alternative models also helps you to understand the system better.
Are all documented requirements covered in the use case model? The use cases will define the requirements for the next phase. Ensure that any previously stated requirements (e.g., in the Request for Proposal or standards) are covered.

 

Use Case Quality Checklist

 

USE CASE QUALITY CHECKLIST
	Yes	No	N/A	Remarks
Correctness Does every use case accurately state one or more functional requirements that the system must meet?
Completeness Does the set of use cases capture all functional requirements of the system?
Clarity Are the use cases specified so that they are unambiguous, and have only one interpretation? Terms used to specify actors and events should be defined unambiguously, and included in a data dictionary or glossary.
Consistency Is the set of use cases internally consistent, so that no subset of use cases conflicts with another subset? Consequently, common terms (e.g., specific actors and events) should be defined and used consistently across all use cases.
Is the set of use cases also externally consistent with other OOAD products (e.g., class diagrams, object diagrams, state transition diagrams)?
Verifiability Is there a cost-effective process for determining that the software product satisfies the requirements implied by the use cases? That is, is the specification testable?
Modifiability Does the structure and style of use cases support changes that can be made easily, completely and consistently?
Traceability Do the use cases support both backward and forward traceability? Backward traceability: each use case should reference its source in earlier documents (e.g., business requirements). Forward traceability: each use case should have a unique name and/or reference number to facilitate reference in future OOAD products (e.g., class diagrams, object diagrams, state transition diagrams) and documents (e.g., software design specifications).

  
Use a sequence diagram to show the messages and responses of the objects with each other to complete the sequence.  In analysis, describe the message with descriptive text. As the model is refined, use message names and parameter lists.

Remember that use cases do not define the object model. Return to the object model to review inheritance, examine state transitions, or document flow of control.

Structure the Use Cases

Use cases deal with complexity.  Each use case considers only those objects relevant to the use case.  An object participates in many use cases.  All responsibilities of an object are identified by considering all use cases in which it participates.

Even complex systems can usually be described with a modest number of high-level use cases. These high-level use-cases, of course, can be used to organize as many more detailed use cases as are required.

As the object model gets larger and more complex, use cases may be identified for subsets of the entire model, to refine the interactions and responsibilities of objects at a more detailed level.

Extend to Subordinate Use Cases

A subordinate use case is a sequence of events and interactions that contains supplemental information about the system functions.  The subordinate use case is used to document:

• alternate paths though the sequence,
  
• exceptions,
  
• variations on the main functionality.

Define the subordinate as a complete stand-alone use case documenting the applicable sequence.  Use it to support the main use case, do not repeat the information.

• For each main use case, consider the alternatives.  For example, an application received by mail may have slightly different processing, than an application received in person.
• Identify the main exception processes. For example, applicants for drivers license renewals may have their renewals automatically issued, unless they have outstanding summonses.
• Review the interactions by developing sequence diagrams for the subordinate use cases.