System Requirements Definition

---

Lead Author: Tami Katz Contributing Authors: Lou Wheatcraft, Mike Ryan, Alan Faisandier, Garry Roedler

---

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 specify what the system needs to do (input into the design process), where a specification describes how a system is built and works (outputs from the design 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", or "requirement artifact" to avoid confusion with products generated during the design process.

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 that are used as input into the design process. These requirements are appropriate for the level the SoI that communicate “what” the system must do to meet the needs, avoiding requirements stating “how” to achieve the design realization of the physical SoI. Need statements communicate a stakeholder perspective, where the requirement communicates the system perspective.  

Example transformation:

• 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.”

In actuality the process of generating the requirement statement is more than changing the subject of the statement, it is an analysis of what must the system do to achieve what is needed. Types of analyses that are used to make this determination include:

• Functional analysis
• Use of system models (activity, state machine, sequence diagrams, internal block 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
• Specialty analyses (reliability, maintainability, etc.)

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 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 coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for system realization. Using a detailed analysis a single need statement can 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 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 of the completed system. The system requirements are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable.

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
• Rationale
• Trace to source
• Category
• System verification method

Example benefit of using attributes: Capturing rationale when developing the requirements. Requirement rationale is a statement as to why the requirement exists, any assumptions made, 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.

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.

Table 1. Example Types of Requirement Categories. (Derived from the INCOSE Needs and Requirements Manual)

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.

Table 2. Example Requirement Statements. (SEBoK Original)

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 applicable requirements as noted 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 utilize four user inputs: 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

Upon determination of the system hierarchy through the System Architecture Design Definition process, 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 the children of the allocated parent requirement.

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).
• Budget refers to the total value of a parameter 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.

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

Addressing Interfaces and Interactions

An interface is a boundary where two or more systems interact. Complex systems have 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:

1. Identify the interface boundaries and interactions across those boundaries.
2. Define the interactions across the interface boundaries (the characteristics of what is crossing the boundary, and media involved).
3. 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 are able to be specified associated with interactions from external systems. Interface requirements should be included with 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.

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 natural language expression, or in the form of a model element using MBSE.

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 textual statement as part of a requirement model element (Figure 6).

[insert figure SysReqt-6 here]

Figure 6. Example Mode-Based Requirements.  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 and correct requirements. 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, as this involves understanding intent, and is not purely based on logic.

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, 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 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.)

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.

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. Traceability helps ensure the requirements trace to their needs, and that they are correct and complete. Traceability 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 Applying Life Cycle Processes). 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.

[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".

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

There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from (ISO 2011, Sections 5.2.5 and 5.2.6).

Table 3. Characteristics of Individual Requirements. (SEBoK Original)

Characteristic	Description
Necessary	The requirement defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements
Appropriate	The specific intent and amount of detail of the requirement is appropriate to the level of the entity to which it refers (level of abstraction). This includes avoiding unnecessary constraints on the architecture or design to help ensure implementation independence to the extent possible
Unambiguous	The requirement is stated in such a way so that it can be interpreted in only one way
Complete	The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement
Singular	The requirement should state a single capability, characteristic, constraint, or quality factor
Feasible	The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk
Verifiable	The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level at which the requirement exists
Correct	The requirement must be an accurate representation of the entity need from which it was transformed
Conforming	The individual requirements should conform to an approved standard template and style for writing requirements, when applicable

Table 4. Characteristics of a Set of Requirements. (SEBoK Original)

Characteristic	Description
Complete	The requirement set stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, and/or quality factors to meet the entity needs without needing other information. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses.
Consistent	The set of requirements contains individual requirements that are unique, do not conflict with or overlap with other requirements in the set, and the units and measurement systems they use are homogeneous. The language used within the set of requirements is consistent, i.e., the same word is used throughout the set to mean the same thing.
Feasible	The requirement set can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk. (Note: Feasible includes the concept of "affordable".)
Comprehensible	The set of requirements must be written such that it is clear as to what is expected by the entity and its relation to the system of which it is a part.
Able to be validated	It must be able to be proven the requirement set will lead to the achievement of the entity needs within the constraints (such as cost, schedule, technical, legal and regulatory compliance).

System Requirement Artifacts

This process may create several artifacts, such as:

• System requirements document
• Set of requirements and associated attributes
• Requirement tree
• System model requirement diagram
• System model requirement table

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.

Practical Considerations about System Requirements

There are several pitfalls that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.

Table 5. Major Pitfalls with Definition of System Requirements. (SEBoK Original)

Pitfall	Description
Insufficient Analysis of Stakeholder Needs and Requirements	If the receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.
Insufficient Analysis of Operational Modes and Scenarios	The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.
Incomplete Set of System Requirements	If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.
Lack of Verification Method	Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.
Missing traceability	Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.

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. 2011. 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. 2015.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:2015.

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.

Additional References

Faisandier, A. 2012. Systems Opportunities and Requirements. Belberaud, France: Sinergy'Com.

Hooks, I.F. and K.A. Farry. 2000. Customer-Centered Products: Creating Successful Products through Smart Requirements Management. New York, NY, USA: American Management Association.

Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. Systems Engineering, 3rd ed. London, UK: Springer.

Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. Systems Engineering Leading Indicators Guide, version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.

SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in Capability Maturity Model Integrated (CMMI) for Development, version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).

Relevant Videos

• Introduction to Systems Engineering and Requirements
• INCOSE Requirements Working Group YouTube Channel

---

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