<<Project Name>>

Functional Specification
Customer Name
Directions for using template:
Read the Guidance (Arial blue font in brackets) to understand the information that
should be placed in each section of this template. Then delete the Guidance and
replace the placeholder within <<Begin text here>> with your response. There may be
additional Guidance in the Appendix of some documents, which should also be
deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be
differentiated by font type and size:
Heading 1 Arial Bold 16 font
Heading 2 Arial Bold Italic 14 font
Heading 3 Arial Bold 13 font
Heading 3 Arial Bold Italic 12 font
You may elect to indent sections for readability.

Author
Author Position
Date

Version: 1.0

07/12/2016

2002 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not
be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR
IMPLIED, IN THIS DOCUMENT.
Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or
other countries.

07/12/2016

Revision & Sign-off Sheet

Change Record
Date
Author

Reviewers
Name

Distribution
Name

Version

Version Approved

Change Reference

Position

Position

Document Properties
Item
Details
Document Title Functional Specification
Author
Creation Date
Last Updated

07/12/2016

Date

Table of Contents
Project Vision/Scope Summary......................................................................................3
Project History................................................................................................................3
Functional Specification Executive Summary...............................................................3
Project Justification and Design Goals...........................................................................3
Business Requirements Summary..............................................................................4
User Requirements Summary.....................................................................................4
System Requirements Summary.................................................................................4
Operations Requirements Summary...........................................................................4
Usage Scenarios/Use Case Studies Summary............................................................5
Feature Cuts and Unsupported Scenarios.......................................................................5
Assumptions and Dependencies.....................................................................................5
Solution Design..............................................................................................................6
Conceptual Design Summary.....................................................................................6
Logical Design Summary...........................................................................................6
Physical Design Summary..........................................................................................6
Security Strategy Summary............................................................................................7
Installation/Setup Requirements Summary....................................................................7
Un-Installation Requirements Summary........................................................................7
Integration Requirements Summary...............................................................................7
Supportability Summary.................................................................................................8
Legal Requirements Summary.......................................................................................8
Risk Summary................................................................................................................8
References......................................................................................................................8
Appendix........................................................................................................................9

07/12/2016

[Introduction to the Template

Description: The Functional Specification is the repository for the set of deep,
technical drill-down documents that detail every element of the solution deliverables,
explaining in exact and specific terms what the team is building and deploying. The
Functional Specification is the final technical document against which every
development team member will build. The Functional Specification is built upon the
foundation of 8 separate documents, which are summarized in the Functional
Specification. You may choose to provide customers with all 9 documents (4
requirements document, 1 Usage Scenarios document, 3 design documents, plus the
parent Functional Specification document), or you may simply choose to combine the
requirements documents, usage scenarios, and design documents into a single
Functional Specification with sub-topics. The eight foundational documents are

Usage Scenarios
User Requirements
Business Requirements
Operations Requirements
System Requirements
Conceptual Design
Logical Design
Physical Design

Justification: The Functional Specification is in essence a contract between the

customer and the team, describing from a technical view what the customer expects.
The quality of the Functional Specification (completeness and correctness) has a
significant impact on the quality of the development activities and all follow on
phases.
{Team Role Primary: Program Management is responsible for ensuring that the
Functional Specification is completed by its estimated completion date. Program
Management must also ensure that the design elements of the Functional
Specification are consistent with the Vision/Scope document and all relevant plans
from the Master Project Plan and Operational Plan. Development will have the
primary responsibility for creating the content of the design documents within the
Functional Specification. Release Management will participate with Development
both in content creation and review to ensure operational, deployment, migration,
interoperability and support needs are addressed within the designs.
Team Role Secondary: Product Management will review and understand the
design documents within the Functional Specification in order to convey solution
design to parties external to the team and to ensure that product features are
represented in the design according to initial project sponsor requirements. Test will
review the Functional Specification to ensure test plans are in place to validate the
designs. User Experience must review the design documents to ensure user
requirements are met.}]

07/12/2016

Project Vision/Scope Summary

[Description: Provide an overview of the projects vision and scope. This should
include a summary of the business opportunity, solution concept, and scope sections
of the Vision/Scope document.
Justification: This information provides essential context for the reader. The
vision/scope information is the strategic statement of the solution, which must be
understood before the reader approaches the Functional Specification details. By
including this information, both internal and external project members share a
common understanding of the project, thus setting a common set of expectations.]

