Process 2: Write the Functional Specification

In this process, the project team documents the project requirements, creates the design documents, and writes the functional specification.

Figure 4. Write the functional specification

Activities: Write the Functional Specification

At the beginning of this process, the project team analyzes and creates the requirements documents. There are four categories of requirements:

• Business requirements
• User requirements
• Operational requirements
• System requirements (requirements of the solution).

As team members design the solution and create the functional specifications, they must maintain traceability between requirements and features. Maintaining traceability serves as a way to check the correctness of the design and to verify that the design meets the solution’s goals and requirements. The usual method of maintaining traceability is to tag items in the functional specification with requirement IDs.

The design process gives the team a systematic way to work from abstract concepts to specific technical details. This begins with an analysis of user profiles, or personas. The team refines these personas into a series of use scenarios. Finally, the team refines each use scenario into use cases. This process is called story-boarding and results in the use scenarios document.

The team then uses the requirements documents, the use scenarios document, and the product and technology evaluations from the previous process to develop a functional specification that it submits to its customer and stakeholders for review. This is a detailed description, from the user’s and customer’s perspectives, of what the solution will look like and how it will behave. The functional specification serves multiple purposes, including:

• Instructions to developers on what to build.
• A basis for estimating work.
• Agreement with the customer on exactly what will be built.
• A point of synchronization for the whole team.

The functional specification is also the basis for building the master project plan and master project schedule. After the customer and stakeholders accept the functional specification, the team baselines (places under change control) it and begins to formally track changes to it. After the functional specification is reviewed and a baseline made, the team can only change it with customer approval.

The project team also creates the design documents that record the results of the design process. These documents are separate from the functional specification and are focused on describing the internal workings of the solution. The project team can keep them internal and change them without burdening the customer with technical issues. The design process has three levels—conceptual design (owned by Product Management), logical design (owned by Program Management), and physical design (owned by Development)—so the team produces the following three design documents:

• Conceptual design document
• Logical design document
• Physical design document

The team completes and baselines each level in a staggered sequence.

The following table lists the activities involved in this process. These activities include:

• Documenting the project requirements.
• Writing the functional specification.

Table 5. Activities and Considerations for Writing the Functional Specification

Activities

Considerations

Document the project requirements

Key questions:

• Does the organization have specific business requirements for the solution?
• Does the organization have return on investment (ROI) requirements for the solution?
• Does the organization have scalability, availability, performance, or security requirements for the solution? See the Policy SMF for more information.
• Do users have specific ease-of-use, reliability, performance, accessibility, language, or training requirements for the solution? See the Reliability SMF for more information.
• Does the solution have specific system and service dependencies? See the service map section of the Business/IT Alignment SMF for more information.
• Does the solution have interoperability requirements?
• Will the solution affect the network?
• Does Operations have scalability, security, manageability, supportability, availability, reliability, staffing, or training requirements for the solution?
• Does User Experience understand how users will interact with the solution? Can they document these interactions as user scenarios and use cases?

Inputs:

• Vision/scope document
• Policies
• Reliability requirements

Outputs:

• Usage scenarios document
• Requirements documents, including:
  • Business requirements
  • Operations requirements.
  • System requirements.
  • User requirements.

Write the functional specification

Key questions:

• Has the project team cut any features from the vision/scope document?
• What assumptions is the team making about the solution, the team’s customers, and the solution’s users?
• What dependencies does the solution have on other services, technologies, and people within the organization?
• Does the project team have a strategy for addressing security?
• Does the solution have specific installation and un-installation requirements?
• Does the solution have specific integration requirements?
• Is the solution’s business situation understood by the project team?
• Is the solution’s high-level architecture understood by the project team?
• Are all of the solution’s components understood by the project team, including how they behave and how they relate to other components?
• Does the solution have naming standards it must follow?
• Does the solution have rules it must follow for sizing and placing servers?
• Does the organization have an administration model that the solution must use?
• Does the organization have security guidelines that the solution must follow?
• Does the solution include any of the following infrastructure components: intranet communication, Internet communication, extranet communication, authentication, addressing, name resolution, remote access?

Inputs:

• Vision/scope document
• Requirements documents, including:
  • Business requirements.
  • Operations requirements.
  • System requirements.
  • User requirements.
• Product and technology evaluations

Outputs:

• Design documents, including:
  • Conceptual design.
  • Logical design.
  • Physical design.
• Functional specification

Best practices:

• Avoid scope creep. Use the vision/scope document and specifications to maintain focus on the stated business goals and to trace critical features back to the original requirements. Apply the vision statement and specifications as filters to identify, discuss, and remove additional features that may have been added without proper consideration after the project has been defined.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download Get the Microsoft Operations Framework 4.0

Solution Accelerators Notifications Sign up to learn about updates and new releases

Feedback Send us your comments or suggestions