FunctionalSpecification

VersionNumber
RevisionDateTime
DevelopmentProjectLead
PeerReviewer
AssignedSQAEngineer
BusinessAnalyst
EngineeringManager

1
5/18/201212:20:00PM

Version
1

Status
Draft

Date
1/11/11

EditedBy
J.Delmore

DescriptionofChange
Startofdrafttemplate

CompanyConfidential
ThisdocumentcontainsconfidentialandproprietaryinformationofYOURCOMPANYNAME.Anyreproduction,
disclosure, oruse in wholeor in part is expressly prohibited, exceptas may bespecifically authorized by prior
writtenagreementorpermission.

Functional Specification

Table of Contents
1 OVERVIEW
1.1

Description

4
4

1.2
Scope
1.2.1 Objectives
1.2.2 Non-Objectives

4
4
5

1.3

References

2 FUNCTIONALITY
2.1

Existing Functionality Details

2.2
Proposed Design
2.2.1 Description of Functionality
2.2.2 User Interface Changes
2.2.3 External Interfaces
2.2.4 Process Flow

6
7
7
7
7

2.3

Alternate Design Options Considered

2.4

Design Decision Summary

3 CONSIDERATIONS

3.1

Dependencies and Assumptions

3.2

Risks

3.3

Managed Issues

4 EFFORT

4.1

Original Estimate from SOW

4.2

Latest Estimate

4.3

Reasons for Change in Estimate/Scope

5 SIGN-OFF

Page2of9

Functional Specification

What Information Belongs in a Functional Specification?

A comprehensive functional specification meets the following objectives:

It provides the correct level of detail needed for the subsequent design
phase.

This template is a guideline for writing conceptual, high-level, and detailed functional
specifications for projects or products. The content of a functional specification is
determined by the level of complexity of the project or product.
A functional specification should provide the following information pertaining to
conceptual, high-level and detail design.

an overview of how the various pieces of the functionality fit together

a description of the objectives and non-objectives of the project
a description of existing, proposed, or alternate functionality

If the project or product is small, you may combine documents (for example,
combining the Requirements and Functional Specification). If you do combine
documents, the appropriate sections from the Requirements and Functional
Specification Templates should be inserted and included in this document.

What Information Does Not Belong in a Functional Specification?

A functional specification does not duplicate information that is already described in
other documents (for example, in the Project Plan, Design Specification, Marketing
Requirements Document (MRD), Requirements Specification, or in any other
product-related document).

Page3of9

Functional Specification

1 Overview
Introducing the Subject of the Functional Specification
This section briefly introduces the subject of the functional specification. It
summarizes the issues discussed and the solutions that will be developed in this
specification.

1.1 Description
Providing an Overview of the Project or Product
This section provides the reader with a high level picture of the project/product being
designed in this document. It includes additional or more detailed information about
the project, which is needed to address the design of the project.

1.2 Scope
Defining the Scope of the Functional Specification
This functional specification may only address a portion of the requirements or
functionality defined in the MRD and/or the Requirements Specification. Similarly,
this specification may describe functionality, which will not be addressed by this
particular project for a variety of reasons including looking at future functionality,
which should be considered while this project is being defined.
This section clearly defines the boundaries of this project in terms of the
requirements and functionality, which will not be implemented as part of this initial
project.

1.2.1 Objectives
This section describes the purpose of this project or document. Reference existing
documents (requirements, architecture, etc.) rather than duplicate information.
State and prioritize the objectives of the design, such as performance, expandability,
compatibility, etc., which are intended to be achieved in the scope of this
specification.
When writing this section, consider the following questions.

What requirements are being achieved by this functionality?

What questions and/or needs does this document or project respond to?

Page4of9

Functional Specification

1.2.2 Non-Objectives
Defining the Non-Objectives of the Specification
This section describes any objectives, which are not planned to be achieved in the
scope of this specification. Make no assumptions about a readers understanding of
the product or project.
When writing this section, consider the following questions.

What are the non-objectives of this project?

Why are these non-objectives?

1.3 References
Listing Important References
This section lists any references that may be important to the complete
understanding of this design specification. For each reference, include the title and
author. Include the version number only if it is important that this specification satisfy
exactly that version. If it is the intent of the project to satisfy the latest version of the
reference, then a version number should not be specified.
Such references could include, but are not limited to, the following sources.

Marketing Requirements Document (MRD)

Requirements Specification
Architectural Specification
Associated hardware requirements specifications
Associated hardware test plans.
Statement of Work
Work request, change request, enhancement request, bug report, etc.
Customer letter or memo
Request for proposal
Published standards, regulations, or criteria
Contract
Competitive product information or a competitive analysis report
Previously published documents on the subject.
Documentation concerning related projects.

2 Functionality
Providing an Overview of the Functional Architecture
This section provides a general and integral view of the functional architecture. It
describes functional components at a high level, as well as how they interact with
each other.

Page5of9

Functional Specification

