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?