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.