Requirements are the expression of the needs and desires of all the stakeholders in a software development project. They include everything from an application's basic functions to esoteric capabilities that end-users wish for but may not get. Remember, software development too follows the WYSIWYG rule (What You Say Is What You Get). The clearer and more detailed our requirements, the closer will be the final product to your expectations. Dean Leffingwell of Rational Software estimates that between 40 percent and 60 percent of software defects and failures can be attributed to bad requirements.

Mind boggling statistics? What it boils down to simply this. The more you know exactly what you want, the greater the chance that you will get it. The time that you spend researching your customers and users, will pay off handsomely when it comes to taking tough decisions during the implementation phase.

Given this logical argument, one would wonder why would anyone give unclear requirements in the first place. Bad requirements can come due to many factors such as;

Incomplete understanding of the business model: Probably the most common reason why requirements tend to be vague is because customers do not put in adequate time and thought into how the business will work. One good way to avoid this mistake is to prepare a business plan and run it through your banker or a venture capitalist. Even if you are not looking for VC funding, the feedback you get from them will prove invaluable when it comes to knowing whether you have put in enough thought into the project to maximize the chances of success.

Wrong understanding of your requirements by the developer: This happens more often than we would like to believe. While large companies hire IT consultants who help to bridge the gap between what the client wants and how the developer understands it, smaller customers need to ensure that they work closely with the developer to bridge this divide. In our experience, it is often wiser to pay the developer a separate fee to do the requirements capture phase in a comprehensive manner, so that neither the customer nor the developer ends up with a wrong understanding of what the application (or website) is expected to do. Paying the developer for this consultancy ensures that the developer puts in the adequate time and effort to bring out something that both you (the client) and the developer can clearly understand.

Understand that not all requirements are created equal: Often, during the Requirements capture phase, the client and the developer come out with innovative, extravagant and even esoteric features and solutions. However, there needs to be a stage (before the development gets under way) where a reality check is conducted on the features. Some may be too expensive to build or may take too long, in which case you may need to consider dropping (or at the very least, postponing) the development of these features until the application goes live and returns sufficient value to you. A good exercise to do here would be to prioritize features based on its importance, cost and complexity. At the end of the day, it is better to have 5 features working well, rather than start up on 15 and see the development budget blow up to unreasonable levels.

Consider management overhead: Probably the most hidden area of cost and source of value is the administrator section of the application (or website). Normally, the admin section of any web application will never be available to the user (for obvious security reasons). This means that as a client you will need to clearly specify what areas of the site you will need to manage. Do you need to add, edit or delete registered users? If you have an ecommerce application, what level of control do you require over user data? Normally, such “back-end” functions on the website contribute to more than 50% of the total cost of the website.

If you are interested in learning more about our services and what we do, please check out the Services and Portfolio sections. Would you like to see if we identify your needs well? Click here to find out more.

Not surprisingly, all successful applications development efforts invariably show both the client and the developer working closely together throughout the life of the project. Such close involvement ensures that nothing is left to chance and no unnecessary assumptions are taken leading to confusion, frustration, and eventual project failure.