Requirements Management

a key process area for level 2: Repeatable

The purpose of Requirements Management 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.

Requirements Management involves establishing and maintaining an agreement with the customer on the requirements for the software project. This agreement is referred to as the "system requirements allocated to the software." The "customer" may be interpreted as the system engineering group, the marketing group, another internal organization, or an external customer. The agreement covers both the technical and nontechnical (e.g., delivery dates) requirements. The agreement forms the basis for estimating, planning, performing, and tracking the software project's activities throughout the software life cycle.

The allocation of the system requirements to software, hardware, and other system components (e.g., humans) may be performed by a group external to the software engineering group (e.g., the system engineering group), and the software engineering group may have no direct control of this allocation. Within the constraints of the project, the software engineering group takes appropriate steps to ensure that the system requirements allocated to software, which they are responsible for addressing, are documented and controlled.

To achieve this control, the software engineering group reviews the initial and revised system requirements allocated to software to resolve issues before they are incorporated into the software project. Whenever the system requirements allocated to software are changed, the affected software plans, work products, and activities are adjusted to remain consistent with the updated requirements.

Goals

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.

Commitment to perform

Commitment 1 -- The project follows a written organizational policy for managing the system requirements allocated to software.

The system requirements allocated to the software are referred to as "allocated requirements" in these practices.

The allocated requirements are the subset of the system requirements that are to be implemented in the software components of the system. The allocated requirements are a primary input to the software development plan. Software requirements analysis elaborates and refines the allocated requirements and results in software requirements which are documented.

This policy typically specifies that:

The allocated requirements are documented.
The allocated requirements are reviewed by:
- the software managers, and
- other affected groups.
  Examples of affected groups include:
  - system test,
  - software engineering (including all subgroups, such as software design),
  - system engineering,
  - software quality assurance,
  - software configuration management, and
  - documentation support.
The software plans, work products, and activities are changed to be consistent with changes to the allocated requirements.

Ability to perform

Ability 1 -- For each project, responsibility is established for analyzing the system requirements and allocating them to hardware, software, and other system components.

Analysis and allocation of the system requirements is not the responsibility of the software engineering group, but is a prerequisite for their work.

This responsibility covers:

Managing and documenting the system requirements and their allocation throughout the project's life.
Effecting changes to the system requirements and their allocation.

Ability 2 -- The allocated requirements are documented.

The allocated requirements include:

The nontechnical requirements (i.e., the agreements, conditions, and/or contractual terms) that affect and determine the activities of the software project.
Examples of agreements, conditions, and contractual terms include:
- products to be delivered,
- delivery dates, and
- milestones.
The technical requirements for the software.
Examples of technical requirements include:
- end user, operator, support, or integration functions;
- performance requirements;
- design constraints;
- programming language; and
- interface requirements.
The acceptance criteria that will be used to validate that the software products satisfy the allocated requirements.

Ability 3 -- Adequate resources and funding are provided for managing the allocated requirements.

Individuals who have experience and expertise in the application domain and in software engineering are assigned to manage the allocated requirements.
Tools to support the activities for managing requirements are made available.
Examples of support tools include:
- spreadsheet programs,
- tools for configuration management,
- tools for traceability, and
- tools for test management.

Ability 4 -- Members of the software engineering group and other software-related groups are trained to perform their requirements management activities.

Examples of training include:

the methods, standards, and procedures used by the project, and
the application domain.

Activities performed

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

Incomplete and missing allocated requirements are identified.
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, and
- testable.
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.
Commitments resulting from the allocated requirements are negotiated with the affected groups.
Examples of affected groups include:
- software engineering (including all subgroups, such as software design),
- software estimating,
- system engineering,
- system test,
- software quality assurance,
- software configuration management,
- contract management, and
- documentation support.
Refer to Activity 6 of the Software Project Planning key process area for practices covering negotiating commitments.

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

The allocated requirements:

Are managed and controlled.
"Managed and controlled" implies that the version of the work product in use at a given time (past or present) is known (i.e., version control), and changes are incorporated in a controlled manner (i.e., change control).
If a greater degree of formality than is implied by "managed and controlled" is desired, the work product can be placed under the full discipline of configuration management, as is described in the Software Configuration Management key process area.
Are the basis for the software development plan.
Are the basis for developing the software requirements.

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

The impact to existing commitments is assessed, and changes are negotiated as appropriate.
- Changes to commitments made to individuals and groups external to the organization are reviewed with senior management.
  Refer to Activity 4 of the Software Project Planning key process area and Activity 3 of the Software Project Tracking and Oversight key process area for practices covering commitments made external to the organization.
- Changes to commitments within the organization are negotiated with the affected groups.
Refer to Activities 5, 6, 7, and 8 of the Software Project Tracking and Oversight key process area for practices covering negotiating changes to commitments.
Changes that need to be made to the software plans, work products, and activities resulting from changes to the allocated requirements are:
- identified,
- evaluated,
- assessed for risk,
- documented,
- planned,
- communicated to the affected groups and individuals, and
- tracked to completion.

Measurement and analysis

Measurement 1 -- Measurements are made and used to determine the status of the activities for managing the allocated requirements.

Examples of measurements include:

status of each of the allocated requirements;
change activity for the allocated requirements; and
cumulative number of changes to the allocated requirements, including total number of changes proposed, open, approved, and incorporated into the system baseline.

Verifying implementation

Verification 1 -- The activities for managing the allocated requirements are reviewed with senior management on a periodic basis.

The primary purpose of periodic reviews by senior management is to provide awareness of and insight into software process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.

Refer to Verification 1 of the Software Project Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.

Verification 2 -- The activities for managing the allocated requirements are reviewed with the project manager on both a periodic and event-driven basis.

Refer to Verification 2 of the Software Project Tracking and Oversight key process area for practices covering the typical content of project management oversight reviews.

Verification 3 -- The software quality assurance group reviews and/or audits the activities and work products for managing the allocated requirements and reports the results.

Refer to the Software Quality Assurance key process area.

At a minimum, these reviews and/or audits verify that:

The allocated requirements are reviewed, and problems are resolved before the software engineering group commits to them.
The software plans, work products, and activities are appropriately revised when the allocated requirements change.
Changes to commitments resulting from changes to the allocated requirements are negotiated with the affected groups.

[^^] Table of contents [->] Forward one chapter