Every word matters when writing requirements. Something as simple as adding an adverb or using “should” instead of “must” can create ambiguity that confuses engineers and sets a project back.
Better requirements lead to clearer, more effective communication between stakeholders. This drives the entire organization toward greater transparency, less rework, and, accelerated development… without sacrificing quality. While writing requirements is both an art and a science that will vary by context, there are a few best practices to consider.
Follow these top dos and don’ts for writing requirements and you’ll find yourself with both clear and traceable requirements across the product development lifecycle.
1. DO: Use a Requirements Template
A template gives consistent structure to requirements. It can be in a user story or systems engineering format, either of which provides uniform construction to support easier testing.
2. DON’T: Use Adverbs
“Quickly,” “easily,” and other adverbs don’t provide clear guidance to testers. Instead, focus on acceptance criteria that are testable and measurable.
RELATED POST: Requirements Management – Living NOT Static
3. DO: Standardize Your Language
The English language contains numerous words with similar meanings in everyday usage. Settle on a few to represent agreed-upon meanings, like “shall” for binding high-priority requirements.
4. DON’T: Be Ambiguous
Requirements are often ambiguous because they’re too general, e.g., “the device shall be easy to use.” Get more specific, whether that means setting a clear benchmark or naming a specific color
5. DO: Use Active Voice and Specific Adjectives
Use active voice verbs. For instance, “the car shall withstand…” is clearer than “the car shall be enhanced to withstand…” Also select specific adjectives instead of standbys like “user-friendly” and “compatible.”
RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships
6. DON’T: Mix Design Specifications into Requirements
When possible, aim to remove design from requirements, as the latter describe a need while the former constitute a response to that need. Design-free requirements give engineers more freedom.
7. DO: Regularly Review Requirements with Stakeholders
Reviewing your requirements with others is a reliable way to ensure shared understanding. Collaborating within a real-time platform lets teams exchange feedback, ensure testability, and minimize rework.
8. DON’T: Rely on Negative Requirements Statements
Negative statements can introduce ambiguity, since there are virtually infinite things that any system will “not do” en route to fulfilling its positive requirements. Check negative statements
