Modality and Requirements Precision: MUST vs SHOULD vs MAY for Testable Specs

Why Modality Matters for Testable Specifications

Specifications live or die by clarity. When a requirement is ambiguous, different implementers guess differently, tests become inconsistent, and products fail to interoperate. The single most powerful tool to avoid this is precise modality: using standardized keywords that encode not just tone, but obligation and testability. RFC 2119—widely adopted across technical standards—defines the core modal verbs used to mark normativity and strength of requirement. Understanding and applying these modals consistently is essential for writing requirements that can be verified, traced, and enforced.

In this system, three families of words anchor the spectrum of obligation:

• MUST / MUST NOT indicate absolute requirements or prohibitions. If the condition applies, compliance is mandatory with no discretionary exceptions. These statements set the non-negotiable backbone of a spec and are prime material for conformance tests.
• SHOULD / SHOULD NOT indicate strong recommendations. The requirement should be followed unless a justified, documented exception is made. This acknowledges practical constraints while still steering implementations toward interoperable behavior.
• MAY indicates permission. Implementers are allowed—but not required—to do something. MAY never implies obligation; it authorizes optional behavior that tests may exercise but cannot demand.

Equally important is the distinction between normative and informative content. Normative content defines what is required for conformance—these are the rules against which implementations are judged. Informative content explains background, rationale, or examples—it informs without imposing obligations. Normative sections use RFC 2119 keywords; informative sections avoid them. Confusing these two dilutes enforceability: if rationale reads like a rule, implementers may misunderstand priorities; if rules are buried in narrative prose, test authors struggle to extract verifiable statements.

Modality, then, is not style; it is the encoding of conformance. Choosing the correct modal verb signals how a statement should be tested, how failures should be treated, and how implementers must reason about trade-offs. The rest of this lesson unpacks each modal family, aligns them with verification strategies, and provides a decision framework to choose appropriately based on risk, interoperability impact, and feasibility.

Deep Dive: How Each Modal Maps to Verification

MUST / MUST NOT: Absolute, Fully Testable Obligations

Definition and force. A statement with MUST or MUST NOT sets a non-negotiable rule: if the preconditions are met, the specified behavior is required or forbidden. No silent exceptions are allowed. Because there is no implementation discretion, these are the clauses most naturally translated into objective tests.

Litmus tests for MUST:

• Does violating the statement directly threaten safety, security, data integrity, or interoperability?
• Can a test unambiguously detect compliance or noncompliance given a precise trigger condition and observable outcome?
• Would allowing an exception undermine consistent behavior across implementations?

Positive and negative forms.

• MUST requires the presence of a behavior under a specific condition.
• MUST NOT prohibits a behavior under a specific condition.

Both forms should be framed with explicit actors and triggers, avoiding compound obligations. Each MUST maps to a single testable behavior, not a checklist of loosely related actions. Wording should avoid qualitative adjectives that cannot be measured (e.g., “quickly,” “appropriately,” “safely”) unless they are operationalized with measurable criteria.

Verification. Because MUST statements are binary and unconditional, conformance tests verify them by:

• Setting up the stated preconditions precisely.
• Invoking the behavior once.
• Observing a clear outcome or artifact that indicates pass or fail.

A test suite should cover all MUST clauses relevant to conformance levels. Failure indicates nonconformance.

SHOULD / SHOULD NOT: Strong Guidance with Documented Exceptions

Definition and force. SHOULD expresses a near-obligation: it is the preferred behavior because it improves interoperability, safety, or performance, but exceptions may be acceptable if justified and documented. SHOULD NOT similarly discourages a behavior while allowing reasoned exceptions. The burden of proof is on the implementer to show why deviation is necessary.

Litmus tests for SHOULD:

• Is the behavior highly desirable for interoperability or safety, but known constraints (legacy systems, platform limitations, regional regulations) might make universal compliance impractical?
• Can you articulate legitimate scenarios where deviation is acceptable without breaking the ecosystem?
• Can tests detect whether the preferred behavior is implemented when feasible, and can exceptions be validated through explicit signaling or documentation?

Positive and negative forms.

• SHOULD identifies best practices that most conforming implementations will follow.
• SHOULD NOT discourages a behavior while leaving narrow room for justified use.

Verification. Testing SHOULD clauses requires two layers:

• First, attempt to verify the preferred behavior. Tests check for compliance under typical conditions.
• Second, if an implementation does not comply, verification looks for legitimate exception handling. This might include support for alternative mechanisms, explicit capability signaling, or documented constraints. A comprehensive conformance program often defines how exceptions are presented (e.g., via metadata, negotiation, or error codes), so that deviation is still predictable and interoperable.

MAY: Permission Without Obligation

Definition and force. MAY grants optional capabilities or behaviors. An implementer can choose to support them or not, without affecting conformance. MAY is appropriate when optional features expand functionality but are not necessary for baseline interoperability.

Litmus tests for MAY:

• Does the feature add value for some implementers without being foundational to the protocol or interface?
• Can other participants interoperate regardless of whether the feature is present?
• Would requiring the feature increase cost or complexity without commensurate benefit across the ecosystem?

Verification. For MAY statements, conformance testing is conditional:

• If an implementation claims to support the optional behavior, tests verify correct behavior under defined conditions.
• If it does not claim support, tests must not penalize it. The test plan checks for correct refusal, negotiation, or fallback rather than presence of the feature.