2.1 Existing Functionality Details

Providing a Detailed Description of the Existing Functionality
Describe the existing functionality in a general manner, providing more detail if it aids
understanding of the evolved design. Reference existing functional and design
specifications or documents where appropriate. Use text only where figures,
diagrams, tables, etc., will not serve to provide appropriate understanding.
When writing this section, consider the following questions.

How does the existing design work?

What are the functions accomplished in the existing design?
Does the existing design support or partially support the requirements?
What makes the existing design insufficient for the new requirements?
What are the disadvantages relative to the proposed design?
What are the major components in the existing design and how do they
interact?

2.2 Proposed Design

Providing a Detailed Description of the Entire Design
This section describes the proposed design in detail. Using text, figures, diagrams,
and tables, it discusses the overall design, as well as individual components. Note
that this section can be inspected before the remainder of the document is complete.
Since this specification represents the final stage in the project lifecycle process
before the implementation stage, this section should break down the components
defined in prior specifications to clearly specify the design. Do not duplicate
information contained elsewhere for this project, but to refer to the information and
documents as appropriate.
In the case where changes are being made to an existing design, focus on the
portions of the existing design that are affected by the proposed design, and explicitly
indicate those changes. Provide enough information to demonstrate how the
changes fit into the existing design, and make no assumptions about a readers
understanding. Reference sections from previous specifications where helpful.
In this section, provide the following information.

Description of functionality
Proposed User Interface Changes (Via wireframes or user flow
diagrams)
External Interfaces (inputs and outputs)
Process and control flow

When writing this section, consider the following questions.

Page6of9

Functional Specification

What is the design?

What are the major components?
How does the proposed design work?
What functions will be accomplished in the design?
Is the proposed design an enhancement to an existing design?
What is the general design of each component?
What functions are supported by each component?
How do the components interact?
When do the components interact?
With what information do the components interact?
How will the proposed design meet the conventions, criteria, and
standards for the project?

2.2.1 Description of Functionality

2.2.2 User Interface Changes
2.2.3 External Interfaces
2.2.4 Process Flow

2.3 Alternate Design Options Considered

Defining Alternate Designs (Overview)
This section describes any alternate designs for the entire proposed design or for
specific components. This section is optional. If alternate designs are described in a
Conceptual Design Document, High Level Architecture, or other document, simply
include a reference here.
Detail should be provided only if it is necessary to justify the decision. Note: Repeat
this section as many times as needed.
When writing this section, consider the following questions.

To which part of the proposed design does this alternative pertain?

What is the difference between this alternative and the proposed design?
What is the high-level design architecture?
What are the major components?
What is the general design of each component?
What functions are supported by each component?
How does the alternative work?
Why was this design not chosen? Why was it rejected?

Page7of9

Functional Specification

2.4 Design Decision Summary

3 Considerations
3.1 Dependencies and Assumptions
Listing Product or Project Dependencies and Assumptions
This section lists additional product or project dependencies and assumptions not
included in other related documents, or relevant to this document. Include previously
undocumented dependencies, which this project has on other products/projects, on
specific modules, devices, internal groups, and customers. Include previously
undocumented projects, modules, groups, customers, etc. that are dependent upon
this project/product.

3.2 Risks
Identifying Risks
This section lists risk areas and constraints that are important to this specification
and not included in the Project Plan, or Requirements Specification. If all risks are
fully documented in the Project Plan, and/or Requirements Specifications, you may
omit this section.
Risks are things that might cause the project to be delayed or to fail to meet all of its
deliverables. Do not simply list a risk; you must explain who owns it, how it is being
resolved, when it needs to be resolved by, etc.
Note: The list of risks should be brought to the project team. The team is responsible
for the following tasks.

Managing the list of risks

Tracking the risks in an issues list which is separate from this document
Reporting on the status of these risks.

3.3 Managed Issues

Identifying Managed Issues
This section describes managed issues. You must create a subsection for each
managed issue.
A managed issue is an issue to which an owner is assigned and for which there is a
plan for resolving the issue. The contents of the plan include the following
information.

Plan description.
Owner who is responsible for mitigating this issue?
Consequences if not adequately addressed.

Page8of9

Functional Specification

Date when this will become a blocking issue if left unresolved.

Status at the time of this document (see the Note in previous section.)

This section describes unmanaged issues. You must create a subsection for each
unmanaged issue.
An unmanaged issue is an issue for which there may not be an owner and there is
no plan. List any issues that are not resolved by the proposed requirements.
When writing this section, consider the following questions.

What are the unresolved issues?

When will these issues be resolved?

4 Effort
4.1 Original Estimate from SOW
4.2 Latest Estimate
4.3 Reasons for Change in Estimate/Scope

5 Sign-off
Role
DevelopmentRepresentative
DevelopmentManager
QualityAssuranceRepresentative
BusinessDevelopmentRep
DirectorofTechnology

Assigned

DateofSignoff

Page9of9