This blog is all about how to write *good* requirements but…. what does *good* mean? I’m sure that the characteristics of a good requirement are different from one company to the other.
It’s exactly the same problem with the meaning itself of your requirements. If your design team could understand your requirements in a way, while the testing team understand anything else, then you’re lost (which of both approaches is closer to what the interviewee stakeholder really meant?).
Addressing ambiguity has different forms:
Avoid ambiguous terms:
- By using an ontology describing the accurate meaning of the most common concepts in your project
- By avoiding adjectives such as good, best…: remember how difficult could be to agree on what *good* means
- Avoid quantifiers such as some, nearly…
- Avoid adverbs such us usually, typically…
- Avoid using pronouns: as we saw in our last entry of the blog
Use an agreed upon grammar:
- Patterns and boilerplates are a good solution for that and will reduce the chances for long and ambiguous requirements
Other techniques to avoid ambiguity in your specifications are:
- - Use a heterogeneous reviewer team: many times different interpretations of a requirement come depending on the point of view of the reader. Reviewing the document with a designer, a tester and end-users coming from different departments could be the best (although expensive) solution
- - Write your tests soon: TDD could be a way of thinking very soon in the tests to our requirement, detecting soon ambiguous requirements