Dr. Dobb's Digest May 2009
When developers deliver software that turns out to be something other than what the client expected, it's usually because of a communication -- not a technical -- problem. These are exactly the kinds of problems that comprehensive requirements documents are supposed to prevent. But requirements documents aren't without problems. They're time consuming and expensive to produce, are apt to be misinterpreted, can become irrelevant as requirements change (as they usually do), and ultimately are only as good as the questions that are asked.
For instance, the traditional "big requirements up front," or BRUF, approach usually has a business analyst on the team who elicits the elements that are required from the stakeholders, passing them on to the development team via the requirements document. This scenario usually is justified by the assumption that developers have poor communication skills. But that's clearly not the case. Enter agile development.
Instead of collecting, collating, and casting in concrete everyone's 2 cents worth before launching development, agile developers take a more flexible approach. They work one-on-one with stakeholders who make decisions, provide information, and prioritize requirements throughout the process.
Requirements are developed, but in bite-sized fashion. In other words, the developer does almost everything the business analyst does, except generate a detailed requirements document. This includes answering fundamental questions ranging from "How much will this cost?" to "How long will this take?" These are concerns that require an understanding of the task at hand, but not a stack of three-ring binders. Instead, scrawled notes and hand-drawn illustrations do just fine.
The end result is a much leaner, more focused requirements specification that includes only the features that stakeholders expect and developers can deliver. And when it's all said and done, that's what counts.