Keep requirements strictly free of implementation specifics: Expert requirements state the problem, not the solution. They describe WHAT is needed, not HOW the system will physically provide it
Never mix operations or personnel tasks with product requirements: Statements such as “The operator shall…” are operational descriptions or task assignments, not system requirements. Experts know to separate these domains by placing operational scenarios into the Concept of Operations (ConOps) document and personnel tasks into a Statement of Work (SOW)
Always document the “Rationale” and maintain “Bidirectional Traceability”
Ruthlessly eliminate unverifiable terms: A requirement is useless if it cannot be strictly tested, analyzed, or demonstrated
Enforce the “One Thought per Shall” rule: To prevent confusion during testing and design, requirements must be concise, standalone statements. Experts ensure that a requirement contains only one subject and one predicate, utilizing exactly one “shall” per statement, rather than bundling multiple conditions into a single paragraph
Controversies
Using TBDs (To Be Determined) vs. TBRs (To Be Resolved): When a value is unknown during the early stages of a project, engineers often use “TBD” as a placeholder until trade studies and technology mature. However, advanced guidance dictates that the use of TBDs should be minimized. Instead, engineers are pushed to establish a “best estimate” value marked as “TBR” (To Be Resolved), alongside a rationale and a deadline for elimination. Forcing engineers to commit to a tentative parameter before full analysis is complete can cause internal friction and disagreement over baseline accuracy.
User Stories vs. Shall Statements: Most modern teams use User Stories (As a user, I want…). Critics argue that User Stories are often too vague for backend logic or security, leading to “requirements rot” where nobody actually knows what the system is supposed to do technically.
The “Death” of the SRS: Traditionalists love the Software Requirements Specification (SRS)—a massive, 100-page document. Agilists argue it’s a waste of time, preferring “Just-In-Time” requirements. The controversy lies in whether you can actually build a complex system without a “Source of Truth” document.
The “Requirement vs. Design” Line: There is a classic rule: “Tell me what, not how.” However, in industries like cybersecurity or Embedded Systems Engineering, the how (the specific algorithm or hardware constraint) is the requirement. Over-abstracting can lead to unbuildable designs.
Factor
High-Ceremony (Aerospace, Med-Tech)
Low-Ceremony (SaaS, Gaming)
Tooling
Heavy (IBM DOORS, Jama)
Light (Jira, Notion, Slack)
Language
Legalistic, using “Shall/Must/Will”
Conversational User Stories
Culture
Risk-Averse: Every change needs a board signature.
Speed-Averse: Requirements change weekly based on data.
Communication
Low-Context: Everything must be written down explicitly.
High-Context: Shared understanding via “Stand-ups” is enough.
🛠️ The “Universal” Quality Checklist
1. The Language Test (Precision)
No “Weak” Words: Have you scrubbed the text of fast, efficient, user-friendly, robust, flexible, several, or approximately?
Single Intent: Does the requirement contain only one “shall” or one “action”? (If it says “The system shall do X and Y,” split it into two).
Active Voice: Is it clear who or what is performing the action? (e.g., “The System shall…” vs. “It is expected that…“).
2. The Verification Test (Evidence)
Quantifiable: If you gave this to a QA Engineer, could they design a pass/fail test case without asking you a follow-up question?
Observable: Is the result something that can actually be seen, logged, or measured?
Boundary Conditions: Does it specify what happens at the limits? (e.g., “The field accepts 1–10 characters” instead of “The field accepts short text”).
3. The Context Test (Value)
The “Why” (Rationale): If a developer asks “Why are we doing this?”, is the answer already in the document? (This prevents “feature creep”).
Traceability: Is it linked to a higher-level business goal or a specific user pain point?
Feasibility: Do you actually have the tech stack or budget to build this? (Don’t require “Real-time AI video upscaling” on a $50/mo server budget).