When a good requirement is not as good as you thought

Wrtitten by Ciset Gestor
17 January 2014

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:

  1. By using an ontology describing the accurate meaning of the most common concepts in your project
  2. By avoiding adjectives such as good, best…: remember how difficult could be to agree on what *good* means
  3. Avoid quantifiers such as some, nearly…
  4. Avoid adverbs such us usually, typically…
  5. Avoid using pronouns: as we saw in our last entry of the blog

Use an agreed upon grammar:

  1. Patterns and boilerplates are a good solution for that and will reduce the chances for long and ambiguous requirements

All the items described above can be analyzed with Requirements Authoring Tool and Requirements Quality Analyzer.

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

Leave your comments

Post comment as a guest

terms and conditions.