What Makes a Good Requirement? The Characteristics of High-Quality Requirements

Bad requirements rarely look bad at first. They usually sound reasonable, survive early reviews, and only become expensive when design teams, suppliers, testers, or customers interpret them differently.

A good requirement does more than describe what someone wants. It creates a shared engineering contract. It tells the team what must be true, why it matters, how success will be judged, and how the requirement connects to the rest of the system.

Standards and guides such as ISO/IEC/IEEE 29148, NASA’s requirements guidance, and the INCOSE Guide to Writing Requirements all emphasize similar quality characteristics: requirements should be correct, complete, consistent, unambiguous, feasible, verifiable, necessary, and traceable.

1. Correctness

A requirement is correct when it accurately reflects the stakeholder need, operational context, regulation, interface, or higher-level requirement from which it was derived.

Example:

Poor: The payment system shall process all transactions instantly.

Better: The payment system shall authorize standard credit card transactions within 3 seconds under normal network conditions.

The first statement may sound attractive, but “instantly” is not technically correct. The improved version defines a realistic and measurable expectation.

Correctness asks: are we specifying the right thing?

2. Completeness

A complete requirement contains enough information to be understood, implemented, and verified without guessing.

Poor: The device shall alert the user when the battery is low.

Better: When battery charge falls below 15%, the device shall display a low-battery warning within 5 seconds.

The improved version defines the trigger, threshold, response, and timing.

Completeness does not mean adding unnecessary detail. It means including the information needed to remove interpretation gaps.

3. Consistency

A requirement is consistent when it does not conflict with other requirements, terminology, constraints, or assumptions.

Example:

Requirement A: The mobile app shall allow users to reset their password using email.

Requirement B: The mobile app shall not collect or store user email addresses.

Both may be valid ideas individually, but together they conflict. Consistency problems often appear when different teams write requirements independently.

This is one reason requirement reviews become harder as systems scale.

4. Unambiguity

A requirement is unambiguous when it can be interpreted in only one reasonable way by its intended audience.

Poor: The dashboard shall load quickly.

Better: The dashboard shall display the primary user view within 2 seconds after login for 95% of requests under normal operating conditions.

Words like fast, robust, user-friendly, optimized, seamless, sufficient, and appropriate often hide ambiguity. They may be useful in marketing language, but they are dangerous in requirements unless they are defined.

Unambiguity is one of the most important characteristics because ambiguity allows disagreement to survive until integration, verification, or customer acceptance.

5. Verifiability

A requirement is verifiable when there is a practical way to prove whether it has been satisfied.

Good requirements usually support verification by test, analysis, inspection, or demonstration. MIT’s systems engineering material similarly describes verification methods such as examination, test, demonstration, and analysis.

Poor: The system shall be easy to maintain.

Better: A trained technician shall be able to replace the filter module in less than 10 minutes using standard hand tools.

The second version can be tested. The first version is an opinion.

A requirement that cannot be verified is not really a requirement. It is a hope.

6. Feasibility

A requirement is feasible when it can realistically be achieved within known technical, cost, schedule, regulatory, and operational constraints.

Poor: The delivery robot shall operate for 72 hours continuously without recharging, weigh less than 2 kg, and carry a 20 kg payload.

This may violate physics, cost targets, or available battery technology.

Feasibility does not mean requirements should be easy. It means they should be achievable or clearly marked as needing trade study, risk retirement, or technology maturation.

7. Necessity

A requirement is necessary when it exists for a valid reason.

Every requirement should answer: what stakeholder need, risk, regulation, interface, safety concern, business objective, or higher-level requirement justifies this?

Unnecessary requirements are not harmless. They add design constraints, verification effort, documentation burden, and change-management overhead.

Poor: The kiosk shall support voice commands.

Better question: Is voice control required by accessibility needs, operating conditions, customer demand, or regulation?

If not, it may be a feature idea, not a requirement.

8. Traceability

A requirement is traceable when its origin, relationships, implementation path, and verification evidence can be followed.

Good traceability helps answer:

Where did this requirement come from?

What design elements satisfy it?

What tests verify it?

What happens if it changes?

Traceability is especially important when systems involve multiple teams, suppliers, interfaces, or regulated development environments. The SEBoK describes requirements verification and validation as including comparison against requirement characteristics and the integrated set of needs.

Without traceability, teams lose the ability to understand change impact. A small wording change can quietly affect architecture, interfaces, test plans, cost, and schedule.

Why Requirement Quality Breaks Down

Most teams know what good requirements look like. The problem is not awareness. The problem is scale.

A small project may have dozens of requirements. A serious engineering program may have hundreds or thousands across stakeholder needs, system requirements, subsystem requirements, interface requirements, verification cases, and compliance evidence.

Manual reviews become inconsistent. Reviewers get tired. Ambiguous words slip through. Duplicate requirements multiply. Conflicts hide across documents. Verification methods are added late. Traceability becomes stale.

This is where automated requirement quality analysis becomes valuable.

The Role of Automated Requirement Quality Analysis

Automated requirement analysis does not replace engineering judgment. It supports it.

Research on natural language processing for requirements engineering has explored how NLP can help with requirements quality checking, ambiguity detection, classification, extraction, traceability, and other requirements engineering tasks.

In practice, automated analysis can help teams identify:

vague or subjective language

missing units, thresholds, conditions, or triggers

compound requirements that should be split

requirements that are difficult to verify

inconsistent terminology

potential duplicates

missing trace links

requirements without clear verification intent

This is exactly the type of gap Ngenaire is designed to fill.

Ngenaire helps engineering teams analyze requirement quality earlier by flagging weak requirement statements, surfacing ambiguity, supporting traceability, and reducing the manual overhead that usually slows down requirement reviews. The goal is not to remove the engineer from the process. The goal is to give engineers better visibility before poor requirements become expensive design, integration, or verification problems.

A Practical Checklist for Good Requirements

Before approving a requirement, ask:

Is it correct?

Is it complete enough to implement and verify?

Is it consistent with related requirements?

Can it be interpreted in only one way?

Can it be verified by test, analysis, inspection, or demonstration?

Is it feasible within known constraints?

Is it necessary?

Can it be traced to its source, implementation, and verification evidence?

If the answer to any of these is unclear, the requirement is not ready yet.

Final Thought

A good requirement is not just a well-written sentence. It is a decision made visible.

It captures intent, limits interpretation, supports verification, and connects engineering work back to real stakeholder needs.

Poor requirements create hidden risk. Good requirements create alignment.

And as systems become more complex, the future of requirements engineering will not be purely manual. It will combine engineering judgment with automated quality analysis, so teams can find problems earlier, move faster, and build with more confidence.

Sources

1. INCOSE Requirements Working Group, Guide to Writing Requirements, Version 4 Summary Sheet.
2. ISO/IEC/IEEE 29148:2018, Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
3. NASA, Appendix C: How to Write a Good Requirement.
4. NASA, Systems Engineering Handbook.
5. Olivier L. de Weck, MIT OpenCourseWare, Fundamentals of Systems Engineering: Requirements Definition.
6. Zhao et al., Natural Language Processing for Requirements Engineering: A Systematic Mapping Study.
7. Necula et al., A Systematic Literature Review on Using Natural Language Processing in Software Requirements Engineering.
8. Umar et al., Advances in Automated Support for Requirements Engineering.
9. SEBoK, System Requirements Definition.