INCOSE Requirements Quality: The Complete 42-Rule Guide to Writing Excellent Requirements for Systems Engineers

Well-written requirements form the foundation of successful systems engineering projects. Poor requirements lead to cost overruns, schedule delays, and systems that fail to meet stakeholder needs. This comprehensive guide presents the 42 rules for writing excellent requirements, based on the International Council on Systems Engineering (INCOSE) Guide to Writing Requirements. These rules represent the systematic approach to Requirements Quality Engineering – the disciplined process of ensuring requirements possess the characteristics necessary for successful system development. The rules are organized into 12 categories that systematically address every aspect of requirement quality, from basic accuracy to complex organizational structures.

Introduction

Requirements are the bridge between stakeholder needs and system implementation. They serve as the formal agreement between customers and developers, the basis for design decisions, and the criteria for verification and validation. Despite their critical importance, requirements are often poorly written, leading to misunderstandings, rework, and project failures.

What is Requirements Quality Engineering?

Requirements Quality Engineering is the systematic application of proven principles, rules, and practices to ensure that requirements possess the characteristics necessary for successful system development. This discipline goes beyond simply writing requirements – it encompasses the entire process of crafting, reviewing, organizing, and maintaining requirements that truly serve their intended purpose.

The INCOSE Requirements Working Group has developed a comprehensive framework for Requirements Quality Engineering, distilling decades of systems engineering experience into 42 specific rules. This framework represents the gold standard for professional requirements engineering practice.

Recommended Further Reading Amazon Books

The 15 Essential Characteristics of Quality Requirements

Quality requirements possess 15 essential characteristics at two levels:

1. Necessary – Required to satisfy a lifecycle concept, need, or higher-level requirement
2. Appropriate – Suitable to the level of the entity to which it refers
3. Unambiguous – Can be interpreted in only one way by all intended audiences
4. Complete – Sufficiently describes the necessary capability without further amplification
5. Singular – States a single capability, characteristic, constraint, or quality factor
6. Feasible – Can be realized within entity constraints with acceptable risk
7. Verifiable/Validatable – Structured so realization can be verified/validated
8. Correct – Accurate representation of the source from which it was transformed
9. Conforming – Follows approved standards and patterns
10. Complete – Set stands alone and sufficiently describes all necessary aspects
11. Consistent – Individual requirements don’t conflict and use homogeneous language
12. Feasible – Set can be realized within constraints with acceptable risk
13. Comprehensible – Clear what is expected of the entity and its relationships
14. Able to be Validated – Possible to validate the set leads to achievement of goals
15. Correct – Accurate representation of sources from which the set was transformed

The complete INCOSE Guide to Writing Requirements (INCOSE-TP-2010-006-04) is available at https://www.incose.org for INCOSE members and provides the authoritative source for these principles.

This guide organizes the 42 INCOSE rules into logical categories, providing systems engineers with a practical reference for implementing Requirements Quality Engineering practices that truly serve their intended purpose.

AI Support for Requirements Quality Engineering

While mastering these 42 rules is essential for systems engineers, manually applying them can be time-consuming and error-prone. Try our free Rex AI requirements writing tool at reqi.io/rex that uses advanced AI and systems engineering principles. Say goodbye to manual requirement hassles and hello to efficiency with REX, our cutting-edge AI-powered assistant. This tool uses AI and the INCOSE framework to generate new, well-formed requirements from your input, rated against the 42-Point Guide to Writing Requirements.

1. Accuracy Rules (R1-R9): Building the Foundation

Accuracy forms the bedrock of Requirements Quality Engineering. These nine rules ensure that requirements communicate their intended meaning clearly and precisely.

