Avoid Surprises - Insist on a Requirements Doc for Your New Website

(Article first published in September '11. It has been modified slightly to suit its publication on our site)

This article is also translated to Serbo-Croatian language by Jovana Milutinovich from Web Geeks Resources. Many Thanks Jovana.

I have just finished writing the fourth website requirements document for as many clients in just a few weeks and am amazed by how important these documents are to the success of the overall web development process for both the client and the developer. While some websites are quite straightforward and require little more than the ability to change the content, other sites can be quite complex. Whether you are a large company or SME, if the website you want falls into the complex category (i.e., e-commerce, customer back end access, multiple levels of content management), then you want to be sure that the web developer you hire creates a requirements document that you can review together before they start to build the site.

A requirements document is intended to 'protect' both you and the developer.

The last thing you want is an invoice for work that you didn't approve or a website that has features you didn't request. A requirements document will help to avoid these 'surprises' by clearly articulating all of the elements you and the developer have agreed to for the website.

From the developer's perspective, the document is intended to avoid what we call 'mission creep'. Mission creep refers to additional requests made by clients after they have signed off on a project. The problem with mission creep is that it affects both the timeline to develop the site as well as the total development costs. At the end of the day, we want our clients to be satisfied on multiple levels: timeframe for a site to go live, cost and end result.

What should you look for in a requirements document?

The two most important things to look for in a requirements document is that it is written clearly and covers all functional elements of the website. The document should also be separate from the website brief, which covers the more general look and feel that you want from your website.

Clarity. A requirements document is different from a functional spec in that it is written so that you will be able to understand it. It is not intended for technical coders. If it doesn't make sense to you, chances are that the developer isn't quite sure what the requirements are for your website.

Some of the topics that the document should cover include the following:
 

• Project Scope - What is the purpose of your website?
• User classes and characteristics - Who will use your site and what general level of navigation knowledge will they have? This includes your team who will be managing the back and front ends of your website.
• On what operating environments will the website work? Mobile phones? IPads? The latest Mac systems?
• Design/Implementation constraints - Does your website need to be translated into multiple languages?
• Front-end - What features do you want in the front end? News feed? Advertising feed? Flash banners?

Functionality. A thorough explanation of the functionality of your site is critical. How will your site work? How will you update it? How will customers pay online? How will your website administrators add/edit/delete content? Send emails/newsletters? All of these questions need to be clearly answered in the document. What you want the requirements document to tell you is that this functionality will be included in the website, as well as how this functionality will be achieved.

For example, say you want users to be able to log into the site and manage their details, as well as download documents. Does the requirements document explain the functionality surrounding these actions? While you're not looking for a technical explanation here, you do want to get a sense that this is something the developer is able to do. And you want to make sure that no element of the functionality of your website has been overlooked.

In summary, your website requirements document is a roadmap for how your website will function when it is built. Make sure the developer you choose for your website is a stickler for detail and insists on drafting a requirements document that covers all of the elements you want included in your website. It's better to take additional time up front to agree to the functionality than to end up with a website that misses the target or costs you a lot more than what you budgeted.

Suzanna Rosenberg Doyle has worked in marketing and communications since 2004 for companies in the US, London and Dublin. She was most recently a marketing manager for an international renewable energy company before joining The DG Group in 2011.

The DG Group is dedicated to delivering all the marketing solutions any company may require. Whether it's a website or leaflets and brochures, or even some product packaging; The DG Group will manage the whole project, providing sound guidance along the way.

The content in this section is the original creation of The DG Group and is protected by copyright. You may use this content on your site or in other materials providing you acknowledge The DG Group as the author and include a link to our site.