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.

A Typical Requirements Gathering Process

Our consultant is going to talk to a client about a new Intranet. The client already has an Intranet, but wants a new one. It works well in the main, but the technology is old and the client would like some new features. Over the course of several days our consultant quizzes the client about all areas of the system. He is a good consultant, so he does the following:

  • Structures the meeting into particular topic areas (review of old system, interview with users, potential new features etc.) and works through them with the appropriate people.
  • Takes notes from all his meetings.
  • Spends some time himself working through the system, forming his own impressions.
  • Writes up a report at the end of the requirements phase, with his recommendations.

Our consultant reports back to his project team that he understands the problem, works with a developer to devise a solution, and sits back with a rosy feeling as the solution is built. What he has forgotten is his requirements gathering is flawed, and his results are not very good (do you see a recurring theme yet?). However, it is not his fault; he did a good job, or at worst, an average one. You see, it is just the nature of the beast. Here is why:

The Process is Flawed

Our consultant sat in lots of meetings, being told what was wrong with the old system. Different stakeholders showed him various problems. Some discussed what they would like to see instead. Some even drew pictures. Our consultant listened, processed and made notes. Let’s breakdown these activities:

  • Client thinks about a requirement
  • Client communicates a requirement
  • Consultant hears requirement
  • Consultant documents requirement

But let us look again: