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.

For a more detailed discussion concerning RM, refer to the INCOSE Needs and Requirements Manual and Guide to Needs and Requirements.

It 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.

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.  

[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 RM processes, CM 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 and understanding as a result of the iterative and recursive nature of SE as the project moves between levels of the architecture and across the lifecycle.

• Re-allocation of system performance
• Changing operational environments
• Changing external interfaces
• Introduction of new technology and Innovation
• Obsolescence
• Customer budget and schedule changes
• Standards and Regulation changes
• Changes in the market
• Changing stakeholder needs
• Emerging threats and risks

Need and requirement changes can include modifications, new needs or requirements, or deleted needs or requirements. Once a need or requirement is baselined, changes must include rationale why the change is necessary and helps with assessment of impact 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 planning, verification execution, validation planning, validation execution, etc.). Impacts to related needs and 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 [link] 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 lifecycle 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, 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:

• Number of needs
• Number of requirements
• Number of needs that have been verified and validated
• Number of requirements that have been verified and validated
• Needs and Requirements volatility (rate of change)
• Types of needs and requirements
• Requirements not traceable to Stakeholder needs, parent, or source
• TBX Count (maturity)
• Completeness of system verification planning (number of requirements that have system verification attributes defined)
• Completeness of system validation planning (number of needs that have the system validation attributes defined.
• Number of requirements implemented by design.
• Number of requirements the system has been verified to have been met.
• Number of needs the system has been validated to have been met.

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. A complete list of attributes, their descriptions, and guidance for use is included in the INCOSE Needs and Requirements Manual (NRM).

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 needs and RM tools include definition, collaboration, change control, and traceability to other project data.  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. Various capabilities and features to consider when choosing tools within a project toolset is included in the INCOSE Needs and Requirements Manual (NRM).

Examples of different RMTs and other SE tools can be found in the INCOSE and PPI Systems Engineering Tools Database. A list of various requirement management tools that have been rated by users can be found at https://www.g2.com/categories/requirements-management.

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.  This ability is critical to being able to establish a Federated Authoritative Source of Truth (ASoT).  Managing the project data within an integrated and federated data and information model of the system is a key characteristic of MBSE.

[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, user stories, misuse cases, loss scenarios, operational scenarios.
• Stakeholder needs and expectations.
• MGOs and measures
• Higher-level requirements
• Lower-level requirements
• Life cycle concepts
• Drivers and constraints,
• Risks
• Other requirements with relationships (such as shared performance budgets from an allocation where there is a dependency or related interface requirements)
• Design outputs which satisfy the requirements
• Parent requirements and other sources of requirements
• Verification artifacts
• Validation artifacts
• Project data (budget, schedule, risks)
• Interface definitions
• Required standards and regulations
• Supplementary data

RM processes are used to monitor these traces 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 described above.

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 lifecycle. 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).[link]   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 lifecycle 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?

Plan for the RM approach based on the scale and complexity of the project and system to be developed and generate a 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 a RM process.

References

Works Cited

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

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

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

Primary References

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

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

Additional References

Katz, T. 2021. Cost Optimization in Requirements Management for Space Systems. PhD Dissertation, Dept. of Systems Engineering, Colorado State University.

Video References

pending

---

< Previous Article | Parent Article | Next Article> SEBoK v. 2.9, released 20 November 2023