Requirements gathering, the act of trying to understand a problem by talking to a selection of actual and potential users, is common place in nearly all good IT projects. Traditional waterfall projects require that a problem is fully understood, and documented, before beginning to build the solution. Agile projects stipulate that only a “broad brush” understanding of the problem is required to start work, with the gaps in knowledge being filled in as the project progresses. But generally speaking, any type of project, large or small, agile or waterfall, will have some form of requirements gathering component to it.
And that is a problem. You see, all requirements gathering activities are flawed. The end result of any requirements gathering phase is just not very good. Don’t believe me? Let me take you through a typical scenario.