Requirements Management and the SEI CMM

Requirements Management and the SEI CMM

Requirements management is a key process area (KPA) for SEI CMM Level 2, the repeatable level. The purpose is to "establish a common understanding between the customer and the software project of the customer's requirements that will be addressed by the software project." The customer may be a stakeholder other than the external user, such as the system engineering group, the marketing group, or another internal organization. The CMM views this KPA as managing system requirements that have already been gathered and subdivided into hardware and software requirements. On the other hand, these requirements allocated to software are often just bare bones and must be fleshed out via further requirements-gathering activities with the customer.

The goals for the requirements management KPA, along with related activities, are listed below.


Goal 1: System requirements allocated to software are controlled to establish a baseline for software engineering and management use.

Goal 2: Software plans, products, and activities are kept consistent with the system requirements allocated to software.

Activities Performed

Activity 1: The software engineering group reviews the allocated requirements before they are incorporated into the software project.

1.  Incomplete and missing allocated requirements are identified.

2.  The allocated requirements are reviewed to determine whether they are:

●  feasible and appropriate to implement in software;

●  clearly and properly stated;

●  consistent with each other;

●  testable.

3.  Any allocated requirements identified as having potential problems are reviewed with the group responsible for analyzing and allocating system requirements and necessary changes are made.

4.  Commitments resulting from the allocated requirements are negotiated with the affected groups.

Activity 2: The software engineering group uses the allocated requirements as the basis for software plans, work products, and activities.

Activity 3: Changes to the allocated requirements are reviewed and incorporated into the software project.

Critical Success Factors as Applied to Software Requirements

Requirements are often viewed as a set of critical success factors (CSFs) for a software product. Descriptions of CSFs make the link seen reasonable:

●  Those limited number of areas where "things must go right";

●  Those managerial or enterprise areas that must be given special and continual attention to bring about high performance;

●  Those factors predicting success on projects;

●  Events or circumstances that require the special attention of managers;

●  Those factors in which success is necessary in order that each of the major project participants in a project has the maximum chance of achieving the goals;

●  Achieving quality targets.

There is a temptation to create CSFs with simplistic characteristics, such as "find a solution to the defined problem" but we shouldn't give in because there is too much ambiguity in this sort of definition of success. In order to proceed with requirements specification and design, requirements that will make the project results successful to the user community and other stakeholders need specificity.

CSFs, when clearly identified as critical requirements, can be tested and measured and can assist the analyst with controlling scope-creep. This does not give the analyst license to ignore the additional or remaining requirements, but does keep the project focused on those that were defined as the most significant during this crucial requirements gathering phase. The use of CSFs has been demonstrated to be especially effective in the rapid prototyping, RAD, and spiral models due to the rapidly changing environment of these life cycles.

CSFs are directly related to strategic and business plan objectives and goals. For each critical success factor there is an associated key indicator that provides the measure, and a standard of performance or allowable variance from planned performance. CSFs for software projects are generally thought of as completing certain milestones or other key indicators that provide a reading of performance. For our purposes here, we will limit our discussion to CSFs for the product and keep in mind that some requirements are simply more essential than others. We will use the definitions of CSFs to help identify them. This will come in handy when functions must inevitably be scrubbed or delayed in the prioritization process.


software product, life cycle, software engineering group, software project, csf
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus