Difference between revisions of "System Requirements"

From SEBoK
Jump to: navigation, search
(Checking and Correctness of System Requirements)
m (Text replacement - "<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>" to "<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>")
 
(245 intermediate revisions by 20 users not shown)
Line 1: Line 1:
 +
----
 +
'''''Lead Authors: ''''' ''Alan Faisandier, Garry Roedler,'' '''''Contributing Author:''''' ''Richard Turner, Rick Adcock, Ariela Sofer''
 +
----
 +
{{Term|System Requirement (glossary)|System requirements}} are all of the {{Term|Requirement (glossary)|requirements}} at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the {{Term|Stakeholder Requirement (glossary)|stakeholder needs and requirements}}, and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary.
  
==Introduction, Definition and Purpose of System Requirements==
+
System requirements play major roles in systems engineering, as they:
'''Introduction''' - This section provides knowledge about the notion of system requirements, the translation of Stakeholder Requirements into System Requirements, the relationships between the system requirements of the system-of-interest and those of its systems or system elements, and the related SE activities and methods. The set of baselined System Requirements is one of the major outcomes of these activities. This set represents the problem from a supplier and a designer point of view, and it can be viewed also as a model of the expected System-of-Interest.
+
* Form the basis of system {{Term|Architecture (glossary)|architecture}} and {{Term|Design (glossary)|design}} activities.
 +
*Form the basis of system {{Term|Integration (glossary)}} and {{Term|Verification (glossary)|verification}} activities.
 +
* Act as reference for {{Term|Validation (glossary)|validation}} and stakeholder acceptance.
 +
* Provide a means of communication between the various technical staff that interact throughout the project.
  
 +
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis.  System requirements are considered in detail during [[System Definition|System Definition]]. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.
  
