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 System Concept Definition processes: Business or Mission Analysis and Stakeholder Needs Definition, as well as traceability of requirements to other systems engineering artifacts as described in System Requirements Definition process. RM includes providing an understanding of the requirements, establishing a baseline, communicating the requirements, managing changes, providing status of the requirement and associated verification process, and maintaining traceability among the requirements and 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).
[insert figure ReqMgt-1 here]
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 separating “management” of needs and requirements across the life cycle from “execution” of the activities performed during Business or Mission Analysis, Stakeholder Needs Definition, and System Requirements Definition process activities as well as the System Verification and System Validation process activities. RM ensures the data and information from these 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, including:
| Continuing maturity of knowledge | Changing external interfaces | Customer budget and schedule changes | Changing stakeholder needs |
| Re-allocation of system performance | Introduction of new technology and Innovation | Standards and Regulation changes | Emerging threats and risks |
| Changing operational environments | Obsolescence | Changes in the market | Emerging opportunities |
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; this drives the need for an established change control process early in the effort.
Requirement changes 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, 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, To Be Determined, etc.), addressing the quality and correctness of the needs and requirements, and managing changes to the needs and requirements.
Example metrics used as part of Monitoring and Controlling can include:
| Number of needs | Requirement Categories | Trace Assessment | Based on Heritage | Implemented in Design |
| Number of requirements | Status | TBX Count (maturity) | Completeness of System Verification content | System Verification Status |
| Requirement Quality | Need Quality | Volatility (rate of change) | Completeness of System Validation content | System Validation Status |
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 Status, Prioritization, 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 with its execution and validation of the end product through ability to:
- Capture needs and requirements and associated attributes.
- Capture needs and requirement traceability.
- Communication of needs and requirements metrics and status.
- Manage version control and changes needs and requirements.
- Facilitate change impact analysis.
- Control access to edit/change needs and requirements.
- Enable reuse of needs and requirements.
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).
[insert figure ReqMgt-2 here]
Figure 2. Requirement Management Tool as part of a Project's Digital Ecosystem. This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 16-1, reprinted with permission of INCOSE. 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, including:
| Use Cases and user stories | Measures of success | Higher-level requirements | Design artifacts |
| Operational Scenarios | Drivers and Constraints | Lower-level Requirements | Verification/Validation artifacts |
| Stakeholder Needs and Expectations | Architecture elements | Related requirements (performance budgets, etc.) | Interface definitions |
| Mission, Goals and Objectives (MGOs) | Project data (cost, schedule, etc.) | Risks | Required standards and regulations |
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.
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 project life cycle. Generating a 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.
Some key questions to be addressed within a RMP include:
- Who will be responsible for the RM activities and deliverables?
- How will the project interact with the stakeholders?
- What activities are involved in life cycle and needs definition?
- What activities are involved in the transformation of the integrated set of needs into the system design input requirements?
- What are the standards that define and assess need and requirement quality?
- How will the needs and requirements be verified and validated?
- How will requirements be prioritized? Critically be established?
- 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 TBX managed?
- How will changes be managed and controlled?
- What is the process for allocation and budgeting of requirements?
- What tool(s) will be used?
- What is the relationship between the RM activities and Interface Management activities?
- What is the relationship between the RM activities and system verification and validation activities?
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
Katz, T. 2021. Cost Optimization in Requirements Management for Space Systems. PhD Dissertation, Dept. of Systems Engineering, Colorado State University.