Rule #	Name	Description	Objective
R1	Structured Statements	Need and requirement statements must conform to agreed patterns, resulting in well-structured complete statements	Ensure consistency, completeness, and conformance to organizational standards
R2	Active Voice	Use active voice with the responsible entity clearly identified as the subject	Make clear who/what is responsible for performing the action
R3	Appropriate Subject-Verb	Ensure subject and verb are appropriate to the entity the statement refers to	Align requirements with correct organizational/system level
R4	Defined Terms	Define all terms within an associated glossary and/or data dictionary	Eliminate ambiguity through consistent terminology
R5	Definite Articles	Use “the” rather than “a” when referring to entities	Avoid ambiguity about which specific entity is referenced
R6	Common Units of Measure	Use appropriate and consistent units of measure with a common measurement system	Ensure precision and consistency in quantitative statements
R7	Vague Terms	Avoid vague terms like “some,” “adequate,” “reasonable”	Eliminate ambiguity and ensure verifiability
R8	Escape Clauses	Avoid escape clauses like “where possible,” “as appropriate,” “if necessary”	Prevent loopholes that could excuse non-compliance
R9	Open-Ended Clauses	Avoid non-specific clauses like “including but not limited to,” “etc.”	Ensure completeness and prevent scope creep

R1 – Structured Statements

Objective: Ensure consistency, completeness, and conformance to organizational standards

Requirements must follow agreed-upon patterns or templates. A basic pattern might be: “When [condition], the [entity] shall [action] [object] [performance measure].” This structure forces completeness and consistency across all requirements.

Example:

• Poor: “The system should work fast”
• Good: “When processing user queries, the Database_System shall return search results within 2.0 ± 0.5 seconds”

R2 – Active Voice

Objective: Make clear who/what is responsible for performing the action

Active voice places the responsible entity at the beginning of the sentence, eliminating confusion about accountability.

Example:

• Poor: “Data shall be encrypted” (Who encrypts it?)
• Good: “The Security_Module shall encrypt all transmitted data”

R3 – Appropriate Subject-Verb

Objective: Align requirements with correct organizational/system level

The subject must match the level of the requirement set. System-level requirements should have the system as subject, not users or subsystems.

Example:

• Poor: “The user shall enter a password” (requirement on user)
• Good: “The Authentication_System shall prompt for password entry”

R4 – Defined Terms

Objective: Eliminate ambiguity through consistent terminology

Every technical term must be defined in a glossary or data dictionary and used consistently throughout all project artifacts.

R5 – Definite Articles

Objective: Avoid ambiguity about which specific entity is referenced

Use “the” instead of “a” to refer to specific, defined entities rather than any random instance.

R6 – Common Units of Measure

Objective: Ensure precision and consistency in quantitative statements

All measurements must use consistent units throughout the project. Mixing metric and imperial units creates confusion and potential errors.

R7 – Vague Terms

Objective: Eliminate ambiguity and ensure verifiability

Words like “adequate,” “reasonable,” “user-friendly,” and “fast” are subjective and unverifiable. Replace with specific, measurable criteria.

R8 – Escape Clauses

Objective: Prevent loopholes that could excuse non-compliance

Phrases like “where possible” or “as appropriate” give developers excuses not to implement requirements fully.

R9 – Open-Ended Clauses

Objective: Ensure completeness and prevent scope creep

Avoid “including but not limited to” and “etc.” Instead, explicitly list all required items or write separate requirements for each item.

Recommended Future Learn Short Courses

2. Concision Rules (R10-R11): Eliminating Waste

Concise requirements are easier to understand, implement, and verify. These rules eliminate unnecessary words while preserving meaning.

Rule #	Name	Description	Objective
R10	Superfluous Infinitives	Avoid superfluous infinitives like “to be able to,” “to be capable of”	Eliminate unnecessary words and ambiguity about conditions
R11	Separate Clauses	Use separate clauses for each condition or qualification	Improve clarity and enable proper verification

R10 – Superfluous Infinitives

Objective: Eliminate unnecessary words and ambiguity about conditions

Phrases like “shall be able to” or “shall be capable of” add no value and create ambiguity about when the capability must be demonstrated.

Example:

• Poor: “The system shall be able to process 1000 transactions per hour”
• Good: “When in operational mode, the system shall process 1000 ± 50 transactions per hour”

R11 – Separate Clauses

Objective: Improve clarity and enable proper verification

Each condition or qualification should be in its own clause, properly structured to avoid confusion about what applies to what.

