forget your password?

Requirements Gathering: Is it all or nothing?

There are several schools of thought regarding the extent to which requirements should be gathered before software development begins on a web project. What follows are the viewpoints from both ends of the theory spectrum;

The Case for Capturing Everything. When working on a project with a fixed deadline and budget, requirements that are missed cannot be featured on the website. Therefore we need to think of all the requirements that we’ll need, as any that come up later cannot be easily accommodated.

The Case for Capturing Nothing. It’s more important to make progress on software development than to spend time thinking of requirements. Until we test features on real customers we won’t know what they actually want. Therefore time spent second guessing what people actually want is wasted time.

Both arguments are opposed and at the extremities of the debate, both have merit and logic, but both are flawed.

Fixed budget and fixed term projects have their place but website development never ends. It never ends because there is always room for improvement – data driven improvement. Continual innovation, web analytics and user feedback will always drive continual improvement. You want to be ahead or a least keep up with the competition. If you’re planning a fixed project, plan a second, third and forth project too and more after that. Better still, take a more Agile approach. Getting it all right first time is a fantasy that’s best left in woo-woo land.

Starting with absolutely no requirements is a little like answering the riddle “what came first, the chicken or the egg?” by stating that it was the chicken. Now, I’m not smart enough to answer the question but I do know we have to start somewhere. When starting a web project, especially a particularly large project, you’ll need to start with what you want to achieve or what problem do you want to solve. These in turn will create requirements, i.e. what is it actually that you’re going to do?

Taking some time at the beginning to think about everything you need for your web project is good idea. But it doesn’t mean you have to do everything now, in fact, you can’t do everything now. But not taking a broad view and considering requirements from several different perspectives could prove devastating in the medium to long term. For example, I know a startup that didn’t have ‘being responsive’ as an early requirement for their site. Nine months in, they kicked themselves (fairly hard) for the oversight.  

And so the middle ground in the debate is the option to go for but wisdom can be taken from both extreme viewpoints;  

Consider as many perspectives as possible when creating initial requirements. The more diverse the viewpoints, the less likely there will be serious oversights. Get lots of brains in on the process. Once you have the big picture and have the grand vision, then break up the development into small batches based on what is most important and provides the highest value to the business.  

What is your experience of gathering requirements for your web project? Do you gather too many, too few or just like Goldilocks, do you get it just right? Have you ever missed anything that you wished you hadn’t?

You might also like:

Comments (2)

Ian Sharp

August 16, 2014 at 7.10 pm

Some useful insights- thanks Matthew. Requirements usually work best top down, that is to say broad ballpark type estimates to begin with and then more accurate the more you develop the requirements - quite often using prototyping techniques.

Great point about using estimate ranges as they let everyone know there’s a margin of error (aka contingency) built into the estimate.

Matthew Castle

August 15, 2014 at 10.47 pm

Getting a good understanding of the Scope of a project is far more important that an understanding the detailed requirements.

When project planning stop talking about Estimates and start talk about Budgets .

“How long do we estimate the Catalogue Browsing will take to build?” You have no idea, you done know what’s involved yet.
“How long should we budget to work on Catalogue Browsing?” Great, lets get a feel for the relative complexity and importance of this feature!

Start planning a project with around 5 - 10 high level functional areas you can assign a rough budget to,

Use ranges for budgets. 15 - 20 days vs 10 to 30 days tells you something about the relative risk involved.

Put them in priority order, take the first and start breaking it down until you get to detailed requirements.

Don’t worrying about number 9 or 10, you will never end up doing them. Having Add to Basket automatically shine your shoes will turn out to be much more important smile

Leave a comment