In practice, MAY pairs with capability discovery, negotiation, or versioning so that optional features do not surprise peers. Clarity in preconditions is critical: a MAY clause must still be written so that, if exercised, its behavior is verifiable and deterministic.

Writing Testable Requirements: Structure, Scope, and Placement

Precise modality is only useful when combined with precise requirement structure. A testable requirement should pair a clear actor and condition with a single observable behavior and a verifiable outcome. The following principles ensure this structure:

• One actor per requirement. Name the entity responsible for the behavior (client, server, component, module). Avoid hidden subjects or passive voice that obscures responsibility.
• Explicit preconditions. Define the state or input that triggers the behavior. Preconditions should be objective and reproducible by a tester.
• Single behavior. Avoid stacking multiple obligations in one sentence. Split into separate requirements when needed.
• Observable outcome. Specify outputs, state changes, messages, or errors that can be detected without internal knowledge of the implementation.
• Quantify, don’t qualify. Replace vague adjectives with measurable criteria (counts, time bounds, formats, codes). This turns narrative intent into test steps.
• Don’t stack modals. Each requirement should use one modal verb. Multiple modals in one sentence cause ambiguity in testing.

Placement matters as much as wording. Normative statements—the ones that define conformance—belong in requirements sections and must use RFC 2119 keywords. They should be numbered, stable, and traceable to tests. Informative content—background, motivation, design rationale, examples, and implementation advice—belongs in notes, rationale subsections, or appendices and must avoid RFC 2119 keywords. Instead of “should,” use neutral phrasing like “is recommended because” in informative sections to prevent accidental normativity. This segregation helps implementers know what they must do and helps test authors know what to test.

Choosing MUST vs SHOULD vs MAY: A Decision Framework

Selecting the correct modal hinges on three lenses: risk, interoperability, and feasibility. Treat these as scoring dimensions when drafting or reviewing requirements.

• Risk of failure. Consider the consequences if the requirement is not met. High risk to safety, security, data integrity, or legal compliance typically demands MUST. Moderate risk with mitigations may fit SHOULD. Low risk belongs with MAY or informative guidance.
• Interoperability impact. Ask whether variance across implementations will cause peers to fail, degrade severely, or be forced into brittle logic. If divergence breaks interaction or confuses negotiation, use MUST. If divergence is manageable but undesirable, use SHOULD. If divergence is expected and manageable, use MAY.
• Feasibility across implementations. Gauge whether different platforms, form factors, or legacy constraints can realistically meet the requirement. If universal feasibility is credible, prefer MUST. If obstacles exist for a minority with reasonable workarounds, prefer SHOULD with explicit exception handling. If wide variability is expected, grant MAY and define capability discovery.

When these factors conflict, prioritize risk and interoperability over convenience. However, a requirement that is impossible for a substantial portion of the ecosystem is self-defeating; it will not be implemented or will yield widespread nonconformance. In such cases, reduce the scope, specify a baseline MUST with optional extensions (MAY), or structure the requirement as SHOULD with explicit exception pathways. The key is to express the intended invariant as a MUST where it truly preserves safety and interoperability, and to push variability into controlled, discoverable options.

This framework also guides the separation of normative and informative text. Put the decision rule into the normative requirement, and explain the rationale and trade-offs in an informative note. The reader should be able to comply without consulting the rationale, while the rationale helps justify the chosen modality and supports future revisions.

Modality Discipline: Diagnose, Rewrite, and Annotate

To reinforce consistent use of MUST, SHOULD, and MAY, apply a three-part diagnostic to every candidate requirement:

• Classify the statement. Is it normative or informative? If normative, which modal is appropriate based on risk, interoperability, and feasibility? If informative, remove RFC 2119 keywords and move it to a non-normative section.
• Rewrite for testability. Ensure one actor, explicit preconditions, single behavior, and observable outcome. Replace vague qualifiers with measurable criteria. Remove stacked modals or conjoined obligations by splitting into multiple, numbered requirements.
• Annotate rationale separately. Keep the logic—why this is MUST instead of SHOULD, or why an exception exists—in a note or rationale subsection. If exceptions are allowed, define how they are detected or documented so tests can verify both compliance and legitimate deviation.

Maintaining this discipline improves more than readability. It enables the practical work of conformance: tracing each MUST to a test case, each SHOULD to a preferential test plus exception handling check, and each MAY to conditional tests tied to capability claims. It also makes maintenance easier. When a defect report comes in, editors can systematically adjust modality (for example, promoting a SHOULD to MUST due to new evidence of interoperability failures) and immediately understand the downstream test changes.

Finally, remember that modal choice implicitly designs your test strategy:

• A landscape of many MUSTs yields a tight, predictable baseline and a robust, binary conformance program.
• Strategically placed SHOULDs allow realistic accommodation for diversity while steering the market toward better behavior through test pressure and profiles.
• Carefully bounded MAYs encourage innovation without fragmenting the baseline, provided capability discovery and fallbacks are clearly specified.

By mastering these tools—precise modality, testable requirement structure, and the decision framework—you create specifications that are not only readable but also enforceable. The result is fewer ambiguities, stronger interoperability, and test programs that measure what matters. This is the essence of modality and requirements precision: choosing and placing MUST, SHOULD, and MAY so that every statement in the specification carries a clear, testable meaning, and every implementer knows exactly how to achieve conformance.