3. Non-Ambiguity Rules (R12-R17): Crystal Clear Communication

Ambiguous requirements lead to different interpretations by different stakeholders. These rules eliminate multiple possible meanings.

Rule #	Name	Description	Objective
R12	Correct Grammar	Use correct grammar throughout statements	Ensure clear interpretation, especially for non-native speakers
R13	Correct Spelling	Use correct spelling consistently	Prevent confusion from misspelled words
R14	Correct Punctuation	Use correct punctuation to avoid confusion	Clarify relationships between clauses
R15	Logical Expressions	Use defined conventions for logical expressions like “[X AND Y]”	Make logical conditions explicit and unambiguous
R16	Use of “Not”	Avoid using the word “not”	Enable positive, verifiable statements
R17	Use of Oblique Symbol	Avoid the oblique (“/”) symbol	Eliminate multiple possible interpretations

R12 – Correct Grammar

Objective: Ensure clear interpretation, especially for non-native speakers

Poor grammar clouds meaning and can be especially problematic in international projects where stakeholders work in second languages.

R13 – Correct Spelling

Objective: Prevent confusion from misspelled words

Spell-checkers help, but be aware of correctly spelled wrong words (e.g., “ordinance” vs. “ordnance”).

R14 – Correct Punctuation

Objective: Clarify relationships between clauses

Misplaced commas and other punctuation marks can completely change a requirement’s meaning.

R15 – Logical Expressions

Objective: Make logical conditions explicit and unambiguous

Use clear conventions like “[X AND Y]” or “[X OR Y]” instead of ambiguous natural language constructions.

R16 – Use of “Not”

Objective: Enable positive, verifiable statements

Negative requirements are often impossible to verify completely. Instead of “shall not fail,” specify positive reliability or availability requirements.

R17 – Use of Oblique Symbol

Objective: Eliminate multiple possible interpretations

The “/” symbol can mean “and,” “or,” “per,” or indicate alternatives. Use explicit language instead.

Recommended Further Reading Amazon Books

4. Singularity Rules (R18-R23): One Thought, One Requirement

Singular requirements can be allocated, traced, and verified individually. These rules ensure each requirement addresses exactly one concern.

Rule #	Name	Description	Objective
R18	Single Thought Sentence	Write single sentences containing single thoughts with relevant sub-clauses	Enable proper allocation, traceability, and verification
R19	Combinators	Avoid combinators like “and,” “or,” “then,” “unless” that join multiple clauses	Maintain single-thought principle
R20	Purpose Phrases	Avoid phrases indicating “purpose of” or “intent of” the requirement	Keep statements concise; use rationale attributes for explanations
R21	Parentheses	Avoid parentheses and brackets containing subordinate text	Eliminate superfluous information and potential ambiguity
R22	Enumeration	Enumerate sets explicitly instead of using group nouns	Enable individual allocation and verification of each item
R23	Supporting Diagrams	When requirements involve complex behavior, refer to supporting diagrams, models, or ICDs	Clarify complex relationships that are difficult to express in text

R18 – Single Thought Sentence

Objective: Enable proper allocation, traceability, and verification

Each requirement should contain one main action with appropriate qualifying clauses. Multiple actions require multiple requirements.

Example:

• Poor: “The system shall validate user credentials and log successful attempts and send notifications to administrators”
• Good: Three separate requirements for validation, logging, and notification

R19 – Combinators

Objective: Maintain single-thought principle

Words like “and,” “or,” “then” often indicate multiple thoughts that should be separated into individual requirements.

R20 – Purpose Phrases

Objective: Keep statements concise; use rationale attributes for explanations

Avoid “in order to” and “so that” phrases in the requirement text. Put explanatory information in rationale attributes.

R21 – Parentheses

Objective: Eliminate superfluous information and potential ambiguity

Parenthetical information often indicates nice-to-know information that belongs in rationale, not the requirement itself.

R22 – Enumeration

Objective: Enable individual allocation and verification of each item

Instead of “The system shall manage user functions,” explicitly list each function as a separate requirement.

