INCOSE Guide to Writing Requirements

A requirement that reads “The device should not consume too much electrical energy” looks harmless in a review meeting. Then the hardware team designs to one interpretation of “too much,” the software team budgets to another, and the conflict surfaces at integration testing months later.

Requirements defects cause downstream rework, and catching them during authoring costs less than finding them during verification. The International Council on Systems Engineering (INCOSE) publishes guidance to help teams prevent these defects.

This guide covers its quality characteristics, numbered writing rules, and the review checklists that turn both into practice.

What Is the INCOSE Guide to Writing Requirements?

Engineering teams use the Guide to Writing Requirements (GtWR) to construct individual requirement statements and complete requirement sets. Version 4 (INCOSE-TP-2010-006-04), published in June 2023, defines 42 rules and 15 quality characteristics.

Origin and Relation to the INCOSE Systems Engineering Handbook

The Requirements Working Group (RWG) maintains the guide as part of INCOSE’s broader guidance on needs and requirements. Version 4 added decimal-format guidance (R40) and a fifteenth characteristic, Correct for sets (C15). The guide and the Handbook work at different altitudes. The Handbook covers lifecycle processes, while this guide is a practitioner-level supplement for statement-level writing, aligned with the Needs and Requirements Manual (NRM) supporting the Handbook (INCOSE SE HB).

Core Characteristics of a Well-Written Requirement

Poor requirements carry measurable cost, since architecture, test, and verification evidence all inherit any source ambiguity, and teams applying stronger best practices tend to see less of it downstream. Version 4 separates individual-statement characteristics from set-level characteristics because a clean sentence can still belong to an incomplete or conflicting set.

Necessary, Appropriate, and Unambiguous

A necessary requirement (C1) defines a capability, characteristic, constraint, or quality factor that is required. Appropriate (C2) means the detail matches the level of abstraction, so a system-level specification doesn’t dictate component values. Unambiguous (C3) requires that every audience interpret the statement in only one way.

Complete, Singular, and Feasible

Complete (C4) means the statement stands on its own, and singularity (C5) means it contains exactly one capability or constraint. Feasible (C6) means it’s realizable within cost, schedule, and technical limits at acceptable risk. Complete and feasible to apply again at the set level (C10, C12), since a statement can be complete even if the set has holes.

Verifiable and Traceable

Verifiable (C7) requires structuring the statement so its realization can be confirmed, so a requirement with no defined threshold can’t be verified. Traceability has no lettered characteristic, but set-level correctness (C15) depends on accurately representing the needs and higher-level requirements behind each statement. Aerospace, medical device, automotive, and industrial programs require bidirectional traceability, with varying expectations by program.

The INCOSE Rules for Writing Requirements

The rules sit under quality focus areas such as accuracy, non-ambiguity, singularity, and uniformity of language. A cross-reference matrix maps each rule to the characteristics it supports.

Use Consistent Terms and Sentence Structure

Under R1, every statement conforms to an agreed pattern. One example is “When the Temperature_Sensor detects an over-temperature condition, the Cooling_Controller shall Open the Cooling_Valve within 2 seconds.” R4 requires every term to be defined in a glossary or data dictionary. R36 extends this across the lifecycle, matching terms and units to the project’s ontology.

Avoid Ambiguous or Subjective Language

Vague quantifiers and adjectives are banned by R7, including “some,” “several,” “approximately,” “sufficient,” “adequate,” and “user-friendly.” Escape clauses such as “where possible” and “as appropriate” fail R8 by giving developers a documented excuse for noncompliance. Specific measurable performance targets under R34 replace words like “fast” or “high speed.”

Write One Requirement Per Statement

A single sentence with one subject, one main action verb, and one object satisfies R18. R19 backs it up by flagging combinators, the conjunctions that quietly weld requirements together. Compound statements break verification when a test passes half the sentence and fails the other half.

State Requirements Positively and Keep Them Implementation-Free

Active voice under R2 puts the responsible entity in the subject position. “The system shall use a 20 V electrical input” names an owner, while “A 20 V electrical input shall be used” names nobody. R16 restricts negation, since “not” invites ambiguity, though “shall not” remains permissible. R31 similarly limits implementation to cases with documented rationale, since requirements define what the system must do, not how.

INCOSE Requirements Writing Checklist