'''Definition and Purpose''' - A requirement is “a statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.” ('''INCOSE 2010''', p. 362). The System Requirements are all of the requirements at the “system level” that have been properly translated from the list of stakeholders' requirements. The System Requirements will form the basis of system design, verification, and stakeholder acceptance. In this context, the “stakeholders” include, but are not limited to, end users, end user organizations, supporters, developers, producers, trainers, maintainers, disposers, acquirers, customers, operators, supplier organizations, accreditors, and regulatory bodies.  ('''ISO/IEC June 2010''')
+
==Definition and Purpose of Requirements==
 +
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO 2007).
  
System Requirements play major intricate roles in the engineering activities. They serve:
+
To avoid confusion in the multitude of terms pertaining to ''{{Term|Requirement (glossary)|requirements}}'', consider the following classifications:
*as the essential inputs of the system design activities, in order designers know what characteristics are expected and so being able to give corresponding properties to the solution.
+
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled).  
*as reference for the system validation activities, in order testers may review the requirements during their development checking their right expression as validation reference, and identifying the necessary means to test the system against the requirements.
+
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.
*as a communication means, between the various technical staff that interact within the project.
+
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.
  
 +
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to (Martin 1997, Chapter 2).
  
 +
==Principles Governing System Requirements==
 +
===Relationship to Stakeholder Requirements and Logical Architecture===
 +
A set of {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}} are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis.
  
----
+
The system requirements are based around identification and {{Term|Synthesis (glossary)|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 {{Term|System Requirement (glossary)|system requirements}} are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent,  exhaustive, and verifiable. Of course, 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 {{Term|System Realization (glossary)|system realization}}.
  
==Principles about System Requirements==
+
The {{Term|Logical Architecture (glossary)}} defines system boundary and functions, from which more detailed system requirements can be derived.  The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]).  However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems {{Term|Life Cycle Model (glossary)}}.
===Translation of Stakeholder Requirements into System Requirements===
 
Quite often, the set of Stakeholder Requirements may contain vague, ambiguous, and qualitative “user-oriented” requirements that are difficult to use for design or to verify. Each of these requirements may need to be further clarified and translated into “engineering-oriented” language to enable proper design and verification activities. The System Requirements resulting from this translation are expressed in technical language useful for design; unambiguous, consistent, with no contradiction, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate.
 
  
As an example, a need or an expectation such as "To manoeuvre easily a car to park it", will be transformed in a set of Stakeholder Requirements such as, "Increase the drivability of the car", "Decrease the effort for handling", "Assist the piloting", "Protect the coachwork against shocks or scratch", etc. Analyzing for example the Stakeholder Requirement "Increase the drivability of the car", it will be translated in a set of System Requirements specifying measurable characteristics such as the turning circle (steering lock), the wheelbase, etc.
+
====Traceability and the Assignment of System Requirements during Architecture and Design====
 +
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see [[Applying Life Cycle Processes]]). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.
  
 +
During {{Term|Architecture (glossary)|architecture}} definition and {{Term|Design (glossary)|design}}, the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.
  
===Traceability and assignment of System Requirements during design===
+
<center>
Requirements traceability provides the ability to trace information from the origin of the Stakeholder Requirements at the top level to the lowest level of the system hierarchy - see section "Top-down and recursive approach to system decomposition" in the topic [[Fundamentals of System Definition]]. Traceability is also used to provide an understanding of the extent of a change as an input to impact analyses conducted with respect to proposed engineering improvements or requests for change.
+
{|
 +
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)
 +
!Assignment Type for a System Requirement
 +
!Description
 +
|-
 +
|'''Direct Assignment'''
 +
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).
 +
|-
 +
|'''Indirect Assignment (Simply Decomposed)'''
 +
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.
 +
|-
 +
|'''Indirect Assignment (Modeled and Decomposed)'''
 +
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.
 +
|-
 +
|'''Derived Requirement (from Design)'''
 +
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.
 +
|}
 +
</center>
  
During design, the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate:
+
===Classification of System Requirements===
#'''Direct assignment''': the System Requirement from the higher level is directly assigned to a system or a system element of a lower level (for example, the color used to paint visible parts of the products)
+
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).
#'''Indirect assignment''' (simply decomposed): the System Requirement is distributed across several systems or system elements and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed “assignment budget” for each assignment must be maintained.
 
#'''Indirect assignment''' (modeled and decomposed): the System Requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulted design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc. will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.
 
#'''Derived requirement''' (from design): such System Requirements are developed during the design activities as a result of decision of the design team, not the stakeholder community. These requirements may include the use of Commercial-Off-the-Shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a “best value” solution for the customer. As such, these design/dereived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.
 
  
 +
<center>
 +
{|
 +
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)
 +
!Types of System Requirement
 +
!Description
 +
|-
 +
|'''Functional Requirements'''
 +
|Describe qualitatively the system functions or tasks to be performed in operation.
 +
|-
 +
|'''Performance Requirements'''
 +
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.
 +
|-
 +
|'''Usability Requirements'''
 +
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).
 +
|-
 +
|'''Interface Requirements'''
 +
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.
 +
|-
 +
|'''Operational Requirements'''
 +
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.
 +
|-
 +
|'''Modes and/or States Requirements'''
 +
|Define the various operational modes of the system in use and events conducting to transitions of modes.
 +
|-
 +
|'''Adaptability Requirements'''
 +
|Define potential extension, growth, or scalability during the life of the system.
 +
|-
 +
|'''Physical Constraints'''
 +
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.
 +
|-
 +
|'''Design Constraints'''
 +
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).
 +
|-
 +
|'''Environmental Conditions'''
 +
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).
 +
|-
 +
|'''Logistical Requirements'''
 +
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.
 +
|-
 +
|'''Policies and Regulations'''
 +
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).
 +
|-
 +
|'''Cost and Schedule Constraints'''
 +
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.
 +
|}
 +
</center>
  
===Classification of System Requirements===
+
===Requirements Management===
Several classifications of System Requirements are possible, depending on the requirements definition methods and/or the design methods used. '''ISO/IEC 29148:2011 – Systems and software engineering – Life cycle processes – Requirements engineering''' provides a classification summarized below – see references for other interesting classifications:
+
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, 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.
#'''Functional requirements''': describe qualitatively the system functions or tasks to be performed in operation.
 
#'''Performance requirements''': define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.
 
#'''Usability requirements''': define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.
 
#'''Interface requirements''': define how the system is required to interact or to exchange material, energy or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface Requirements include physical connections (Physical Interfaces) with external systems or internal system elements supporting interactions or exchanges.
 
#'''Operational requirements''': define operational conditions or properties under which the system is required to operate or exist. This type of requirements includes human factors and ergonomics, availability, maintainability, reliability, security.
 
#'''Modes and/or states requirements''': define the various Operational Modes of the system in use, and events conducting to Transitions of Modes.
 
#'''Adaptability requirements''': define potential extension, growth or scalability during the life of the system.
 
#'''Physical constraints''': define constraints on weight, volume and dimension applicable on system elements that compose the system.
 
#'''Design constraints''': define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an on-line repository).
 
#'''Environmental conditions''': define the environmental conditions to be encountered by the system in its different Operational Modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats, societal environment (e.g. legal, political, economic, social, business, etc.)
 
#'''Logistical requirements''': define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.
 
#'''Policies and regulations constraints''': define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labour policies, reports to regulatory agency, health or safety criteria, etc.).
 
#'''Cost and schedule constraints''': define for example the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.
 
  
 +
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.  Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control.  When the requirements have been defined, documented, and approved, they need to be put under baseline management and control.  The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.
  
----
+
==Process Approach==
 
 
==Process Approach – System Requirements==
 
 
===Purpose and Principle of the Approach===
 
===Purpose and Principle of the Approach===
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet Stakeholder Requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable System Requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements('''ISO/IEC 2008''')
+
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO 2015).
  
 +
===Activities of the Process===
 +
Major activities and tasks during this process include:
 +
# Analyzing the stakeholder requirements to check completeness of expected services and {{Term|Operational Scenario (glossary)|operational scenarios}}, conditions, operational modes, and constraints.
 +
# Defining the system requirements and their {{Term|Rationale (glossary)|rationale}}.
 +
# Classifying the system requirements using suggested classifications (see examples above).
 +
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.
 +
# Establishing the upward traceability with the stakeholder needs and requirements.
 +
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy.
 +
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.
 +
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.
 +
# Identifying potential {{Term|Risk (glossary)|risks}} (or threats and hazards) that could be generated by the system requirements.
 +
# Synthesizing, recording, and managing the system requirements and potential associated risks.
 +
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.
  
===Activities of the process===
+
===Checking Correctness of System Requirements===
Major activities and tasks performed during this process include:
+
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).
#Analyzing the Stakeholder Requirements to check completeness of expected services and operational Scenarios, conditions, Operational Modes, and constraints.
 
#Defining the System Requirements and its Rationale.
 
#Classifying the System Requirements using suggested classifications classifications – see examples above.
 
#Incorporating the derived requirements (coming from design) into the System Requirements baseline.
 
#Establishing the upward traceability with the Stakeholder Requirements.
 
#Verifying the quality, completeness of each System Requirement and the consistency of the set of System Requirements.
 
#Validating the content and relevance of each System Requirement against the set of Stakeholder  Requirements.
 
#Identifying potential Risks (or threats and hazards) that could be generated by the System Requirements.
 
#Synthesizing, recording, and managing the System Requirements and potential associated Risks.
 
  
 +
===Methods and Modeling Techniques===
 +
====Requirements Elicitation and Prototyping====
 +
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.
  
===Artifacts and Ontology Elements===
+
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.
This process may create several artifacts such as:
 
#System Requirements Document
 
#System Requirements Justification Document (for traceability purpose)
 
#System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.
 
#System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the System Requirements Document above).
 
  
This process handles the ontology elements of the Table below.
+
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.
  
TABLE - Main ontology elements as handled within system requirements definition
+
====Capturing Requirements Rationale====
 +
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely 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. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).
  
 +
Some of the benefits of this approach include:
 +
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.
 +
* '''Early exposure of bad assumptions'''
 +
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation.
 +
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).
  
The main relationships between ontology elements are presented in Figure below.
+
====Modeling Techniques====
 +
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:
 +
* State-charts models (ISO 2011, Section 8.4)
 +
* Scenarios modeling (ISO 2011, Section 6.2.3.1)
 +
* Simulations, prototyping (ISO 2011, Section 6.3.3.2)
 +
* Quality Function Deployment (INCOSE 2011, p. 83)
 +
* Systems Modeling Language (SysML) sequence diagrams, activity diagrams, use cases, state machine diagrams, requirements diagrams (OMG 2010)
 +
* Functional Flow Block Diagram for operational scenarios (Oliver, Kelliher, and Keegan 1997)
  
FIGURE - System Requirements relationships with other engineering elements. © Alain Faisandier-2011
+
====Presentation and Quality of Requirements====
 +
Generally, requirements are provided in a textual form. Guidelines exist for writing good 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 (INCOSE 2011, Section 4.2.2.2) and (ISO 2011).
  
 +
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).
  
===Checking and Correctness of System Requirements===
+
<center>
System Requirements should be checked to gauge whether they are well expressed and appropriate. There are number of characteristics which can be used to check System Requirements. The set of System Requirements can be verified using standard peer review techniques and by comparing each requirement against the set of requirements characteristics listed in the Tables of the section "Presentation and Quality of Requirements".
+
{|
 +
|+'''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 the requirements 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.
 +
