I've been in many development environments where you're expected to extract the business requirements at the start of the project then deliver a working system at the end of the project. Then when you deliver the system, the users argue that it's not what they asked for. There are two approaches to avoiding this problem. The first one (which doesn't work very well) is to make sure that everything is specified in writing at the start of the project. That way, when you deliver the final system you can say that it was implemented based on the written spec that everyone agreed on. The better way is to constantly deliver prototypes of the system as it's being developed and request feedback. So long as you make sure you are converging toward a solution, this approach tends to work much better. Rapid feedback is more reliable at creating the systems that the users actually need than the traditional approach of specifying it up front.
Download