Requirements Management

---

Lead Author: Tami Katz Contributing Authors: Lou Wheatcraft, Mike Ryan

---

Requirements management (RM) is performed to ensure alignment of requirements with other representations, analyses, and system artifacts generated across the life cycle.  The scope of RM includes management of artifacts from the Concept Definition processes: Business or Mission Analysis and Stakeholder Needs Definition, as well as traceability to other systems engineering artifacts as described in System Requirements Definition process. RM includes providing an understanding of the requirements, an understanding of the needs from which they originated, establishing a baseline, communicating the needs and requirements, managing changes, providing status, and maintaining traceability with the rest of the artifacts of System Definition (INCOSE NRM 2022).

Purpose and Definition

As shown in Figure 1, RM is a cross-cutting series of activities that involve managing the sets of needs and the sets of design input requirements, including managing the needs and requirement definition activities, baselining the needs and requirements, communicating the needs and requirements, managing the flow down (allocation and budgeting) of requirements from one level to another, managing interactions (interfaces) both internal and external to the SoI, managing bidirectional traceability, and managing the design and system verification and validation artifacts, and managing change (INCOSE GtNR 2022).  

Figure 1. Requirements Management Activities. This figure is derived from the INCOSE Guide to Needs and Requirements v1, Figure 22, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.

While needs and requirements development addresses elicitation and creation of the needs and requirements as described in System Requirements Definition, the RM activities address how needs and requirements are managed across the project life cycle. These activities leverage other systems engineering management processes including Configuration Management (CM), Interface Management, Systems Analysis, and Information Management.

Process Approach

RM begins at the beginning of a project addressing the management of needs and requirements across the life cycle, ensuring the data and information from the development life cycle activities are captured, configuration controlled, and communicated. Enablers for RM include organizational processes, tools, and trained personnel in those processes and tools.

Configuration Management and Change Control

RM is closely tied to CM activities associated with baseline management and control of the sets of needs and requirements and other related artifacts. When the sets of needs and requirements have been defined, assessed, and approved, they are baselined. The baseline allows the project to define and manage budgets and schedules as well as analyze and understand the impact (technical, cost, and schedule) of any proposed changes.

There are several reasons needs and requirements could change:

• changing stakeholder needs, requirements, expectations,
• customer budget and schedule changes,
• emerging threats and risks,
• re-allocation of system performance, and
• changing operational environments.

Note that due to the iterative and recursive nature of SE across the life cycle there is an expectation of changes to needs and requirements, particularly early in the development life cycle, as requirements are allocated, budgeted, and requirements defined for lower-level architecture entities. This drives the need for an established change control process early in the effort.

Changes to needs and requirements can include modifications, additions, or deletions. Once a need or requirement is baselined, changes must include rationale why the change is necessary, which helps with impact assessment of the change. Impacts could include the cost of making changes at multiple levels in the architecture hierarchy (including suppliers), as well as the cost/schedule/technical impacts associated with any work-in-process updates (design, verification, etc.). Impacts to related needs, requirements, and interfaces also need to be considered when making changes. Traceability, described below, is a powerful enabler to support assessment and impact of need and requirement changes.

Monitoring and Control

The monitoring process uses the Measurement process to enable situational awareness of the status and quality of the RM process activities, including status of needs and requirement definition activities, incorporation of changes, and progress towards obtaining objective evidence during System Verification and System Validation that the needs and requirements have been met.

Controlling the needs and requirements involves actions taken to ensure the integrated set of needs reflect the life cycle concepts, MGOs, and measures from which they were derived, and that the requirements continue to address the intent of the integrated set of needs from which they were transformed. Monitoring and controlling also includes resolving unknowns (To Be Resolved (TBR), To Be Determined (TBD), etc.), addressing the quality and correctness of the needs and requirements, and managing changes to the needs and requirements.

Several types of metrics can be used as part of Monitoring and Controlling:

• number of needs,
• number of requirements,
• number of needs and requirements with TBDs or TBRs
• needs and requirements not traced to a source,
• status of system verification, and
• status of system validation,

The project must define which metrics will be used to monitor and control the needs and requirements as well as choose tools that enable these metrics to be defined and managed as well as tools that can communicate these metrics to the project team. The ability to monitor these metrics is supported through the use of attributes that provide additional content for the need or requirement. Example attributes to support requirements management include Rationale, Status, Criticality, Priority, Stability, and Responsible Person or Owner. Reference System Requirements Definition for more details on defining attributes.