|}
 +
</center>
  
The requirements can be validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques" further.
+
Note: Traceability is considered by some sources as a characteristic (ISO 2011). However, a recent viewpoint is that Traceability is actually an attribute of a requirement; that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement (INCOSE 2011). The traceability characteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.  
  
===5.3.5. Methods and Modeling Techniques===
+
<center>
====5.3.5.1 Requirements Elicitation and Prototyping====
+
{|
Requirements Elicitation is one approach that requires user involvement, and can be effective in gaining stakeholder involvement and buy-in. QFD (Quality Function Deployment) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.
+
|+'''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).
 +
|}
 +
</center>
  
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs. The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.
+
====Requirements in Tables====
 +
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply:
 +
* Invoke each requirements table in the requirements set that clearly points to the table.
 +
* Identify each table with a unique title and table number.
 +
* Include the word “requirements” in the table title.
 +
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.
 +
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.
 +
* Each cell should contain, at most, a single requirement.
  
Early prototyping can help the users and developers identify the functional and operational requirements and user interface constraints through interactive use of system elements, models, and simulations. The prototyping allows for realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This helps to form a more complete set of requirements by improving the user’s requirements understanding.
+
====Requirements in Flow Charts====
 +
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:
 +
* Invoke flow charts in the requirements set that clearly points to the flow chart.
 +
* Identify each flow chart with a unique title and figure number.
 +
* Include the word “requirements” in the title of the flow chart.
 +
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.
  
====5.3.5.2. Capturing Requirements Rationale====
+
====Requirements in Drawings====
One of the most powerful and cost-effective techniques to translate stakeholder requirements to design requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This is especially powerful in capturing the rationale for stakeholder requirements, as this supports further requirements analysis and decomposition. The rationale can be captured directly in the requirements database. Of course, stakeholder involvement is essential for this process.
+
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:
 +
* Drawings are used when they can aid in the description of the following:
 +
** Spatial Requirements
 +
** Interface Requirements
 +
** Layout Requirements
 +
* Invoke drawings in the requirements set that clearly point to the drawing.
  
Some of the benefits of capturing requirements rationale include:
+
===Artifacts===
*'''Reducing the total number of requirements'''. As requirements are gathered and rationale is required for each, the requirement author may realize that a particular requirement may not be required or supportable, or that it duplicates an existing requirement. Reducing requirements count will reduce project cost and risk.
+
This process may create several artifacts, such as:
*'''Early exposure of bad assumptions'''. Many poorly written or incorrect requirements are based upon faulty assumptions. By capturing (and questioning) requirements rationale, incorrect or faulty assumptions can be exposed early in the process, and the related requirements can be eliminated or properly rewritten.
+
* System Requirements Document
*'''Removes design implementation'''. Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. The requirements authors may be jumping to solution space, rather that stating the problem to be solved. By properly capturing requirements rationale, these “design requirements” are often exposed and rewritten properly to allow appropriate design latitude to develop a cost-effective solution.
+
* System Requirements Justification Document (for traceability purpose)
*'''Improves communication with the stakeholder community'''. By capturing the requirements rationale for all Stakeholders Requirements, the line of communication between the users and the designers is greatly improved. This will result in better understanding of the problem space, elimination of ambiguous requirements, and, eventually, a greatly improved system validation process, etc. since the intent of the stakeholders is well-documented and clarified. Adapted from (Hooks and Farry 2000, Chapter 8).
+
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.
 +
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.
  
====5.3.5.3. Modeling Techniques====
+
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.
Modeling techniques can be used when requirements must be detailed or refined, or when they address topics not considered during the Stakeholders’ Requirements Definition and Mission Analysis:
 
*State-charts models ('''ISO/IEC June 2010''', Section 8.4.2)
 
*Scenarios modeling ('''ISO/IEC June 2010''', Section 6.2.3.1)
 
*Simulations, prototyping ('''ISO/IEC June 2010''', Section 6.3.3.2)
 
*Quality Function Deployment ('''INCOSE 2010''', p. 83)
 
*Etc.
 
  
ADD ACTION RELATED TO COMMENT 1157 and others
+
==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.
  
====5.3.5.4. Presentation and Quality of Requirements====
+
<center>
Generally, requirements are provided in a textual form. Guidelines exist to write good requirements; they include recommendations about sentence syntax, wording (exclusions, representation of concepts, etc.), semantics (specific, measurable, achievable, realistic, testable). Refer to ('''INCOSE 2010''', section 4.2.2.2).
+
{|
 +
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)
 +
!Pitfall
 +
!Description
 +
|-
 +
|'''Insufficient Analysis of Stakeholder 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.
 +
|}
 +
