8 Tips to Capture Better Requirements For Your Software Project

By Chris Wright Aug 23, 2011

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:

The client has a particular angle on a requirement based on their own experiences with the system. These experiences might be representative, or they might not. The requirement might be valid, or it might not.
The client communicates the requirement as best they can to our consultant. They might be good at this, or they might need some coaching from the consultant. Let’s say they get 80% of their version of the requirement over to the consultant.
Our consultant listens, understands the problem as best they can, and naturally puts their own interpretation on what they have heard. We are now quite possibly down to 70% of the original (possibly itself biased) requirement.
Our 70% requirement is documented. I think most of us will agree note taking is an art in itself, so our requirement is watered down further to 60% of its former self. Maybe our notes aren’t clear, don’t make sense after the meeting, or are just wrong.

So now when our consultant sits down with the development team to discuss the problem, we understand that in fact they are discussing a 60% watered down version of the original problem. Depending on who they spoke to originally, this problem might not be all that accurate either. This is the inherent danger in requirements gathering. This is not to say requirements gathering is a pointless exercise, but it must be approached carefully.

8 Tips to Capture Better Requirements

So how do we mitigate against these factors, if they are oh so inevitable in requirements gathering? Good question. Try the following tips. They won’t magically solve the problem, but they will all help you keep the percentage of the original requirement you record as high as possible: