<Project Name> Functional Specification

Client Name (insert)

Project Title (insert)

Functional Specification

Version:
Author:
Date:

This document provides a detailed description of the operation

of the (insert Project Title)

Document Review and Sign off

I hereby agree to having read and fully understood the contents and implications of the
attached document.
For & on behalf of: Date:
(Insert client name)
For & on behalf of: Date:
(Insert supplier name)

© E-consultancy.com Ltd 2007 Page 1 of 12

<Project Name> Functional Specification

1. Version Control
The following is a list all changes made to this document, the person making the change, the new
version number and the reason why the change was necessary.

Date Author Version Change Description

© E-consultancy.com Ltd 2007 Page 2 of 12

<Project Name> Functional Specification

2. Distribution List
The following list contains the names and organisational details of the people to whom this
document has been distributed.

Name Organisation Position

© E-consultancy.com Ltd 2007 Page 3 of 12

<Project Name> Functional Specification

3. Terms and Abbreviations

3.1. Abbreviations
The following table contains a list of the terms and abbreviation specific to the project

Abbreviation Definition

3.2. Reference Documents

This functional specification should be read in association with the following:

Document Purpose Version Date Status Author

Creative Concepts Key screens that
demonstrate the creative
look and feel.
Content Plan Details content providers,
owners, any sign- off
processes, delivery
format, who receives it,
how often it is updated
and to what deadlines.
Technical Includes specifications
Specification for the technical
architecture, security,
server specification &
user machine
specification
Site Map Navigational architecture
Project Schedule Specifies the tasks
involved in the
implementation of the
solution and the related
time scales,
dependencies and
durations of these tasks.
Other referenced e.g. Accessibility
project documents Compliance Document

© E-consultancy.com Ltd 2007 Page 4 of 12

<Project Name> Functional Specification

4. Table of Contents

1. VERSION CONTROL ...................................................................................................................2

2. DISTRIBUTION LIST.....................................................................................................................3

3. TERMS AND ABBREVIATIONS...................................................................................................4

3.1. Abbreviations............................................................................................................................4

3.2. Reference Documents..............................................................................................................4

4. TABLE OF CONTENTS.................................................................................................................5

5. BACKGROUND & BUSINESS REQUIREMENTS........................................................................6

5.1. Business Process Description.................................................................................................6

5.2. Process Overview – optional...................................................................................................6

5.3. Assumptions.............................................................................................................................6

6. USE CASES (OR “SCENARIOS”)................................................................................................7

7. DATA REQUIREMENTS...............................................................................................................8

7.1. Data Requirements....................................................................................................................8

7.2. Data Interaction.........................................................................................................................8

7.3. Data Persistence.......................................................................................................................8

7.4. Data Workflow...........................................................................................................................8

8. SITE ACCESSIBILITY/USABILITY REQUIREMENTS.................................................................9

9. USER INTERFACE & SECTION OVERVIEW............................................................................10

9.1. Navigation................................................................................................................................10
9.1.1. Global navigation...............................................................................................................10
9.1.2. Secondary / section specific navigation.............................................................................10
9.1.3. Tertiary navigation systems...............................................................................................10

9.2. Section Overview ...................................................................................................................11

9.2.1. Section name (for each section)........................................................................................11
9.2.1.1. Page name and content (for each page)........................................................................11

10. WIREFRAMES (STORYBOARDS)............................................................................................12

11. MI REPORTING ........................................................................................................................12

© E-consultancy.com Ltd 2007 Page 5 of 12

<Project Name> Functional Specification

5. Background & Business Requirements

This section should give a very brief explanation of the background to the project and its business
objectives (referenced to a requirements document or listed here).

5.1. Business Process Description

High Level narrative to describe the business process

5.2. Process Overview – optional

Diagram showing each detailed process

5.3. Assumptions
List any assumptions that are specific to this functional specification document

• Assumption 1
• Assumption 2
• Assumption 3

© E-consultancy.com Ltd 2007 Page 6 of 12

<Project Name> Functional Specification

6. Use Cases (or “Scenarios”)

Describing the journey through a site is useful at early stages of a project, as a way of getting under
the skin of a prospective user and articulates a common understanding of how requirements are
being translated into a customer experience.

Use a separate use case to describe each task or requirement. These use cases can then be used
as a means of checking the page content and wire frames later in this document.

Use Case No. Make this a unique reference

Task e.g. buy a book
Summary Explain the task that the use case describes
Trigger What makes this use case happen, what is the user trying
to do?
Events Action System Response
What does the user do How does the system
respond
What does the user do next How does the system
respond

Alternative Paths What other routes might the user take to complete this task
or what decisions might trigger alternative paths?
Exceptions What errors may occur, and what happens if they do
Related Use Case Does this use case link to other use cases?
Assumptions
Preconditions What conditions must be true for the user to start this task
e.g. user already registered
Outcome What happens at the end if the task is completed
successfully
Data items What data is captured, stored, retrieved to complete this
task?
Related Business Rules Are there any business rules involved in this scenario e.g.
qualify that customer eligible for discount

© E-consultancy.com Ltd 2007 Page 7 of 12

<Project Name> Functional Specification

7. Data Requirements
Only relevant where project incorporates data processing or integration with back end systems

7.1. Data Requirements

Data entity model showing entities required to service the Process flows/use cases,
detailed down to the specific Items of data required by each process

7.2. Data Interaction

Transformation and movement of data, decisioning. (Reference to application
components/middleware)
Mapping of data
Use a table to display data