</center>
  
There are several characteristics of requirements and sets of requirements that ensure the quality of requirements. These are used both to aid the development of the requirements and to verify the implementation of requirements into the solution. Table 4 provides a list and descriptions of the characteristics for individual requirements and Table 5 provides a list and descriptions of characteristics for a set of requirements, as adapted from ('''ISO/IEC June 2010''', sections 5.2.5 and 5.2.6).
 
  
TABLE 4
+
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.
  
TABLE 5
+
<center>
 +
{|
 +
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)
 +
!Practice
 +
!Description
 +
|-
 +
|'''Involve Stakeholders'''
 +
|Involve the stakeholders as early as possible in the system requirements development process.
 +
|-
 +
|'''Presence of Rationale'''
 +
|Capture the rationale for each system requirement.
 +
|-
 +
|'''Always Complete before Starting'''
 +
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.
 +
|-
 +
|'''Peer Reviews'''
 +
|Organize peer reviews of system requirements with applicable subject matter experts.
 +
|-
 +
|'''Modeling Techniques'''
 +
|Use modeling techniques as indicated in sections above.
 +
|-
 +
|'''Requirements Management Tool'''
 +
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.
 +
|-
 +
|'''Measures for Requirement Engineering'''
 +
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:
 +
* Requirements Volatility
 +
