Should Requirements Be Written in Shall Language, or Is There a Better Way?

There is a genuine argument happening in systems engineering right now, and it is not the kind that gets resolved by citing a standard.

On one side: “Shall language is the backbone of testable, traceable requirements. Every obligation has a modal verb, every modal verb signals a verification action. Drop it and you get ambiguity.” On the other side: “Shall language has become a ritual. Teams write tortured passive-voice sentences to fit the convention, lose the actual intent, and still call it requirements engineering.”

Both positions have real evidence behind them. The answer is not “shall is always right” or “shall is outdated.” The answer is that the convention solves a specific problem, creates other problems when misapplied, and modern tooling has changed what part of the problem humans need to solve manually.

Where “Shall” Came From

The shall/should/may convention is not arbitrary. It has roots in contract law and was codified in defense acquisition standards — primarily MIL-STD-490, later MIL-STD-490A, and the DOD-STD-2167 series — because government contracts needed unambiguous language for what was legally binding.

The logic is clean:

  • Shall = mandatory requirement. The contractor must demonstrate compliance. Non-compliance is a contract violation.
  • Should = a recommendation. Non-compliance requires documented rationale.
  • May = permissive. The developer has discretion.

This three-level hierarchy gave acquisition programs a direct mapping between text and verification obligation. If the word “shall” appears, there must be a test, inspection, analysis, or demonstration that proves compliance. That is genuinely useful. The verb carries legal and engineering weight simultaneously.

IEEE 830 and later standards carried the convention into commercial software requirements. INCOSE adopted it in the Systems Engineering Handbook. NASA embeds it in NPR 7123.1 and associated requirements writing guides. It became the default for aerospace, defense, medical devices, and any domain with formal verification obligations.

What “Shall” Language Actually Gets Right

Before criticizing the convention, acknowledge what it delivers when applied well.

Obligation traceability. Every “shall” statement is a claim that must be verified. This creates a one-to-one (ideally) mapping between requirement text and verification evidence. When you parse a specification for verification planning, “shall” acts as a syntactic marker that automated tools can find without NLP — even a simple grep. That is not nothing.

Forcing function against vague intent. Writing “The system shall X” forces the author to commit to a specific system behavior. It is harder to write a non-requirement — a statement about goals, context, or aspirations — and dress it as a requirement when the modal verb demands specificity. Not impossible, but harder.

Reviewer alignment. On large programs with multiple contractors, subcontractors, and government oversight, a shared linguistic convention reduces interpretation variance. “Shall” is a signal that everyone in the room understands as binding. Replacing it with plain English requires more contextual judgment from reviewers, which introduces more variance.

Testability scaffolding. The shall/should/may hierarchy, combined with guidance like “one requirement per shall,” implicitly pushes writers toward atomic, testable statements. The discipline is embedded in the syntax.

Where It Breaks Down

The convention was designed for a specific context — large defense contracts with formal V&V regimes. When applied outside that context, or applied mechanically within it, it produces a specific set of pathologies.

Passive voice distortion. The combination of formal requirements style and shall language strongly encourages constructions like “The system shall be capable of being operated by…” or “Data shall be provided to the operator when…” Passive constructions obscure who does what to whom. You can write requirements that pass a shall-compliance check and still have no clear subject, no defined condition, and no measurable outcome.

Compound shall statements. “The system shall acquire, process, and transmit sensor data within 200 ms under all operating conditions.” That is three requirements and an implicit performance constraint jammed into one sentence. The presence of “shall” makes it look like one atomic requirement. Many programs have verification matrices full of entries like this — a single row that requires three separate tests and nobody has noticed the mismatch.

Shall-ification of non-requirements. “The system shall be user-friendly.” The word “shall” makes this look like a requirement. It is not. No amount of modal verb discipline fixes the absence of a measurable acceptance criterion. But in document-centric tools, the sentence passes the filter.

Over-formalization that loses the engineering. This is the most serious failure mode. Teams spend time making sentences grammatically conform to the convention rather than thinking about what the system actually needs to do. Requirements reviews become syntax audits. The shall police show up and nobody asks whether the requirement captures the right behavior.

What INCOSE and NASA Actually Say

Both organizations endorse shall-based conventions while spending significant guidance on avoiding exactly the failure modes described above.

The INCOSE Systems Engineering Handbook (current edition) recommends the shall/should/may hierarchy for specifying requirements but lists “good requirements characteristics” that go well beyond modal verb compliance: singular, verifiable, unambiguous, complete, feasible, traceable. The handbook explicitly calls out compound requirements and passive constructions as quality defects — and those defects appear constantly in shall-formatted specifications.

NASA’s requirements writing standard (NPR 7123.1 and the associated training materials) requires “shall” for all binding requirements and provides a checklist that includes: each requirement contains a single “shall,” requirements are stated in active voice where possible, and each requirement is independently verifiable. NASA also uses the SMART criteria (Specific, Measurable, Achievable, Realistic, Timely) as a complementary layer on top of the linguistic convention.

