Digital Functionality Specification

What?

It's a document that is technical in nature, written primarily for the development team as a guideline and reference point as to how and what they are going to build. The document should outline objectives, requirements, Information Architecture and Platform delivery and break down these compartments into as much technical details as possible in order to provide a clear road map for production. The document should also outline the development lifecycle. Here is a generic example of what the doc should cover. If working within an agency it is great to have a template functionality spec document as many areas of these docs can be recycled across projects. A functionality spec can be as detailed as you choose. This usually directly correlates to the budget of the site and the time allocated to planning.

An example of a func spec framework

• Title
• Table of Contents
• Version
• Brief
• Requirements
• Objectives
• Timelines and Milestones
• The Team
• Platform Delivery
• Functional Description (all external user and programming applications and interfaces)
  • User Community (Define who the user is)
  • Administration requirements
  • Expansion Requirements (if numerous planned )
  • Support and Maintenance Agreement
  • Site Map
  • Wireframes. (This can be referenced as sometimes requires seperate documentation)
  • Database Design
  • Break down of the wireframes by description and reference in detail of planned functionality in each proposed section of the site.
• User documentation
• Test plan
• Launch and Delivery
• Terminology & Appendix

Who?

A func spec will primarily be used by your development team to reference the road map that they are traveling within the production life cycle. It may be at your discernment to include the client in on this process particularly in regards to sign off. This should be taken into account when writing the document, so that anything particularly technical is explained within the appendix and is referenced accordingly. The document usually proves important to the producer of the project who is navigation the full project lifecycle, it states objectives and creates milestones and timelines too keep track of the project. The downside with including the client in on this phase may be the time spent educating them as to this process. Ideally you don't want to be too bogged down in minutiae at this stage, particularly as a functional specification is usually an evolutionary document.

Why?

The age old question... Basically because a func spec can save your behind. If you are contracting a third party to develop a 'back end' solution or your client is creating changes outside of scope, the func spec can reference this in solid documentation. It also gives your developers a clear idea of where they're heading and how they are getting there particularly if the team is diverse or geographically separated...so make them read it.

How?

A producer should ideally be the creator of the functionality spec but it needs to be in community with the entire production team. It is of course no good specifying functionality that cannot be delivered because it is outside of a teams technical capacity. The first thing to do is really flesh out how your going to deliver a project and this needs the entire teams collaboration. The functionality specification is the formalization and documentation of this process so do the ground work and research first. If this is your first time creating a func spec find a template to follow as a guideline. There are numerous examples to be found online. Do not copy it of course as each project is unique so be mindful that a template will most certainly not be directly applicable. Do your research, collaborate and be clear. No one is impressed by unnecessary technical jargon so don't use it unless it is absolutely required for your developers. Whilst this is a technical document it will most likely be changing hands with the client and the non geeky.