R23 – Supporting Diagrams

Objective: Clarify complex relationships that are difficult to express in text

For complex behaviors, reference well-defined diagrams, models, or Interface Control Documents rather than trying to capture everything in text.

5. Completeness Rules (R24-R25): Self-Contained Statements

Complete requirements stand alone without requiring external context or cross-references.

Rule #	Name	Description	Objective
R24	Pronouns	Avoid personal and indefinite pronouns	Eliminate cross-references and maintain statement independence
R25	Headings	Avoid relying on headings to support understanding	Ensure statements are complete and self-contained

R24 – Pronouns

Objective: Eliminate cross-references and maintain statement independence

Avoid “it,” “they,” “this,” and “that.” Repeat nouns to ensure each requirement is self-contained, especially important when requirements are managed in databases where order may change.

R25 – Headings

Objective: Ensure statements are complete and self-contained

Requirements should not depend on section headings for meaning. Each requirement must be fully understandable in isolation.

6. Realism Rules (R26): Achievable Targets

Unrealistic requirements waste resources and create impossible verification challenges.

Rule #	Name	Description	Objective
R26	Absolutes	Avoid unachievable absolutes like “100%” or “always”	Ensure feasibility and verifiability

R26 – Absolutes

Objective: Ensure feasibility and verifiability

Avoid “100%,” “always,” “never,” and “all” unless truly absolute. These typically cannot be verified with finite resources.

Example:

• Poor: “The system shall have 100% availability”
• Good: “The system shall have ≥99.9% availability during operational hours”

7. Conditions Rules (R27-R28): When Requirements Apply

Many requirements only apply under specific conditions. These rules ensure conditions are stated explicitly and clearly.

Rule #	Name	Description	Objective
R27	Explicit Conditions	State conditions’ applicability explicitly instead of inferring from context	Ensure completeness and verifiability
R28	Multiple Conditions	Express propositional nature of conditions explicitly for single actions	Clarify when multiple conditions apply (AND vs OR)

R27 – Explicit Conditions

Objective: Ensure completeness and verifiability

State all applicable conditions directly in the requirement rather than assuming they’re understood from context.

Example:

• Poor: “The system shall encrypt data” (When? What data?)
• Good: “When transmitting customer records over public networks, the system shall encrypt data using AES-256”

R28 – Multiple Conditions

Objective: Clarify when multiple conditions apply (AND vs OR)

When multiple conditions trigger an action, make clear whether all conditions must be met simultaneously (AND) or any condition is sufficient (OR).

8. Uniqueness Rules (R29-R30): No Duplication

Duplicate requirements create confusion and maintenance problems when changes are needed.

Rule #	Name	Description	Objective
R29	Classification	Classify needs and requirements by problem/system aspects they address	Enable organization, completeness checking, and conflict identification
R30	Unique Expression	Express each need and requirement once and only once	Eliminate duplication and potential conflicts

R29 – Classification

Objective: Enable organization, completeness checking, and conflict identification

Classify requirements by type (functional, performance, interface, safety, etc.) to help identify gaps, overlaps, and conflicts.

R30 – Unique Expression

Objective: Eliminate duplication and potential conflicts

Each requirement should appear exactly once in the requirements set. Similar requirements with different wording often indicate incomplete analysis or poor organization.

9. Abstraction Rules (R31): Appropriate Level of Detail

Requirements should specify what the system must do without unnecessarily constraining how it does it.

Rule #	Name	Description	Objective
R31	Solution Free	Avoid stating implementation unless there’s rationale for constraining design	Focus on “what” rather than “how” to preserve design freedom

R31 – Solution Free

Objective: Focus on “what” rather than “how” to preserve design freedom

Unless there’s a compelling reason to constrain the design, requirements should state the desired outcome rather than the implementation approach.

Example:

• Poor: “The system shall use a MySQL database”
• Good: “The system shall store customer records with 99.9% data availability”

10. Quantifiers Rules (R32): Clear Scope

Quantifiers determine whether requirements apply to individual items or collections.

