Activities of the process
Major activities and tasks during this process include
1. Analyze the stakeholder requirements to check completeness of expected services and operational scenarios (glossary), conditions, operational modes, and constraints.
2. Define the system requirements and their rationale.
3. Classify the system requirements using suggested classifications (see examples above).
4. Incorporate the derived requirements (coming from architecture and design) into the system requirements baseline.
5. Establish the upward traceability with the stakeholder needs and requirements.
6. Establish bi-directional traceability between requirements at adjacent levels of the system hierarchy.
7. Verify the quality and completeness of each system requirement and the consistency of the set of system requirements.
8. Validate the content and relevance of each system requirement against the set of stakeholder requirements.
9. Identify potential risks (or threats and hazards) that could be generated by the system requirements.
10. Synthesize, record, and manage the system requirements and potential associated risks.
11. Upon approval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established configuration management practices.
Checking and Correctness of System Requirements
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics which 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 (above). Requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques" (below).
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).
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.
Characteristics of Individual Requirements. (SEBoK Original)
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.
Characteristics of a Set of Requirements. (SEBoK Original)
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.
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.
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.
Rationale Argument that provides the justification for the selection of an engineering element.
Scenario A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.
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.