Business Analysis Coaching

“Deficient requirements are the single biggest cause of software project failure.”

(Hofmann and Lehner, 2001)

We’ve probably all been on a project where the requirements have been deficient or where the business has articulated a solution instead of a need. As an example, a requirement that I’ve often heard articulated on projects in the past has been; “The solution must be delivered via the Intranet”. This appears to the business to be a very clear requirement and, if left unchecked, it’s what the development team will eventually deliver.

However, is it what the business actually needs? Why did they request a web site? Did they want to avoid the need to install software on client machines or was it to reduce the processing that has to be done on the end user’s laptops. If so the project will either fail or become much more expensive if all the computers in an organisation need to have the flash player installed for the Intranet site to run or if all the processing is done on the client machine to reduce the stress on the web server.

Projects with requirements that are clearly deficient, such as the one above, are doomed to failure as Hofmann and Lehner stated, so it’s important that the person gathering the requirements, the Business Analyst, ensures that they are accurate and clearly articulate a business need. The following five tips cover areas where requirements usually fail and offer advice on how you might improve your requirements:

1. Improve the Clarity of your Requirements

Defining requirements is a tricky business. In my experience the business owner will either not read them or go through them word by word looking for ambiguous requirements, hoping that they will give them a get-out clause or room to negotiate change at a later stage of the project. Continue reading ’5 Ways to Improve your Requirements by Patrick Bowe’