System Name
Functional Specification
Functional Specification
System Name
Release: Draft/Final
Date: DD MMM YYY
Authors: XXXXX
Date: 27 May 2014
Page 1
System Name
Functional Specification
1 Report History
Document Location
This document is only valid on the day it was printed.
The source of the document will be found at XX
Revision History
Revision date
Author
Version Summary of Changes
Approvals
This document requires the following approvals:
Name
Title
Date of
Issue
Version
Distribution
This document has additionally been distributed to:
Name
Title
Date of Issue
Date: 27 May 2014
Page 2
Status
Changes
marked
System Name
Functional Specification
Table of Contents
Page
1 Report History..................................................................................................................... 2
Document Location............................................................................................................. 2
Revision History..................................................................................................................2
Approvals............................................................................................................................ 2
Distribution.......................................................................................................................... 2
2 Purpose .............................................................................................................................. 4
3 Background......................................................................................................................... 4
4 Scope.................................................................................................................................. 4
In Scope.............................................................................................................................. 4
Out of Scope....................................................................................................................... 4
5 Timescales and Priorities.....................................................................................................4
6 Summary of Business Requirements...................................................................................4
7 Policy and Issues.................................................................................................................4
8 Summary of Functional Areas.............................................................................................4
9 Functional Requirements by Module...................................................................................5
10 Screens and Workflows.....................................................................................................5
11 User Interface Description.................................................................................................5
12 Interfaces to other systems................................................................................................5
13 Users and Security............................................................................................................ 5
14 System administration and maintenance...........................................................................6
15 Non-Functional Requirements...........................................................................................6
16 Appendices........................................................................................................................ 6
Date: 27 May 2014
Page 3
System Name
Functional Specification
2 Purpose
The purpose of this document is to summarise the functional requirements of x. It is not a
system solution, but a guideline of the required system functionality.
3 Background
Background about the project
4 Scope
In Scope
Out of Scope
5 Timescales and Priorities
6 Summary of Business Requirements
Summary of business requirements that have been selected for this phase of development
- brief descriptions
- priority
7 Policy and Issues
Particular points to consider that may influence the development. Decisions regarding why it
should be done in one way and not in another way.
8 Summary of Functional Areas
Brief summary of key functions required if possible with diagram illustrating the
relationship between them.
Date: 27 May 2014
Page 4
System Name
Functional Specification
9 Functional Requirements by Module
This section sets out the functional requirements of the system by module. It would include
details of key functions that the system must perform:
- Key processes
- Creation/Amendment/Deletion of records
The requirements set out here are ranked in MoSCoW order:
M Must Have
S Should Have
C Could Have
W Would like to have
10 Screens and Workflows
For an internal development the Functional Specification should contain details of the
screens required with:
- Basic mock ups
- Links to processes defined in the Functional Areas
- Details of the workflow between the screens, i.e. data flow, inputs and outputs
In the case of amendments/enhancements to existing systems (either internally or externally
provided) the Functional Specification might include suggestions for changes to existing
screens which are already in operation in order to meet business requirements.
11 User Interface Description
Whilst the Business Analyst will not be designing the User Interface for a new system, the
Functional Specification should include a description of the expected User Interface.
12 Interfaces to other systems
Interfaces required to other systems should be detailed, with information about the nature of
the interface and of each system concerned.
13 Users and Security
Different types of users/user roles
User permissions i.e. where permissions are required to access:
- Specific processes
- Specific data
Date: 27 May 2014
Page 5
System Name
Functional Specification
14 System administration and maintenance
How will base data in the system (e.g. users, parameters) be maintained and by whom?
Who is the owner of the data?
15 Non-Functional Requirements
Where identified, relevant Non-Functional Requirements (requirements that do not specify
what the software functions should do, but how the software should operate) should be
specified. Ideally there should be some descriptive detail that will allow assessment of
whether the requirement has been met (e.g. response time in the case of performance).
16 Appendices
These might include:
-
Data catalogue where applicable - Where appropriate details of new data fields that
need to be created and how they might be grouped into or added to a table and why
Date: 27 May 2014
Page 6
