System Requirements Definition

5.1. Introduction, Definition and Purpose of System Requirements

Introduction - This section provides knowledge about the notion of system requirements, the translation of stakeholders’ requirements into System Requirements, the relationships between the system requirements of the system-of-interest and those of its sub-systems or system elements, and the related SE activities and methods. The set of baselined System Requirements represents the problem from a supplier and a designer point of view, and is one of the major outcomes of these activities.

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)

---

5.2. Principles about System Requirements

5.2.1. Translation of Stakeholder Requirements into System Requirements

Quite often, the set of Stakeholder Requirements could 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 Stakeholder Requirement such as, "The users expect a comfortable means of transportation" will be translated in a set of System Requirements specifying thermal monitoring conditions, vibration level, acoustic ambiance, ergonomic characteristics of seats, etc. as measurable characteristics.

5.2.2. Utility of requirements definition

ADD ACTION RELATED TO COMMENT 3038

5.2.3. Traceability and Allocation of System Requirements during design

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

ADD ACTION RELATED TO COMMENT 827, 2226

During design, the allocation of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate:

1. Direct allocation: the system requirement from the higher level is directly allocated to a sub-system or a system element (for example, the color used to paint visible parts of the products)
2. Indirect allocation: the System Requirement is distributed across several sub-systems and the sum or a more complex calculation 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 “allocation budget” for each allocation must be maintained.
3. Derived allocation: the System Requirement is allocated to several sub-systems using an analysis or mathematical modeling technique, and the derived design parameters are allocated to the appropriate sub-systems (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 allocated to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.
4. Derived or Design requirement: 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 subsystems in inventory, common components, and similar design decisions in order to produce a “best value” solution for the customer. As such, these design requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or constraint.

5.2.4. Classification of System Requirements

ADD ACTION RELATED TO COMMENT 406

Several classifications of System Requirements are possible, depending on the requirements definition methods and/or the design methods used. (ISO/IEC June 2010) provides a classification summarized below – see references for other interesting classification:

1. Functional Requirements: describes qualitatively the system or system element functions or tasks to be performed.
2. Performance Requirements: defines quantitatively the extent, or how well, and under what conditions a function or task is to be performed. 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.
3. Interface Requirements: defines how the system is required to interact with external systems (external interface) or how system elements within the system, including human elements, interact with each other (internal interface).
4. Design Constraints: defines 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).
5. Non-Functional Requirements: These specify requirements under which the system is required to operate or exist or its properties. They define how a system is supposed to be. Quality requirements and human factors requirements are examples of this type.
6. Process requirements: These are stakeholder, usually acquirer or user, requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather how the end-item system is developed and provided. Process requirements include compliance with national, state or local laws, including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.

ADD ACTION RELATED TO COMMENT 1155, 2743, 2744, 2745, 2746

---

5.3. Process Approach – System requirements

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

5.3.2. Activities of the process

Major activities and tasks performed during this process include:

1. Analyzing the Stakeholder Requirements to check completeness of expected services and operational Scenarios, conditions, and constraints.
2. Defining the System Requirements and its Rationale.
3. Classifying the System Requirements using suggested classifications.
4. Incorporating the derived requirements (coming from design) into the System Requirements baseline.
5. Establishing the upward traceability with the Stakeholder Requirements.
6. Verifying the quality, completeness of each System Requirement and the consistency of the set of System Requirements.
7. Validating the content and relevance of each System Requirement against the set of Stakeholders' Requirements.
8. Synthesizing, recording, and managing the System Requirements and potential associated Risks.

5.3.3. Artifacts and Ontology Elements

This process may create several artifacts such as:

1. System Requirements Document
2. System Requirements Justification Document (for traceability purpose)
3. System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.
4. 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 3.

TABLE 3

The main relationships between ontology elements are presented in Figure 6.

FIGURE 6

5.3.4. Checking and Correctness of System Requirements

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 Table 3 and Table 4 of section 3.3.5.3.5.4.

The requirements can be validated using the requirements elicitation and rationale capture described in section 3.3.5.3.5.

5.3.5. Methods and Modeling Techniques

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.

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.

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.

5.3.5.2. Capturing Requirements Rationale

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.

Some of the benefits of capturing requirements rationale include:

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

5.3.5.3. Modeling Techniques

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

5.3.5.4. Presentation and Quality of Requirements

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

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

TABLE 5

ADD ACTION RELATED TO COMMENT 3106

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

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

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

TO BE WRITTEN

5.5. Practical Considerations about System Requirements

There are several pitfalls that will inhibit the generation and management of an optimal set of system requirements. These pitfalls include:

1. 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.
2. 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.
3. 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.
4. 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.
5. Incorrect or missing traceability of each requirement, both to an upper-level “parent” requirement and allocation to an appropriate system or system element.

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:

1. Involve the stakeholders early in the System Requirements development process.
2. Capture the rationale for each System Requirement.
3. Check that Stakeholder Requirements are complete as much as possible before starting the definition of the System Requirements.
4. Organize peer reviews of System Requirements with applicable subject matter experts.
5. Use modeling techniques as indicated in section 3.3.5.3.5.
6. 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.
7. 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:
   1. Requirements volatility
   2. Requirements trends
   3. Requirements verification progress (plan vs. actual)
   4. Requirements validation progress (plan vs. actual)
   5. TBD and TBR closure progress per plan
   6. Peer Review defects

---

5.6. Primary References related to System Requirements

(ISO/IEC June 2010)

IEEE 830

(ISO/IEC 2008)

(van Lamsweerde 2009)

(Faisandier 2011)

---

5.7. Additional References and Readings related to System Requirements

(Roedler et al. 2010)

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

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

[Go to discussion page]