• How to Adopt the Use-Case Driven Development Practice

• Key Concepts
• Requirements
• Use Case
• Actor
• Use-Case Model

• Work Products
• Use Case
• Use-Case Model
• System-WideRequirements

• Tasks
• Identify and Outline Requirements
• Detail Use-Case Scenarios
• Detail System-Wide Requirements

• Guidance
• Guidelines
• Detail Use Cases and Scenarios
• Identify and Outline Actors and Use Cases
• Developing System-Wide Requirements Specification
• Use-Cases Realizations

• [Technical Specification]

Many organizations document requirements as a list of declarative statements (or "shall" statements) that lead the team to focus on developing atomic functions and fine-grained assertions of need. Moreover, applications developed from such requirements are often difficult to use and require more time for integration and testing than applications developed using user-focused requirements.

A second, more serious organizational anti-pattern is no focus on requirements at all. Many organizations simply fail to document requirements, leaving it to developers to discern from a perhaps vague vision document, or even nothing more than a meeting or conversation, what the application or system to be developed must do.

This practice shows how to avoid these pitfalls by using use cases and scenarios to capture functional requirements. That approach provides development of usage scenarios that clearly express behavior (or the interaction between users and the system under development). Use cases categorize valuable and useful end-to-end, testable and collaborative behavior in which the system is involved. Non-functional requirements (such as performance, stability, usability, and so on) can still be captured using traditional techniques. This practice also explains how use cases and scenarios are best developed in conjunction with (and used to drive) other development activities, including design and testing.  

The best way to review a practice is to familiarize yourself with the enablement materials, and then review key concepts, work products, tasks, and the more detailed guidance, either by reviewing the guidance category directly, or by navigating from tasks and work products to their related guidance.

You may first want to become familiar with general requirements concepts:

• Requirements

Then become familiar with use cases:

• Use Case
• Actor
• Use-Case Model

This practice focuses on the following work products:

• Use Case
• System-WideRequirements

Both work products go through similar states: they are identified and outlined, which allows them to be prioritized, and then detailed. However, in general, a use case is detailed a scenario at a time. (This is particularly important when following an iterative approach, where a scenario is detailed "just in time" to be implemented, as opposed to the approach of detailing all or most requirements up front). The tasks that drive these states are listed here: Tasks.

In addition, guidelines and tool mentors associated with each task provide details of how to perform the task. Templates and checklists associated with the work products guide you in their completion and evaluation.

Measurements can guide you on assessing how well you are following this practice.

Books and Articles