Requirements that are vague are open to interpretation by stakeholders. It’s easy for such phrases to creep in when defining requirements but they are risky and will inevitably lead to confusion, wasted effort and rework. For Example:
“Flexible”. The business’s definition of flexible and the developer’s definition of flexible might not be compatible so be SPECIFIC about the actual variables. Requirements must say exactly what is needed by the business. Specific requirements must be clear, simple, consistent and at an appropriate level of detail.
“Some”, “Several” or “Many”. State a specific value, or provide the minimum and maximum limits, this will help to clarify exactly what you want in terms that everyone can understand. Requirements must be MEASURABLE, it must be possible once the system has been developed, to verify that the requirement has been met.
“Better”, “Faster”. In the context of your requirements, quantify how much better or faster constitutes a satisfactory improvement, this will help you ensure the requirement can be ACHIEVABLE within the constraints of the project and existing systems. If you can, sound out your requirements with a developer to ensure feasibility.
“Etc.”, “Such as” or “So on”. Be explicit about what happens next. Don’t let people guess the next steps as this could lead to various incorrect outcomes for your requirements. Requirements must always stay RELEVANT, you must be able to connect a requirement back to the overall business objective.
“Acceptable”,” Adequate”. Define the acceptance criteria, ensure that there is a statement or statements that can be used to determine a pass or fail result for each requirement. In other words it must be possible to design a TEST or come up with a means to determine if a solution has met the requirement.
Such ambiguous phrases should signal that requirements are incomplete and need further clarification with the stakeholders.
At Be Positive we use the SMART (Specific, Measurable, Achievable, Relevant and Testable) acronym to help avoid some of these troublesome phrases.
If you stick to writing SMART requirements you should find that you avoid ambiguous phrases naturally. But just to be safe, an effective check for ambiguous phrases is to consider your requirements from the perspective of a Tester. If you can’t envision a test that would determine whether or not a requirement has been met, you need to be more specific.
Ambiguous phrases must be corrected at the earliest point in the solution delivery lifecycle (defect avoidance costs much less to resolve than defects identified in subsequent phases of the solution delivery lifecycle).