BANTER Business Analysts on Business Analysis

24/05/2020

Top 10 ambiguous phrases to avoid when writing business requirements - or your project will fail

 

Everyone recognises the importance of good requirement writing.

Good requirements must be Specific; they must say exactly what is needed by the business.  Requirements must be written in such a way as to be clear and unambiguous to all readers.  Explicit requirements require fewer review cycles to achieve approval.

 

All of the phrases below are vague and open to interpretation.  It’s easy for such phrases to creep in when defining requirements but they are risky and will inevitably lead to confusion, wasted effort and rework.

 

1) “Acceptable”,” Adequate”

Define the acceptance criteria.

 

2) “Better”, “Faster”

Quantify how much better or faster constitutes a satisfactory improvement.

 

3) “Etc.”, “Such as” or “So on”

Be explicit about what happens next.

 

4) “Flexible”.

Explain the actual variables.

 

5) “Ideally” or “Normally”.

Define expected outcomes when under non-ideal or abnormal conditions. 

 

6) “Maximise”, “Minimise” or “Optimise”

Declare the maximum and minimum acceptable values.

 

7) “Reasonable”, “When necessary”, “Where appropriate”

Explain how to make this judgement.

 

8) “Robust” or “Easy to use”

Describe the expected operating conditions.

 

9) “Some”, “Several” or “Many”

State how many, or provide the minimum and maximum limits.

 

10) “Sufficient”

Specify how much of something equals’ the right amount.

 

Such ambiguous phrases should signal that requirements are incomplete and need further clarification with the stakeholders.  A requirement that only states what will happen under normal circumstances is ambiguous e.g. normally Marital Status must be Single, Married or Divorced.  You need to go a step further and define what will happen under abnormal circumstances for example, will there be an error produced if any other status is entered?

 

An effective check for ambiguous phrases is to consider your requirements from the perspective of a Tester.  If you can’t envision a test that would determine whether or not a requirement has been met, you need to be more specific.

 

Ambiguous phrases must be corrected at the earliest point in the solution delivery lifecycle (defect avoidance costs much less to resolve than defects identified in subsequent phases of the solution delivery lifecycle).

 

Source Acknowledgement

Please note that this list is a concise adaptation of wording from the list of ambiguous terms from the book: Software Requirements (Developer Best Practices) 3rd Edition.  Authored by Karl Wiegers and Joy Beatty.

You can find the book here

 

 

Why not try our online course - BA Simplified?

BA Simplified is the perfect place to start your BA journey. Our easy-to-follow online course lets you learn Business Analysis, through a full project lifecycle, at a pace that suits you. You get access to 9 info packed modules, knowledge tests, downloadable content and a final completion certificate.

 

Try module 1 FREE today

 

Tags:

Try our online course BA Simplified today - FOR FREE

BA Simplified is an easy-to-follow online course lets you learn Business Analysis, through a full project lifecycle, at a pace that suits you. ACCESS YOUR FREE DEMO HERE and test drive module 1 free. No card required for demo set-up.
Be Positive logo
Contact us now to discuss how we can help Enhance your Business Analysis capability.
Easter Dalry House, 3 Distillery Lane, Haymarket, Edinburgh, EH11 2BD
Google + | Site Map | LinkedIn | Twitter | Privacy Policy | Terms & conditions
© Be Positive 2020