Weasel words are vague or noncommittal words, such as could, should, may, might or ideally, that make a statement sound definite while leaving its meaning open. In requirements, specifications and user stories they are a common source of ambiguity, because different people read them in different ways.
Why it matters: Ambiguous requirements are one of the easiest places for bugs to start. If a specification says a field "should" be validated or a page "may" load quickly, developers, testers and stakeholders can each assume something different, and the mismatch only shows up once the software is built.
In practice: Testers read requirements, acceptance criteria and design documents looking for words that hedge or soften commitments. When they find one, they ask what it means in concrete terms: is this mandatory or optional, under what conditions, and how will we know it has been met? The answers are written back into the requirement, often as measurable acceptance criteria. Similar warning signs include fudge such as "this will be resolved later" with no owner or date, and oversimplified terms like "performant" or "user friendly".
Examples:
- A story says the system "should send a confirmation email", and the tester asks whether a failed email must block the order or not.
- A requirement says results "may be cached", prompting a conversation about when stale data is acceptable.
- A specification says the page "could support" mobile, and the team agrees which devices and screen sizes are actually in scope.
Common pitfalls:
- Accepting soft wording in early drafts and never coming back to clarify it before development starts.
- Replacing a weasel word with another vague term, such as changing "should be fast" to "must be fast", without defining what fast means.
Why are words like should and may a problem in requirements? They leave it unclear whether something is mandatory, optional or conditional, so people build and test against different expectations.
How do you fix weasel words in a user story? Ask what the word means in practice, then rewrite it as a specific, testable statement or acceptance criterion that everyone agrees on.
