Practice: Use Case Driven Development
This practice describes how to capture requirements with a combination of use cases and system-wide requirements, and then drive development and testing from those use cases.
Relationships
Purpose

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 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.  

How to read this practice

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 might first want to become familiar with general requirements concepts:

Then become familiar with use cases:

This practice focuses on the following work products:

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.

Be also familiar with the tasks that drive the states above. 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.

Additional Information

Books and Articles

Kurt Bittner and Ian Spence 2003. Use Case Modeling. Addison Wesley Longman.
Comprehensive coverage of use case techniques and practices, including useful examples showing how use-case specifications evolve over time.
Alistair Cockburn 2001. Writing Effective Use Cases. Addison Wesley Longman.
Excellent guidance for those who need to write use cases. Multiple styles and techniques contrasted with insight in an unbiased way. Many helpful tips to improve your use cases.