Knowing Your RequirementsPosted by Chris Garrett / December 4, 2008
Gathering requirements to build a new web site or application can seem tedious and confusing. It can also feel like it’s delaying the launch of the project, however, it’s THE most important stage.
Yeah sure, development is important – without development there is no end product. But what happens if the end product is not what you wanted at all?
What’s the point of the process?
Requirements gathering prevents misinterpretation, it prevents the Dr Seuss game of he said she said – they said we said. It allows the developers to design and engineer a product that is going to work for you, now and into the future.
The person gathering the requirements should not be a sales person, they should not try to ‘up sell’. They should ideally be coming from a technical background and know what can and can’t be done within your budget. They will work with you to make sure what you are asking for is what you are going to get.
Let’s put this into context by using an example we all understand.
First, let’s create a project.
Requirements: draw a house
Simple right? I conducted an experiment and asked the guys to draw me a picture of a house. This is what I received:-
By just saying “I want a house”, not setting boundaries or specifying exactly what I wanted, I opened myself up to a multitude of interpretations. The same goes for a website or application. Often what we say is not what we mean. It’s extremely easy to misinterpret requirements or even miss entire sections.
Be careful about how you explain something, give examples of what you want. Draw pictures if you have to and make sure the person who is gathering your requirements understands exactly what you want.
As a result of requirements gathering you should be provided with a requirements specification that will require sign-off before the project is handed to the developers. The specification is a document that outlines in full detail every functional item pertaining to your proposed application – whether it simply be a contact form that sends an email or a complete work-flow process, if it has a function it should be in the spec.
A requirements specification should be written for you, not for a developer. (Some companies have a separate technical specification for this purpose). It should include detailed descriptions of all functions within your proposed application and should show diagrams or wire-frames of how it works from a functional perspective.
And, it’s not just for the big projects, sometimes the smaller projects need them the most!
Seeing through the fog
A lot of questions are raised during the process of requirements gathering . Often things are brought up that you may not have even thought about. Resist the temptation at this stage to add new features when you start to see the possibilities. Remember, extra features usually mean extra cost.
Having said that, it is also a good time to start thinking about a possible ‘Phase Two’. Make a note of features you would like added in the future if they won’t fit in the current scope.
But I am allowed to change my mind
Changing functionality after your project is complete could turn out to be very costly. What may seem like a small change to you may change the entire design and structure.
Let’s look at the house analogy again, if you build a house and realise you want a window on a different wall once it is already built, it will require knocking down part of the wall to fit it in and filling in the hole where it was previously. Sure, it can be done, but it will take time and cost money – this is the same with web development. Better to get it right to begin with.
You know your business better than we do
It’s your web developer’s job to find the best solution and user experience for your application, however they don’t know your business as well as you do. Make sure you take the time to read through your requirements specification and understand what it is you are reading. If you’re not sure, just ask. At the end of the day it is your product and if you don’t understand what is being built, you’d be crazy to sign off.
Know what you want
- Be clear about what you want
- Don’t add extra features
- Focus on the core solution
- Read and fully understand the requirements specification – if you don’t understand, ask.
*Special thanks goes to CJ, Dallas, Michael, Dan and Chris for the lovely house drawings