Looking into the "too-hard-basket"
Wednesday, September 27, 2006
The requirements phase is often not given the attention it deserves.
Albert Einstein once said "Requirements are the foundation of software"...well, maybe it wasn't Einstein, but it was someone smart.
The outputs of requirements gathering are the blueprint to your site - critical documents! They are used for quoting, planning, designing, building and testing your Web application. The requirements will give you artefacts to describe the behaviour of the system (such as wireframes and use cases).
Defects in requirements will have a cascading effect throughout the project. While fixing an error in the requirements phase is often 100 times cheaper than after the software is built.
Statistics show that investing up to 30% of the project budget on requirements documentation significantly improves the chance of a project successfully meeting budgets. Make sure you invest the time and effort in a detailed requirements phase - this will reduce the risks and give you peace of mind.
The requirements phase aims to define and document the scope of the system so it can be quoted and developed based on that scope. However, some projects just aren't suited to fixed scope. You might want a more flexible system, perhaps your business is changing, or your market is rapidly changing. This is where agile development comes in.
The concept of the agile approach is to break the system into smaller projects which are delivered in iterations with less documentation. Each delivery is quoted based upon the experience of the previous iterations. The risks are reduced by this approach, but it doesn't suit a fixed budget.
It's rare to find project sponsors who don't have a fixed budget. But time and materials work doesn't necessarily mean you need deep pockets. You can put controls around the hours that are spent, and re-evaluate your requirements after each iteration (fortnightly or monthly), thus keeping a tight rein on expenditure.
Matt Watson, Technical Director
Add to Del.icio.us
Digg this
Add to Reddit
Email a friend
Home
Albert Einstein once said "Requirements are the foundation of software"...well, maybe it wasn't Einstein, but it was someone smart.
The outputs of requirements gathering are the blueprint to your site - critical documents! They are used for quoting, planning, designing, building and testing your Web application. The requirements will give you artefacts to describe the behaviour of the system (such as wireframes and use cases).
Defects in requirements will have a cascading effect throughout the project. While fixing an error in the requirements phase is often 100 times cheaper than after the software is built.
Statistics show that investing up to 30% of the project budget on requirements documentation significantly improves the chance of a project successfully meeting budgets. Make sure you invest the time and effort in a detailed requirements phase - this will reduce the risks and give you peace of mind.
The requirements phase aims to define and document the scope of the system so it can be quoted and developed based on that scope. However, some projects just aren't suited to fixed scope. You might want a more flexible system, perhaps your business is changing, or your market is rapidly changing. This is where agile development comes in.
The concept of the agile approach is to break the system into smaller projects which are delivered in iterations with less documentation. Each delivery is quoted based upon the experience of the previous iterations. The risks are reduced by this approach, but it doesn't suit a fixed budget.
It's rare to find project sponsors who don't have a fixed budget. But time and materials work doesn't necessarily mean you need deep pockets. You can put controls around the hours that are spent, and re-evaluate your requirements after each iteration (fortnightly or monthly), thus keeping a tight rein on expenditure.
Matt Watson, Technical Director
Labels: Process and Methodology




0 Comments:
Post a Comment