Last article (Simple Tips in Writing Software Requirements), I was given advices in writing software requirements document or software requirement specifications (SRS) and that advice came from my very short experience in the field. I got a request from to give examples of these effects of how costly mistakes comes can be from inaccurate requirement document.
A software requirement is the foundation of a project. It is the blueprint of a building. It is the base of the architecture of a building. If your blueprint is not correct, the building will fall at 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.
The main 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 manpower. 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.
But again, two key factors are the delivery (from start to finish) time duration, and the manpower. You need to make sure the team you build has right experience with right tools and technologies and they suit 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 of 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.
As Mahesh Chand writes in his 10 Tips Why Software Projects Fail, not having clear and detailed requirements is one of the key reasons why software projects fail or take longer than expected delivery time. Longer delivery time increases total cost of development and also leads to unhappy business stakeholders and customers. That could eventually end up shutting down the project. Less than 20% of new software projects go live. Rest 80% died due to various reasons and one of them being the requirements.
Please feel free to open any discussion.
Gowtham RajamanickamPosted Apr 20, 2015, 4:20 AM
great one
javed khanPosted Jan 26, 2011, 3:01 PM
can you please explain it with simple example ?
Mike GoldPosted Jan 26, 2011, 11:58 AM
Unfortunately a software requirements doc for a project is very very often a luxury in the real world. But when you get one, it makes all the difference in the world to the developer. The best part of a well written software doc, is 1) you can check your work against the document as your testing. 2) you can communicate with the client accurately their needs. 3) And for UI developers, you have a great feedback loop and point of reference for matching the work you created against the blueprint the customer signed off on. The best requirement documents for a UI developer have a mocked up screen for each screen in the app and a set of use cases indicating what is suppose to happen after pressing each button or key on that screen. There are different levels of how detailed a requirements doc you may create, but usually I'm perfectly happy getting one (at minimum) that just is roughly a list of numbered sentences that describe what is expected of the application. In this case the customer leaves it up to the UI developer's judgement on how their application can be brought to fruition.
Mahesh ChandPosted Jan 25, 2011, 1:39 PM
Good work Tamer. But I think you should extend it more with more details. Also, having a sample SRS template attached with the article would be nice.
knightsPosted Jan 24, 2011, 10:35 AM
I would add that these are the first ever documents for any project.If foundation is not correct the whole building will not be in shape.There is no other option to fix it besides doing it first time as accurately as possible.