Use-Case Driven Development |  |
This practice describes how use cases can be used to capture requirements and drive design and testing.
Relationships
Contents | How to Adopt this Practice Enablement Key Concepts Work Products Tasks Guidance
Main Description
### Why Adopt this Practice Many organizations document requirements as a list of declarative statements (or "shall" statements) that lead the team to focus on development of 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. ### 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 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 focusses on the following work products: Use Case System-Wide Requirements 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.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright.