E Consultancy Functional Specification MSWord

<Project Name> Functional Specification

Client Name (insert)

Project Title (insert)

Functional Specification

Version:Author:Date:

Document Review and Sign offI hereby agree to having read and fully understood the contents and implications of the

attached document.For & on behalf of: (Insert client name)

Date:

For & on behalf of: (Insert supplier name)

Date:

© E-consultancy.com Ltd 2007 of 12

This document provides a detailed description of the operation of the (insert Project Title)


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



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

Name Organisation Position



3. Terms and Abbreviations

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

Abbreviation Definition

3.2. Reference DocumentsThis functional specification should be read in association with the following:

Document Purpose Version Date Status AuthorCreative 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 Specification

Includes specifications 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 project documents

e.g. Accessibility Compliance Document



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.4. Data Requirements 8

7.5. Data Interaction 8

7.6. Data Persistence 8

7.7. Data Workflow 8

8. SITE ACCESSIBILITY/USABILITY REQUIREMENTS 9

9. USER INTERFACE & SECTION OVERVIEW 10

9.1. Navigation 109.1.1. Global navigation 109.1.2. Secondary / section specific navigation 109.1.3. Tertiary navigation systems 10

9.2. Section Overview 119.2.1. Section name (for each section) 119.2.1.1. Page name and content (for each page) 11

10. WIREFRAMES (STORYBOARDS) 12

11. MI Reporting 12



5. Background & Business RequirementsThis 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



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 referenceTask e.g. buy a book

Summary Explain the task that the use case describesTrigger 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 doRelated Use Case Does this use case link to other use cases?

AssumptionsPreconditions What conditions must be true for the user to start this task

e.g. user already registeredOutcome What happens at the end if the task is completed

successfullyData 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



7. Data Requirements

Only relevant where project incorporates data processing or integration with back end systems

7.1. Data RequirementsData 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 InteractionTransformation 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 WorkflowDetails of data in/out passed between each stage of the process



8. Site Accessibility/Usability requirementsThis 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.



9. User Interface & Section OverviewThis 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 & Functionalityo Section by sectiono 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 CommentsNavigation 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)



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



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 Functional Specification MSWord

Documents

Transcript of E Consultancy Functional Specification MSWord