The best practice of requirements management is captured in the Rational Unified Process in the requirements discipline , one of nine core disciplines described in the process. This requirements discipline produces and updates the artifacts shown in Figure E-2.
Figure E-2. Requirements discipline
Many of these artifacts are consistent with those described in this book, including the following:
Other artifacts are also developed as a result of this discipline, including
Workers involved in this discipline include
The description of the requirements discipline activities and steps is organized in the Rational Unified Process into six smaller disciplines (called discipline details ), which parallels many of the team skills described in this book.
Analyzing the Problem
As shown in Figure E-3, the purpose of this discipline detail is to
Figure E-3. Analyzing the problem
This discipline detail may be revisited several times during inception and early elaboration. As requests from stakeholders are more clearly understood , both business process solutions and technical solutions will evolve .
The primary activity in this discipline is to develop the Vision document, which identifies the high-level user or customer view of the system to be built. In the Vision document, initial requirements are expressed as key features the system must possess in order to solve the most critical problems. The features should be assigned attributes, such as rationale, relative value or priority, source of request, and so on, so that dependencies can begin to be managed. As the vision develops, the system analyst identifies users and system interfaces ”the actors of the system.
Understanding User and Stakeholder Needs
The purpose of this discipline detail is to elicit and collect information from stakeholders of the project (Figure E-4). The collected stakeholder requests can be regarded as a "wish list" that will be used as primary input to defining the use-case model, use cases, and supplementary specification. Typically, this is performed only during iterations in the inception and elaboration phases.
Figure E-4. Understanding user and stakeholder needs
The key activity is to elicit stakeholder requests . The primary outputs are collection(s) of prioritized stakeholder requests, which enable refinement of the Vision document, as well as a better understanding of the requirements attributes. Also, during this discipline, you may start discussing the system in terms of its use cases and actors. Another important output is an updated glossary of terms to facilitate a common vocabulary among team members.
Defining the System
The purpose of this discipline detail (Figure E-5) is to
Figure E-5. Defining the system
Typically, this is performed only in iterations during the inception and elaboration phases.
Problem analysis and understanding stakeholder needs create early iterations of key system definitions, including the Vision document, a first outline to the use-case model, and the requirements attributes. In defining the system, you focus on identifying actors and use cases more completely and adding supplementary specifications.
The purpose of this discipline detail (Figure E-6) is to
Figure E-6. Managing the scope of the system
Although project scope should be managed continuously, the better understanding of system functionality obtained from identifying most actors, use cases, and supplementary specifications will allow the system analyst to apply priority, effort, cost, risk values, and so on to requirements attributes more accurately and will enable the architect to identify the architecturally significant use cases. An input to managing scope not seen in other discipline details of the requirements discipline is the iteration plan , developed in parallel by project and development management. The iteration plan defines the number and frequency of iterations planned for the release. The scope of the project defined in managing scope will have a significant impact on the iteration plan since the highest-risk elements within scope will be planned for early iterations. Other important outputs from managing scope include the initial iteration of the software architecture document and a revised Vision document that reflects the system analyst's and key stakeholders' better understanding of system functionality and project resources.
Refining the System Definition
The purpose of this discipline detail (Figure E-7) is to further refine the requirements in order to
Figure E-7. Refining the system definition
Refining the system begins with use cases outlined, actors described at least briefly , and a revised understanding of project scope reflected in reprioritized features in the vision and believed to be achievable by fairly firm budgets and dates. The output of this discipline is more in-depth understanding of system functionality expressed in detailed use cases, revised and detailed supplementary specifications, and user interface elements.
Managing Changing Requirements
The purpose of this discipline detail (Figure E-8) is to
Figure E-8. Managing changing requirements
Changes to requirements naturally impact the models produced in the analysis and design discipline, as well as the test model created as part of the test discipline. Traceability relationships between requirements identified in the manage dependency activity of this discipline and others are the key to understanding these impacts.
Another important concept is the tracking of requirements history. By capturing the nature and rationale of requirements changes, reviewers (in this case, the role is played by anyone on the software project team whose work is affected by the change) receive the information needed to respond to the change properly.