Answers to questions such as “What is a functional spec?”, “Why is it important?”, “How do you write a functional spec?”, “What does it contain?”, “What does it not contain?”
The Functional Specification is the most important document in the development of web applications when using the Waterfall development methodology. Extensive documentation is not the focus of Iterative development, however.
When using the Waterfall method, without a good functional spec, your project is guaranteed, 100%, to fail!
What is a functional spec?
- It identifies the information to be displayed on each distinct page type in a website, and defines what a user can do and what the application does when they do it.
- It is an evolutionary document that will change dramatically during the planning phase of a project. It should also be kept up to date when additional functionality is implemented, throughout the development phase (you’ll never get everything in the spec before build starts), and entire the shelf-life of the project.
- In an ideal world, a complete functional spec should leave no questions unanswered or anything open to interpretation about the functionality of the application. It should be completely objective.
Details are the most important thing in a functional spec. Whenever a user does anything, the application should do something too, right? This includes simple things like displaying a certain page when a user clicks a link, to more complex things like registering personal details.
Taking the complex case as an example, there are many things that can happen depending on the business reqiurements and information provided by the user. The data supplied could be invalid in many ways, and checks need to be in place and feedback provided to the user for all possibilities. All cases correspond to real code that has to be written, but more importantly, these cases correspond to decisions that somebody has to make. Somebody has to decide what the policy is for a valid user details. The spec needs to document these decisions.
Why have a functional spec?
- It allows the programmer to accurately estimate for the development. (Whenever an estimate is provided to a client, it should always be with reference to a particular version of the functional spec.)
- It allows programmers to write code instead of figuring out business logic.
- It forms the basis of a test plan which is used to test the application once its built.
- The clients expectations of the functionality to be delivered for the agreed budget are aligned with those of the programmer.
- If a programmer understands the full requirements of the application from outset, he can design a system to fulfill the requirements from the outset, which will result in better code, a more robust application, and shorter development time.
- Allows multiple programmers to work on the app at the same time, independently.
What does a functional spec contain?
The first thing to note is that different people have different thoughts about what should be in a functional spec. These are my thoughts:
- A description of the features and functionality within the chrome of the site.
- A sitemap identifying the distinct page types or key pages only. Its not necessary to identify all content pages, that is the remit of the content plan, only the fact that there are content managed pages.
- The information to be displayed, what the user can do, and what happens when they do it, for each key page/distinct page type. These are called Interaction Points. If key user journeys span multiple pages with variable paths, consder using flow charts illustrating conditions, user inputs etc.
- Wherever dynamic content is displayed, if there are multiple items specify the sort order and direction, e.g. sort by created date, descending. If only some items should be displayed, specify the criteria, e.g. status = enabled.
- It should also identify future requirements for future phases of development / future releases. These should be summarised in their own section, and referred to in any other parts of the spec where they may be relevant. Its much more cost effective to plan for these up front.
What should a functional spec not contain?
- Anything to do with business strategy, such as marketing, competitor analysis, metrics etc.
- Anythng to do with the visitors’ equipment, including their monitor size, connection speed, computer processor speed, amount of RAM, color depth, installed plug-ins, etc.
- Anything to do with the visual design and the tone and imagery that the site should take on.
- Anything to do with any static content that the site will contain either added manually by the developer or by the client using a Content Management System.
- Anything to do with the internal implementation of the application, such as data structures and algorithms, etc.
- Anything to do with the site structure, navigation, and layout.
- Any subjective statements.
Consider the staement “The site must be easy to use” – this is a subjective requirement. What constitutes easy to use is subject to the user. A seasoned web user might find a web application easy to use, whereas a novice would not.
How do you start writing a functional spec?
- Take a top down approach, i.e. start with an overview and go into increasing detail.
- Imagine how users will navigate through the site and identify any global navigational elements.
- Describe features in order of priority.
- Imagine how users within your target audience will want to use a feature.
- Specify what the user can do at each stage and what should happen when they do it.
- List the elements that should be displayed to enable the user to fulfill the actions.
- Imagine what information a user will need or might want at each stage. List all information that is not static.
- Perhaps with reference to a wireframe mockup of layout, identify the consistent and variable elements across pages.
Some people think that wireframes alone will suffice and they infer functionality in a visual way – they do not. The wireframes should be created within the capabilities of the application as anddefined in functional spec. They only indicate the layout of the information and elements identified to be displayed at each stage of the key user journeys. The wireframes can then be used by the designers to design templates.
What skills help in writing a good functional spec?
- Excellent wrtten communication skills.
- An understanding of web usability.
- An understanding of User Interface design.
- Familiarity with the technical capabilities of the developer.
- Diplomacy and capable of interacting with clients and developers.
- An appreciation and awareness of client business.
How do you get people to read it?
There’s no point writing a spec if nobody reads it. Here are a few hints and tips that might help:
- Be funny.
- Use simple, concise language and consistent terms.
- Add clearly labelled side notes that include information necessary for one of your target reader groups, e.g. technical, client, marketing etc.
What happens when you finish a functional spec?
- Get someone to proof read it, if it has not been written collaboratively.
- Review it with the client and make changes as required until they are ready to sign off.
- During the build add any new functionality or relevant content that was missed initially.
- Don’t forget to add to it when embarking on future releases and feature additions.
Are there any disadvantages to functional specs?
- In an ideal scenario, you would not provide a final estimate to the client until you’ve written, and got sign off on the functional spec. This may be more difficult than it sounds. Clients prefer committments on budget fairly early on in the project.
- A functional spec can take a while to write, and require considerable input from the client, consequently they need to invest budget in creating functional spec, and time in answering questions.
- Essentially, to the client, the interface is the product, so it can be more difficult getting them to read and understand the functional spec than wireframes and visuals.