The characteristics become actionable as review questions for individual statements and the full set. A checklist keeps reviewers focused on defects that can still be fixed before baseline approval.

Checklist Criteria for Individual Requirements

For each statement, reviewers map questions to C1 through C9. Reviewers use these questions to catch defects before they become test or integration problems:

• Identification: The requirement carries a unique identifier.

• Interpretation: The statement can be read in only one way by every audience.

• Verification: Realization can be confirmed through test, demonstration, or analysis.

• Alignment: The statement is consistent with its parent system requirement.

• Design freedom: The wording avoids unnecessary design constraints.

A statement that fails any check is rewritten before it enters the baseline, to ensure cleaner test and quality inputs downstream.

Checklist Criteria for Requirement Sets

Set-level review catches what no single statement can reveal. Requirements must be unique, free of conflicts or overlaps, and unified in units (C11), while the full set must be realizable within cost, schedule, and technical limits (C12). Reviewers also confirm cross-references, consistent detail, and expected error-condition behavior.

Using the Checklist During Peer Review

Peer review catches defects that solo authoring misses. Reviewers who work the checklist independently beforehand leave meeting time for disposition rather than discovery.

Examples of Good vs. Poor Requirements

Frequent review findings trace to the same wording patterns. Small wording changes can turn an unverifiable statement into an engineering input.

Ambiguous vs. Measurable Requirements

“The controller shall respond quickly” fails R34 because “quickly” has no test. The corrected version reads “The controller shall acknowledge each operator command within 200 ms.”

Compound vs. Atomic Requirements

“The Charger will start cooling the Battery_Pack until the temperature reaches 35°C, when it will restore normal charging” contains two event-driven requirements, ambiguous pronouns, an undefined measurement point, and “will” where a binding requirement demands “shall.” The fix uses two separate shall statements, one for starting cooling and one for restoring charging.

Design-Constrained vs. Implementation-Free Requirements

“The kiosk shall use the Acme X200 touchscreen” is a design constraint masquerading as a requirement. The implementation-free version, “The kiosk shall register a valid user selection within 100 ms of screen contact,” states the needed performance and leaves touchscreen selection to designers.

Common Mistakes Teams Make When Writing Requirements

Requirement defects fall into recurring patterns the rules already address. Naming the pattern helps reviewers move from opinion-based comments to rule-based fixes.

Vague or Untestable Language

“The system must refresh the data reasonably quickly” can’t fail a test, which means it can’t pass one either. Terms like “as appropriate” and “and/or” create ambiguities, while “should” and “would” imply optionality where the writer meant obligation.

Mixing Rationale or Design Into Requirements

Mixing requirements and rationale in one paragraph is a known defect pattern. Rationale belongs in a separate attribute that captures why the requirement exists and what assumptions shaped it. Blending the two inflates statements past singularity and invites readers to treat explanation as obligation.

Missing Traceability Links

Controlled baselines need bidirectional traceability to baselined customer expectations, system needs, or approved Systems Engineering and Quality & Regulatory Affairs inputs. Derived requirements need links back to their validated technical requirements. An orphan requirement is either unnecessary, failing C1, or evidence of a missing parent.

Ignoring Requirement Independence

A strong requirement set keeps requirements unique and free of conflicts or overlap (C11). Overlap is the quieter failure, since two statements covering the same behavior can be updated separately and drift into contradiction. Independence also protects verification, since each must be testable without reference to how another is implemented.

Applying the INCOSE Requirements Writing Guide Across Regulated Industries

Aerospace, medical device, automotive, and industrial standards demand many of the same statement qualities that the GtWR defines, making the guide useful even when a program’s formal compliance framework comes from elsewhere.

Aerospace and Defense Requirements

Airborne software programs under DO-178C decompose requirements from system needs through software levels to code, with traceability maintained across the chain and derived requirements handled under safety processes. DO-254 applies the same expectations to airborne hardware. Aerospace and defense specifications require each requirement be necessary, measurable and verifiable, per Military Standard 961E (MIL-STD-961E), which limits each paragraph to one requirement.

Medical Device Requirements

