I don’t normally have much time to write articles – however the intention of this article is to reduce the time I am spending at the start of the project when trying to understand what a client wants. There are different techniques that can be used for gathering requirements for projects but here’s how I prefer to do it:
- The first step is to list everything that you want. Do you want a search facility? Twitter integration? Contact form? If there are multiple decision makers then get everybody’s opinions. Once you have that list together you’re ready for step two.
- Step two is to prioritise your requirements from number 1 all the way down to the last and most insignificant one.
- Next, you need to decide which of the requirements are essential in order for the project to succeed. For example, if you want an online shop then having a checkout and payment is a must, however automatically reducing stock levels is something that might be useful, but not essential. Put a ring around these essential requirements and make them stand out so whoever is working on your site knows what they have to do first and foremost.
- The last stage is to apply MoSCoW rules to your requirements. Next to each requirement put an M, S, C or W:
- The items that you have previously highlighted are MUSTs and the system wouldn’t work without. (M)
- Next you’ll have items that SHOULD be in the project – they are not essential but they are heavily desired. (S)
- The next bracket are the COULDs. These could be items that have been suggested could be good for the project – in the context for a shop, maybe a currency convertor might be useful, but if it doesn’t make it in then the rest of the site is going to function just fine. (C)
- The last set of features are the ones that WOULD be included in the future, such as in phase 2 of a project. These features could be dependent on budget or the success of the first part of the project. It’s important to highlight these as it encourages you to think about the direction of your project and how it can be added to and improved in the medium-long term. (W)
Once you have your prioritised list then they are ready to be priced up. If the price is too high, consider moving items down the list from SHOULD to COULD, or COULD to WOULD.
Having this list also creates discussion. For example – something you think is a MUST, might not be as essential as you thought – therefore you could move it down the list, save time and therefore save money.
When the list is complete you can then use it to check against when the project is delivered. It’s written down in black and white and if a requirement doesn’t exist then you have the right to go back and ask for it. Alternatively, if something wasn’t captured in the first place then you should expect to pay an additional cost for it – however by carrying out the process above there’s less chance of you missing requirements.
One last comment to make is that this list is intended to outline WHAT needs to be done and not necessarily HOW – that is a different discussion altogether. However if you know the WHAT then the experts should be able to figure out the HOW for you.
Posted on March 20, 2012 in Web Development