* Requirements Trends
 +
* Requirements Verification Progress (plan vs. actual)
 +
* Requirements Validation Progress (plan vs. actual)
 +
* TBD and TBR Closure Per Plan
 +
* Peer Review Defects
 +
|}
 +
</center>
  
ADD ACTION RELATED TO COMMENT 3106
+
==References==
  
====5.3.5.5. Requirements in Tables====
+
===Works Cited===
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply:
+
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988).
*Invoke each requirements table by using a “shall” statement in the requirements set that clearly points to the table.
 
*Identify each table with a unique title and table number.
 
*Include the word “requirements” in the table title.
 
*Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.
 
*For independent-dependant variable situations, organize the table in a way that best accommodates the use of the information.
 
*Each cell should contain, at most, a single requirement.
 
  
====5.3.5.6. Requirements in Flow Charts====
+
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.
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:
 
*Invoke flow charts using a “shall” statement in the requirements set that clearly points to the flow chart.
 
*Identify each flow chart with a unique title and figure number.
 
*Include the word “requirements” in the title of the flow chart
 
*Clearly indicate and explain unique symbols that represent requirements in the flow chart.
 
  
====5.3.5.7. Requirements in Drawings====
+
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. For drawings, the following conventions apply:
 
*Drawings are used when they can aid in the description of the following:
 