FDA design and development requirements sit at 21 CFR 820.10(c), which incorporates ISO 13485 Clause 7.3 by reference. The Quality Management System Regulation made that change effective in February 2026. Design input and output traceability still carries verification evidence at the requirements, architecture, and system testing levels under International Electrotechnical Commission (IEC) 62304. Writing design inputs to GtWR characteristics gives defensible evidence that they were unambiguous and verifiable before an auditor asks.

Automotive and Industrial Systems Requirements

Functional and non-functional software requirements should adhere to the defined characteristics of Automotive SPICE (ASPICE) programs. Traceability should connect safety requirements to upstream sources and downstream realization in accordance with ISO 26262, the standard that also defines Automotive Safety Integrity Levels.

Best Practices for Rolling Out INCOSE Guidelines Org-Wide

A guide nobody applies changes nothing. Rollouts succeed when teams define review structures, exception paths, and quality checks. Teams still reviewing requirements in spreadsheets can start by standardizing the decisions reviewers make repeatedly.

Standardize Requirement Templates

Patterns beat prose instructions when writers need to move fast. The Easy Approach to Requirements Syntax (EARS) gives writers sentence templates for common requirement situations:

• Event response: When [trigger], the [system] shall [response].

• State condition: While [state], the [system] shall [response].

• Unwanted condition: If [condition], then the [system] shall [response].

Pairing EARS notation with a project glossary satisfies R1, R4, and R39 in one move.

Build Peer Review Into the Requirements Workflow

Phased adoption tends to outperform top-down mandates. Teams that start with a pilot group and appoint an engineering champion see the standard survive deadlines with a documented exception process. A few tracked metrics keep the loop honest, including requirements that follow approved patterns and undefined terms per the baseline.

Automate Requirements Quality Checks

Natural language processing (NLP) can automatically check vague terms, escape clauses, passive voice, and combinators. Judgment-based characteristics such as Necessary and Correct still require an engineer.

How Jama Connect Supports INCOSE Requirements Writing

A rule set only helps if it reaches the writer at the moment of writing. Jama Connect Advisor™, an add-on to Jama Connect® Cloud, analyzes each requirement against 36 INCOSE rules and 6 EARS syntax patterns. It returns a quality score and flags what it finds, including vague terms, passive voice, and ambiguous language, then drafts a refined statement that resolves those flags. The engineer reviews that draft and accepts, edits, or rejects it. The revision enters the requirement only at acceptance, and both versions stay in the audit trail.

Requirements quality is only half of what an auditor asks about. Every AI action inside Jama Connect is versioned and recorded as AI-generated. A reviewer can see what was suggested, what an engineer accepted, and which requirement it changed. An AI assistant working outside the requirements system leaves no such record. What makes that possible is the Traceability Information Model, which connects requirements, tests, risks, and verification evidence into one structure.

Put INCOSE Requirements Guidance Into Practice

The guide will keep changing. Version 4 added a rule and a characteristic, and the RWG continues to align it with the NRM. A process anchored solely to rule numbers requires maintenance with every edition, but a team trained to ask whether each statement is necessary, unambiguous, singular, and verifiable carries that habit forward.

If your team is ready to put those habits into a live requirements workflow, request a 30-day free trial of Jama Connect and test the process against real project data.

Frequently Asked Questions About the INCOSE Requirements Writing Guide

What is the GtWR?

The GtWR is the RWG’s practitioner guide for writing requirement statements and sets, designated INCOSE-TP-2010-006-04. Reviewers use it for measuring requirement quality decisions, like whether a statement is singular, measurable, implementation-free, or baseline-ready, the same judgment Jama Connect’s review workflows support.

How many rules does the GtWR include?

Version 4 includes 42 rules, with R40 on decimal format added in that edition. Teams usually get more value turning high-frequency rules into EARS sentence patterns, glossary checks, and review questions before asking every writer to memorize the full set.

Is the GtWR free to access?

The full guide is available to INCOSE members, while non-members can use a short Version 4 summary sheet reproducible with attribution. Controlled programs should still define which rules are mandatory, how exceptions are approved, and where evidence is stored.

What’s the difference between the GtWR and the Handbook?

The INCOSE SE HB defines when requirements work happens in the lifecycle, while the guide focuses on whether each statement itself is clear enough for review. A GtWR-based review covers the requirement set, glossary, parent links, verification approach, and any approved exceptions.

This article was authored by Mario Maldari and published on August 20, 2026.