Chapter 16. Eliciting Requirements

Almost everyone involved in software engineering or software project management during the last 20 years is well aware of the importance of requirements. We rarely hear of a success story declaring victory over the ever-elusive set of specs, but we often hear poor requirements cited as public enemy number one. As developers and managers, we're cautioned about the exorbitant cost to the project of a missed or incorrect requirement—the most expensive error to correct and the most damaging to customer relations. We're advised of the meaninglessness of a fuzzy requirement, and we're counseled about tester angst over an imprecise one. If we are far enough off the mark with requirements, we may be building a completely different system than the one actually desired; we may slip the bounds of the contractual agreement. Even when starting out on the right foot, requirements volatility can wreak havoc on the best-laid plans. Our goal is to understand the problem we have pledged to solve, even though we have multiple customers, often with conflicting needs. Each stakeholder has his own view of what is needed and wanted, each has a “filter” of the world, and each has individual learning and communication styles. If we fail to listen and communicate effectively, the “right” requirements will be discovered too late, if ever. Methods exist to aid requirements elicitation, albeit none is an exact science. Given that requirements form the foundation for the software product, it's well worth our time to adopt as many approaches as possible to triumph over this most challenging, yet crucial, step in the development process.