System Requirements Definition
System requirements are all of the requirements at the system level that describe the functions which the system as a whole should fulfil to satisfy the stakeholders', expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability etc, which are called for.
System requirements play major roles in the Systems Engineering, they
- form the basis of system architecture and design activities;
- form the basis of system integration and verification activities;
- are a reference for validation, and stakeholder acceptance; and
- a means of communication between the various technical staff that interact within 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 process operational, functional, or design characteristic or constraint which is unambiguous, testable or measurable and necessary for product or process acceptability (ISO/IEC 2007).
To avoid confusion in the multitude of terms around requirements, 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: translated, derived, satisfied; or its state of agreement: proposed, approved, cancelled.
- Level of abstraction: The level within the definition process for 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 kinds of requirements, refer to chapter 2 of Martin (1997).
Principles Governing System Requirements
Stakeholder Requirements
The set of stakeholder requirements may contain vague, ambiguous, and qualitative user-oriented need statements 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 architecture definition, design, and verification activities. The system requirements resulting from this translation are expressed in technical language 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.
As an example, a need or an expectation such as To easily maneuver a car in order to park 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. This results in a set of system requirements specifying measurable characteristics.
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 ensuring 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.
Traceability and Assignment of System Requirements during Architecture and Design
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements at the top level to requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the System Definition article). 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.
During architecture definition and 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.
| 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 (for example, 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 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 resulting 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 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 used. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).
| 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 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 requirement 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 lift 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 online 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 | 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. |
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/IEC 2008).
Activities of the process
Major activities and tasks during this process include
- Analyze the stakeholder requirements to check completeness of expected services and operational scenarios , conditions, operational modes, and constraints.
- Define the system requirements and their rationale.
- Classify the system requirements using suggested classifications (see examples above).
- Incorporate the derived requirements (coming from architecture and design) into the system requirements baseline.
- Establish the upward traceability with the stakeholder needs and requirements.
- Establish bi-directional traceability between requirements at adjacent levels of the system hierarchy.
- Verify the quality and completeness of each system requirement and the consistency of the set of system requirements.
- Validate the content and relevance of each system requirement against the set of stakeholder requirements.
- Identify potential risks (or threats and hazards) that could be generated by the system requirements.
- Synthesize, record, and manage the system requirements and potential associated risks.
- Upon approval of the requirements, establish and 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 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 so 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 and 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 when they address topics not considered during the stakeholder requirements definition and mission analysis, include
- State-charts models (ISO/IEC 2011, Section 8.4)
- Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)
- Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)
- Quality Function Deployment (INCOSE. 2010, p. 83)
- Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams
- Functional Flow Block Diagram for Operational Scenario
Presentation and Quality of Requirements
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).
There are several characteristics of both requirements and sets of requirements that are used to aid the development of the requirements 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/IEC (2011, Sections 5.2.5 and 5.2.6).
| Characteristic | Description |
|---|---|
| Necessary | The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process. |
| Implementation Free | The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met. |
| Unambiguous | The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand. |
| Consistent | The requirement is free of conflicts with other requirements. |
| Complete | The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs. |
| Singular | The requirement statement includes only one requirement with no use of conjunctions. |
| Feasible | The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory). |
| Traceable | The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification 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. |
| Verifiable | The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable. |
| Characteristic | Description |
|---|---|
| Complete | The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note: Some practices are recommended to improve completeness; include all requirement types; account for requirements in all stages of the life cycle; and involve all stakeholders in the requirements elicitation activity. |
| Consistent | The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements. |
| Affordable | The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory). |
| Bounded | The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs. |
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; and
- 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 points to the drawing.
Artifacts and Ontology Elements
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 utilizes the ontology elements described in Table 5.
| Element | Definition
Attributes (Examples) |
|---|---|
| System Requirement | Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.
Identifier; name; description; parent (result of a stakeholder requirement translation or of a design choice); type (classification); effectivity (immediately applicable, allocated to a later version, etc.); verification method (inspection, analysis, demonstration, test, etc.); decision (result of a trade-off study having led to choosing or rejecting the requirement); status (identified, analyzed, verified, allocated, satisfied). Criticality (importance related to the safety and the availability of the system); weighing/priority (relative importance compared to others); history records (date, author, identification, and contents of the modification, type of modification, reason for the modification); comments. |
| Rationale | Argument that provides the justification for the selection of an engineering element.
Identifier; name; description (rational, reasons for a requirement to be satisfied). |
| Scenario | A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.
Identifier; name; description. |
| Risk | An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.
Identifier; name; description; status. |
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 6.
| Pitfall | Description |
|---|---|
| Insufficient analysis of stakeholder requirements | 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 and help the designer to remember functions and interfaces. |
| Uncompleted 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 and allocation to an appropriate system or system element. |
The proven practices in Table 7 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.
| Practice | Description |
|---|---|
| Involve stakeholders | Involve the stakeholders early in the system requirements development process. |
| Presence of rationale | Capture the rationale for each system requirement. |
| Always 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 show 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 - 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:
|
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., Jackson, K., Dick, A.J.J. 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. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
Martin, J.N. 1997. Systems Engineering Guidebook: A Process for Developing Systems and Products. 1st ed. Boca Raton, FL, USA: CRC Press.
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. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
INCOSE. 2011. INCOSE 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.
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).
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus