<<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:

You may elect to indent sections for readability.

 

 

 

Author

 

Author Position

 

Date

 

 

 

 

 

Version: 1.0

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

 


 

Revision & Sign-off Sheet

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

 

 



 

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

 


 

[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.}]


 

Project Vision/Scope Summary

[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>>

 

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 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>>

 

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. 

 

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.)

 

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>>

 

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>>

 

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:

 

 

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>>

 

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 Planís 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 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 customerís corporate policies or from regulatory agencies governing the customerís 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>>

 


 

Appendix