** Spatial requirements
 
**Interface requirements
 
**Layout requirements
 
*Invoke drawings by using a “shall” statement in the requirements set that clearly points to the drawing.
 
  
==5.4. Application to Product systems, Service systems, Enterprise systems==
+
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
  
TO BE WRITTEN
+
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.
  
==5.5. Practical Considerations about System Requirements==
+
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Requirements Engineering''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.  
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements. These pitfalls include:  
 
#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.
 
#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 and help the designer to remember functions and interfaces.
 
#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 or validation of the system will be delayed.
 
#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.
 
#Incorrect or missing traceability of each requirement, both to an upper-level “parent” requirement and allocation to an appropriate system or system element.
 
  
 +
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. ISO/IEC/IEEE 15288:2015.
  
The following '''proven practices''' in system requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development:
+
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.
#Involve the stakeholders early in the System Requirements development process.
 
#Capture the rationale for each System Requirement.
 
#Check that Stakeholder Requirements are complete as much as possible before starting the definition of the System Requirements.
 
#Organize peer reviews of System Requirements with applicable subject matter experts.
 
#Use modeling techniques as indicated in section '''3.3.5.3.5'''.
 
#Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between System Requirements to show relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.
 
#Use typical measures for requirement engineering - refer to the Systems Engineering Leading Indicators Guide ('''Roedler et al. 2010'''). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:
 
##Requirements volatility
 
##Requirements trends
 
##Requirements verification progress (plan vs. actual)
 
##Requirements validation progress (plan vs. actual)
 
##TBD and TBR closure progress per plan
 
##Peer Review defects
 
  
 +
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering complex systems with models and objects''. New York, NY, USA: McGraw-Hill.
  
----
+
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2. Needham, MA: Object Management Group. July 2010.
  
==5.6. Primary References related to System Requirements==
+
===Primary References===
(ISO/IEC June 2010)
 
  
IEEE 830
+
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].
  
(ISO/IEC 2008)
+
ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|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.[[ISO/IEC/IEEE 15288]]:2015.
  
(van Lamsweerde 2009)
+
INCOSE. 2015. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0
  
(Faisandier 2011)
+
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.
  
 +
===Additional References===
  
----
+
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.  
 
 
==5.7. Additional References and Readings related to System Requirements==
 
(Roedler et al. 2010)
 
  
 +
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.
  
==References==
+
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
 
  
===Citations===
+
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.
List all references cited in the articleNote:  SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
 
  
===Primary References===
+
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).  
All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ ([[title]]).  Please do not include version numbers in the links.
 
  
===Additional References===
 
