Case for and against "freezing software requirements"
Im looking for some advice and pointers for a report which i have to write. Basically i need programmers opinions on why or why not should requirements be frozen during a programming project.
I need to know if your for or against it and why you feel that way. Just as many points as you can make for your case.
Have you ever been in a position where you wish they had been frozen or do you think a plan needs to evolve as the project evolves?
Thanks in advance.
yes they should and it's very simple why.
just try to imagine you build a house and when ur half way up, they tell you that they want 30% less space and twice deeper fondation.
you don't need arguments for that. just common sense ;)
If the project evolves then the deadline needs to shift and the cost needs to be renegotiated upwards. After a few changes what was going to be finished this year for a few thousand will be decades long and cost billions.
Better is to record the proposed changes during the project, complete the original project and then start a new project to implement changes. That allows each enhancement to be separately prioritised and priced and gets something working soonest.
Living in the real world, changes are probably going to happen to requirements unless there's a very short build time.
How you handle them depends on your build methodology.
If you're running a standard waterfall, then you need to freeze requirements at some point to start building, and then manage any changes via change control. In the 'house' example, if the house is half built and needs to moved 10m to the left, then the impact and costs are high, but the impact of changing the roof tiles is small. That's why you'd do an impact assessment as part of your change control. It may be that changes remove requirements (not frequent, in my experience) or change them so significantly that you need to stop building as the resultant product no longer has a value to the business.
If you're adopting some form agile approach, then requirements can be more fluid, and are fed into each iteration the build team works. You might, therefore, decide to leave articulating some (possibly lower priority) requirements until after the build team have started on the high priority requirements.
Some projects lend themselves better to one methodology. Web projects tend to work quite well with agile methodologies, I think. Big infrastructure projects don't.
I think the real question is not so much whether you freeze requirements, as how you work.
I hope this isn't homework....
Cheers for the help folks thats an amazing help.
Part of the exercise is to go out and actually ask people. Im just beginning a software development course so its pretty much impossible to give an experienced answer without outside input. I assumed that people would be against it but i was also looking for cases in favour as the report has to be 50/50.
If anyone has anything to add to this feel free as its all appreciated.
|All times are GMT +1. The time now is 12:46 PM.|
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.