Artifacts > Requirements Artifact Set > Use-Case Model... > Use Case


Use Case

 A use case 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.
UML representation: Use Case
Role: Requirements Specifier
Templates:
Enclosed in: Software Requirements Specification
Sample Reports:
Examples:
More information:

Input to Activities: Output from Activities:

Purpose To top of page

The following people will use the use cases:

  • Customers will use the use cases to understand the system's behavior, and, since they must approve the use case's flow of events, customer will also use the use cases to approve the result of use-case modeling.
  • Potential users will use the use case to understand the system's behavior.
  • Software Architects will use the use cases to identify architecturally significant functionality.
  • People who analyze, design, and implement the system will use the use case to understand the required system behavior and to refine the system.
  • Use-case designers will use the use cases' flows of events to find classes. (These are the most important artifacts for use-case designers.)
  • Testers will use the use cases as a base for identifying test cases.
  • Managers will use the use cases to plan and follow up the use-case modeling.
  • Documentation writers will use the use cases to understand what sequence of use should be described in the documentation (such as the system user guide).

Properties To top of page

Property Name

Brief Description

UML Representation
Name The name of the use case. The attribute "Name" on model element.
Brief Description A brief description of the role and purpose of the use case. Tagged value, of type "short text".
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. Tagged value, of type "formatted text".
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. Tagged value, of type "short text".
preconditions A textual description that defines a constraint on the system when the use case may start. Tagged value, of type "short text".
postconditions A textual description that defines a constraint on the system when the use cases have terminated. Tagged value, of type "short text".
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. Tagged value, of type "short text".
Relationships The relationships, such as communicates-associations, include-, generalization-, and extend-relationships, in which the use case participates. Owned by an enclosing package, via the aggregation "owns".
Activity Diagrams These diagrams illustrate the structure of the flow of events. Participants are owned via the aggregation "types" and "relationships" on a collaboration traced to the use case.
Use-Case Diagrams These diagrams show the relationships involving the use case. Participants are owned via the aggregation "types" and "relationships" on a collaboration traced to the use case.
Other Diagrams Other graphical illustrations of the use case. Tagged value, of uninterpreted type.

Brief Outline To top of page

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.  

The diagrams of the use case can be developed in a visual modeling tool, such as Rational Rose. A use-case report (with all properties) may be generated with Rational SoDA.  

For more information, see tool mentors: Managing Use Cases using Rational Rose and Rational RequisitePro and Creating a Use-Case Report using Rational SoDA. 

Timing To top of page

Use cases are identified and possibly briefly outlined early in the inception phase, to help in defining the scope of the system. The use cases that are relevant for the analysis or the architectural design of the system are then described in detail within the Elaboration phase. The remaining use cases are described in detail within the Construction phase.

Responsibility To top of page

A requirements specifier is responsible for the integrity of the use case, which ensures that:

  • the use case fulfills its requirements (that is, it correctly describes the functionality that is relevant to the use case, and only this functionality)
  • the flow of events is readable and suit its purpose
  • the use-case relationships originating from the use case are justified and kept consistent
  • the role of the use case where it is involved in communicates-associations is clear and intuitive
  • the diagrams describing the use case and its relationships are readable and suit their purpose
  • the special requirements are readable and suit their purpose
  • the preconditions are readable and suit their purpose
  • the postconditions are readable and suit their purpose

It is recommended that the requirements specifier who is responsible for a use case is also responsible for its enclosing use-case package. For more information, refer to Guidelines: Use-Case Package.

Tailoring To top of page

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 Guidelines: Use Case for guidance related to Use Case tailoring.  Document tailoring decisions in the Artifact: Use Case Modeling Guidelines.


Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process