How to Write a Website Functional Specification Document

Every website project should start with a specification. This should outline the objectives for your website along with any deadline or budget constraints.

A Functional Specification document is a document that you:

  • Give to the developers so they know what to build
  • Give to the testers so they know what tests to run
  • Give to the stakeholders (and get them to approve) so they know what they are getting

Here is a guide on how to write a useful functional specification document – one that will satisfy all parties and make for a successful project that is both on time and within budget:

 

1. Introduce yourself

Briefly explain what your organisation does, this provides the background to the project. Useful information includes:

  • A brief history of the company
  • Size - number of employees, turnover etc.
  • Key services
  • Major achievements

 

2. Start with the objectives

Why do you need a website? What outcomes do you want to achieve? Are they measurable? Are there problems with the existing site? What are the business drivers for the change?

Explaining your objectives will help drive everything else in the specification.

Define at least one goal that the website should help you achieve. Some examples are:

  • Increase number of enquiries via website
  • Increase online sales
  • Increase number of phone enquiries

When trying to quantify these, instead of looking at industry benchmarks, look at what you are achieving currently and come up with the improvements you'd like to see.

You may also have secondary objectives, for example to gain press attention, or to reduce the admin associated with new enquiries. Make a note of these too.

 

3. Key Audiences

You now need to identity the key audiences that you need to appeal to in order to reach your objectives. Your developers and designers need to know who is going to be looking at your website.

These might be:

  • Prospective customers or clients
  • Existing clients / returning customers

Be sure to mention their gender and age.

Once you have your audiences listed, the key thing you need to consider for each is what they want to be able to do on your site and what you want them to do on your site (these might be the same things, but they could well be different - e.g. they're objective might be to read a blog post, but as well as this you might want them to steer them to sign-up for your newsletter).

In other words, what are you trying to persuade them to do? Buy something? Sign up for something? Enquire about something? This will be the method with which you achieve your objectives in section 1 above.

Another useful thing to consider is the priority of these audiences. This will help when it comes to designing the layout and navigation of the website.

 

4. Provisional site structure

Create a site map – a tree like structure that shows all the pages that are to appear in a website. This can be sketched, typed up or put in a spreadsheet.

If this is too complicated for you, create your website menu, showing all the pages under each top link.

It is likely that this structure will change during the design stage, but it's useful to have a starting point that clearly conveys the 'information architecture' of the site.

The main purpose is to try and ensure nothing is forgotten about what needs to be on the site.

If you are upgrading a website, don't necessarily copy your old website structure - a change could yield benefits. Don't carry old assumptions in to a new project, you risk missing out on a beneficial change.

 

5. Technical specifications

In other words, what should the website do?

If it's a brochure site, most pages will be 'static' in the sense that they don't react to user actions. The exception here is usually contact pages that have interactive forms. 

If it's an e-commerce site, you need to list out any requirements for your home page, product listing page, product search and product detail pages.

If your checkout will be non-standard, for example it allows customers to customise their orders, information on this should be included.

If it's anything more advanced or unusual than this, write a detailed list of what every user should be able to do.

User Cases’ are a way of describing the actions a visitor should be able to perform on the site.

They look like this:

  • As a customer 
I want to add items to my cart 
So I can buy them later
  • As a member of staff
I want to change the status of orders 
So I can mark items as dispatched

Create user cases for each type of audience on your site, especially if you have unusual functionality.

When documenting, you have 2 options. Use an excel spreadsheet* for this that shows a list of all ‘user cases’ in the first tab and unlimited detail about each case in the tabs that follow.

* At BLAST we will provide you with an Excel framework to help you get started with your user stories.

Website Specification - Case Log    Website specification - Case Details

Alternatively, if you are allergic to excel, you can document each user's interaction with the system. For example:

Use Case 1: User Logs On

Main Flow

  1. User launches the application
  2. System prompts user for log-on details (user name and password)
  3. User enters log-on details and submits them
  4. System requests user’s log-on details from the external single-sign on directory
  5. System validates that user’s entered log-on details match those from the directory
  6. System displays the main menu

Alternative Flow 4a: Incorrect log-on details

  1. System tells user their log-on has failed
  2. Return to Main Flow step 2

Alternative Flow 4b: User account locked

  1. System tells user their account is locked and they should call the helpline
  2. Return to Main Flow step 2

In order for your user cases to be complete, you need to cover all the interactions through all the interfaces, whether they be human user interfaces or system interfaces, in particular including any “back-end” systems.

 

6. Non-functional requirements

These are requirements related to:

  • Usability - do you have accessibility requirements, perhaps your website will be used mainly on tablets, or by the elderly.
  • Security
  • Loading times - how important are loading speeds to you? If you're in e-commerce, the answer is very.
  • Legal - Are there any compliance requirements that the website must adhere to?
  • Will your customers need to accept terms & conditions?

 

7. Websites you like and don't like

For the design process, it's handy to have a list of websites you like and don't like to help guide the process.

This will give us a starting point from which to work towards your ideal design.

 

8. Who are you competitors?

Listing your competitors serves three functions:

  • We can see what other people are doing and perhaps borrow from their most appealing website features
  • We can find opportunities to improve on what the market already offers
  • We can ensure your website design is distinct from the competition

Competitor analysis is something you are probably doing anyway, even if it's not formal, so this should be easy. 

 

9. Budget

Many people don't want to disclose their budget when they contact us.

This is counterproductive. If we know your objectives and your budget, we can come up with the best solution.

If your budget is low, we will think about what can be done with it. Either we can select a specific technology that is cheaper to set up or we can suggest a phased approach where more functionality can be added later.

Be realistic and keep in mind that if you don't have much budget you'll need to compromise on the site specification.

 

10. Timeline

Now is the time to mention any deadlines you might have.

It goes without saying, make them reasonable!

Web projects can take anywhere from six weeks to six months depending on the size of the project.

Usually a short-term solution can be made available if you have nothing online currently. A sign up page is a good way of gathering email addresses before you launch your new site.

 

What to avoid

We thought it may be worth including some things to avoid, as that can also help when creating the perfect specification.

  • Overly long specifications - remember people have to actually read this
  • Jargon, no clear specification
  • Don't focus too much on the website should look or be structured like, this will be defined during the project design phases.