The functional specification (overall system design) is a central document in classical project documentation and the contractor-side counterpart to the requirements specification. Creating a functional specification is typically the responsibility of the contractor (CN) in collaboration with the client (CL) and takes place during the project management phase of “planning.” The functional specification is the key starting document for system development. For a quick entry point, a functional specification template is available.
Functional Specification Structure
A proven, concrete structure for a functional specification, based on the V-Modell XT, looks like this:
1. Introduction
The essential 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 in an appropriate form. An initial high-level system architecture is developed and described in an interface overview. The system to be developed, as well as any additional systems that may need to be developed, are identified and mapped to the requirements. Additional logistics requirements are worked out in collaboration with the logistics manager. Acceptance criteria and the scope of delivery for the completed overall system are taken from the requirements specification and refined. To ensure that all requirements have been addressed, requirements tracing is carried out — both back to the requirements specification and forward to the individual systems.
Creating the overall system design requires knowledge from various disciplines such as systems engineering, security, ergonomics, and logistics — knowledge that typically cannot be covered by a single person. Since requirements form the core of the specification, the requirements analyst (CN) bears primary responsibility for creating the overall system design. However, they need intensive support from experts in the various disciplines for the substantive work.
For each system and segment identified in the overall system design, the corresponding deliverables — such as specifications and architecture documents — are produced. Logistics requirements are further addressed in the logistics support specification.
2. Current Situation and Objectives
This section provides a clear picture of the current situation and the reason for undertaking the project. It describes what deficiencies or problems in existing systems, or in the current situation, led to the decision to carry out the project, and what advantages are expected from deploying the new system.
All relevant stakeholders of the project are also named, and the technical and functional embedding of the system to be developed within its environment is outlined. In addition, initial framework conditions for development are identified and described. Framework conditions may include, for example, an initial rough project plan, a project manual with procedural guidelines, technical specifications, or security requirements.
3. Decomposition of the Overall System
The decomposition of the overall system identifies the central system along with any additional systems required, and specifies which logistics elements are to be created. It also names the architecture documents, implementation concepts, integration concepts, and verification concepts to be produced. The basis for this is the functional and non-functional requirements, as well as the overall system architecture sketch from the requirements specification. A work breakdown structure (WBS) helps to place everything within the project structure. Contributions provided by the client are taken into account.
The overall system architecture is reviewed for potential use of off-the-shelf products. Where appropriate, a market survey for commercial off-the-shelf products may already be conducted on the basis of the functional specification, in order to assess the influence of potential candidates on the requirements and the system architecture.
4. Interface Overview
An interface overview is created to illustrate the relationships between the system and its environment. Starting from the system, interfaces to the user, to other systems being developed within the project, to logistics, and to neighboring systems are identified and documented in an appropriate form.
The concrete description of the interfaces is provided in the specifications of the system elements and in the “logistics support specification.”
5. Lifecycle Analysis
Based on the requirements, the lifecycle 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” must 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 scenarios for the system.
Functional requirements are described, for example, in the form of use cases. A use case describes a specific, functionally self-contained sub-process. The totality of use cases defines the system behavior. A use case can be described in simple text format, though organization-specific templates for description are often available. For data-centric systems, an initial domain data model must be developed as part of the functional requirements — this serves as the basis for the later database design. The domain data model of the system is derived from the entities of the domain model.
The functional requirements are the central specifications for system development. They are incorporated into the functional specification (overall system design) and refined as needed.
7. Non-Functional Requirements
This section lists the non-functional requirements described in the requirements specification, refines them as necessary, and explains how they will be implemented.
If the requirements specification contains provisions regarding information security, data protection, or IT operations, then based on these provisions, the other requirements, the “Decomposition of the Overall System,” and the “Interface Overview,” it must be determined:
- whether a security concept needs to be developed at the level of the overall system in order to document threats and countermeasures.
- whether these provisions need to be changed or extended. Intended changes and extensions must be coordinated with the client and may result in a contract amendment.
8. Requirements Tracing to the Requirements Specification
As part of requirements tracing to the requirements specification, the mapping of functional and non-functional requirements from the requirements specification to the requirements in the functional specification is summarized. Particularly for software in safety-critical systems, bidirectional traceability must be ensured. In practice, this requires support from a project management software such as Allegra, which allows the creation of documents and the linking of topics. In straightforward cases, a matrix can be used for the presentation.
9. Requirements Tracing to the Specifications
As part of requirements tracing, the functional specification summarizes the mapping of functional and non-functional requirements to the elements of the overall system architecture (system, segment, or logistics). Particularly for software in safety-critical systems, bidirectional traceability must be ensured. A matrix can be used for the presentation.
10. Acceptance Criteria and Outgoing Inspection Procedure
Acceptance criteria define the conditions that a delivery must meet in order to be considered compliant with 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 the acceptance criteria is generally the client’s responsibility; however, the contractor should be aware of them and include them in the functional specification to have clarity about the conditions under which the system will be accepted. In some cases, it may make sense for the contractor — or both contractor and client together — to define the acceptance criteria jointly.
Before delivery, the contractor should be as confident as possible that the delivery will be accepted, and should therefore carry out an appropriate outgoing inspection. The system elements to be delivered are checked against a “system element test specification,” and the documents to be delivered (especially the “logistics support documentation”) are checked against a “test specification.” The test cases required for this are derived from the acceptance criteria, but in general cannot be completely identical to the client’s test cases — for example, because the contractor does not have access to the target platform or cannot involve the actual end users.
11. Scope of Delivery
All items (including software and documents) and services that are to be delivered during or at the conclusion of the project must be listed. Each delivery requires an acceptance inspection. 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 clear to all readers. It is therefore useful to create a glossary in which these terms are explained. When using a simple ALM system such as Allegra, a glossary can be created and maintained centrally.
Functional Specification Example
Together with the requirements specification, the functional specification forms the basis for the project scope. A project schedule helps to place the deliverables defined in the functional specification within a time frame.
Creating a functional specification is faster with a functional specification document template. The templates are available in Microsoft Word format and for Allegra Project.
Frequently Asked Questions
What is a functional specification?
A functional specification is a technical document that describes how the requirements from the requirements specification will be implemented. It contains detailed specifications, proposed solutions, and technical framework conditions for the implementation of the project.
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 describes what the client wants a product or system to achieve (what needs to be accomplished?). The functional specification defines how the contractor will technically implement those requirements (how will it be done?).
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 defines technical requirements.
Editor and Writer
Gabriella Martin is a Yale University graduate and holds a Master's degree in German Literature from the University of Tübingen. She loves explaining complex things in simple terms.
