The learner can find ambiguous and unverifiable wording ('fast', 'user-friendly', 'etc.') in a requirement and rewrite it into a precise, testable statement.
Red flags and how to fix them
Ambiguity red flags — and how to turn them into testable requirements
Certain words and phrases are warning signs that a requirement is vague and untestable. Learning to spot them is one of the most practical skills a business analyst can have.
The most common red flags are: vague adjectives ('fast', 'easy', 'user-friendly', 'reliable', 'modern', 'secure'); unmeasured comparatives ('faster than before', 'better performance'); open-ended lists ('and etc.', 'such as…', 'including but not limited to'); and undefined scope words ('the system should handle large volumes', 'as needed', 'appropriate response time'). A quieter defect is the hidden assumption: 'The system shall save the data' — which data, where, and when?
Each of these can be fixed by adding a measurable threshold or a concrete condition. 'Fast' → 'within 2 seconds for 95% of requests under a load of 500 concurrent users.' 'User-friendly' → 'A new user with no training shall be able to complete checkout in under 4 minutes.' 'Etc.' → list every item explicitly, or define an objective criterion for inclusion. 'Handles large volumes' → 'The system shall support up to 10,000 simultaneous active sessions without degradation.'
The test is simple: after rewriting, ask yourself — can I write a test case right now that will give a definitive pass or fail? If yes, the requirement is verifiable. If you still need to ask someone 'what exactly do you mean?', it is still ambiguous. Good requirements remove that question entirely.
Red flags and their testable rewrites
If you can't write a pass/fail test, it's still a red flag.
| Red flag | Why it fails | Testable rewrite |
|---|---|---|
| fast | no threshold | within 2 s for 95% of requests |
| user-friendly | subjective | new user completes checkout in under 4 min |
| etc. | open-ended list | list every item or a rule for inclusion |
| better than before | no baseline | from 4 min today to under 30 s |
| support | which action? | accept uploads / display / export |
Lesson notes
Ambiguity red flags — and how to turn them into testable requirements
Certain words and phrases are warning signs that a requirement is vague and untestable. Learning to spot them is one of the most practical skills a business analyst can have.
The most common red flags are: vague adjectives ('fast', 'easy', 'user-friendly', 'reliable', 'modern', 'secure'); unmeasured comparatives ('faster than before', 'better performance'); open-ended lists ('and etc.', 'such as…', 'including but not limited to'); and undefined scope words ('the system should handle large volumes', 'as needed', 'appropriate response time'). A quieter defect is the hidden assumption: 'The system shall save the data' — which data, where, and when?
Each of these can be fixed by adding a measurable threshold or a concrete condition. 'Fast' → 'within 2 seconds for 95% of requests under a load of 500 concurrent users.' 'User-friendly' → 'A new user with no training shall be able to complete checkout in under 4 minutes.' 'Etc.' → list every item explicitly, or define an objective criterion for inclusion. 'Handles large volumes' → 'The system shall support up to 10,000 simultaneous active sessions without degradation.'
The test is simple: after rewriting, ask yourself — can I write a test case right now that will give a definitive pass or fail? If yes, the requirement is verifiable. If you still need to ask someone 'what exactly do you mean?', it is still ambiguous. Good requirements remove that question entirely.