The Rational Unified Process defines flows of information, transformations, guidelines, heuristics, and formal traceability links that tie these artifacts to other software development activities and artifacts. For example, the requirements artifact may be tied upstream in the process to a business model,
Software engineering tools support many of the best practices presented in the Rational Unified Process ”from requirements management and visual modeling to report generation, configuration management, and automated testing. Tool mentors are also included, which provide detailed descriptions on how Rational's software tools can be used to support particular steps and activities within the process.
Appendix F. Requirements Management in the SEI-CMM and within ISO 9000:2000
Requirements Management in the SEI-CMM
Requirements Management in ISO 9000:2000
Requirements Management in the SEI-CMM
In November 1986, the Software Engineering Institute (SEI) at Carnegie-Mellon University
Figure F-1. CMM maturity levels
Despite the ongoing debate and controversy about the advantages and disadvantages of the CMM, an
The CMM provides a framework for process improvement that consists of "key process areas," or organizational activities that have been found, through experience, to be influential in various aspects of the development process and resultant software quality. Table F-1 identifies the key process areas of each of the five levels of the CMM. (The reason we're discussing all of this at length in this book is that Table F-1 shows that the first key process area that must be addressed to move from level 1 to level 2 is requirements management.)
The CMM summarizes the process area of requirements management as
This common understanding serves as the basis of agreement between the customer and the development team and, as such, is the central document that defines and controls the activity to follow. Requirements are controlled to establish a
for software engineering management use. Throughout the CMM, guidelines specify that all activities, plans, schedules, and software work products are to be developed and modified as necessary to be consistent with the requirements allocated to software. In this manner, the CMM moves the organization toward an integrated view wherein technical requirements must be kept consistent with project plans and activities. To support this process, software requirements must be documented and reviewed by software managers and affected groups, including representatives of the customer and
Table F-1. Levels of the CMM with Key Process Areas
The software requirements specification serves as a central project document, a defining element with relationships to other elements of the project plan. The requirements include both technical (the behavior of the application) and nontechnical (for example, schedule and budget) requirements.  In addition, acceptance criteria, which are the tests and measures that will be used to validate that the software meets its requirements, must be established and documented.
In order to accomplish these objectives and to
The CMM further specifies that requirements should be managed and controlled and should serve as the basis for software plans, work products, and activities. Changes to the requirements should be reviewed and incorporated into the project plans, and the impact of change must be assessed and negotiated with the affected groups. In order to provide feedback on the results of these activities and in order to verify compliance, the CMM provides guidelines for measurements and analysis, as well as activities for verifying implementation. Suggested measures include
One of the most enlightened aspects of the CMM is its understanding that requirements management is not simply a "document-it-up-front-and-go" process of the
The analysis process is necessary to ensure that the requirements make sense and are clearly stated, complete and unambiguous, consistent with one an other, and testable. Various analysis techniques are suggested, including simulations, modeling, scenario generation, and functional and object-oriented decomposition. The results of this process will be a better understanding of the requirements of the application, which are then reflected in revised requirements documentation. In addition, the group responsible for system and acceptance testing also analyzes the requirements to ensure testability.
The resulting software requirements document is reviewed and approved by the affected parties to make sure that the points of view represented by these parties are included in the requirements. Reviewers include customers and end users, project management, and software test personnel. In order to manage change in a controlled way, the CMM also calls for placing the software requirements document under configuration management control.
Another important concept in the CMM is
. Under the CMM, all worthwhile software work products are documented, and the documentation must be maintained and readily available. The software requirements, design, code, and test cases are traced to the source from which they were derived and to the products of the
All approved changes are tracked to completion. The documentation that traces the allocated requirements is also managed and controlled. Measurements are made to determine the functionality and the quality of the software products and to determine the status of the software activity. Example measurements include
Finally, the CMM recognizes that change is an integral part of software activity in any development project. In place of frozen specifications, we instead strive for a stable baseline of requirements that are well elicited, documented, and placed into systems that provide support for managing change. Specifically, the CMM requires the following.
In summary, the CMM provides a comprehensive view of the activities that must be applied to improve software quality and to increase productivity. Requirements management is an integral part of this process, wherein requirements serve as living entities that are at the center of development activity. Once elicited, requirements are documented and managed with the same degree of care that we provide to our code work products. This process puts the team in control of its project and helps team members manage both the project and its scope. Lastly, actively managing changing requirements keeps the project under control and helps ensure the reliable, repeatable production of high-quality software products.
Although all of this provides an important "validation" of the concept of requirements management, along with some high-level advice for inserting requirements-oriented processes into the development lifecycle, it doesn't tell us how to
requirements management. The detailed activities of