The primary purpose of the Use Case is to capture the required system behavior from the perspective of the end user, to achieve one or more goals. Different users benefit in different ways, of course:

• Customers use them to describe, or at least to approve, the description of the system's behavior.
• Potential users use them to understand the system's behavior.
• Architects use them to identify architecturally significant functionality.
• Developers use them to understand the required system behavior so they can identify classes from the Use Cases' flow of events.
• Testers use them as a basis for identifying a subset of the required Test Cases.
• Managers use them to plan and assess the work for each iteration.
• Technical writers use them to understand the sequence of system behavior that they need to describe in the documentation.

• Analyst

• Analyst
• Developer

• Create Test Cases
• Design the Solution
• Detail Requirements
• Develop the Architecture

• Analyze Architectural Requirements
• Demonstrate the Architecture
• Implement the Solution

• Detail Requirements
• Find and Outline Requirements
• Implement the Solution

• Use-Case Specification

Decide the extent to which you will elaborate on Use Cases:

• Describe only major flows?
• Describe only the most important Use Cases?
• Fully describe preconditions and post-conditions?
• Describe scenarios first, and then raise the level of abstraction by describing Use Case flows?

Some projects apply Use Cases informally to help discover requirements, documenting and maintaining these requirements in another form such as user stories. How you tailor Use Cases may depend on project size, team experience, your tool set, the customer relationship, and so forth. See Guideline: Detail Use Cases and Scenarios for guidance related to documenting Use Cases.

• Use Case

• Use Case