Rule #	Name	Description	Objective
R32	Universal Qualification	Use “each” instead of “all,” “any,” or “both” for universal quantification	Clarify whether action applies to whole set or individual elements

R32 – Universal Qualification

Objective: Clarify whether action applies to whole set or individual elements

Use “each” instead of “all,” “any,” or “both” to make clear that the requirement applies to every individual item, not the collection as a whole.

11. Tolerance Rules (R33): Realistic Ranges

Single-point specifications are rarely achievable or necessary. Appropriate tolerances enable cost-effective solutions.

Rule #	Name	Description	Objective
R33	Range of Values	Define quantities with appropriate value ranges for verification/validation	Enable realistic verification and provide acceptable trade-space

R33 – Range of Values

Objective: Enable realistic verification and provide acceptable trade-space

Specify acceptable ranges rather than single values. Consider what variation would still meet stakeholder needs.

Example:

• Poor: “Response time shall be 2.0 seconds”
• Good: “Response time shall be 2.0 ± 0.3 seconds”

12. Quantification Rules (R34-R35): Measurable Targets

Quantified requirements enable objective verification and clear success criteria.

Rule #	Name	Description	Objective
R34	Measurable Performance	Provide specific measurable performance targets	Enable objective verification
R35	Temporal Dependencies	Define temporal dependencies explicitly instead of using indefinite temporal keywords	Provide specific, verifiable timing constraints

R34 – Measurable Performance

Objective: Enable objective verification

Replace subjective terms like “fast,” “user-friendly,” and “reliable” with specific, measurable criteria.

R35 – Temporal Dependencies

Objective: Provide specific, verifiable timing constraints

Replace vague temporal terms like “eventually,” “soon,” and “before” with specific time constraints.

13. Uniformity of Language Rules (R36-R40): Consistent Communication

Consistent language prevents misunderstandings and enables effective tool support.

Rule #	Name	Description	Objective
R36	Consistent Terms and Units	Use terms and units consistently throughout all artifacts	Ensure consistency across the entire system lifecycle
R37	Acronyms	Use acronyms consistently throughout all artifacts	Maintain consistent terminology
R38	Abbreviations	Avoid abbreviations unless clearly defined	Prevent ambiguity from multiple meanings
R39	Style Guide	Use project-wide style guide for statements	Ensure organizational consistency and quality
R40	Decimal Format	Use consistent format and significant digits for decimal numbers	Maintain precision consistency

R36 – Consistent Terms and Units

Objective: Ensure consistency across the entire system lifecycle

Use identical terminology in requirements, design documents, test procedures, and user manuals. Maintain a project glossary and enforce its use.

R37 – Acronyms

Objective: Maintain consistent terminology

Use the same acronym consistently throughout all project artifacts. Don’t mix “GPS” and “Global Positioning System” randomly.

R38 – Abbreviations

Objective: Prevent ambiguity from multiple meanings

Avoid abbreviations unless absolutely necessary and clearly defined. Many abbreviations have multiple meanings depending on context.

R39 – Style Guide

Objective: Ensure organizational consistency and quality

Develop and follow organization-wide standards for requirement patterns, attributes, and formatting.

R40 – Decimal Format

Objective: Maintain precision consistency

Use consistent decimal notation and significant digits throughout all requirements. Don’t mix “5.0” and “5.00” randomly.

14. Modularity Rules (R41-R42): Organized Structure

Well-organized requirements are easier to understand, maintain, and verify for completeness.

Rule #	Name	Description	Objective
R41	Related Requirements	Group related needs and requirements together	Improve organization and identify relationships
R42	Structured Sets	Conform to defined structure/template for organizing sets	Ensure systematic coverage and organization

R41 – Related Requirements

Objective: Improve organization and identify relationships

Group related requirements together by function, interface, or other logical relationships. This helps identify gaps and conflicts.

R42 – Structured Sets

Objective: Ensure systematic coverage and organization

Use consistent organizational templates that ensure all types of requirements are considered: functional, performance, interface, safety, security, etc.

Implementation Strategy for Requirements Quality Engineering

