How to Do an Efficient Requirements Gathering for an Internet Website Project?

Posted in: Blog, Methodologies, Project Delivery | Jan 10, 2013 at 1:50 PM

No comments

Inviting client to a cafe for a cup of coffee is one thing but to have an efficient meeting and discuss about the website requirements is another thing.

On this opportunity I want to share with you my experience during requirements gathering time and how to make it efficient.

One rule that will not change: Client never knows what they want! Therefore – if we don’t guide them – don’t expect them to explain to us what they actually have in mind. Well, not all clients are the same but most of them are!

Especially with designing and developing a website, some of the clients I know don’t even have any knowledge on what it’s all about. Yes they’re expert in what they’re doing (ie. their business) but they normally have no idea what website is all about and what it takes to build one. What they know is: they need a website and that’s about it.

It’s our job as a professional web site designer and developer to guide them with this process.

What Do You Need?

Before coming to any meeting, it’s always good to prepare what you want to talk about. I always prepare a checklist for this. The checklist doesn’t have to complicated but at least it captures the basics of website development. For example:

– Domain name to use

– Colour theme and logo

– Basic pricing for domain and space hosting

– Website layouts discussion

– Site structure discussion

– Functionalities discussion

The Bottom Line

The bottom line is always that big question, “So how much will that cost me?”. Client always wants to know pricing up-front. Always tell them, “It all depends on the functionalities.”. Never say anything about price up-front because client remembers! And we’ll be cornered later on if we’ve quoted them a price and we actually need more money.

It’s OK to let them know of static pricing such as domain and hosting price, SSL price, etc.

The Requirements

Just like searching in Google, we have to know what questions to ask to get the right answer. You can pretty much type in what you like in Google but it doesn’t mean that the results you get are the ones you want. When gathering requirements, make sure that you ask the right questions.

So, what are the right questions then?

Always start with this question “What’s the purpose of the web site?”. Be assertive and listen! Some clients are direct (ie. straight to the point), some aren’t. Those who are direct will answer, “It will contain information about my business and nothing more.”. But those who are not will go around in a circle and answer, “Well…I thought before that the website will talk about where my company is but then I changed my mind… I think the website should allow user to submit bla bla bla”. At this point, you have to be assertive and ask the keyword question: “So, your website will only contain information about your company and nothing more?”.

Then guide them into more detail, “Do you need visitors to be able to register?”, “Does it need a contact form where visitors can submit enquiries from?”, etc. They will then answer your questions either directly or indirectly. So in a nutshell:

At any time always be assertive and ask the keyword questions!

That’s really how you can gather requirements efficiently. Don’t let them steer you but you steer them. Apologise if you feel that you’re cutting off their explanation but don’t be afraid to do so. The more direct you are the better. Otherwise, they’ll keep going on a circle.

If you need to, prepare a checklist that contains general website functionalities such as news roller on the homepage, contact us form, news & events page, etc. I will talk more about general functionalities that a website normally has later.

Your Homework

Once your meeting ends, summarize what you’ve talked about on a document then send it to them (client). Get them to ask you questions on things that they’re not clear about. Otherwise, get them to approve the requirements document by signing it.

I will discuss later about how to write a good requirements document. It has to be detail enough and clear! It shouldn’t say things that are too broad, for example:

– Client wants a news listing page.

Make it more detailed, for example:

– Client wants a news listing page that lists latest 10 news sorted by date. A paging control will also be added to the page to allow readers to navigate to older news items.

It’s OK to make assumptions!

Once again, you’re the expert not them. If a particular requirement is not clear, just make an assumption. You may forget to mention during the meeting how the news listing page is going to look like, but it’s OK to make an assumption based on your expertise (just like above). When client later receives your requirements document, they can then picture it in their head and they may go, “Aha..that’s a good idea” or even “Nah..that’s a bit too over the top, let’s forget about the news listing page”.

A lot of the times client thinks that your ideas are great ideas and they normally approve it. That’s even better because it means you will get longer work hence more money! Imagine if they cancel the news listing page, you have lost 1-2 days worth of work.

Don’t complicate the requirements. Even though you want to win more work, it doesn’t mean that you have to complicate them (the requirements). As long as what you add in there can help them achieving what they want, that’s good enough. By complicating the requirements, it will make your life a lot harder later on when developing the website. It will also increase development time and may blow out the budget. Client may not want to go ahead with your service because it’s too expensive.

Conclusion

So, let me remind you again. An efficient requirements gathering can only happen if you’re assertive and listen.  Ask the keyword questions. Do a lot of practice to find the keywords in a question.

Cheers,

Tommy

No Comments Yet.