Functional Specification: Tips and Templates!

The functional specification (also known as a system design specification, or in German: Pflichtenheft) is a central document in traditional project documentation and the contractor’s counterpart to the requirements specification (Lastenheft). Writing a functional specification is typically the responsibility of the contractor in collaboration with the client and takes place during the project management phase “Planning.” The functional specification is the central starting document for system development. For a quick start, there is a functional specification template.

Functional Specification Structure

A proven, concrete structure for a functional specification, based on the V-Model XT, looks like this:

1. Introduction

The key contents of the functional specification are the functional and non-functional requirements for the overall system to be developed. The requirements are taken from the requirements specification and prepared appropriately. An initial high-level architecture of the system is developed and described in an interface overview. The system to be developed, along with any additional systems that may need to be developed, are identified and mapped to the requirements. Additional logistics requirements are developed in collaboration with the logistics manager. Acceptance criteria and scope of delivery for the finished overall system are taken from the requirements specification and refined. To ensure all requirements are accounted for, requirements traceability is performed — both back to the requirements specification and to the individual systems.

Creating the overall system design requires knowledge from various disciplines such as systems engineering, safety, ergonomics, and logistics, which typically cannot be covered by a single person. Since requirements form the core of the specification, the requirements analyst bears the responsible role for creating the overall system design. However, for the substantive elaboration, they need intensive support from experts in the various disciplines.

For each system and segment identified in the overall system design, the corresponding deliverables such as specifications and architecture documents are created. Logistics requirements are further pursued in the logistics support specification.

2. Current Situation and Objectives

This section clearly presents the current situation and the reason for carrying out the project. It describes what deficiencies or problems with existing systems or the current situation led to the decision to carry out the project, and what benefits are expected from deploying the new system.

Additionally, all relevant stakeholders of the project are named, and the technical and domain-specific integration of the system to be developed into its environment is outlined. Initial framework conditions for development are also identified and described. Framework conditions may include, for example, an initial rough project plan, a project manual with process guidelines, technical specifications, or safety requirements.

3. Decomposition of the Overall System

In the decomposition of the overall system, the central system along with any additionally required systems is identified, and it is determined which logistics elements need to be created. Furthermore, the architecture documents and implementation, integration, and test concepts to be produced are named. The basis for this is the functional and non-functional requirements as well as the sketch of the overall system architecture from the requirements specification. A work breakdown structure supports the integration into the project structure. Client-furnished items are taken into account.

The overall system architecture is reviewed with regard to the potential use of off-the-shelf products. Where applicable, a market survey for off-the-shelf products is already conducted based on the functional specification to assess the impact of potential candidates on the requirements and system architecture.

4. Interface Overview

To illustrate the relationships between the system and its environment, an interface overview is created. Starting from the system, interfaces to the user, to other systems to be developed within the project, to logistics, and to neighboring systems are identified and documented in a suitable form.

The concrete description of the interfaces is provided in the specifications of the system elements as well as in the logistics support specification.

5. Life Cycle Analysis

Based on the requirements, the life cycle phases to be supported (development, maintenance, and decommissioning) are determined. It is specified for which of the systems identified in the “Decomposition of the Overall System” section a logistics support concept needs to be created.

6. Functional Requirements

Functional requirements describe the capabilities of a system that a user expects in order to solve a domain-specific problem with the help of the system. The requirements are derived from the business processes to be supported and the usage workflow descriptions.

The functional requirements are described, for example, in the form of use cases. A use case describes a concrete, self-contained sub-process. The entirety of the use cases defines the system behavior. A use case can be described in simple text format, although organization-specific templates are often available. For data-centric systems, an initial domain data model needs to be developed as part of the functional requirements, which serves as the foundation for the subsequent database design. The domain data model of the system is derived from the entities of the domain model.

Functional requirements are the central specifications for system development. They are carried over into the functional specification (overall system design) and refined as needed.

