Summary of the INCOSE Requirements Writing Guide (June 2023)
Introduction
INCOSE (International Council for Systems Engineering) in June 2023 released a final summary of the guidelines for writing requirements (link).
This summary contains definitions, a brief description of the properties that well-formulated needs/requirements should have, and sets of needs/requirements. The summary contains a summary of the rules for writing quality needs/requirements, as well as their attributes.
This article is a translation from English of the final summary on writing requirements.
Definitions
Essence is a single element to which a concept, need, or requirement applies. An entity can be an organization, business unit, project, vendor, service, procedure, system (system, subsystem, system element), product, process, or class of stakeholders (user, operator, tester, maintainer, etc.).
Need Statement is the result of the formal transformation of one or more sources or life cycle concepts into an agreed commitment that an entity will perform a certain function or have a certain quality, within certain constraints, at an acceptable risk.
Statement of requirement is the result of the formal transformation of one or more higher-level sources, needs, or requirements into an agreed commitment that an entity will perform a certain function or have a certain quality, within certain constraints, at an acceptable risk.
A set of needs is a structured set of agreed expressions of needs for an entity (enterprise/business unit/system/subsystem/system element/process) and its external interfaces.
Requirements set is a structured set of consistent requirement expressions for an entity (enterprise/business unit/system/subsystem/system element/process) and its external interfaces.
Attribute – additional information related to the need / requirement, which is used to facilitate its / its definition, understanding and management.
Need expression – statement of need + attributes.
Requirement expression – requirement statement + attributes.
System Verification and Validation Processes
Needs and requirements “threads” link together all the stages and artifacts of the system creation life cycle. Once the needs are verified and validated, all subsequent artifacts are checked against the needs, and once the design input requirements are verified and validated, all subsequent artifacts are checked against those design input requirements.
Properties of Individual Needs/Requirements Statements
Formal transformation
Property | Brief description |
C1 – Necessity | A need/requirement statement identifies an important characteristic, capability, constraint, or quality that is actually needed to fulfill the underlying need or higher-level requirement. |
C2 – Adequacy to the level | The specific goal and level of detail of the need/requirement statement correspond to the selected level (level of abstraction, organization or system architecture) of the entity to which the need/requirement refers |
C5 – Simplicity | A need/requirement statement contains only one ability, characteristic, constraint, or quality indicator |
C8 – Correctness | The requirement statement should accurately reflect the life cycle concept or source from which it was created. The requirement statement must accurately reflect the need, source, higher-level requirement from which the requirement was created. |
C9 – Compliance | The need/requirement statement should follow an approved standard style/standard guide, a template for writing and managing needs and requirements. |
formal agreement
Property | Brief description |
C3 – Unambiguity | The entire audience that reads the need/requirement statement interprets it in the same way |
C4 – Completeness | A need statement adequately describes the necessary capability, characteristic, limitation, or quality to satisfy a need from the higher level source from which it was derived. The requirement statement adequately describes the necessary capability, characteristic, limitation, or quality to satisfy the higher level need, source, or requirement from which it was derived. |
C6 – Realizability | A need/requirement can be implemented with an acceptable risk within the given constraints: cost, time, technical, legal, ethical, security constraints |
C7 – Suitability for Verification | The need/requirement must be formulated and structured in such a way that its fulfillment can be verified by the approving body |
Requirements set properties
Formal transformation
Property | Brief description |
C10 – Completeness | The set of needs and requirements should adequately describe the required capabilities, characteristics, functionality, performance, drivers, constraints, conditions, interactions, standards, regulations, security, resiliency, and quality factors without other sets of needs or requirements at an appropriate level of abstraction. |
C11 – Consistency | A set of needs and a set of requirements is consistent if it contains separate needs or requirements that are unique, do not contradict, do not overlap with each other, are developed using a uniform language using consistent terms. |
C15 – Correctness | The set of needs should accurately reflect the concept of the life cycle or the source from which it was created. A set of requirements must accurately reflect the need, source, higher-level requirement from which it was created. |
formal agreement
Property | Brief description |
C12 – Feasibility | A set of needs/requirements can be implemented with acceptable risk within given constraints: cost, time, technical, legal, ethical, security constraints |
C13 – Comprehensibility | The set of needs/requirements should contain a clear description of the entity’s expectations and a description of the relationship of the entity to the system of which it is a part. |
C14 – Validability | The implementation of the set of needs should lead to the achievement of goals, stakeholder expectations and life cycle concepts within constraints (cost, time, technical, legal and regulatory) with acceptable risk. The implementation of a set of requirements should result in the satisfaction of a set of higher level needs and requirements within constraints (cost, time, technical, legal, and regulatory) at an acceptable risk. |
Rules giving properties
In order for a need/requirement to have certain properties of qualitative needs/requirements, certain rules must be followed.
Accuracy
R1 – Structured sentences
The wording of the need or requirement must follow a certain agreed pattern.
R2 – Active voice
In the formulation of needs or requirements, you need to use the active voice (rather than the passive) to clearly indicate which entity is the subject (subject).
R3 – Level-appropriate subject and predicate
The subject and predicate in the statement of need/requirement must correspond to the level to which the need/requirement applies.
Unacceptable:
At the business level, in the formulation of business requirements, use: The system must …
At the system level, in requirements statements, use: The user must …
R4 – Defined Terms
All terms used in descriptions of needs and requirements should be defined in an appropriate glossary and/or data dictionary.
R5 – Definite articles
This rule applies to English.
The definite article “the” should be used, not the indefinite “a”.
R6 – Units
Each numerical value should be accompanied by a unit of measurement.
R7 – Inaccurate terms
Adverbs should be avoided: several; any; permissible; any; a lot of; a large number of; few; almost always; very close to; approximately; near; close to; almost.
Adjectives to be avoided: optional; up-to-date; ordinary; general; typical; important; flexible; expandable; typical; sufficient; adequate; fit; effective; spectacular; qualitative; reasonable; common.
R8 – Disclaimer
Do not use words that blur responsibility: as far as possible; as less as possible; where possible; as much as possible; if necessary; if necessary; as needed; according to the circumstances; as required; within the expedient; if it’s feasible.
R9 – Open formulations
Wording should avoid: “including, but not limited to”, “and so on”, “and the like”.
Brevity
R10 – Extra verbs in indefinite form
Extra verbs in an indefinite form that go in a row should be avoided.
Unacceptable: The system must have the ability to store …
Acceptable: The system must store …
R11 – Individual offers
Requirements should be formulated in such a way that only one state or one characteristic is defined in one simple sentence.
Unambiguity
R12 – Grammar rules
In the wording, grammatical errors should be avoided.
R13 – Spelling Rules
Spelling errors should be avoided in wording.
R14 – Punctuation Rules
Punctuation errors should be avoided in wording.
R15 – Logical operators
In the formulations, it is necessary to single out and use logical operators in a uniform way: “[X И Y]”, “[X ИЛИ Y]”, [X Искл. ИЛИ Y]”, “NOT [X ИЛИ Y]” etc.
R16 – Avoid Particle HE
In the formulation of the requirement, the particle “Not” should be avoided.
R17 – Slash sign
Avoid using the forward slash (“/”) in statements except for units of measurement, such as km/h.
The slash sign introduces uncertainty into the formulation, since different interpretations can occur. For example, the entry “and/or”.
Simplicity
R18 – One thought – One sentence
One sentence must contain one soap, which can be supplemented by subordinate clauses.
R19 – Unions
Unions should be avoided in the wording: “and”, “or”, “then”, “if”, “but”, “also”, “however”, “while”, “on the other hand”, “otherwise”. The presence of these unions is a characteristic sign of the presence of several requirements in one formulation.
R20 – Statement with justifications
Phrases that indicate the “purpose,” “intention,” or “justification” of a need or requirement should be avoided. Including justification in the wording is redundant, since there is a special attribute A1 “Justification”.
R21 – Parentheses
Parentheses should be avoided, as they often indicate insignificant, superfluous text.
R22 – Enumeration
You should list sets of requirements explicitly instead of using generic phrases to designate a set.
The system should generate the report “Report Name 1”.
The system should generate the report “Report Name 2”.
The system should generate the report “Report name 3”.
R23 – Supplement with diagrams, models
If a requirement needs to describe complex behavior, it should refer to a diagram or model.
completeness
R24 – Pronouns
The use of personal and indefinite pronouns should be avoided.
R25 – Headings
The heading should not be assumed to be part of the requirement. The requirement must be self-contained and without a header.
realism
R26 – Absolute values
Avoid using unattainable absolute values such as 100% reliable, 100% available, all, every, always, never, etc.
Conditions
R27 – Explicit Conditions
If one condition applies to several requirements, then these requirements should be written separately from each other, this condition should be included in the wording of each of the requirements.
Unacceptable:
If condition A occurs, then
The system must do X
The system must do Y
The system should do Z.
Acceptable:
If condition A occurs, then the System must do X
If condition A occurs, then the System must do Y
If condition A occurs, then the System must do Z.
R28 – Multiple Conditions
If there are several conditions in the requirement, you should explicitly specify the logical rules between them.
Unacceptable:
The system must execute function A under the following conditions:
Condition X
Condition Y
Condition Z.
Acceptable:
The system must perform function A in case simultaneous fulfillment of the following conditions:
Condition X
Condition Y
Condition Z.
Uniqueness
R29 – Classification
Needs and requirements should be classified according to the aspects of the problem or system to which they relate.
R30 – Uniqueness
The requirement must be unique, there must not be duplicates in the set of requirements.
Abstraction
R31 – No decision
The requirement statement should not contain design elements, a specific solution. Exceptions are allowed if there is a reason for it, for example, some objective restrictions.
Set Pointers
R32 – All elements of the set
If it is necessary to refer to all elements of a set, the word “each” should be used instead of the words “all”, “any” or “both”.
Permissibility
R33 – Value range
For quantification, the requirement statement should include a range of values. For example, “…with an accuracy of ±3 meters”.
Quantity
R34 – Measurable quantities
In the statement of the requirement, it is necessary to quantify the quantities for which this is appropriate.
Unacceptable: The communication channel must have the maximum bandwidth.
Acceptable: The communication channel must pass at least 100 Mbps.
R35 – Time gaps
Time intervals should be specified explicitly. The following should be avoided in the wording of the requirements: “ultimately”, “before”, “earlier”, “when”, “after”, “as”, “once”, “earliest”, “last”, “instantaneous”, “ at the same time”, “for now” and “finally”.
Language uniformity
R36 – Harmonized terms and units of measurement
It should be ensured that each term is used with the same meaning throughout the set of needs/requirements.
R37 – Single list of acronyms
A single list of acronyms should be used and acronyms should be used in statements of needs/requirements in strict accordance with this list.
R38 – Abbreviations in wording
Abbreviations should not be used in requirements statements. For example, you should not use the abbreviation “Op” within the same set of requirements, where in one case “Op” is an operator, in another case it is an operation.
R39 – Style Guide
Throughout the project, a style guide should be used, which should define the requirements for design, wording, templates.
R40 – Decimal format
A consistent format and a consistent number of significant digits after the decimal point should be used for decimal numbers.
Modularity
R41 – Related needs and requirements
Group related needs and requirements.
R42 – Structured Sets
Requirements sets should be formed according to certain structures or patterns.
Matrix of properties and rules
Below is a matrix of properties of qualitative requirements/requirements sets and rules that give requirements/requirements sets these properties.
Attributes
Attributes to help identify needs and requirements and justify them
A1 – Rationale
A2 – Link to parent requirement
A3 – Link to source
A4 – States and Modes
A5 – Distribution / Budgeting
Attributes related to system verification and validation
A6 – Success criteria for system verification or validation
A7 – Strategy for system verification or validation
A8 – Method for system verification or validation
A9 – Organization responsible for system verification or validation
A10 – Level of system verification or validation
A11 – System Verification or Validation Phase
A12 – Application conditions
A13 – Results of system verification or validation
A14 – System verification or validation status
Attributes to help support requirements
A15 – Unique identifier
A16 – Unique name
A17 – Author/Initiator
A18 – Date of request
A19 – Owner
A20 – Stakeholders
A21 – Change Committee
A22 – Proposed change
A23 – Version number
A24 – Date of approval
A25 – Last modified date
A26 – Stability
A27 – Implementing person
A28 – Need or requirement verification status
A29 – Need or requirement validation status
A30 – Request status
A31 – Status (implementations)
A32 – Link to interface description
A33 – Link to requirement of the same level
A34 – Priority
A35 – Criticality
A36 – Risk (realizations)
A37 – Prevention of risk
A38 – Key requirement
A39 – Additional comments
A40 – Type/Category
Attributes that facilitate requirements reuse
A41 – Applicability
A42 – Region
A43 – Country
A44 – State/Province
A45 – Market segment
A46 – Structural unit
Attributes to help you manage your product line
A47 – Product line
A48 – General needs and requirements for the product line
A49 – Needs and requirements for a product line option