<<Begin text here>>

Project History
[Description: The Project History section describes the important events and
decisions that have been made to date to deliver the project to this point. This history
may be associated with the process of understanding the customers circumstances
and business needs or any prior attempts at delivering a similar solution. If this is the
first implementation, this section may be omitted.
Justification: All team members (internal and external) should share the same
understanding of the project, and this historical information ensures that this can
occur. Providing this information will close any gaps or discrepancies in the teams
historical knowledge base.]

<<Begin text here>>

Functional Specification Executive Summary

[Description: The Functional Specification Executive Summary section provides a
strategic statement of the contents of the Functional Specification. It should identify
which foundational documents (requirements, usage scenarios, designs) comprise
the Functional Specification and provide a brief statement about the content of each.
Justification: This information provides the reader a guideline of the structure of this
document and the strategic context for reading its detail.]

<<Begin text here>>

Project Justification and Design Goals

[Description: The Project Justification and Design Goals section summarizes the
requirements documents by stating their contents in terms of business, user, and
technical needs. These needs justify the project. This section should also convert
those needs into a statement of the solution design goals that guided the
development of the design documents.

07/12/2016

Justification: This information provides an understanding of the requirements

analysis that was completed and further clarification of project goals in addition to
those already summarized in the Vision/Scope section above.]

<<Begin text here>>

Business Requirements Summary

[Description: The Business Requirements section provides a summary of the
contents of the Business Requirements document. This should include a succinct
statement of the contents of each of the key sections of the requirements document
(Cost Benefit Analysis, Scalability, etc.)
For some projects, it may be appropriate to include the entire contents of the
business requirements, if a choice has been made to consolidate all technical
documentation into one large central document.]

<<Begin text here>>

User Requirements Summary

[Description: The User Requirements Summary section provides a summary of the
contents of the User Requirements document. This should include a succinct
statement of the contents of each of the key sections of the requirements document
(User Experience, Reliability, Accessibility, etc.)
For some projects, it may be appropriate to include the entire contents of the user
requirements, if a choice has been made to consolidate all technical documentation
into one large central document.]

<<Begin text here>>

System Requirements Summary

[Description: The System Requirements Summary section provides a summary of
the contents of the System Requirements document. This should include a succinct
statement of the contents of each of the key sections of the requirements document
(Systems and Services Dependencies, Interoperability, etc.)
For some projects, it may be appropriate to include the entire contents of the system
requirements, if a choice has been made to consolidate all technical documentation
into one large central document.]

<<Begin text here>>

Operations Requirements Summary

[Description The Operations Requirements Summary section provides a summary
of the contents of the Business Requirements document. This should include a
succinct statement of the contents of each of the key sections of the requirements
document (Security, Manageability, Supportability, etc.)

07/12/2016

For some projects, it may be appropriate to include the entire contents of the
operations requirements, if a choice has been made to consolidate all technical
documentation into one large central document.]

<<Begin text here>>

Usage Scenarios/Use Case Studies Summary

[Description: The Usage Scenarios/Use Case Studies Summary section provides a
summary of the contents of the Usage Scenarios document. This should include a
succinct statement of the contents of each of the key use case sections of the
document.
For some projects, it may be appropriate to include the entire contents of the usage
scenarios, if a choice has been made to consolidate all technical documentation into
one large central document.]

<<Begin text here>>

Feature Cuts and Unsupported Scenarios

[Description: The Feature Cuts and Unsupported Scenarios section identifies the
requirements that will not be met by this project or release. This should include the
identification of any requirement (business, user, system, operational, usage
scenario) that cannot be met and an explanation of why it cannot be met. This
section may also identify future solution releases that will satisfy these requirements.
Justification: Just as it is important to provide detailed descriptions of what the
project will deliver, it is equally important to describe features and scenarios that are
being omitted from the project scope. This will further clarify the current project
emphasis and deliverables and prevent possible misunderstanding or confusion.]

<<Begin text here>>

Assumptions and Dependencies

