The requirements say the system must be user friendly. How can we test that?
Untestable requirementTranslate vague quality language into observable tasks and acceptance conditions. Agree the user groups, context, and evidence that will demonstrate acceptable usability.
What to do now
- Identify the intended users and tasks
- Describe observable success conditions
- Test a prototype with representative users
- Record agreed acceptance measures
When to escalate
Escalate when
Stakeholders refuse to define what acceptable performance means.
Who decides
The scope owner and authorized sponsor
Example
A usability requirement becomes successful completion of a defined request workflow without facilitator assistance.
Mistake to avoid
Accepting a subjective adjective as a complete requirement.
Prevent a repeat
Review ambiguous requirements and unresolved acceptance conditions before the affected work begins.
Suggested ApprovedFlow setup
- Projects
- Tasks
- Documents
- Approvals
Keep the agreed scope and acceptance evidence with the project; record any proposed change and its decision separately. See the platform
Related cases
- A requirement changed after testing began. How do we handle it?Late requirement change
- How do we prove every requirement was delivered and tested?Missing requirements traceability
- An acceptance test fails because the requirement was wrong. What should happen?Requirement validation failure
- Our acceptance criteria change after delivery. What should we do?Moving acceptance boundary