Requirements Management: Difference between revisions
(RWG Draft effort) |
(RWG Draft effort) |
||
Line 31: | Line 31: | ||
=== Monitoring and Control === | === Monitoring and Control === | ||
The | The monitoring process uses the Measurement [link] process to enable situational awareness of the status and quality of the requirement process, including status of requirement development completion, incorporation of changes, and progress towards obtaining objective evidence during System Verification [link]. Controlling the requirements is actions taken to ensure requirements continue to address the stakeholder needs; this includes resolving unknowns, addressing findings in the quality and correctness of the requirements, and making changes. | ||
Example metrics: | |||
* Requirements quantity | |||
* Requirements quality | |||
* Requirements volatility (rate of change) | |||
* Types of requirements | |||
* Requirements not traceable to Stakeholder needs | |||
* TBX Count (maturity) | |||
* Completeness of system verification planning | |||
This activity often supported through the use of attributes that provide additional content for the requirement. Example attributes to support requirements management include Status, Prioritization, Stability, and Responsible Person or Owner. A more complete list of attributes, their descriptions, and guidance for use is included in the INCOSE Needs and Requirements Manual (NRM). | |||
=== Requirement Management Tools === | === Requirement Management Tools === | ||
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. | There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. |
Revision as of 22:21, 17 March 2024
Lead Author: Tami Katz Contributing Authors: Lou Wheatcraft, Mike Ryan
Requirements management is performed to ensure alignment of the system requirements [glossary link] with other representations, analyses, and artifacts of the system. 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 [glossary link] among the requirements and with the rest of the artifacts of system definition [link to glossary].
Purpose and Definition
Requirements Management is the discipline of gathering, expressing, organizing, tracing, analyzing, reviewing, agreeing, tracking, communicating, changing and validating requirement statements (Pohl, 2010). While requirements develop addresses elicitation and creation of the requirements as described in System Requirements Definition, the requirements management process addresses how the products of that activity are managed over the project life cycle [link to glossary term]. This process leverages the other systems engineering management processes of Configuration Management [link] and Information Management [link] in addressing the activities highlighted in Figure 1.
[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.
The scope of requirements management also includes management of artifacts from the Confect Definition activities [link] Business or Mission Analysis [link] and Stakeholder Needs [link], as well as traceability of requirements to other systems engineering artifacts as described in System Requirements Definition [link].
Process Approach
Requirements management begins with the definition of stakeholder needs and system requirements, ensuring the data from these activities are captured, configuration controlled, and communicated. Enablers for requirements management include attributes, tools, and configuration management processes.
Configuration Management and Change Control
Requirements management is also closely tied to configuration management [link] for baseline management and control. When the requirements have been defined, assessed, and approved, they are baselined. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of any proposed changes. There are several reasons requirements could change, including
- Continuing maturity through resolution of TBXs
- Re-allocation of system performance
- Changing operational environments
- Changing external interfaces
- Introduction of new technology and Innovation
- Obsolescence
- Customer budget changes
- Regulation changes
- Changes in the market
- Emerging threats and risks
Requirement changes can include modifications, new requirements or deleted requirements. Once a requirement is baselined, changes must come with rationale to explain to the stakeholders why this change is occurring, which helps with assessment of impact. Impacts could include the cost of making requirement 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, etc.). Impacts to related requirements and interfaces also need to be considered when making changes to requirements. Traceability, described below, is a powerful enabler to support assessment and impact of requirement changes.
Monitoring and Control
The monitoring process uses the Measurement [link] process to enable situational awareness of the status and quality of the requirement process, including status of requirement development completion, incorporation of changes, and progress towards obtaining objective evidence during System Verification [link]. Controlling the requirements is actions taken to ensure requirements continue to address the stakeholder needs; this includes resolving unknowns, addressing findings in the quality and correctness of the requirements, and making changes.
Example metrics:
- Requirements quantity
- Requirements quality
- Requirements volatility (rate of change)
- Types of requirements
- Requirements not traceable to Stakeholder needs
- TBX Count (maturity)
- Completeness of system verification planning
This activity often supported through the use of attributes that provide additional content for the requirement. Example attributes to support requirements management include Status, Prioritization, Stability, and Responsible Person or Owner. A more 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 requirements management; the best choice is the one that matches the processes of the project or enterprise.
x
Establishing Traceability
Requirement Management Planning
Plan for the requirement management approach on a project based on the scale and complexity, and generate a Requirement Management Plan accordingly.
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
get