Sometimes in business the managers want to introduce a new computing
system so that they can radically change working practises - the program
becomes the means to fulfill a non-computing end. The "success" of the
system will depend on the quality of staff training and the nature of
input the staff had into the design process.
In the academic world
the true purpose of the program is usually clearer, but even so, as soon
as the program needs to be used by someone other than the programmer,
misunderstandings can arise.
- Requirements Document - should be used as part of the contract. Extracting
requirements from users might not be an easy task but if you don't do
it, you can guarantee (and deserve to get!) massive requirements creep
and completely unrealistic estimates of timescale and cost. Performance does
matter (some recent projects have produced sluggish results) but isn't
always easy to specify.
- Prototypes - Useful for extracting requirements. What should you do with them once development begins? It
may be best to throw them away (or at least say you have), otherwise you may
have to keep updating it in step with the real product's changed specification
to attract new customers
Updated 10/10/06 with help from James Matheson