All additional references should be listed in alphabetical order.
 
 
----
 
----
====Article Discussion====
 
  
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[System Architecture|Next Article >]]</center>
 +
 
 +
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
  
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
 +
[[Category:System Definition]]

Latest revision as of 09:11, 28 October 2019


Lead Authors: Alan Faisandier, Garry Roedler, Contributing Author: Richard Turner, Rick Adcock, Ariela Sofer


System requirementsSystem requirements are all of the requirementsrequirements at the system level that describe the functions which the system as a whole should fulfill to satisfy the stakeholder needs and requirementsstakeholder needs and requirements, and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary.

System requirements play major roles in systems engineering, as they:

  • Form the basis of system architecturearchitecture and designdesign activities.
  • Form the basis of system integrationintegration and verificationverification activities.
  • Act as reference for validationvalidation and stakeholder acceptance.
  • Provide a means of communication between the various technical staff that interact throughout the project.

Elicitation of stakeholder requirements starts in Concept Definition, and will be initially developed though interview and mission analysis. System requirements are considered in detail during System Definition. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.

Definition and Purpose of Requirements

A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO 2007).

To avoid confusion in the multitude of terms pertaining to requirementsrequirements, consider the following classifications:

  • Process Role or State: The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled).
  • Level of Abstraction: The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.
  • Type of Requirement: The nature of the requirement itself; for instance, functional, performance, constraint, etc.

Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to (Martin 1997, Chapter 2).

Principles Governing System Requirements

Relationship to Stakeholder Requirements and Logical Architecture

A set of stakeholder requirementsstakeholder requirements are clarified and translated from statements of need into engineering-oriented language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis.

The system requirements are based around identification and synthesissynthesis 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 requirementssystem requirements are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, 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 realizationsystem realization.

The logical architecturelogical architecture defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see Synthesizing Possible Solutions). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems life cycle modellife cycle model.

Traceability and the Assignment of System Requirements during Architecture and Design

Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see Applying Life Cycle Processes). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.

During architecturearchitecture definition and designdesign, the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.

Table 1. Assessment Types for a System Requirement. (SEBoK Original)
Assignment Type for a System Requirement Description
Direct Assignment The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).
Indirect Assignment (Simply Decomposed) The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.
Indirect Assignment (Modeled and Decomposed) The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.
Derived Requirement (from Design) Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.

Classification of System Requirements

Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).

Table 2. Example of System Requirements Classification. (SEBoK Original)
Types of System Requirement Description
Functional Requirements Describe qualitatively the system functions or tasks to be performed in operation.
Performance Requirements Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.
Usability Requirements Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).
Interface Requirements Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.
Operational Requirements Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.
Modes and/or States Requirements Define the various operational modes of the system in use and events conducting to transitions of modes.
Adaptability Requirements Define potential extension, growth, or scalability during the life of the system.
Physical Constraints Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.
Design Constraints Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).
Environmental Conditions Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).
Logistical Requirements Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.
Policies and Regulations Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).
Cost and Schedule Constraints Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.

Requirements Management

Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, 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.

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. Requirements management is also closely tied to configuration management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.

Process Approach

Purpose and Principle of the Approach

The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO 2015).

Activities of the Process

Major activities and tasks during this process include:

  1. Analyzing the stakeholder requirements to check completeness of expected services and operational scenariosoperational scenarios, conditions, operational modes, and constraints.
  2. Defining the system requirements and their rationalerationale.
  3. Classifying the system requirements using suggested classifications (see examples above).
  4. Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.
  5. Establishing the upward traceability with the stakeholder needs and requirements.
  6. Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy.
  7. Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.
  8. Validating the content and relevance of each system requirement against the set of stakeholder requirements.
  9. Identifying potential risksrisks (or threats and hazards) that could be generated by the system requirements.
  10. Synthesizing, recording, and managing the system requirements and potential associated risks.
  11. Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.

Checking Correctness of 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).

Methods and Modeling Techniques

Requirements Elicitation and Prototyping

Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.

QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.

Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.

Capturing Requirements Rationale

One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely 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. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).

Some of the benefits of this approach include:

  • Reducing the total number of requirements - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.
  • Early exposure of bad assumptions
  • Removes design implementation - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation.
  • Improves communication with the stakeholder community - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).

Modeling Techniques

Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:

  • State-charts models (ISO 2011, Section 8.4)
  • Scenarios modeling (ISO 2011, Section 6.2.3.1)
  • Simulations, prototyping (ISO 2011, Section 6.3.3.2)
  • Quality Function Deployment (INCOSE 2011, p. 83)
  • Systems Modeling Language (SysML) sequence diagrams, activity diagrams, use cases, state machine diagrams, requirements diagrams (OMG 2010)
  • Functional Flow Block Diagram for operational scenarios (Oliver, Kelliher, and Keegan 1997)

Presentation and Quality of Requirements

Generally, requirements are provided in a textual form. Guidelines exist for writing good 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 (INCOSE 2011, Section 4.2.2.2) and (ISO 2011).

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

Note: Traceability is considered by some sources as a characteristic (ISO 2011). However, a recent viewpoint is that Traceability is actually an attribute of a requirement; that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement (INCOSE 2011). The traceability characteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.

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

Requirements in Tables

Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply:

  • Invoke each requirements table in the requirements set that clearly points to the table.
  • Identify each table with a unique title and table number.
  • Include the word “requirements” in the table title.
  • Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.
  • For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.
  • Each cell should contain, at most, a single requirement.

Requirements in Flow Charts

Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:

  • Invoke flow charts in the requirements set that clearly points to the flow chart.
  • Identify each flow chart with a unique title and figure number.
  • Include the word “requirements” in the title of the flow chart.
  • Clearly indicate and explain unique symbols that represent requirements in the flow chart.

Requirements in Drawings

Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:

  • Drawings are used when they can aid in the description of the following:
    • Spatial Requirements
    • Interface Requirements
    • Layout Requirements
  • Invoke drawings in the requirements set that clearly point to the drawing.

Artifacts

This process may create several artifacts, such as:

  • System Requirements Document
  • System Requirements Justification Document (for traceability purpose)
  • System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.
  • System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.

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.

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


The proven practices in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.

Table 6. Proven Practices for System Requirements. (SEBoK Original)
Practice Description
Involve Stakeholders Involve the stakeholders as early as possible in the system requirements development process.
Presence of Rationale Capture the rationale for each system requirement.
Always Complete before Starting Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.
Peer Reviews Organize peer reviews of system requirements with applicable subject matter experts.
Modeling Techniques Use modeling techniques as indicated in sections above.
Requirements Management Tool Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.
Measures for Requirement Engineering Use typical measures for requirement engineering; for further information, refer to the Systems Engineering Leading Indicators Guide (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:
  • Requirements Volatility
  • Requirements Trends
  • Requirements Verification Progress (plan vs. actual)
  • Requirements Validation Progress (plan vs. actual)
  • TBD and TBR Closure Per Plan
  • Peer Review Defects

References

Works Cited

Hauser, J. and D. Clausing. 1988. "The House of Quality." Harvard Business Review. (May - June 1988).

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.

INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

ISO/IEC. 2007. Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), 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. ISO/IEC/IEEE 15288:2015.

Martin, J.N. 1997. Systems Engineering Guidebook: A Process for Developing Systems and Products, 1st ed. Boca Raton, FL, USA: CRC Press.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY, USA: McGraw-Hill.

OMG. 2010. OMG Systems Modeling Language specification, version 1.2. Needham, MA: Object Management Group. July 2010.

Primary References

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), 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.ISO/IEC/IEEE 15288:2015.

INCOSE. 2015. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0

Lamsweerde, A. van. 2009. Requirements Engineering: From System Goals to UML Models to Software Specifications. New York, NY, USA: Wiley.

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


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019