Every discussion of requirements management eventually reaches for tooling — traceability matrices, suspect-link detection, coverage dashboards. All of it is real and all of it matters, but none of it fixes the problem that causes the most program pain: requirements that are badly written in the first place. A perfect traceability engine linking ambiguous, untestable, compound requirements just gives you an auditable record of confusion. Requirement quality is upstream of traceability, verification, and every review gate, and it is the cheapest thing to fix and the most expensive thing to leave broken.
The authoritative reference on this is the INCOSE Guide to Writing Requirements, which codifies decades of hard-won practice into a set of characteristics that a good requirement should have and a set of rules for achieving them. The characteristics are worth stating plainly because they are the criteria a review board is implicitly applying whether they name them or not: a good requirement is necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct, and conforming. Every recurring requirements defect is a violation of one of these, and learning to spot the violations is most of the skill.
Start with singular, because compound requirements are the most common defect and the easiest to catch. A requirement should state exactly one thing. The moment you see the word "and" joining two capabilities — "the system shall log the transaction and notify the operator" — you have two requirements wearing one ID. This matters far beyond style. When you verify it, you need one test for logging and another for notification, and a single pass/fail status cannot represent both. When one half changes, the whole requirement is flagged suspect even though the other half is untouched. Split compound requirements at authoring time and the entire downstream chain gets cleaner.
Unambiguous is the characteristic that separates requirements that two engineers read identically from requirements that spawn arguments at CDR. Ambiguity hides in vague adjectives and undefined terms. "The system shall respond quickly" is unverifiable because "quickly" has no number. "The system shall be user-friendly" cannot be tested because "user-friendly" is not a measurable property. "The system shall support relevant standards" invites the question: which ones? The fix is discipline about quantification — every performance requirement carries a number and a unit, every reference names the specific standard and revision, and every subjective term is either quantified or removed.
Verifiable is the characteristic that connects requirement quality directly to the V&V matrix, and it is the one that catches the most trouble late. A requirement is verifiable only if there exists a practical method — test, analysis, inspection, or demonstration — that can prove it is met. "The system shall be reliable" is not verifiable as written; "the system shall achieve a mean time between failures of at least 10,000 hours, verified by reliability analysis" is. The test is simple and worth applying to every requirement as you write it: can I name the method and the pass criterion right now? If not, the requirement is not done, no matter how good it sounds.
The other characteristics are subtler but no less real. Necessary means the requirement traces to a genuine stakeholder need and its absence would leave a real gap — requirements that exist because someone thought they sounded thorough are just cost. Appropriate means the requirement is stated at the right level of the hierarchy and does not over-specify implementation ("the system shall use a 12-volt bus" is a design decision masquerading as a requirement, constraining designers for no stated reason). Feasible means it can actually be achieved within the program constraints. Complete means it stands on its own without relying on unstated assumptions or "to be determined" placeholders that never get resolved.
This is where EARS earns its place. EARS — the Easy Approach to Requirements Syntax, developed by Alistair Mavin and colleagues at Rolls-Royce — is a small set of sentence patterns that structurally prevent many of the defects above. Instead of leaving requirement authors to compose free-form prose and hope it comes out unambiguous, EARS gives them a handful of templates that force the right shape. The patterns are constrained enough to eliminate the worst ambiguity and flexible enough to cover essentially every requirement a real system needs.
The EARS patterns map to the situations a requirement can describe. Ubiquitous requirements state something always true, with no trigger or condition: "The system shall <requirement>." Event-driven requirements use a trigger: "When <trigger>, the system shall <requirement>." State-driven requirements hold while a condition is active: "While <state>, the system shall <requirement>." Unwanted-behavior requirements handle error and off-nominal cases: "If <unwanted condition>, then the system shall <requirement>." Optional-feature requirements scope to a configuration: "Where <feature is included>, the system shall <requirement>." Complex requirements combine these building blocks in a controlled way. That is nearly the whole notation, which is exactly why it works — it is small enough to actually adopt.
What EARS buys you is that the structure carries the precision. A well-formed EARS requirement names its trigger or condition explicitly, so the reader is never left guessing when the behavior applies. It puts the behavior in a single "shall" clause, which nudges the author toward singular requirements. And because the patterns for normal behavior, states, and error handling are visibly different, EARS makes it obvious when a requirement set has covered the happy path but forgotten the unwanted-behavior cases — the "if the sensor fails" and "if the input is out of range" requirements that ambiguous prose lets you skip without noticing.
EARS is not a silver bullet, and it is worth being honest about its limits. It structures the sentence; it does not supply the number. You can write a perfectly formed event-driven requirement that still says "respond quickly," and the pattern will not save you — quantification is a separate discipline. EARS also does not decide whether a requirement is necessary or at the right level. What it does is remove a large class of structural defects so that review effort can focus on the harder judgment calls about content, feasibility, and necessity instead of being spent rewording tangled sentences.
The practical workflow that combines these ideas: adopt EARS as the default syntax so requirements come out structurally sound; apply the INCOSE quality rules as an authoring checklist so each requirement is singular, quantified, and verifiable; and gate on verifiability by requiring a verification method to be named as the requirement is written, not months later when the V&V matrix is assembled. Reviewing a requirement set then becomes tractable, because the mechanical defects are already gone and the board can spend its attention on whether the requirements are the right ones. A sampled read of ten requirements should surface zero compound statements, zero unquantified performance claims, and zero requirements without a verification method — and if it does not, the set is not ready.
Requirement quality has a compounding effect that is easy to underestimate. A defect authored into a requirement at SRR does not stay contained. It gets derived into child requirements that inherit the ambiguity, allocated into design elements built on the wrong interpretation, and carried into verification activities that test the wrong thing. The cost of fixing a badly written requirement grows with every phase it survives, which is precisely why the discipline belongs at authoring time. The cheapest requirements review is the one the author does on their own sentence before anyone else ever sees it.
Hitt Hosting SE supports requirement quality where it is cheapest to enforce — at the point of authoring. Requirements can be written to EARS patterns, and the same connected model that maintains traceability makes the quality signals visible: requirements without a named verification method surface as gaps in the V&V coverage, compound requirements that were split keep their derivation pedigree intact, and every performance requirement sits next to the analysis or test that proves it. Because requirements, design, and verification live in one model, a requirement that cannot be verified is not an abstract style complaint — it shows up as a hole in the coverage the review board is looking at. The tool cannot write a good requirement for you, but it makes a bad one impossible to hide.