BANTER Business Analysts on Business Analysis


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.
  1. “Better”, “Faster”. Quantify how much better or faster constitutes a satisfactory improvement.
  1. “Etc.”, “Such as” or “So on”. Be explicit about what happens next.
  1. “Flexible”. Explain the actual variables.
  1. “Ideally” or “Normally”. Define expected outcomes when under non-ideal or abnormal conditions. 
  1. “Maximise”, “Minimise” or “Optimise”. Declare the maximum and minimum acceptable values.
  1. “Reasonable”, “When necessary”, “Where appropriate”. Explain how to make this judgement.
  1. “Robust” or “Easy to use”. Describe the expected operating conditions.
  1. “Some”, “Several” or “Many”. State how many, or provide the minimum and maximum limits.
  1. “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).

We're Hiring!

We have Business Analyst Consultant roles available across Central Scotland.

Click here to visit our careers page and apply.




One thought on “Top 10 ambiguous phrases to avoid when writing business requirements - or your project will fail.

  1. AvatarVic Summers

    It’s really good to see that Be Positive are encouraging requirements to be written in a manner that takes account of the testability of the requirement; for too long business requirements have been written with IT being the main customer.

    My experience is that requirement testability and business understanding of the delivery is hugely helped by writing Requirements in the format:-"As a [role] I want [feature] so that [benefit]” and Acceptance Criteria in the format “Given [context], when [event occurs] then [this outcome happens]“

Comments are closed.

Be Positive Newsletter
Worried you might miss one of our posts? Sign up to our newsletter and receive a regular roundup of all posts we published. Be kept up to date with all the latest industry knowledge and training courses.
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