System Requirements Definition
Lead Author: Tami Katz Contributing Authors: Lou Wheatcraft, Mike Ryan
The System Requirements Definition process transforms the stakeholder view of desired capabilities into a technical view of how the system can achieve the capabilities. System requirements describe requirements which the integrated system must fulfill to satisfy the stakeholder needs and are expressed in an appropriate combination of well-formed textual statements and supporting models or diagrams. Inputs into this process are the life cycle concepts and integrated set of needs generated during the System Concept Definition activities.
System requirements play major roles in systems engineering, as they:
- Form the basis of system architecture and design activities.
- Form the basis of system integration and verification activities.
- Provide a means of communication between the various project team members that interact throughout the project.
The results of the System Requirements Definition process are a well-formed set of requirements that are used as inputs into the System Design Definition process.
Principles and Concepts
The outcome of the System Concept Definition activities is the identification of what is needed, why it is needed, and initial architecture/life cycle concepts which will be further matured during Engineering Development activities. This information is provided as input to the System Requirements Definition, the first activity in the System Definition Process (shown in Figure 1).
[insert figure SysReqt-1 here]
Figure 1. System Requirements Definition is the first activity in the System Definition Process. Original SEBoK figure derived from ISO 15288-2023.
Defining requirements is not an exercise in writing but is an exercise in engineering. Every requirement represents an engineering decision as to what the SOI must do, or a quality the system must have, to meet the needs from which they were transformed. Determination of what the system must do to meet a need is through a process of detailed requirement analysis, which can include the development and use of models and simulations.
Purpose of Requirements
A requirement is a statement that translates or expresses a need and its associated constraints into an agreed-to obligation for an entity to perform some function or possess some quality [INCOSE 2022]. There are many types of requirements; this article will describe the requirements which are used as inputs into the Design Definition process. At the highest level of the architecture hierarchy these are referred to as System Requirements.
Needs versus Requirements
"Needs" communicate the stakeholder’s perspective concerning their expectations of what they need the system of interest (SoI) to do from an external, black box view. Example: The user needs the coffee maker to stop heating water once the user selected temperature has been achieved.
"Requirements" communicate the developer perspective concerning what the SoI must do to meet the stakeholder needs from an internal white box view. Example: The Coffee Maker shall stop the heating function once the selected Brew Temperature been achieved.
The sources of needs are described in Stakeholder Needs Definition. These sources include the stakeholder expectations and needs, drivers and constraints, risk analysis, and life cycle concept analysis and maturation activities. These needs are treated as inputs to the System Requirement Definition process, which results in a set of requirements on the SoI. A more complete discussion on life cycle concepts and needs definition is included in the INCOSE Needs and Requirement Manual (NRM) and the INCOSE Guide to Needs and Requirements.
Requirements versus Specifications
Requirements communicate what the system must do (inputs into the Design Definition process), where a specification describes how a system is made (built or coded) (outputs from the Design Definition process). While historically the term "requirements specification" has been used to describe a set of requirements, a more appropriate designator is "requirement document", "set of requirements", "set of design input requirements" or "requirement artifact" to avoid confusion with products generated during the design process. For a specification, a more accurate designator is "design output specification".
Process for Generating System Requirements
Transforming Needs to System Requirements
The System Requirement Definition activities begin with the transformation of the integrated set of needs into a set of requirements for the SoI. These requirements must be appropriate to the level that the SoI exists within the system architecture and communicate “what” the SoI must do to meet the needs, avoiding requirements that state implementation of “how” to achieve the design realization of the physical SoI.
Example transformation of a Need to a design input Requirement:
- Need: "The customers need the bicycle to transport the rider using non-motorized power."
- Requirement: "The bicycle shall transport a rider using the propulsion force supplied by the rider.”
The process of generating a requirement statement is more than changing the subject of the need statement, it is an analysis of what must the system do to achieve what is needed. Types of analyses and tools that are used to make this determination include:
- Functional analysis
- Use of system models
- Data flow diagrams
- Interface analysis (context diagrams, external interface diagrams, I² diagrams)
- Performance measure analysis from MOEs
- House of Quality method
- Needs to requirements transformation matrix.
- Margin assessment and allocation
- Performance and resource budgets and allocation
- Quality analyses (reliability, maintainability, etc.)
- Compliance analysis (standards and regulations)
For functions that address the primary mission, goals, objectives and measures of the SoI, there are characteristics that describe the performance of that function, addressing "how well". Requirement analysis for functions and performance can be performed by using system models (supported by Model-Based Systems Engineering (MBSE) applications). Key enabling model views include activity diagrams, sequence diagrams, state machine diagrams, and structure diagrams (for hierarchy and interfaces). An example functional analysis is shown in Figure 2.
[insert figure SysReqt-2 here]
Figure 2. Example Function Analysis using a SysML Activity Diagram. Original SEBoK figure.
Close and frequent coordination with the stakeholders is necessary to ensure the transformation is accurate and traceability is maintained. This results in a set of system requirements communicating measurable characteristics which can form the basis for system realization. Using a detailed analysis a single need statement may be transformed into multiple requirements expressing what the system must do to meet it, including definition of measurable performance criteria.
An example requirement from the above transformation analysis could be:
Need: The stakeholders need the automobile to increase speed when driver provides an input to accelerate.
Requirement: When driver increases accelerator position, the Automobile shall increase torque to the engine in direct proportion to the acceleration position change.
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment of candidate solutions and verification the completed system will meet the requirements. The system requirements are expressed in a well-formed technical language that is useful for architecture and design. To ensure requirements are communicated clearly, it is recommended that a set of criteria for requirement pattern and characteristics is used, such as those provided in the INCOSE Guide to Writing Requirements.
A more complete discussion on the transformation of needs into requirements is included in the INCOSE Needs and Requirements Manual (NRM) and Guide to Needs and Requirements.
Use of Attributes
An attribute is additional information associated with an entity which is used to aid in its definition and management. Well-chosen attributes, when properly defined and tracked, can enable correct interpretation and management of requirements throughout the system life cycle. Example attributes include:
- Identifier
- Title
- Owner
- Rationale
- Trace to source
- Category
- Priority
- Criticality
- System verification method
The use of an attribute like Rationale when definition a requirement helps communicate why the requirement is needed, any assumptions made, the source of numbers, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition, as well as identifying the source of any requirement value. Defining the system verification method helps ensure the requirement is well-formed, is verifiable, and aids in the planning for the project's verification program. A more complete list of attributes, their descriptions, and guidance for use is included in the INCOSE Needs and Requirements Manual (NRM).
Categorizing Requirements
It is useful to organize the requirements into categories, grouping similar types of requirements together within a set. An example set of categories is shown in Table 1. While organizations may have different categorizations, in order for the set of requirements to be complete each category topic in Table 1 must be addressed. Refer to the INCOSE Needs and Requirements Manual for a more detailed discussion concerning the categorization of requirements.
| Category | Description |
|---|---|
| Function/ Performance | The primary functions and associated performance that the SoI needs to perform in terms of its intended use. The functions address the capabilities and features the stakeholders expect the SoI to have; performance addresses how well, how many, how fast attributes of the function. Many of the primary functions involve interactions (interfaces) between the SOI and systems external to the SOI. All critical and high priority needs would be included in this category. |
| Fit/Operational | Requirements dealing with functions that deal with a secondary or enabling capabilities, functions, and interactions between the SoI and external systems needed for the system to accomplish its primary functions. This includes functions concerning the ability of the system to interface with, interact with, connect to, operate within, and become an integral part of the macro system it is a part. Fit includes human system interactions and interfaces as well as both the induced and natural environments (conditions of operations, transportation, storage, maintenance). For example, needs associated with safety, security, power, cooling, transportation and handling, storage, maintenance, and disposal. |
| Form | Physical Characteristics. The shape, size, dimensions, mass, weight, and other observable parameters and characterizes that uniquely distinguish a system. For software, form could address programming language, lines of code, memory requirements. |
| Quality | Fitness for use. For example, various “-ilities” such as reliability, testability, operability, availability, maintainability, operability, supportability, manufacturability, and interoperability. |
| Compliance | Conformance with design and construction standards and regulations. |
See Table 2 for example Requirement statements, attributes and categories.
| Reqt ID | Requirement Title | Requirement | Rationale | Category |
| R1 | Variable Temperature Settings | The Coffee Maker shall have two selectable settings for coffee brewing: Warm: 96°C +/- 2°C, Hot: 100°C+/- 2°C. | Based on focus group inputs for selectable temperature; values are from analysis associated with consumer research surveys and safety regulations. | Function/Performance |
| R2 | Prohibit Brew if Container Missing | If coffee container is missing from the brew location, the Coffee Maker shall prohibit brew function. | Protective measure related to off-nominal use case. | Function/Performance |
| R3 | Electrical Standard Compliance | The Coffee Maker shall comply with the requirements in Table 1 of UL 1082, Household Electric Coffee Makers and Brewing-Type Appliances. | Ensures compliance with US National Electrical Code, NFPA 70. | Compliance |
| R4 | Coffee Maker Variants | The Coffee Maker shall consist of four variants that are differentiated by color. | Design constraint based on marketing strategy. | Form |
| R5 | Operational Life | The Coffee Maker operational life shall be greater than or equal to 3 years. | Analysis shows expected operational service of 1,000 hours over three years of usage, ensuring appliance lasts through the warranty period. | Quality |
| R6 | User Interface | The Coffee Maker shall limit the number of user inputs to: Power On, Brew Temperature, Brew Size, Brew Start. | User inputs are assessed from focus groups to minimum set of inputs to achieve coffee maker full set of life cycle concepts. | Fit/Operation |
Requirements At Levels Within the Hierarchy
Requirements definition is a recursive process performed concurrently with the Architecture Definition Process. Upon determination of the system hierarchy, a requirement tree can be established showing the system level requirements and the supporting requirements at the lower-level elements of the hierarchy. Figure 3 shows an example flow from system requirement to lower-level requirements, and an example requirement tree is shown in Figure 4.
[insert figure SysReqt-3 here]
Figure 3. Example Flow of System Requirements with to Lower-level Requirements. This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 6-20, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.
[insert figure SysReqt-4 here]
Figure 4. Example Requirement Tree using a SysML Package Diagram. Original SEBoK figure.
Allocation is the process by which the requirements at one level of the physical architecture are assigned to those entities at the next lower level of the architecture that have a role in the implementation of the allocated requirement. This involves an analysis where the project team determines what “role”, if any, each subsystem and system element at the next level of the architecture has in the implementation of the requirement being allocated. Requirements generated at the lower level are referred to as child requirements of the allocated parent requirement. An important concept associated with allocation is budgeting. Budget refers to the total value of a parameter defined at the system level. The system requirement value may be decomposed to ensure the lower-level elements contribute their portion, enabling the system level to achieve its total value. Budgeted quantities result in requirements that have a dependency - a change in one will result in the need to change another. Budgeted values can include mass (weight), power usage, bandwidth, time, and quality attributes). Refer to the INCOSE Needs and Requirements Manual for a more detailed discussion concerning moving between levels, allocation, and budgeting.
Principles Governing System Requirements
Establishing Achievable Measures
When generating the criteria for requirements in the form of numerical values, the following guidance can ensure the final values are achievable and aligned with the original stated need:
- Requirement values must be achievable, for this reason a tolerance or range of values is applied to any specified value. Tolerance refers to a permissible deviation from a specified value, while a range refers to a span of acceptable values, including less than, greater than options. Usage of tolerances and ranges ensures the values are achievable in test and operations (avoiding absolutes). If the tolerance or range is too “tight” or the range too “narrow” the cost to manufacture and verify the system will be more expensive. If the tolerance is too “loose” or range is too “wide”, the possible variability during manufacturing may result in an issue with “tolerance stack up” (when the combination of +/- tolerances or allowable ranges may result in a SoI that does not work).
- For requirements that deal with taking a measure, the concepts of accuracy and precision are a consideration when specifying expected performance. Accuracy is a measure of how close an average of measures is to a baseline value expressed as a percent. Precision is a function of the distribution of measurements taken, i.e., closeness of agreement between independent, repeated measures obtained from the same sample under specific conditions. If the accuracy or precision values are too “tight” or “narrow” the cost to design and manufacture a system that meets those performance values will be more expensive, as will the cost to verify the system meets those values.
- For any system in its development life the current best estimate of a resource changes as the development team matures the design. For a system in development, most technical resources carry margin. A margin is the difference between the expected value and the value used in the requirement. Margins account for unexpected growth or limitations to ensure overall system is still able to meet its needs. When defining performance values, including margins is especially important when using new, immature technologies (harder to predict performance). Refer to the INCOSE Needs and Requirements Manual for a more detailed discussion concerning margins when defining requirements.
Addressing Unknowns
When initially generating a set of requirements, there is often a set of parameters which may require future analysis to determine their actual value. One common method to do this is to use a placeholder in the requirement statement to indicate the requirement is drafted, yet further work is needed before it is considered complete. When a value is unknown, a common approach is to use the "To Be Determined" (TBD) indication within the requirement statement, in place of an actual value. When a value is determined but confidence is low (e.g., feasibility has not been assessed), a method to reflect this is to use the "To Be Resolved" (TBR) indication next to the value. Keeping track of the TBXs allows for awareness of the maturity of the requirements throughout the life cycle and is a valuable metric to evaluate completion and maturity of the set of needs and set of design input requirements.
TBXs can lead to risk if not addressed by the project prior to significant work in establishing the design solution. TBX management is the process of identifying the TBXs in a requirement set, establishing the work needed to resolve closure of the issue, identifying the owner of the work, and "burning down" the actions to enable removal of these placeholders in the requirements. Refer to the INCOSE Needs and Requirements Manual for a more detailed discussion concerning TBX Management.
Addressing Interfaces and Interactions
An interface is a boundary where, or across which, two or more systems interact. Complex systems have a large number of internal interactions, increasing the complexity of system integration as well as emergent behaviors of the integrated system. For each part of the architecture an external interface diagram provides the ability to address interactions between the SoI and external systems (Figure 5).
[insert figure SysReqt-5 here]
Figure 5. Interfaces Address Interactions between Systems. This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 6-10, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.
The phrase “interface requirement” refers to the specific form or template for a requirement that deals with an interaction of a system across an interface boundary with another system. Writing interface requirements is a three-step process:
- Identify the interface boundaries and interactions across those boundaries.
- Define the interactions across the interface boundaries (the characteristics of what is crossing the boundary, and media involved).
- Write the interface requirements.
Example forms of interface requirements:
- The System shall [interact (function verb/object) with] [Another System] as defined in [location where the interaction is defined].
- The System shall [use/provide from/to] [Another System] [something] having the characteristics defined in [location where the something is defined].
The creation of interface requirements ensures that function/performance and fit/operational requirements address the interactions with external systems. Interface requirements should be included within the category of requirements they support based on their role in the primary SoOI objectives; placing them in separate locations just because they address interfaces may lead to confusion on whether the set of requirements is complete. Refer to the INCOSE Needs and Requirements Manual for a more detailed discussion concerning interfaces and interface management.
Textual versus Model Form of Requirement
Requirements can be recorded and managed via a document, database, or model-based approach in the form of a structured natural language expression, or in the form of a model.
Benefits of Textual Requirements:
- For many concepts that need to be communicated, there is a sizeable audience who cannot interpret (or are not willing to work with) diagrammatic or model-based representations of needs or requirements.
- Not everyone has access to the toolset to leverage the model-based requirements and associated data, while most people have access to document-based tools.
- From a legal perspective, textual requirement statements are more acceptable in a formal agreement (or contract-based effort) by a wider, often non-technical, set of stakeholders.
Benefits of Model-based Requirements:
- Models provide the capability to address completeness in terms of functions, inputs to those functions, sources of those inputs, outputs, and customers (destinations/users) for those outputs.
- Models help facilitate communication by making complex systems and processes easier to understand (a picture is worth a thousand words….).
- Models enable the capture of interdependencies of requirements to other aspects of the system dataset, such as inputs, needs, architecture, test cases, etc.
- Models enable quantitative analyses and execution of simulations.
Each type of form represents a specific visualization, ideally both are used to fully communicate the requirements of the system of interest. Combining textual requirements and models can leverage the advantages of both forms. In MBSE, this is achieved when using the full well-formed textual statement as part of a requirement model element that can be expressed as a diagram (Figure 6) or within a table in the modeling tool. Refer to Requirements Management for further guidance on usage of tools associated with textual and model requirements.
[insert figure SysReqt-6 here]
Figure 6. Example of a Model Based Requirement. Original SEBoK figure.
There is a growing trend involving the usage of Natural Language Processors and Artificial Intelligence (AI) in generation of requirements. Some tools and organizations are researching how to utilize AI to develop complete, correct, and consistent well-formed requirement statements. As a supporting tool, there is a lot of promise in AI with needs and requirements activities. At this time, the AI is unable to do the analysis associated with life cycle concepts and needs elicitation, or transformation of needs to requirements, assessing feasibility, correctness, and completeness of the set of requirements as this involves understanding intent, and is not purely based on logic. In this context the NLP/AI tools which exist currently are useful as "digital assistants", but do not replace the systems engineering associated with the definition of well-formed requirements and sets of requirements.
Methods of Consolidation
Ensuring requirement statements are singular may result in a large quantity of requirements, which can lead to a challenge in comprehensibility of the requirement set, as well as costs associated with management and system verification activities for each of the requirements. A requirement set should have "just enough" requirements to ensure the realized system addresses the needs (achieving system validation). The concept of consolidation is used to define techniques to ensure the requirements are necessary, complete, consistent, feasible, sufficient, and "just enough".
The first method to ensure a consolidated requirement set is to assess each requirement against the following criteria:
- Is every requirement necessary to achieve the set of integrated needs?
- Does every requirement trace to a source?
- Are there redundancies or inconsistencies within the requirement set?
- Are there hidden requirements in standards and regulations called out by requirements which need to be explicitly assessed for applicability, and perhaps pulled into the requirement set directly?
- Are all requirements at the correct level of abstraction? (No subsystem requirements in a system requirement set, and vice versa.)
- Are the requirements feasible?
- Would the needs be met if the requirement was removed from the set?
When there are groupings of similar requirements with a common function and system verification approach, consider using a table to capture different criteria around that function. While this does reduce the requirement quantity it is important to note that each criterion in the table will still require verification evidence. Also, keep in mind the concepts of allocation and budgeting when consolidating requirements, as discussed earlier.
Traceability
Traceability is a powerful way to manage the design input requirements, especially across levels and across subsystems and system elements within a specific level as well as manage the requirements across the life cycle. Traceability helps ensure the requirements trace to their needs, and that they are correct and complete and also helps identify allocation of requirements to elements of the architecture.
The individual sets of life cycle concepts, set of needs, system requirements, design output specifications, system validation artifacts, system verification artifacts represent a multi-level “spider web” of relationships throughout the development of the SoI. Traceability provides the ability to connect this data, and track information at all levels of the system hierarchy (see Requirements Management). Traceability can be used to understand the source of requirements and can connect the verification data to the associated requirement during the System Verification process. Traceability is also used to address any impacts of changes to requirements or other types of data, enabling insight into whether that change is beneficial or costly.
Defining a traceability relationship model at the beginning of the project enables an understanding of which relationships will be established and managed via traceability throughout the development of the SoI. An example traceability model is shown in Figure 7. Refer to the INCOSE Needs and Requirements Manual for a more detailed discussion on traceability.
[insert figure SysReqt-7 here]
Figure 7. Example Traceability Model. This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 6-20, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.
Planning for System Verification
A best practice is to do early planning for how the project will perform system verification. Verification activities must align with project constraints – otherwise there is a risk of missing objective evidence that the requirement is met by the SoI. System verification is the process to obtain objective evidence that the SOI satisfies the design input requirements. Defining the system verification Success Criteria, Strategy, and Method at this life cycle stage helps ensure the requirement statements are worded properly, are within the scope of the project plans, and demonstrate they achieve the characteristic of "verifiable". This information can be captured within the attributes defined for the requirements, as discussed earlier.
Assessing the System Requirements
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).
Requirement verification addresses: Are the requirements well-formed, i.e., defined (stated) in a correct manner? Has the organization criteria for quality been followed?
Requirement validation addresses: Do we have the right requirements? Are the capabilities communicated by the requirement set sufficient to satisfy the intent of the integrated set of needs? Validation addresses if the requirements are correct and are also achievable.
For requirements communicated in a textual form, guidelines exist for writing well-formed requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to the INCOSE Guide to Writing Requirements as one example of guidance for writing and assessing well-formed requirements.
System Requirement Artifacts
This process may result in various artifacts, such as:
- System requirements document
- Set of requirements and associated attributes
- Requirement tree
- System model requirement diagram
- System model requirement table
- Traceability of requirements to other SoI data (architecture, behavior, needs, related requirements)
- Definition of interactions across interface boundaries
- Allocation of requirements to the next level in the system architecture
- Budgets of parameters associated with allocated requirements
- Initial system verification plans (e.g., methods, success criteria)
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.
Requirements Management
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analyses, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. The Requirements Management article provides additional guidance on methods for performing requirements management.
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.
Primary References
ISO/IEC/IEEE. 2018. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/ Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148.
ISO/IEC/IEEE. 2023.Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2023.
INCOSE. 2023. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
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.
INCOSE. 2023. INCOSE Guide to Writing Requirements, version 4. INCOSE-TP-2006-004-04.
Additional References
INCOSE.2022. INCOSE Guide to Verification and Validation, version 1. INCOSE-TP-2021-004-01.
Relevant Videos
- Introduction to Systems Engineering and Requirements
- INCOSE Requirements Working Group YouTube Channel