Link: ArsDigita Systems Journal:
Requirements Gathering for Application Design
A solution delivery team and a client agree to develop a software application. Together they agree on scope, specifications, timeline, and price. The delivery team begins coding against the specifications and at the initial milestone date meets with the client to review functionality. The clientâ�s reaction upon seeing the functionality - “This is not what we were expecting!”
Even with a seemingly well-defined set of functional requirements, web service developers and customers often have different interpretations for how requirements translate into applications. But regardless of why or how these differences surface, the customer expects the development team to be accountable and to meet predefined project timelines and budgets. The outcome is solutions that are delivered late and result in significant incremental costs to the delivery team (e.g. additional development resources are needed, developers are overworked, morale suffers, other projects are neglected). Often the original project timeline is compromised and customers are generally unhappy.
With dot.com type clients, these risks are real but manageable. With larger, more established clients (e.g., Fortune 500), these risks can result in very public and damaging failures. As web service companies continue to grow and extend their customer bases, success will be largely predicated on how quickly and comprehensively they can get to know their customers and understand their needs.