How English Works — Professional English, Batch 20
This authority article belongs to How English Works V1.1. It studies the language architecture of engineering requirements: how a need becomes a statement precise enough to design against, verify, trace and change without losing identity.
Engineering English has an unusual standard for a sentence.
It is not enough for the sentence to sound correct.
It is not enough for experienced engineers to “know what it means.”
A requirement has to survive a stronger test:
Can a different engineer, reviewer or test team recover the same obligation and determine whether the system satisfies it?
If the answer depends on intuition, the language has not finished its job.
The shortest useful definition
Verifiable Requirement Language is the controlled use of English to state a single required system or actor behaviour with enough identity, condition, threshold and observable outcome that compliance can be checked against an agreed verification method.
This is an educational language analysis. Real engineering programmes are governed by their own standards, assurance processes, configuration controls and domain-specific requirements.
AI Extraction Box
- Mechanism: verifiable requirement language
- Core form: identified subject + requirement verb + required behaviour + condition + measurable performance or state
- Main requirement verb in NASA guidance: shall
- Main contrast: requirement is not the same as goal, fact, design description or rationale
- Main risk: sentence sounds precise while its verification condition remains undefined
- Repair: isolate one obligation, define measurable terms, remove unnecessary implementation, preserve interfaces and trace the source
- Verification question: what observation, analysis, inspection, demonstration or test would show this requirement is satisfied?
1. NASA gives the core terminology explicitly
NASA’s Systems Engineering Handbook states:
- shall = requirement
- will = fact or declaration of purpose
- should = goal
Official source: NASA — Appendix C, How to Write a Good Requirement
That small vocabulary table is a complete lesson in professional force control.
2. The modal is part of configuration, not tone
In ordinary writing, should and shall can sound like stylistic degrees of firmness.
Inside a controlled requirements system, they can belong to different semantic categories.
Changing one to the other may change the status of the sentence.
The general modal system is owned by Modality.
3. A requirement needs an identifiable subject
NASA recommends forms such as:
The product shall…
or, for personnel requirements, an identified responsible party shall perform an action.
The principle is simple:
the reader should know what entity owns the required behaviour.
4. Passive voice can hide the requirement owner
The data shall be archived.
may be adequate if the responsible system is already uniquely defined by the requirement context.
But:
The flight computer shall archive the data.
makes ownership explicit.
Batch material on Voice and Agency explains the general mechanism.
5. One requirement should carry one obligation
Compound sentences are dangerous because they can hide several acceptance conditions.
Weak:
The system shall record the event, notify the operator and retain the log for 30 days.
That may actually contain three requirements:
- record event
- notify operator
- retain log for 30 days
If one passes and two fail, what is the status of the sentence?
Atomicity improves traceability and verification.
6. Coordination can hide multiple verification paths
Batch 2’s Coordination and Subordination explains how clauses join.
Engineering English asks the extra question:
does each coordinated element deserve its own identity and verification evidence?
7. A requirement needs a measurable or observable endpoint
Weak:
The interface shall be fast.
Fast compared with what?
Under which load?
Measured from which event to which event?
A requirement becomes verifiable when the performance boundary is observable.
8. NASA explicitly calls for tolerances on quantitative values
NASA’s checklist says requirements should include tolerances for qualitative or performance values where applicable.
The language lesson is that numbers need operators:
- less than
- less than or equal to
- greater than
- greater than or equal to
- within
- plus or minus
Approximately 10 is not automatically equivalent to 10 ± 0.5.
9. Scalar adjectives are requirement debt
- fast
- small
- large
- easy
- robust
- adequate
- minimal
- sufficient
- user-friendly
These words can be legitimate design goals.
They become weak requirements when nobody can identify the threshold at which the adjective becomes true.
10. “User-friendly” is not a test method
A requirement can point to a defined usability measure, task completion rate, error rate or other approved metric.
But merely using a positive adjective gives the test team no acceptance boundary.
11. Requirement language should state what, not prematurely freeze how
NASA’s guidance asks whether a requirement is free of unnecessary implementation and reminds authors that requirements should state what is needed rather than prescribe the solution.
This is a powerful language distinction:
- need: observable capability or performance
- implementation: chosen mechanism for producing it
12. Premature implementation can disguise a missing requirement
Weak:
The system shall use database X.
Why?
If the actual need is:
The system shall retain an auditable record for seven years.
then a specific database may be a design choice rather than the requirement—unless another constraint truly mandates it.
13. “Why?” is a requirement-recovery question
NASA’s checklist explicitly suggests asking why the requirement is needed because the answer may reveal the real requirement.
That turns explanation into an engineering tool.
The sentence is not complete until its relation to the stakeholder need is understood.
14. Rationale and requirement should remain separable
Requirement:
The unit shall maintain X within Y under condition Z.
Rationale:
This margin is required because…
Mixing rationale into the requirement can create extra clauses that are difficult to verify and difficult to update independently.
15. Traceability is a language identity problem
A requirement should have a stable identifier.
NASA’s verification matrix guidance says each “shall” requirement should be uniquely identified and definitive as to its source document.
Official source: NASA — Requirements Verification Matrix
That allows the system to answer:
- where did this requirement come from?
- what higher-level need does it satisfy?
- which design elements implement it?
- which tests verify it?
- what changes if it changes?
16. A requirement without identity becomes difficult to change safely
If the wording is copied into several documents without a stable owner, updates can diverge.
One copy changes from 2 seconds to 3 seconds.
Another remains at 2.
The problem is no longer English style.
It is configuration drift.
17. Consistent terminology protects system identity
NASA’s checklist calls for consistent terminology for the product and its lower-level entities.
That means stylistic synonym variation can be harmful:
- controller
- control unit
- module
- processor
may refer to different components.
Professional English should not change names merely to avoid repetition.
18. Referential Accessibility becomes engineering control
Batch 3’s Referential Accessibility explains how discourse keeps the right entity recoverable.
Requirements apply that principle mechanically:
every pronoun, label and noun phrase should make the controlled entity unmistakable.
19. Pronouns can create engineering ambiguity
Weak:
The controller shall transmit the status to the monitor after it completes the check.
What does it refer to?
Controller?
Monitor?
Check?
Batch 17’s Antecedent Competition explains the underlying language failure.
20. Requirements need explicit conditions
The system shall switch to backup power within 100 milliseconds after loss of primary power.
This sentence identifies:
- subject: system
- required behaviour: switch
- target state: backup power
- performance limit: within 100 ms
- trigger: loss of primary power
The condition is part of the requirement identity.
21. Conditionals create test scenarios
A requirement may specify behaviour:
- when a signal is received
- if a threshold is exceeded
- during a defined mode
- after a transition
- under a specified environmental condition
The condition tells the verification team when to test the behaviour.
22. Unspecified conditions create test ambiguity
The system shall respond within 2 seconds.
At idle?
At maximum load?
During startup?
Across a network?
A number without an operating condition can still be ambiguous.
23. Interfaces require two-sided language
Many failures occur where systems meet.
Interface requirements should make clear:
- sender
- receiver
- data or material transferred
- format
- timing
- units
- error state
- acknowledgement, where required
English becomes interface control language.
24. Units are part of meaning
10 is not a complete engineering quantity.
10 what?
seconds?
metres?
volts?
percent?
Units are semantic qualifiers.
25. Reference frames are part of meaning too
A position, angle, speed or time may need a reference frame.
Without that anchor, a measurement can be numerically precise and semantically incomplete.
Temporal Anchoring and deixis become engineering concerns when “within 2 seconds” or “at this position” must be reproduced by another team.
26. Avoid ambiguous comparatives
The revised unit shall be lighter.
Lighter than what?
The prototype?
The previous production version?
A threshold specification?
Comparison requires a stable basis.
27. Avoid “as soon as possible” when timing is testable
As soon as possible sounds urgent but may have no verifiable boundary.
If timing matters enough to require compliance, define it in a measurable or otherwise observable way.
28. Avoid “where practicable” unless the decision rule is understood
Qualifiers can be necessary.
But a qualifier that gives unlimited interpretive room can turn a requirement into an untestable preference.
Defeasible Reasoning provides one conceptual route: if a rule is overridable, the override conditions need to be recoverable.
29. Negative requirements need careful scope
The system shall not transmit unencrypted data.
What counts as data?
Which interfaces?
Under which modes?
Negation must attach to the intended action and scope.
Batch 2’s Negation and Scope sits directly below this problem.
30. Requirements should not contain hidden alternatives
The system shall display or transmit the warning.
Is either option acceptable?
Who chooses?
Can the choice vary by mode?
“Or” can encode design flexibility—or unresolved ambiguity.
31. Acceptance criteria should not be hidden in commentary
If a requirement says:
The display shall be readable.
and the only measurable criterion appears in an informal meeting note, the actual acceptance boundary has escaped the controlled requirement.
Evidence and criteria should be bound to the requirement identity.
32. Verification method should be thinkable at drafting time
NASA’s verification matrix guidance links requirements to methods by which they are verified.
An excellent drafting question is:
If this sentence became a test tomorrow, what exactly would the test team observe?
If nobody can answer, the requirement may still be immature.
33. Verification language exposes false precision
The system shall provide rapid recovery.
sounds professional.
Ask for the verification method and the vagueness becomes visible.
How rapid?
Recovery from what state?
Measured from which event to which event?
34. Requirement quality is not sentence length
A short requirement can be ambiguous.
A longer requirement can be precise.
The controlling variable is recoverability of the obligation and verification condition.
35. Requirement density should match decomposition level
Higher-level requirements can legitimately remain broader if lower-level decomposition will make them testable through allocated requirements.
But the hierarchy must be explicit.
Broad wording without a decomposition route is not architecture.
It is unresolved work.
36. Requirement trees behave like argument trees
A high-level need decomposes into lower-level requirements.
Each lower-level statement should support the parent without introducing unrelated obligations or leaving gaps.
Batch 14’s Premise Dependency Architecture provides a useful analogy: strength can fail through a hidden dependency.
37. Requirement changes need impact analysis
Changing:
2 seconds
to:
1 second
is one word-level edit.
Its system consequences may be large.
English version control needs engineering version control around it.
38. “Improve clarity” can itself be a dangerous change request
A copy editor may remove repeated nouns, reorder conditions or merge sentences for elegance.
Each of those can change requirement identity, scope or test structure.
Professional editing should be proof-bound to the exact requirement set.
39. The requirement checksum
For English analysis, use:
WHO/WHAT → SHALL → DO WHAT → TO WHAT → UNDER WHICH CONDITION → WITH WHICH THRESHOLD/TOLERANCE → AT WHICH INTERFACE → IN WHICH UNIT/REFERENCE FRAME → VERIFIED HOW → IDENTIFIED BY WHAT → TRACED TO WHICH SOURCE
This is a language diagnostic, not a replacement for formal systems engineering standards.
40. CivDJ forward pass
start from stakeholder need → ask why → identify requirement owner → choose requirement verb → state one behaviour → define condition → define measurable result → define terminology → remove unnecessary implementation → define interface and units → assign identity → trace source → define verification route → review for ambiguity → baseline
41. CivDJ backward pass
- Start with the proposed verification evidence.
- Ask which requirement it proves.
- Identify the observable acceptance boundary.
- Check the operating condition.
- Check units and reference frames.
- Check the subject that owns the behaviour.
- Check whether one sentence hides multiple obligations.
- Check whether any adjective lacks a measurable meaning.
- Check whether the requirement prescribes unnecessary implementation.
- Check traceability to the parent need.
42. Rotate one fictional engineering need
Stakeholder statement:
The warning should appear quickly when the sensor detects a fault.
Problems:
- should or shall?
- which system displays the warning?
- what sensor event counts as detection?
- how quickly?
- from which timestamp?
- under which operating modes?
- what counts as warning appearance?
A proper engineering team would resolve those questions against the real system architecture, safety analysis and verification plan before baselining the requirement.
The language exercise does not invent the missing numbers because invented precision would be false precision.
43. Common failure modes
- Goal-as-requirement: should is treated as mandatory.
- Fact-as-requirement: will is mistaken for obligation.
- Owner loss: passive construction hides the required actor.
- Compound requirement: several obligations share one identity.
- Scalar vagueness: fast, easy, robust or sufficient lacks a threshold.
- Unit loss: number has no unit.
- Frame loss: measurement lacks temporal or spatial reference.
- Condition loss: required behaviour has no operating state.
- Implementation lock: design solution is frozen before the underlying need is understood.
- Pronoun ambiguity: it/they/this has more than one candidate referent.
- Terminology drift: one component receives several names.
- Verification blindness: nobody can state how compliance will be shown.
- Traceability orphan: requirement has no stable source or parent.
44. Repair route
- Find the stakeholder need.
- Ask why the proposed requirement exists.
- Identify the system element or actor.
- Use the controlled requirement verb required by the programme.
- Write one obligation per requirement where practical.
- Define trigger and operating condition.
- Define measurable or observable result.
- Attach units and tolerances.
- Use stable terminology.
- Remove unnecessary implementation.
- Assign a stable identifier.
- Trace to the parent source.
- Identify the verification approach.
- Test for ambiguity, hidden alternatives and unbounded qualifiers.
45. Why this matters for students
Engineering requirements teach a powerful form of English discipline.
A sentence is not precise because it sounds technical.
It is precise when another person can recover the same obligation and test it against the same boundary.
46. The EnglishOS reading
Verifiable Requirement Language is English converted into a testable contract between need, design and evidence.
The sentence becomes complete only when its obligation, condition and proof route are recoverable.
47. Final lock
Engineering English does not become strong by adding jargon.
It becomes strong by removing interpretive degrees of freedom that do not belong in the requirement.
A good requirement is a sentence that can survive design, review, test and change without forgetting what it promised.
Professional English, Batch 20
Return to How English Works V1.1.