Requirement Management Tools

There are many tools available to provide a supporting infrastructure for needs and requirements management; the best choice is the one that matches the needs and processes of the project or enterprise. Desired capabilities and features of RM tools include definition, collaboration, change control, and traceability to other project data (INCOSE NRM 2022).  A requirements management tool (RMT) can enable a project's success by providing several capabilities:

• capturing the needs, requirements, and associated attributes,
• capturing requirement traceability to other data,
• communication of metrics and status,
• management of version control and changes, and
• facilitation of change impact analysis.

Modern RMTs vary in capabilities and costs. Pointers for finding various RMTs and other SE tools can be found in the Primary References section.

It is recommended that RMTs enable the sharing of data and information with other tools in the project toolset as part of a larger digital engineering ecosystem, as highlighted in Figure 2; this ability helps to maximize the ability to ensure consistency with other project data and artifacts generated across the life cycle, which is critical to being able to establish the Authoritative Source of Truth (ASoT) (INCOSE NRM 2022).

Figure 2. Requirement Management Tool as part of a Project's Digital Ecosystem. This figure is reprinted with permission of Lou Wheatcraft. All other rights are reserved by the copyright owner.

RMTs are most effective if they are setup with a common project schema, ontology, and templates, and team members are trained in their use before project initiation, ensuring the project team spends their time on the definition and management of needs and requirements and not on extensive development of the tool infrastructure.

Managing Traceability

As described in System Requirements Definition, traceability can be established between the needs and requirements and other sets of data and artifacts across the life cycle:

• operational Scenarios,
• risks,
• related requirements, and
• verification/validation artifacts.

RM processes are used to monitor traceability of data and ensure they are maintained over the system life cycle. This is enabled through use of toolsets that allow linkages of the needs and requirements to the other data within a digital ecosystem as shown in Figure 2.

Requirements Management Planning

The RM activities involve project resources and must be planned as part of the overall project and systems engineering planning efforts. A Requirements Management Plan (RMP) can be used to define and communicate scope and processes for managing needs and requirements across the SoI life cycle. An RMP keeps all team members and stakeholders on the same page. For smaller and less complex projects, the needs and requirements management process could be captured within the program or project management plan (PMP) or systems engineering management plan (SEMP). For larger and more complex projects, it is recommended a standalone RMP be developed.

There are several topics addressed within an RMP:

• Who will be responsible for the RM activities and deliverables?
• What tool(s) will be used?
• How will the project team interact with the stakeholders?
• What activities are involved in life cycle concepts and needs definition?
• What activities are involved in requirements definition?
• How will the needs and requirements be assessed for quality and correctness?
• How will changes be managed and controlled?
• What types of traceability will be used?
• What is the hierarchy of the sets of needs and requirements and how will it be managed?
• What attributes will be used?
• How will metrics need to be defined and reported?
• How are TBRs and TBDs managed?

Projects should plan for the RM approach based on the scale and complexity of the project and system to be developed and generate an RMP accordingly, and then update the plan if the processes evolve. Note that some projects are required to deliver their RMP to a customer, which may require additional content; however, do not generate a plan merely because a customer directed it, the development of an RMP is critical to project success. Proper planning can ensure desired outcomes when implementing an RM process.

References

Works Cited

INCOSE. 2022. INCOSE Needs and Requirements Manual (NRM), version 1.1. INCOSE-TP-2021-002-01.

INCOSE. 2022. INCOSE Guide to Needs and Requirements (GtNR), version 1. INCOSE-TP-2021-003-01.

Primary References

INCOSE. 2022. INCOSE Needs and Requirements Manual (NRM), version 1.1. INCOSE-TP-2021-002-01.

INCOSE. 2022. INCOSE Guide to Needs and Requirements (GtNR), version 1. INCOSE-TP-2021-003-01.

INCOSE and PPI Systems Engineering Tools Database.

Pohl, K. (2010). Requirements Engineering Fundamentals, Principles, and Techniques.

Additional References

none

---

< Previous Article | Parent Article | Next Article> SEBoK v. 2.12, released 27 May 2025