Successfully implementing Requirements Quality Engineering requires a systematic approach:

1. Organization-Level Implementation

• Develop organizational standards based on these INCOSE rules
• Create requirement templates and patterns
• Establish glossaries and data dictionaries
• Implement tool support for rule checking
• Train personnel on Requirements Quality Engineering practices

2. Project-Level Implementation

• Tailor organizational standards to project needs
• Establish project-specific terminology
• Set up automated checking where possible
• Conduct regular requirement quality reviews
• Link requirements to verification procedures

3. Tool Support

• Many Natural Language Processing (NLP) and Artificial Intelligence (AI) tools can automatically check compliance with these rules
• Requirement management tools can enforce templates and patterns
• Automated checking reduces manual review effort and catches errors early
• Try our free Rex AI requirements writing tool at reqi.io/rex for immediate assistance with applying these INCOSE principles

4. Quality Metrics

Track compliance with these rules as Requirements Quality Engineering metrics:

• Percentage of requirements following proper patterns
• Number of undefined terms
• Frequency of vague language
• Completeness of requirement attributes

Common Pitfalls and How to Avoid Them

Pitfall 1: Treating Requirements as Wishes

Problem: Writing “should” statements instead of “shall” statements Solution: Use “shall” for binding requirements, reserve “should” for goals and preferences

Pitfall 2: Copy-Paste from Previous Projects

Problem: Reusing requirements without adaptation Solution: Always validate that reused requirements apply to the current project context

Pitfall 3: Mixing Levels of Abstraction

Problem: Including implementation details in system-level requirements Solution: Apply Rule R31 – keep requirements solution-free unless there’s compelling rationale

Pitfall 4: Requirements Creep During Development

Problem: Adding requirements informally without proper change control Solution: Implement formal change control processes and ensure all requirements are documented

Verification and Validation in Requirements Quality Engineering

Well-written requirements enable effective verification and validation:

Verification Planning

• Each requirement should have defined success criteria
• Verification methods (test, analysis, inspection, demonstration) should be specified
• Test procedures should map directly to requirement language

Validation Planning

• Requirements should trace back to stakeholder needs
• Validation scenarios should exercise complete operational threads
• Acceptance criteria should be unambiguous

Conclusion

Requirements Quality Engineering is not accidental—it results from disciplined application of proven INCOSE principles. The 42 rules presented in this guide provide a comprehensive framework for writing requirements that truly serve their purpose: communicating stakeholder needs clearly and enabling successful system development.

These rules work together synergistically. Accuracy rules ensure basic clarity, while singularity rules enable effective management. Quantification rules support verification, while modularity rules facilitate maintenance. Master these INCOSE principles, and you’ll write requirements that project teams can actually use to build successful systems.

Remember that tools can help enforce these rules, but human judgment remains essential for understanding stakeholder intent and making appropriate trade-offs. For immediate assistance with applying these INCOSE principles, try our free Rex AI requirements writing tool at reqi.io/rex, then use this guide as your reference for understanding the underlying Requirements Quality Engineering principles, adapt it to your organization’s needs, and continuously improve your requirement-writing practice.

The investment in learning and applying these INCOSE Requirements Quality Engineering rules pays dividends throughout the system lifecycle, reducing rework, preventing misunderstandings, and ultimately delivering systems that truly meet stakeholder needs.

---

References

1. INCOSE-TP-2010-006-04, “Guide to Writing Requirements,” Version 4, International Council on Systems Engineering, July 2023.
2. INCOSE-TP-2021-002-01.1, “Needs and Requirements Manual,” International Council on Systems Engineering, 2022.
3. ISO/IEC/IEEE 29148, “Systems and software engineering — Life cycle processes — Requirements engineering,” 2018.
4. ISO/IEC/IEEE 15288, “Systems and software engineering — System life cycle processes,” 2015.

---

This guide serves as a practical reference for systems engineers seeking to master Requirements Quality Engineering using INCOSE principles. Keep it accessible during requirement development, and refer to it regularly to ensure your requirements meet the highest professional standards.