10 tips to write killer website functional specifications

Would you trust a builder to start building your house without any plans? The same idea goes for website projects – skipping preparations comes with risks. Find out how to write effective website functional specifications that get all team members on the same page before development starts.

Subscribe to our blog

One of the main responsibilities of the functional analyst is to provide a clear and detailed description of the different functional parts of a website and their required behavior. These descriptions of what the website will do are also called functional specifications. It’s not just about those elements that are visible for the website visitors, like image galleries, videos, contact forms but also the functionality that is used by content managers in the authoring interface of the web content management system (WCMS). Examples of the latter are templates used to create different types of web pages (e.g. event, news, job announcements) and manage the customization or styling options of each of the page components.

Functional specifications are also important tools which are used by the different web teams:

  • The client can use them to check if the functionality that will be developed matches their needs and to suggest optimizations before the implementation process starts. The functional specifications are also used by the client to define the project’s acceptation criteria together with the analyst.
  • The project manager will be able to assign resources to tasks and trace a reasonably accurate timeline for the project.
  • The technical lead uses the functional specifications as the starting point to define the technical specifications for the development.
  • The front-end developers translate them into the necessary HTML, CSS and JavaScript files to implement the envisaged front-end behavior.
  • The WCMS developers combine the functional and technical specifications as direct inputs to start development work.
  • The testers use them as the foundation to establish guidelines on what to test for each functionality as well as to document and create detailed test scenarios.
  • For the support team, it’s their go-to source reference to get quick inputs regarding functionalities when solving incidents or performing continuous maintenance and optimization.

A good specifications document has to match the needs of the different teams involved in the website project. But what do you have to take into account to cover so many aspects of design, functionality, development and user experience? The following 10 tips will get you started.

1. Make it collaborative

It is essential to understand that the creation of specifications is not an individual task. It is the result of a collaboration between the client, the functional analyst, UX, design and the technical teams. Therefore, specifications are preferably created in a collaborative environment (e.g. using a tool like Confluence). This makes it possible for all team members to work together in an easy way, even if they operate from geographically remote locations. The functional analyst can be considered as the specification master, who makes sure that all inputs are documented in a consistent way.

2. Make it uniquely identifiable

Functional specifications need to be identifiable. This can be done by defining a clear and unique name for the functionality it describes. This seems to be a trivial step, but experience tells this is an important one. This name is important because it will be used during the whole lifecycle of the web project. It will be used in conversations with all stakeholders, in code, technical documentation, user documentation and training. So think twice before setting the name. Also provide a unique numeric ID, next to the more descriptive title.

3. Make it structured

Specifications need to be structured to make it easy to use them. During conversations it should be easy to consult them and retrieve the required information quickly. Seemingly simple things can help you accomplish this:

  • Create a template to make sure that all the functional specification documents for functional components are structured in the same way.
  • Use a table instead of running text to detail the individual specifications for each component
  • Standardize and structure the wording of individual functional specifications in the same way, e.g. by using a format like “As a visitor I should be able to…”

4.  Make it visual

People prefer watching over reading. They also tend to understand things better when they see it. Adding visual elements to your specification document will help the different teams involved to understand the described functionality more quickly. This can be done by adding wireframes, flow charts, prototypes, design screenshots, and so on.

5. Make it integrated

Whenever you can, add clear references to additional relevant resources within the project. When the different teams start using the specifications documents, it should be easy for them to locate related sources of information, such as design files, coding style guides, design specifications, prototypes or even related functional specifications for e.g. templates on which a functional component is used.

6.  Make it readable

Functional specifications documents are, as already mentioned, used by a lot of different roles. They are used as an instrument to discuss as well as to inform all the teams about all the features, interactions and every detail of functional behaviour that has to be included. Therefore, they should be written in a non-technical way that is clearly understandable by all stakeholders, be they technically minded or not.

7. Make it extendable

An initial specification is created for each functional component at the start of a web project. After the go live of a website, it’s only natural that additional optimizations are made to several of these components, and new functionalities are added. This means the functional behavior might be revised. It’s important that this extensibility is taken into account from the start, and that the setup of the components’ specifications allows for easy extensions in the future.

8. Make it precise

Specifications need to be clear and precise. In the ideal world, developers should not be left to guess or have to interpret the functional descriptions. This can be done by using clear language, providing examples if required, and having all their questions answered about what needs to be achieved, how and why.

9. Make it traceable

During the functional discussions between the web team members and the client a lot of decisions are made. Make sure to keep track of all the decisions related to functionality and that these are reflected in the final functional specifications document approved by the client. While new functionality can still be introduced mid-project, this will be useful to avoid discussions in the future.

10. Make it digestible

When creating written specifications it is important to avoid an information overload. One way to do it is to identify the individual functional parts of a website and create separate specifications for each one of them. It’s also a good idea to organize the specs at the level of page templates and individual functional components that are used on these templates. On one hand, it keeps information focused for the reader, and on the other hand, it matches to the way tasks are usually organized in Agile stories, which makes it easy to integrate with project tracking software like JIRA.


It seems crystal clear that the functional specification document is critical to ensure the design and development teams working on the project are on the same page as the client, and ultimately, to guarantee everyone will be happy with the finished product.

Ensure you have experience functional analysts as part of your web team who have in-depth expertise in all aspects of the website’s design, functionality, development and user experience. Effective website specifications provide a clear roadmap and targets for the web team to aim for, and help avoid unnecessary deviations from the plan, not only in terms of time, but also in terms of cost.

Published on    Last updated on 01/07/2019

#Web Development, #Digital Strategy

About the author

Joris Bekaert is Business Consultant at Amplexor, based in Belgium. Specializing in functional analysis and web development, Joris has been part of the Amplexor Digital Experience team since 2007.