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:
You may elect to indent sections for readability.
|
Author |
|
|
Author Position |
|
|
Date |
|
Ó 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
Change Record
|
Date |
Author |
Version |
Change Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document Properties
|
Item |
Details |
|
Document Title |
Functional Specification |
|
Author |
|
|
Creation Date |
|
|
Last Updated |
|
Project Vision/Scope
Summary. 3
Functional Specification Executive
Summary. 3
Project Justification and Design
Goals. 3
Business 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
Installation/Setup Requirements
Summary. 7
Un-Installation Requirements
Summary. 7
Integration Requirements
Summary. 7
[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
·
Business
Requirements
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.}]
[Description: Provide an overview of the
project’s 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>>
[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 customer’s
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>>
[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>>
[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.
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>>
[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>>
[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>>
[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>>
[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.)
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>>
[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>>
[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>>
[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.]
[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>>
[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>>
[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.]
[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>>
[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:
The
Physical Design document contains the specific security details in a
per-feature/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>>
[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
Plan’s installation sections. The Physical Design document contains the detail
on how these requirements will be satisfied.]
<<Begin text here>>
[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>>
[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>>
[Description: The Supportability Summary
section is a summary of the supportability requirements and the project goals
related to these requirements. The Operations 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>>
[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 customer’s corporate policies or from regulatory
agencies governing the customer’s industry.]
[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>>
[Description: The References section identifies any
internal or external resources that would provide supplementary
information to the Functional Specification.]
<<Begin text here>>