In November 1986, the Software Engineering Institute (SEI), at Carnegie-Mellon University, began developing a process maturity framework to help developers improve their software process. In September 1987, the SEI released a brief description of the process maturity framework, later amplified in Watts Humphrey's Managing the Software Process (1989). By 1991, this framework had evolved into what has become known as version 1.0 of the Capability Maturity Model, or CMM. In 1993, version 1.1 of the CMM was released (SEI 1993). Version 1.1 defines five levels of software maturity for an organization and provides a framework for moving from one level to the next, as illustrated in Figure D-1. The CMM guides developers through activities designed to help an organization improve its software process, with the goal of achieving repeatability, controllability, and measurability.

Despite the ongoing debate and controversy about the advantages and disadvantages of the CMM, an accumulating body of data shows that adherence to the CMM and corresponding improvements in software quality have significantly lowered the cost of application development within many companies. By now, the CMM has been in use by many organizations long enough so that meaningful and positive return-on-investment statistics are appearing. These payoffs should, ideally, provide results in productivity and significant reduction in time to market. In an era of increasingly competitive environments, any improvements to software productivity cannot be ignored.

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 D-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 D-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 follows: The purpose of requirements management is to establish a common understanding between the customer and the software team of the customer's requirements.

Figure D-1. CMM maturity levels

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 baseline 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 user community.

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 (other project requirements, including schedule, budget, and other) 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 demonstrate compliance with the CMM process area of requirements management, adequate resources and funding must be provided for managing requirements. Members of the software engineering group and other affected groups should be trained to perform their requirements-management activities. Training should cover methods and standards, as well as training activities designed to create an understanding on the part of the engineering team as to the unique nature and problems of the application domain.

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 sort often prescribed in the waterfall methodologies of the 1970s. With the CMM, requirements are living entities at the very center of the application development process. Not surprisingly, the process of effective requirements management appears at virtually all levels of the process model and within many key process areas. As an organization moves to level 3 on the CMM scale, the focus is on managing software activities based on defined and documented standard practices. Key process areas for level 3 include organization process focus, organization process definition, training program, integrated software management, software product engineering, intergroup coordination, and peer reviews. The software product engineering key practice is designed to cause an organization to integrate all software engineering activities to produce high-quality software products effectively and efficiently. The software engineering key practice states that the "software requirements are developed, maintained, documented, and verified by systematically analyzing the requirements according to the project's defined software process" (SEI 1993).

The analysis process is necessary to ensure that the requirements make sense and are clearly stated, complete and unambiguous, consistent with one another, 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 traceability. 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 subsequent engineering activity. Requirements traceability provides a means of analyzing impact before a change is made, as well as a way to determine what components are affected when processing a change. Traceability also provides the mechanism for determining the adequacy of test coverage.

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 that

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 do requirements management. The detailed activities of eliciting, organizing, documenting, and managing requirements are the subject of this book, and these activities have been influenced by the CMM framework.

For the past decade or so, a number of organizations around the world have been using a series of quality management standards known as ISO 9000 to improve operating efficiency and productivity and to reduce costs. ISO 9000 has been adopted by the European Community as EN29000 and has become an important fact for international trade; organizations wishing to do business in Europe, for example, often have to demonstrate ISO 9000 certification. The certification requires an on-site assessment by an ISO-approved assessor; the companies that pass realize that they will be reassessed periodically to maintain their certification.

ISO 9000 consists of five quality standards:

Within these documents, ISO 9000-3 provides guidelines for the application of the ISO 9001 "design and development" standard for the development, supply, and maintenance of software. Part 5.3 of that document stipulates "In order to proceed with development, the supplier should have a complete, unambiguous set of functional requirements." The same document also stipulates that the information thus provided to the supplier (which we've described as the "developer" throughout this appendix) should include all performance, safety, reliability, security, and privacy requirements that collectively determine whether the delivered system is acceptable.

Like the CMM, ISO 9000 standards have been the subject of considerable debate, particularly in U.S. organizations that worry about the possibility of the standards degenerating into a bureaucratic demand for excessive documentation. Our purpose here is not to endorse or attack ISO 9000; like all such "common sense" concepts, it can be used or misused. But to the extent that many organizations are adopting ISO 9000 because they think it's a good idea or because it's a necessary prerequisite for doing business in Europe and other parts of the world, it's interesting to note the emphasis that the standard puts on requirements management. For example, ISO 9000 emphasizes the need for mutual cooperation between the customer and the developer for software systems; specifically, it calls for

Although it's easy to dismiss all of this as "obvious" and "common sense," remember what happens during the assessment required to achieve certification. An assessor will visit the organization and ask, "Where are your methods and procedures for approving changes to the requirements? Show them to me in writing. Let me visit some project teams and make some spot-checks to ensure that the procedures are actually being followed."

ISO 9000 also stipulates that the input to the development phase of a project—the lifecycle activity in which technical design and programming usually take place—should be defined and documented. These "inputs" are, of course, requirements, and ISO 9000 states that the requirements should be defined so that their achievement can be verified. ISO 9000 also calls for processes to ensure that incomplete, ambiguous, or conflicting requirements will be resolved in an orderly fashion. One of the important consequences of this kind of emphasis on requirements at the beginning of a development effort is that it helps ensure that, if the technical design and development efforts are carried out in a disciplined fashion, it will be possible to produce a system that meets specifications, or requirements, rather than relying on frantic testing and validation activities at the end of the lifecycle for assurance of quality.

Like the SEI-CMM, ISO 9000 doesn't tell us how to do requirements management. The fact that we have an official process that forces us to choose an "official" user representative and an "official" developer to discuss the requirements of a system obviously doesn't guarantee that these two individuals will be capable of identifying and documenting the correct requirements. But armed with the procedures and techniques described in other chapters of this book, we should be able to create a comprehensive requirements management approach that will satisfy the most demanding of ISO 9000 assessors, as well as CMM assessors.