Sign In
App icon


Available Now!
Get the App
Click Here to Continue Browser Session   ❯

Requirements Management

image of people interacting with post-it notes on wall


The Requirements Management process maintains a current and approved set of requirements over the entire acquisition life cycle. This helps ensure delivery of a capability that meets the intended mission performance, as stipulated by the operational user.

User Needs

The end-user needs are usually identified in operational terms at the system level during implementation of the Stakeholder Requirements Definition and Requirements Analysis processes (see DAG CH 3–4.2.1. Stakeholder Requirements Definition Process and 4.2.2. Requirements Analysis Process, respectively). Through the Requirements Management process, the Systems Engineer tracks requirement changes and maintains traceability of end-user needs to the system performance specification and, ultimately, the delivered capability. As the system design evolves to lower levels of detail, the Systems Engineer traces the high-level requirements down to the system elements through the lowest level of the design.


Requirements Management provides bottom-up traceability from any derived lower-level requirement up to the applicable source (system-level requirement) from which it originates. This bi-directional traceability is the key to effective management of system requirements. It enables the development of an analytical understanding of any system-wide effects of changes to requirements for a given system element, updating requirements documentation with rationale and impacts for approved changes.

At the same time, bi-directional traceability ensures that approved changes do not create any "orphaned" lower-level requirements (i.e., that all bottom-up relationships to applicable system-level requirements remain valid after the change). Bi-directional traceability also ensures that higher-level requirements are properly flowed to lower-level requirements and system element designs so that there are no "childless parent" higher-level requirements (i.e., each high-level requirement is ultimately being addressed by lower-level requirements and system element designs).


Robust Requirements Management, implemented in synchronization with the program’s Configuration Management process (see DAG CH 3–4.1.6. Configuration Management Process), can help the program to avoid or mitigate unintended or unanticipated consequences of changes through rigorous documentation of the system performance specification. Thoughtful analysis and management of requirements can help lay the foundation for system affordability.

Requirements Management Activities and Products

Role of the PM and SE

The Program Manager (PM) should keep leadership and all stakeholders informed of cost, schedule and performance impacts associated with requirement changes and requirements growth.

The Systems Engineer establishes and maintains a Requirements Traceability Matrix (RTM), which captures all the requirements in the system performance specification, their decomposition/derivation and allocation history and rationale for all entries and changes. The requirements should be:

  • Traceable to and from the stated end-user needs.
  • Correctly allocated, with potential effects of proposed changes fully investigated, understood and communicated to the PM.
  • Feasibly allocated, i.e., lower-level system elements cannot have the same or wider tolerance bands as those of the higher-level system elements into which they are incorporated.

Requirements Changes

All affected stakeholders and decision makers should fully understand the effects of proposed changes to requirements at the system or system element level before they accept any changes for incorporation into the design. The RTM provides significant benefits during trade-off analysis activities, since it captures the system-wide effects of proposed changes to established requirements.

In accordance with DoDI 5000.02, para 5.d.5.b, Component Acquisition Executives (CAE) establish Configuration Steering Boards (CSB), following Capability Development Document (CDD) validation, for Acquisition Category (ACAT) I and IA programs in development, production and sustainment. The CSB reviews all requirements changes and any significant technical configuration changes that have the potential to result in cost and schedule impacts to the program. In a continuous effort to reduce Total Ownership Cost (TOC), the PM, in consultation with the Program Executive Officer (PEO) and requirements sponsor, will identify and propose to the CSB recommended requirements changes, to include de-scoping options, that reduce the program cost and/or moderate requirements needed to respond to any threat developments. These recommended changes will be presented to the CSB with supporting rationale addressing operational implications.

Tools and Resources

DAG CH 3–2.4. Tools, Techniques and Lessons Learned contains information about SE tools generally employed in the Requirements Management process. There are many commercial software packages specifically designed for the traceability aspect of Requirements Management, from top-level operational requirements down to the lowest-level system elements in the Work Breakdown Structure.


Key Terms

Interface Requirements Specification (IRS)
Requirements Analysis
Requirements Creep
Requirements Manager
Requirements Scrub

Statutes, Regulations, Guidance

DASD(SE) Initiative

SoS Systems Engineering

ACquipedia Articles

DAU Training Courses

DAU Tools


DAU Communities of Practice

Requirements Management Community of Practice

Products and Tasks

Product Tasks
AWQI 16-1-1: Evaluate requirements traceability matrix
  1. Identify and clarify requirements contained in the initial capabilities document (ICD) and related user-defined capabilities documents.
  2. Coordinate with the contracting officer to develop acquisition document language requiring the contractor to establish and manage the requirements management process for the acquisition.
  3. Identify requirements management language and compliance requirements in the acquisition documentation.
  4. Evaluate the contractor’s requirements management process and requirements traceability tool and compare with the program office’s process.
  5. Evaluate adequacy of contractor-selected requirements traceability tool.
  6. Document the program’s requirements management process in the program’s systems engineering plan (SEP), section 4.3 requirements development and change process.
  7. Document the program’s requirements traceability tool in the program’s SEP, section 4.7 engineering tools.
  8. Evaluate contractor’s requirements traceability matrix as contractor develops lower level system requirements and identifies relevant statutory, regulatory, and derived requirements.

Source: AWQI eWorkbook