3CA

Stopping Ambiguous Requirements »

requirements_accavdar

Quality business requirements should follow the 4 C’s – Clear, Concise, Consistent and Complete.

One of the most important concepts when defining business requirements is making sure the requirement is unambiguous, this will ensure that 2 of the 4 “C” are met – Clear and Complete. Ambiguity in requirements leads to many problems. how can an accurate cost by provided to deliver that requirement, how can the technical staff deliver a solution that meets the requirement, how can testing know whether or not the test case they have created is correct and relevant.

 

Take the requirement below:

“The screen shall capture Customer data” – as a developer/tester or even a stakeholder you know that this requirement is incomplete and ambiguous.

So let’s break it down into its problems.

1) “The Screen” – what screen? If you have done the work to identify that Customer data is required, clearly you know what screen it is required on. Even if it is a new system grouping screens may assist in the design.

2) “Capture” – what is capture? Is a user going to enter this data, will it populated from another source?

3) “Customer data” – again what is Customer data – do I need to include medical data, or just name and date of birth?

As you can see a simple one line requirement can be read and hence delivered incorrectly against the true business requirement.

 

Now think of the current world we live in, and try to deliver projects in. If a developer with little to no understanding of the business gets hold of ambiguous requirements, you could end up with anything. I love overhearing, “That’s not what I meant”, “Or they don’t understand how it works”. If you are working in one of these situations the business requirements need to be detailed and clear enough to overcome this problem.

 

One of the smartest tactics you can use to check off your requirements is provide them to a tester to review. If a tester can’t understand your requirements, how will anyone else? If you leave the ambiguity in your requirements, the punishment will only be felt later on. In the analysis phase the cost of clearing up a requirement is only that of performing more analysis, as the project moves later and later into delivery the cost of ambiguous requirements grows exponentially. Usually it isn’t until the end user sees the outcome that the inevitable “That’s not what I asked for” comment will arise.

 

The audience of the requirements is always important when drafting requirements, think not just of the people you want sign off from, think of the developer and technical team who may need to deliver the solution, think of the test team who will be required to develop test cases and scenarios based on the document and think of yourself – all you are doing is delaying the inevitable. It will still likely be your responsibility later on to create the complete business requirement, and as we are all aware as projects progress through the phases time gets tighter and decisions get worse. If you draft clear and complete requirements the argument about quality and time should not come into play.

 

Below are a list of the 5 words and phrases that should be avoided (whilst there are many more, this is a good start to set you on the path for delivering high quality requirements)

“Sometimes” – In what scenario will this sometimes happen? In what scenario would this sometimes not happen?

“All” – All is just a BA being lazy – if you have done your analysis properly “All” should be more descriptive. It’s funny how many times “all” is not actually correct.

“Optimise” – Project Buzz word – just like “Enhance” and “Improve” – requirements using these terms are difficult to quantify. What is an improvement? This improvement can be quantified in the performance section in the Non-Functional Requirements.

“Daily” – Does this include Saturday and Sunday – what about holidays?

“The field” – what field? The field has a name or at least its function should be quantifiable. Is it a field that the user enters the Customer’s date of birth?

 

To counteract this we designed a simple MS Word macro that looks through the requirements looking for these type of words. It’s not perfect but it does give a good indication on how clear and concise your requirements are.

Removing ambiguity may mean your analysis phase takes a little longer, it may mean that your requirements documents are longer but the project as a whole will receive the benefits of quality and the time spent in analysis will be paid back in development and the future phases.

 
 
 
© Copyright 2017 3CA PTY LTD

Sign Up to our email newsletter!

I agree...
Sign Up Now
Close