This Guide for Writing Requirements is specifically about how to express textual requirements in the context of systems engineering. The main focus of this Guide is on how to express requirements clearly and precisely once they have been discovered, and in a form convenient for further analysis and implementation, independent of whichever process or Systems Engineering (SE) tool is used to capture and manage the requirements. This Guide defines key terms associated with requirements and characteristics that must be possessed by well-formed requirement statements and sets of requirements. The Guide includes a set of rules for writing requirement statements that, if followed, will result in the requirements having these characteristics. The Guide also includes a set of attributes that can be included with the requirement statements to form a complete requirement expression.
Document No.: INCOSE-TP-2010-006-03
Version/Revision: 3.0
Date: July 1, 2019
Author(s): INCOSE
Publisher: INCOSE Publications Office
Year: 2019
Language: English
Pages: 107
City: San Diego
1 INTRODUCTION
1.1 Purpose and Scope
1.2 Why use the Textual Form of Communication?
1.3 Audience
1.4 Approach
1.5 Concepts
1.6 Definitions
1.7 Verification and Validation
1.8 Guide Organization
2 Characteristics of Need and Requirement Statements
2.1 C1 - Necessary
2.2 C2 - Appropriate
2.3 C3 - Unambiguous
2.4 C4 - Complete
2.5 C5 - Singular
2.6 C6 - Feasible
2.7 C7 - Verifiable
2.8 C8 - Correct
2.9 C9 - Conforming
3 Characteristics of Sets of NEEDs and Requirements
3.1 C10 - Complete
3.2 C11 - Consistent
3.3 C12 - Feasible
3.4 C13 - Comprehensible
3.5 C14 - Able to be validated
4 Rules for NEED and REQUIREMENT Statements And Sets of NEEDS and Requirements
4.1 Accuracy
4.1.1 R1 - /Accuracy/SentenceStructure
4.1.2 R2 - /Accuracy/UseActiveVoice
4.1.3 R3 - /Accuracy/SubjectVerb
4.1.4 R4 - /Accuracy/UseDefinedTerms
4.1.5 R5 - /Accuracy/UseDefiniteArticles
4.1.6 R6 - /Accuracy/Units
4.1.7 R7 - /Accuracy/AvoidVagueTerms
4.1.8 R8 - /Accuracy/NoEscapeClauses
4.1.9 R9 - /Accuracy/NoOpenEnded
4.2 Concision
4.2.1 R10 - /Concision/SuperfluousInfinitives
4.2.2 R11 - /Concision/SeparateClauses
4.3 Non-ambiguity
4.3.1 R12 - /NonAmbiguity/CorrectGrammar
4.3.2 R13 - /NonAmbiguity/CorrectSpelling
4.3.3 R14 - /NonAmbiguity/CorrectPunctuation
4.3.4 R15 - /NonAmbiguity/LogicalCondition
4.3.5 R16 - /NonAmbiguity/AvoidNot
4.3.6 R17 - /NonAmbiguity/Oblique
4.4 Singularity
4.4.1 R18 - /Singularity/SingleSentence
4.4.2 R19 - /Singularity/AvoidCombinators
4.4.3 R20 - /Singularity/AvoidPurpose
4.4.4 R21 - /Singularity/AvoidParentheses
4.4.5 R22 - /Singularity/Enumeration
4.4.6 R23 - /Singularity/Context
4.5 Completeness
4.5.1 R24 - /Completeness/AvoidPronouns
4.5.2 R25 - /Completeness/UseOfHeadings
4.6 Realism
4.6.1 R26 - /Realism/AvoidAbsolutes
4.7 Conditions
4.7.1 R27 - /Conditions/Explicit
4.7.2 R28 - /Conditions/ExplicitLists
4.8 Uniqueness
4.8.1 R29 - /Uniqueness/Classify
4.8.2 R30 - /Uniqueness/ExpressOnce
4.9 Abstraction
4.9.1 R31 - /Abstraction/SolutionFree
4.10 Quantifiers
4.10.1 R32 - /Quantifiers/Universals
4.11 Tolerance
4.11.1 R33 - /Tolerance/ValueRange
4.12 Quantification
4.12.1 R34 - /Quantification/Measurable
4.12.2 R35 - /Quantification/TemporalIndefinite
4.13 Uniformity of Language
4.13.1 R36 - /UniformLanguage/UseConsistentTerms
4.13.2 R37 - /UniformLanguage/DefineAcronyms
4.13.3 R38 - /UniformLanguage/AvoidAbbreviations
4.13.4 R39 - /UniformLanguage/StyleGuide
4.14 Modularity
4.14.1 R40 - /Modularity/RelatedRequirements
4.14.2 R41 - /Modularity/Structured
5 Attributes of Need and Requirement Statements
5.1 Attributes to Help Define the Need or Requirement and its Intent
5.1.1 A1 – Rationale*
5.1.2 A2 – SOI Primary Verification or Validation Method*
5.1.3 A3 – SOI Verification or Validation Approach
5.1.4 A4 – Trace to Parent *
5.1.5 A5 – Trace to Source*
5.1.6 A6 – Condition of Use
5.1.7 A7 – States and Modes
5.1.8 A8 – Allocation
5.2 Attributes Associated with the SOI and its Verification or Validation
5.2.1 A9 – SOI Verification or Validation Level
5.2.2 A10 – SOI Verification or Validation Phase
5.2.3 A11 – SOI Verification or Validation Results
5.2.4 A12 – SOI Verification or Validation Status
5.3 Attributes to Help Maintain the Requirements
5.3.1 A13 – Unique Identifier*
5.3.2 A14 – Unique Name
5.3.3 A15 – Originator/Author*
5.3.4 A16 – Date Requirement Entered
5.3.5 A17 – Owner*
5.3.6 A18 – Stakeholders
5.3.7 A19 – Change Board
5.3.8 A20 – Change Status
5.3.9 A21 – Version Number
5.3.10 A22 – Approval Date
5.3.11 A23 – Date of Last Change
5.3.12 A24 – Stability
5.3.13 A25 – Responsible Person
5.3.14 A26 – Need or Requirement Verification Status*
5.3.15 A27 – Need or Requirement Validation Status*
5.3.16 A28 – Status (of the need or requirement)
5.3.17 A29 – Status (of implementation)
5.3.18 A30 – Trace to Interface Definition
5.3.19 A31 – Trace to Peer Requirements
5.3.20 A32 – Priority*
5.3.21 A33 – Criticality or Essentiality*
5.3.22 A34 – Risk (of implementation)*
5.3.23 A35 – Risk (Mitigation)
5.3.24 A36 – Key Driving Need or Requirement (KDN/KDR)
5.3.25 A37 – Additional Comments
5.3.26 A38 – Type/Category
5.4 Attributes to Show Applicability and Enable Reuse
5.4.1 A39 – Applicability
5.4.2 A40 – Region
5.4.3 A41 – Country
5.4.4 A42 – State/Province
5.4.5 A43 – Application
5.4.6 A44 – Market Segment
5.4.7 A45 – Business Unit
5.4.8 A46 – Business (Product) Line
5.5 GUIDANCE FOR USING ATTRIBUTES
Reference DOCUMENTS
A APPENDIX a. ACRONYMS AND ABBREVIATIONS
B APPENDIX B. Requirement PATTERNS
B.1 Introduction to requirement patterns
B.2 Benefits of using patterns to form requirement statements
B.3 building blocks for Requirement Patterns
C Appendix C. Comment Form