The honest read of both bodies of guidance: the convention is a floor, not a ceiling. Compliance with shall syntax is necessary but not sufficient for a well-formed requirement.

Performance-Based Requirements: A Genuine Alternative Frame

One substantive alternative to prescriptive shall statements is performance-based requirements — a framing that specifies what outcome must be achieved rather than what mechanism must exist.

Instead of: “The propulsion system shall use a turbofan engine with a bypass ratio greater than 8.”

Write: “The aircraft shall achieve a specific fuel consumption not exceeding 0.55 lb/lbf·hr under cruise conditions defined in [reference].”

The performance-based form leaves implementation open, which matters enormously in early acquisition and in systems where you want competitive proposals. It is also, in most cases, more directly testable — you measure the outcome, not the implementation.

Performance-based requirements can and often do use “shall.” The issue is not the modal verb; it is whether the requirement specifies the system’s behavior from the outside (performance) or dictates internal design choices (prescriptive). Both approaches have a place. Prescriptive requirements are appropriate when a specific implementation is mandated for interoperability, safety, or standards compliance. Performance-based requirements are appropriate when you want to leave design space open.

The practical guidance: default to performance-based framing, use prescriptive requirements when there is a specific engineering reason to constrain implementation, and use “shall” in both cases to maintain obligation clarity.

Plain Language Requirements: When They Work

Some organizations — particularly in commercial product development and agile hardware contexts — have moved toward plain-language requirements that drop the modal verb convention entirely. User stories, acceptance criteria in natural language, and behavior-driven specifications (Given/When/Then format) are all examples.

These formats work well when:

  • The team writing and verifying requirements is small and stable
  • The program does not involve formal government contractual verification
  • The domain has short iteration cycles where ambiguity is caught quickly
  • Tool support for traceability does not depend on syntactic markers

They work poorly when:

  • Multiple organizations must interpret the same document independently
  • Contractual verification is required
  • Compliance with domain standards (DO-178C, IEC 61508, ISO 26262) demands traceable verification evidence

The honest answer is that “shall” language is not the enemy of clarity — poorly written shall statements are. And plain language requirements are not inherently clearer — poorly written plain requirements are equally ambiguous, without even the obligation signal the modal verb provides.

How Modern Tooling Changes the Equation

Here is where the practical situation has shifted.

The original case for shall language included a pragmatic argument: the verb acts as a machine-readable marker for verification obligations. In a world of static documents and manual reviews, that syntactic handle was genuinely valuable. Tools could count “shalls,” extract them, populate verification matrices.

Modern AI-native requirements tools can do substantially more than count verbs.

Flow Engineering applies AI analysis to requirements regardless of which linguistic convention a team uses. The platform can identify ambiguous phrasing — constructions like “adequate,” “as required,” “where applicable,” “user-friendly,” “state-of-the-art” — that signal incomplete requirements whether or not a “shall” is present. It flags compound requirements (multiple obligations in one statement) and passive constructions that obscure system or actor identity.

Critically, Flow Engineering’s AI can assess whether a requirement is likely testable based on its content and structure, not just its syntax. A requirement can include “shall” and still fail that test. A requirement written without “shall” can still be specific, measurable, and traceable. The AI evaluates the substance.

This changes the human task. Instead of enforcing a linguistic convention as a proxy for quality, engineers can focus on the engineering: Is this the right requirement? Does it capture the actual system behavior? Is the performance level correct? What is the verification method? Flow Engineering’s graph-based model connects requirements to verification nodes directly, so traceability is structural rather than dependent on whether the right word appears in a sentence.

For teams transitioning from legacy document-based tools — IBM DOORS, Jama Connect, Polarion — this represents a meaningful shift in where human effort goes. The AI handles syntax and quality pattern detection. Engineers handle the harder judgment calls about whether the requirements reflect the right system design.

The Practical Answer

Use “shall” language when you are writing binding requirements for programs with formal verification obligations, multi-organization contracts, or compliance with aerospace and defense standards. The convention is load-bearing in those contexts.

Apply it with discipline: one obligation per shall, active voice wherever possible, measurable acceptance criteria, no shall for goals or aspirations.

Add performance-based framing as your default orientation — specify outcomes from the outside, constrain implementations only when there is a specific reason to do so.

Recognize that “shall” compliance is a floor. A specification full of well-formed shall statements can still be a collection of ambiguous, compound, untestable requirements. Linguistic convention is not a substitute for requirements engineering judgment.

And use tooling that evaluates substance, not just syntax. Whether your team writes in shall language, plain language, or a hybrid, the quality questions are the same: Is the obligation clear? Is the subject identified? Is the requirement measurable? Is it traceable to a verification method? Modern AI-assisted tools can answer those questions at scale, across thousands of requirements, faster and more consistently than manual review.

The debate between “shall is essential” and “shall is outdated” is the wrong debate. The right question is whether your requirements — however written — tell the system what it actually needs to do and give your verification team what they need to prove it.