[Description: The Assumptions and Dependencies section lists and defines the
project-oriented assumptions and dependencies (as opposed to feature
dependencies or environmental dependencies) that have been identified through the
process of developing the Functional Specification. An example of a dependency is
this: a delivery may require advanced skills in various product technologies or
business processes.
List assumptions and dependencies separately.
Justification: Assumptions should be identified where actual data does not exist and
will identify the actions required to verify those assumptions. Dependencies will
identify any actions that must be taken to ensure those dependencies are
incorporated into the project plans.]

<<Begin text here>>

07/12/2016

Solution Design
[Description: The Solution Design section identifies the design documents that have
been developed and summarizes the overall solution design in a succinct statement.
It should also define why each of these design documents is necessary for the
project.
Justification: This information provides the reader with strategic context for the
follow on reading. It explains the differences between the design documents and
explains how each provides a unique picture of the solution.]

<<Begin text here>>

Conceptual Design Summary

[Description The Conceptual Design Summary section provides a summary of the
contents of the Conceptual Design document. This should include a succinct
statement of the contents of each of the key sections of the document (Solution
Overview and Solution Architecture, etc.).
For some projects, it may be appropriate to include the entire contents of the design
document, if a choice has been made to consolidate all technical documentation into
one large central document.]

<<Begin text here>>

Logical Design Summary

[Description: The Logical Design Summary section provides a summary of the
contents of the Logical Design document. This should include a succinct statement of
the contents of each of the key sections of the document (Users, Objects, Attributes,
etc.)
For some projects, it may be appropriate to include the entire contents of the design
document, if a choice has been made to consolidate all technical documentation into
a large central document.]

<<Begin text here>>

Physical Design Summary

[Description The Physical Design Summary section provides a summary of the
contents of the Physical Design document. This should include a succinct statement
of the contents of each of the key sections of the document (Application,
Infrastructure, etc.)
For some projects, it may be appropriate to include the entire contents of the design
document, if a choice has been made to consolidate all technical documentation into
one large central document.]

<<Begin text here>>

07/12/2016

Security Strategy Summary

[Description: The Security Strategy Summary section describes the solution security
strategy that will influence the design. The following questions will assist in
developing this strategy:

What are the principal objectives to providing a secure environment?

What compromises in security are necessary for user convenience, usability,
and performance?
What specific security tools and technologies will be implemented within the
solution?

The Physical Design document contains the specific security details in a perfeature/per-component format. This strategy section should be a brief synopsis of a
uniform security strategy, along with references to the Security Plan.]

<<Begin text here>>

Installation/Setup Requirements Summary

[Description: The Installation/Setup Requirements Summary section is a summary
of the environmental requirements for solution installation. This information may be
derived from the Deployment Plans installation sections. The Physical Design
document contains the detail on how these requirements will be satisfied.]

<<Begin text here>>

Un-Installation Requirements Summary

[Description: The Un-Installation Requirements Summary section describes how the
solution is removed from its environment. This should include a definition of what
must be considered prior to removing the solution and what must be considered in a
backup/restore capacity prior to un-installing to insure safe recovery/rebuild at a later
time.]

<<Begin text here>>

Integration Requirements Summary

[Description: The Integration Requirements Summary section is a summary of
integration and interoperability requirements and the project goals related to these
requirements. The Migration Plan may be referenced or summarized here, as it
contains integration and interoperability specifications. The Physical Design
document contains the detail on how integration will be delivered.]

<<Begin text here>>

Supportability Summary
[Description: The Supportability Summary section is a summary of the supportability
requirements and the project goals related to these requirements. The Operations

07/12/2016

Plan and Support Plan may be referenced or summarized here, as they contain
supportability specifications. The Physical Design document contains the detail on
how supportability will be delivered.]

<<Begin text here>>

Legal Requirements Summary

[Description: The Legal Requirements Summary section is a summary of any legal
requirements to which the project must adhere. Legal requirements may come from
the customers corporate policies or from regulatory agencies governing the
customers industry.]

<<Begin text here>>

Risk Summary
[Description: The Risk Summary section identifies and describes the risks
associated with the Functional Specification. This should include all risks that may
impact development and delivery of the solution where the risk source is the content
of the Functional Specification. The list of risks should be accompanied by the
calculated exposure for each risk. If appropriate, this section may also contain a
summary of the mitigation plans for those risks.]

<<Begin text here>>

References
[Description: The References section identifies any internal or external resources
that would provide supplementary information to the Functional Specification.]

<<Begin text here>>

07/12/2016

Appendix

07/12/2016