[Insert Company Title]

[Insert Title]
Functional Specifications

Version 1.0
[Insert Date]
General Template Information

This document captures the functional specifications of a proposed system or application.

Typically, IT development work that will impact more than one “actor” or span more than one
promotion cycle is of sufficient size to need Business Requirements and Functional
Specifications. IT development work that impacts only one or less “actors” or can be done in one
promotion cycle most likely requires Functional Specifications only.

While the Business Requirements represent the high level problems that are to be solved by the
proposed project, how they are to be solved is documented in the Functional Specifications.

Use of This Template

Functional specifications should be developed in conjunction with a Developer and/or IT
Technical Lead.

Functional specifications included in this document should be clear, consistent, precise and
unambiguous. Avoid the use of text to describe non-text designs. Text uses language to describe
specs and can vary based on experience (i.e. very technical) and descriptions. It is open to the
interpretation and subjectivity of the reader and can easily lead to wrong expectations.

Specs should be put into graphical form wherever possible. Functional specs that are
complemented by visual support (e.g. diagrams such as object models, state-transition diagrams,
flow charts, screen shots) significantly reduce interpretation and provide immediate and
straightforward understanding. This greatly reduces the time required in walkthrough sessions
and leads to better negotiation and agreement prior to development.

Disclaimer
While there is currently no industry standard for documenting functional specifications, it is often
useful to examine them from various perspectives. Not all areas in this template may be needed
and it is at the discretion of the creator to decide which are used. Some areas to consider include:
• Functional requirements.
• High level design.
• System architecture.
• Screen mock-ups and layouts, report layouts, etc.
• Parameters, rules and constraints that control functions.
• Hardware and software interfaces.
• Error handling.
• Security considerations.
• Integration and configuration.

Comments in grey font are included throughout the template to assist with content and
direction, and should be removed from the created document.
Document Revision History
Every change to this document (subsequent to initial sign-off) must be recorded in the revision
history chart below. Modifications to this document will be documented in the following chart.
There are no exceptions. Note that the Project Sponsor and the Project Manager must sign off on
any changes to this document.

Document Location: < Insert file path here >

Version Date Author/Editor Comments

1.0 January 1, Full name and title Initial version of this document.
2007
 Related Documentation and Material

List all supporting documentation for this project. Be sure to include all relevant materials,
including Project Charter, Request for Proposals, Business Cases, Business Requirements,
Requirements Checklists, Features Lists, relevant marketing materials, etc. It will be used as a
reference point for others on the project to gain insight into the background of the project, as well
as to provide direction on what to research and where documents can be found when needed.

The following is a list of documentation directly related to this project:

Name of Document Version Date File Name or Location

Business Requirements 1.0 January 1, < insert link here or path to file here >
Document 2007
1 Introduction
Purpose
The purpose of this document is to describe the functionality and use of a system or
application as defined by the requirements from the client’s perspective. This document does
not provide technical design details or basic code and architecture for development or how it
is to be implemented.

Documenting detailed and accurate functional specifications contributes significantly to the

success of development by establishing clear and understandable expectations for all
aspects of the software or application functions, features and performance. In addition, this
document provides the basis for negotiation and agreement between clients and the
development team and creates a measure for validation purposes and ensures requirements
are addressed during design and development.

The functional specifications document communicates the software requirements and client
expectations to the technical community who will eventually specify and build the agreed
upon system or application.

1.1 Design Goals

This section is designed to briefly outline the technical manifestation of the system or
application requirements, and to list the goals the functional specifications are intended to
achieve.
2 Functional Specification
Functional specifications should be developed in conjunction with a Developer or IT Technical
Lead.

2.1 Functional Requirements

Provide a complete list of the system or application’s required functions with associated input
and output considerations. List the functional requirements in order of priority. If these are
already included in the Business Requirements Document, reference it here and provide the
file name and link or file location.

For small scale projects that may not have a Business Requirements Document, the
functional requirements in this section describe the possible effects of a software system, in
other words, what the system must accomplish. The functional requirements section can be
fully text-based or can include a combination of text, diagrams or tables to explain the
functionality.

2.2 High Level Design

Identify the high level design of the system or application. Include system models displaying
relationships between system components and the surrounding environment. These might be
in the form of object models or data flow diagrams.

The objective is to present a non-technical view of the different components of the proposed
system or application, how it will work, how it will interact and considerations around how it
will be implemented.

2.3 System Architecture

Describe or use diagrams to provide an overview of the anticipated system architecture,
showing the distribution functions across (potential) system modules. Architectural
components that can be or are reused and/or 3rd party should be highlighted here.

2.4 User Interface Requirements

Describe the flow of the user interface and highlight important decision points in the user
interface. Include a workflow diagram.
2.5 Screen Mock-Ups and Layout
Insert a drawing of the user screen(s).

2.6 Parameter Table

Example:

Parameter Table

Control Type Action Max Min Parameters

‘OK’ Button Begin verification None None
Button script to verify
entered data
Date Field Month Allow user to select December January
Control a month for the
report
Team
Field

2.7 Hardware and Software Interfaces

Specify how the system or application is expected to interface with external applications. This
section should cover the requirements for the nature of the application program interfaces,
formal software development kits, and any other requirements for data import and export
needs.

Describe the characteristics of each interface between the system or application and other
hardware or software protocols. Be sure to provide the purpose of the interface.

2.8 Platforms
Specify the platforms that will be supported. Indicate appropriate operating system versions.
Also, specify operational requirements for hosting and any variations in behavior of hosted
deployments.
2.9 Integration and Configuration
Specify any integration and software/hardware configuration requirements.

2.10 Expandability
Highlight any likely expansion requirements. Specify requirements on backward and forward
compatibility or upgrades of the system or application.

2.11 Error Handling

Articulate how errors will be handled if they occur in the system or application? List potential
errors and identify the type of error and reason for classification.

2.12 Security Considerations

Specify possible abuses of the system or application and means to protect the system or
application (e.g. authentication, data encryption, password protection, internal checks, etc).

2.13 Conformance and Standards

List any important conditions, guidelines, or governance issues (e.g. Sarbox) that will be
affected or have an effect on the system or application, and standards to which the system or
application must conform.

2.14 Other Requirements

Identify other requirements that do not fit into the preceding sections but must be identified or
are worth noting.
3 Sign Off
Formal approval of this functional specifications document represents the agreement that the
system or application satisfying the specifications described within this document is accepted
by all. Once approved, all changes must be made through regular change management
processes.

< Name > Date

< Name > Date

< Name > Date

< Name > Date