7. Non-Functional Requirements

In this section, the non-functional requirements described in the requirements specification are listed, refined where applicable, and their implementation is explained.

If the requirements specification contains guidelines on information security, data protection, or IT operations, it must be determined — based on these guidelines, the remaining requirements, the “Decomposition of the Overall System,” and the “Interface Overview” — whether:

• a security concept needs to be developed at the overall system level to document threats and countermeasures.
• these guidelines need to be changed or extended. Intended changes and extensions must be coordinated with the client and may lead to a contract adjustment.

8. Requirements Traceability to the Requirements Specification

As part of requirements traceability to the requirements specification, the mapping of functional and non-functional requirements from the requirements specification to the requirements in the functional specification is presented in summary form. Especially for software in safety-critical systems, bidirectional traceability must be ensured. In practice, this requires support from project management software such as Allegra, which allows the creation of documents and linking of topics. In simple cases, the mapping can be presented using a matrix.

9. Requirements Traceability to the Specifications

As part of requirements traceability, the functional specification presents a summary mapping of functional and non-functional requirements to the elements of the overall system architecture (system, segment, or logistics). Especially for software in safety-critical systems, bidirectional traceability must be ensured. The mapping can be presented, for example, using a matrix.

10. Acceptance Criteria and Outgoing Inspection Procedures

Acceptance criteria define the conditions that a delivery must fulfill to meet the requirements. Like SMART goals, they should be measurable and structured. Acceptance criteria can relate both to individual requirements (“Under what conditions is the requirement considered fulfilled?”) and to the scope of delivery (“What conditions must be met for a specific delivery to be accepted?”). Defining acceptance criteria is typically the client’s responsibility; however, the contractor should know them and also name them in their functional specification to have clarity on the conditions under which the system will be accepted. In some cases, it may be beneficial for the contractor, or the contractor and client together, to define the acceptance criteria jointly.

The contractor should be reasonably confident before delivery that the deliverable will be accepted, and should therefore conduct an appropriate outgoing inspection. The system elements to be delivered are tested against a system element test specification, and the documents to be delivered (especially the logistics support documentation) are tested against a test specification. The necessary test cases are derived from the acceptance criteria, but generally cannot be completely identical to the client’s test cases, as the contractor may not have access to the target platform or may not be able to involve the actual users.

11. Scope of Delivery

All items (including software and documents) and services to be delivered during the project or at project completion must be listed. Each delivery requires an acceptance test. The scope of delivery may include, depending on the agreement, a system, parts of a system, documents, and services.

Glossary

Technical documents often contain terms that are not equally understandable to all users of these documents. It is therefore useful to maintain a glossary in which these terms are clarified. Using a simple ALM system like Allegra, a glossary can be created and maintained centrally.

Functional Specification Example

Creating a functional specification is faster with a functional specification document template. Templates are available in Microsoft Word format as well as for Allegra Project.

Frequently Asked Questions

What is a functional specification?

A functional specification (German: Pflichtenheft) is a technical document that describes how the requirements from the requirements specification (Lastenheft) will be implemented. It contains detailed specifications, solution approaches, and technical framework conditions for the project implementation.

Who creates the functional specification?

The functional specification is typically created by the contractor or the development team. It serves as the binding basis for the technical implementation of the client’s requirements.

What is the difference between a requirements specification and a functional specification?

The requirements specification (Lastenheft) describes the client’s requirements for a product or system (What should be achieved?). The functional specification (Pflichtenheft) defines the technical implementation of these requirements by the contractor (How will it be implemented?).

What should a functional specification contain?

A functional specification should contain a detailed description of the technical implementation, including system architecture, interfaces, functions, performance requirements, test criteria, and acceptance criteria.

Is a functional specification mandatory?

A functional specification is not always legally required, but it serves as a binding basis between client and contractor. It helps avoid misunderstandings and clearly define technical requirements.