SYLEN
AboutNewsConferenceMembership

Email updates

Conference, news, and membership updates by email.

Network

  • About
  • News
  • Membership
  • Waitlist

Conference

  • Conference 2026
  • Call for papers
  • Sponsor

Membership

  • Create profile
  • Search profiles
  • Who it's for

SYLEN

  • Guidelines
  • Privacy
  • Terms

© 2026 Systems Leadership and Engineering Network. sylen.org.

Membership details →
Back to news
The 10 Most Common Requirements Anti-Patterns: Evidence from 500 Project Reviews

Image courtesy of systemsengineeringblog.com

Systems EngineeringSource: systemsengineeringblog.comMarch 26, 2026

The 10 Most Common Requirements Anti-Patterns: Evidence from 500 Project Reviews

An analysis of requirements defects across 500 systems engineering project reviews identifies the 10 most prevalent anti-patterns, with "shall ambiguity" and "missing verification method" accounting for 48% of all requirements defects found in independent reviews.

Requirements Anti-Patterns: What 500 Project Reviews Tell Us

Requirements defects are the most expensive defect type in systems engineering. A defect in a requirement propagates through design, implementation, and test before it is typically discovered — and fixing it at each stage is exponentially more expensive than fixing it at requirements time.

This analysis covers 500 independent requirements reviews conducted across aerospace, defence, medical device, and automotive programmes over a 10-year period, covering a combined 1.2 million requirement statements.

The Top 10 Anti-Patterns

1. Shall ambiguity (23% of defects). Requirements using "shall" with terms that are not uniquely interpretable. Example: "The system shall respond quickly." "Quickly" is not a verifiable requirement. The fix is always a measurable criterion.

2. Missing verification method (25% of defects combined with #1). Requirements without a specified verification method (analysis, inspection, demonstration, test). Unverifiable requirements are requirements in name only.

3. Compound requirement (12%). A single requirement statement that contains multiple independent requirements. Compound requirements resist independent verification and traceability.

4. Implementation-in-disguise (9%). A requirement that specifies a solution rather than a capability. Example: "The software shall use a 1024-bit RSA key." The requirement is the security level, not the implementation. Implementation constraints belong in design.

5. Missing assumption documentation (8%). Requirements that are only correct given unstated assumptions about the operational environment. When the environment differs from the assumption, the requirement fails without any individual statement being individually wrong.

6. Circular requirement (6%). A requirement that can only be verified by the system satisfying itself. Common in availability requirements stated as "the system shall be available when required."

7. Untestable negative (5%). Requirements of the form "the system shall never X." Without defining the test conditions under which X must not occur, verification is impossible.

8. Wrong level (5%). Requirements specified at a lower level of decomposition than the document's scope. System-level requirements that specify subsystem behaviour preempt design trade space without adding value.

9. Wishful performance (4%). Performance requirements with no engineering basis. These survive requirements reviews but fail at verification.

10. Missing rationale (3%). Requirements without documented rationale. When requirements conflict with design constraints (common in mature projects), missing rationale makes adjudication impossible.

Practical Implications

The most actionable finding: just two anti-patterns (#1 and #2) account for nearly half of all requirements defects. Training reviewers to reliably identify ambiguous terms and missing verification methods would eliminate more defects than any other single intervention.

Read the original article at systemsengineeringblog.com.