The Cost of poor software requirments document

In this article I will be discussing shortly and simply the cost of poor software requirements document.

Last article (Simple Tips in Writing Software Requirements),I was giving advices in writing software requirements document or software requirement specification (SRS) and that advice came from my very short experience in the field. I got a request from togive examples of these effects of how costly mistakes comes can be from inaccurate requirement document.

Asoftware requirement is the foundation of a project. It is the blue print of a blue print of a building. It is the base of the architecture of a building. If your blue print is not correct, the building will fallat some point. So to have a successful project, the project managers and owners must make sure the requirement documents are solid. 70% of projects failure comes from poor requirements documents.

Themain factors in estimating the cost is the delivery time, and human resources working on a project. In estimating the project budget, the two main factors are development time and man power. Once your requirements are rock solid, next major thing is, your time and manpower estimate. If you do estimate them wrong, your project will fail. Other estimates are cost of goods such as software, tools, technologies,indirect expenses, overtime and so on.

Butagain, two key factors are the delivery (from start to finish) time duration and the man power. You need to make sure the team you build hasright experience with right tools and technologies and they suite for their roles. You can't hire 10 sales guys to do coding. You also can't hire a water boy to cook. So you need to make sure, your team is experienced in tools and technology you're going to use in your project or have considerations for the training and learning time.

When we have a requirements document with ambiguous meanings in it, each of the stakeholders of the document could understand the meaning by his/her own way (since it holds several meanings), therefore you are giving  the client the right to make changes in the deliverable, and you will not be able to negotiate  with him. Therefore this will cost you more time, and off course you will pay more for the human resources; in addition this could affect any future work with your client. Not to mention that this could affect the human resources by feeling bored and not satisfied with the project, this will lead them not being able to give a good output for the project.

I suggest reading the following articles, they have very rich information about this issue.

http://www.requirementsnetwork.com/system/files/Executive%20Guide%20to%20Evaluating%20Requirements%20Quality.pdf

http://www.compaid.com/caiinternet/ezine/Meli-estimation.pdf

Please feel free to open any discussion.