7.3. Data Persistence

In-Session
Listing of data required for duration of session ie. address.
Data not to be stored
Long Term
Listing of data required to be stored in db, include the lifespan of data i.e. archiving
requirements, DP Act requirements.

7.4. Data Workflow

Details of data in/out passed between each stage of the process

© E-consultancy.com Ltd 2007 Page 8 of 12

<Project Name> Functional Specification

8. Site Accessibility/Usability requirements

This section should explicitly document specific accessibility and usability objectives to be met by
the development team.

Accessibility- delivering a site or application that is usable by users with Motor or Visual
impairment- is a politically sensitive issue that has generated many White Papers and books. In
terms of a Functional Specification, you should aim to document what level of accessibility your site
or application will achieve.

The most established benchmark for accessibility is the W3C guidelines. They are divided into
three levels and it is useful to base your objectives on these. In the UK the RNIB, Royal National
Institute of the Blind, offer a guide to practical application of the W3C guidelines as well as
providing am audit of your site.

In writing a functional specification your aim should be to document key usability goals and insights
based on research gathered pre-design, and articulate your plan for evaluating the success of your
design against this.

Setting a specific benchmark for Usability in the same way that you can for accessibility is
impractical, successful user experiences are not easily defined by a set of rules. It is possible to
make statements such as “User able to easily navigate from home page through sales process” but
the only real way to measure whether there is a successful outcome is through user testing, how
else can you establish if it was easy or not?

To ensure the end project is built to deliver happy customer experiences usability testing needs to
be built into the project from the very outset;

• Requirements gathering
• Design stage
• During build
• Post build

Even if your budget is small, a small amount of testing(especially at the design stage) can go a
considerable way to improving the end product and reducing the need for re-work at a later date.

© E-consultancy.com Ltd 2007 Page 9 of 12

<Project Name> Functional Specification

9. User Interface & Section Overview

This section will describe in turn:-

• Navigation systems:
o Global navigation (i.e navigation options that are available at all times)
o Secondary or section specific navigation (i.e exclusive to a particular section)
o Any Tertiary navigation (the lower levels)

• Information & Functionality

o Section by section
o Page specific

In doing so you should:

Cross reference and match these descriptions with the main numbering/naming system created for
the Site Map and Wireframes, and any Process Flows / User Journeys or designed key screens. (If
the site is large, these may be separate documents)

9.1. Navigation

9.1.1. Global navigation

Describe in words and show using wireframes / storyboards what the top level of navigation will be
and how it will work.

9.1.2. Secondary / section specific navigation

Describe in words and show using wireframes / storyboards what the next level of navigation down
will be and how it will work.

9.1.3. Tertiary navigation systems

Describe in words and show using wireframes / storyboards what the lower levels of navigation
down will be and how they will work. E.g crumb trails.

Decide if, and to what level, you might need to use an 'Action /Response' table (see below) to
describe navigation in detail. Such tables are detailed but may be unnecessary for all but complex
areas of functionality and a text description including wireframes may be more efficient.

Description Action Response Comments

Navigation option Expected user action Expected system
response, if
applicable include
the page that the
user will taken to and
the number of the
section within this
document that
describes it (i.e.
2.1.1.1)

© E-consultancy.com Ltd 2007 Page 10 of 12

<Project Name> Functional Specification

9.2. Section Overview

9.2.1. Section name (for each section)

Describe the content and functionality of this section and its broad purpose in the context of the
site.

9.2.1.1. Page name and content (for each page)

Contains;

• Description - In the functional specification you might explain this further as follows:

The mortgage calculator will be a single page with an interactive calculator function that allows the
user to calculate their mortgage repayments. The user can choose to configure the calculator using
the bank’s currently offered interest rate (which will be updated daily by the Webmaster) or they can
input their own rate. The user can also choose between different types of mortgage offered by the
bank, and alter the repayment period to see how this will affect monthly repayment amounts. There
will be direct links to the relevant mortgage products from this page.

At this stage, the calculator will only return monthly repayment amounts and will only give dollar
values. It is envisaged that future developments will allow the user to calculate the maximum
mortgage available to them, as well as to input other monthly outgoings that can be added to the
mortgage repayments to help users balance their personal finances. This will help position the bank
as the first point of contact for all personal finance matters and show that the bank recognizes that
every person’s situation is unique.

• Links and Controls - describing all controls on page, any links to other pages

• Drop downs - Describe any drop-down lists and detail the choices available within each
including references to database tables

• Content Management Requirements - Include any known requirement for the page to be
content managed and what features are to be available

• Business Logic - Describe what happens when the user logs on, logs off, ‘Enter’, ‘save’,
‘cancel’, ‘continue’, ‘back’ etc

• Options Available - Describe what buttons/options may appear which are dependent
upon actual input or content of data held for the User.

• Validation - Describe any validation checks performed on the inputs including any cross-
field validation

• Database cross-references - Cross reference the action that needs to be done to invoke
the validation.

• Errors and Exceptions - Additional screens for handling validation and failure

© E-consultancy.com Ltd 2007 Page 11 of 12

<Project Name> Functional Specification

10. Wireframes (Storyboards)

Wireframes, or storyboards, are a useful way of setting down the elements on a page, as well the
location of navigational options. There is usually no need to produce a Wireframe for each page.

Include Wireframes of key page templates in this section or other referenced document. (See
Wireframes template)

11. MI Reporting
An overview of what MI reports will be provided

© E-consultancy.com Ltd 2007 Page 12 of 12