Artifact: Use Case
This artifact defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.
Work Product Kinds: Model Element
Extends: Software Requirement

The primary purpose of the Use Case is to capture the required system behavior from the perspective of the end-user in achieving one or more desired goals. Use Cases are used for many different roles for many purposes, including:

  • By Customers to describe-or at least approve-the description of the system's behavior.
  • By potential users to understand the system's behavior.
  • By Software Architects to identify architecturally significant functionality.
  • By people who analyze, design, and implement the system to understand the required system behavior and to refine the system definition.
  • By designers to identify classes from the use cases' flows of events.
  • By Testers as a basis from which to identifying a subset of the required test cases.
  • By Managers to plan and assess the work for each iteration.
  • By Documentation writers to understand the system behavior from the perspective of the sequence of use that should be described in the documentation (such as the system user guide).
Brief Outline

The template provided for a Use-Case Specification contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use case properties. 

Representation Options

UML Representation: Use Case (first-class UML element)

A use case consists primarily of a textual specification (called a Use-Case Specification) that contains a description of the flow of events describing the interaction between actors and the system. The specification also typically contains other information such as preconditions, postconditions, special requirements and key scenarios. The use case may also be represented visually in UML in order to show relationships with other use cases and actors. 

A Use Case Specification may have the following properties:

  • Name: The name of the use case.
  • Brief Description: A brief description of the role and purpose of the use case. 
  • Flow of Events: A textual description of what the system does in regard to the use case (not how specific problems are solved by the system). The description is understandable by the customer. 
  • Special Requirements: A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.  
  • preconditions: A textual description that defines a constraint on the system when the use case may start.    
  • postconditions: A textual description that defines a constraint on the system when the use cases have terminated.   
  • Extension points: A list of locations within the flow of events of the use case at which additional behavior can be inserted using the extend-relationship.    
  • Relationships: The relationships, such as communicates-associations, include-, generalization-, and extend-relationships, in which the use case participates.     
  • Activity Diagrams: These diagrams illustrate the structure of the flow of events.    
  • Use-Case Diagrams: These diagrams show the relationships involving the use case.     
  • Other Diagrams: Other graphical illustrations of the use case.   

It is important to decide the extent to which Use Cases will be elaborated:

  • describe only major flows?
  • describe only the most important use cases?
  • fully describe preconditions and postconditions?

Some projects apply use cases informally to discover requirements, but document and maintain these requirements in another form. How you tailor Use Cases may depend on project size, experience, your tool set, customer relationship, and so forth. See Guideline: Use Case for guidance related to Use Case tailoring.

More Information