The requirements specification is the central implementation document in IT and software projects. It describes the realisation specifications drawn up by the contractor on the basis of the specifications. While the requirements specification answers the questions "What?" and "What for?", the functional specification clarifies the decisive follow-up questions: "How will it be implemented?" and "With what?" - i.e. which technologies, architectures and processes the service provider wants to use to fulfil the client's requirements in concrete terms.
The relevant definition is provided by the standard DIN 69901-5 (project management - terms). According to this standard, the requirements specification comprises the "realisation specifications drawn up by the contractor based on the implementation of the specifications provided by the client". This definition clearly assigns the requirements specification to the contractor side - and thus clearly distinguishes it from the requirements specification created by the client.Specification of requirements vs. specification sheet: the distribution of roles
The most common conceptual error in projects is probably the confusion between functional specifications and requirement specifications. Both documents build on each other, but have different authors and different functions. If you don't master the distinction, you risk misunderstandings about responsibilities and the scope of services.
You can imagine the relationship as a question and answer: The client sets out its requirements in the specifications ("The shop must be connected to our ERP"), and the contractor responds in the specifications with the specific solution ("The ERP connection is made via a REST API with synchronisation every 15 minutes via a middleware component"). It is precisely this one-to-one relationship - every requirement receives a documented realisation response - that makes the requirements specification a binding part of the contract.
What belongs in a functional specification? Structure and typical contentA good functional specification is precise, technically specific and fully traceable to the requirements specification. Ideally, every requirement in the requirements specification can be found in the functional specification - including a statement on how it will be implemented or why it will be omitted (in coordination). The following rough structure has proven itself:
Typical structure of a functional specification
| Section | Content |
|---|---|
| 1. target definition | Reference to the specifications, project goals from an implementation perspective |
| 2. product deployment & environment | Target systems, platforms, operating environment |
| 3. functional specification | Concrete implementation of each functional requirement |
| 4. non-functional specification | How performance, security, availability are achieved |
| 5. technical architecture | System structure, components, interfaces, data model |
| 6. test & acceptance concept | How and against what is tested and accepted |
| 7. delivery & project plan | Milestones, phases, responsibilities |
The decisive difference to the requirements specification lies in the level of detail: where the requirements specification deliberately remains solution-neutral, the functional specification is as specific as possible. It specifies frameworks, databases, interface protocols, security measures and architectural decisions - in other words, precisely those technical specifications that the client has deliberately left to the service provider.
Traceability: the centrepiece of the requirements specificationA professional requirements specification ensures traceability - the seamless traceability of every realisation specification to the corresponding requirement in the requirements specification. In practice, reference numbering is often used for this purpose: requirement "L-4.2" in the requirements specification corresponds to specification "P-4.2" in the functional specification. This makes it possible to objectively check at the end of the project whether every promised requirement has actually been implemented - the basis for a clean acceptance and effective protection against disputes about the scope of services.Real-life example: functional specification for a Shopware migrationLet's take the example of a B2B wholesaler that is migrating its online shop from Shopware 5 to Shopware 6. As the contractor, the commissioned digital agency draws up the specifications and answers each requirement with a concrete technical specification:
Each of these points is a concrete response to a requirement from the specification. The client can check and approve the specifications - and thus has a binding document against which performance is measured at the end of the project. This is precisely where the protection for both sides lies.
Why the requirements specification protects the client and contractorThe functional specification is far more than just a compulsory technical exercise. It is the document that turns a vague requirement into a reliable, calculable and enforceable performance promise. Its most important functions:
- Binding service definition: The specifications define what the contractor will deliver in concrete terms - the basis for a fixed price and acceptance.
- Protection against scope creep: What is not in the specifications is not commissioned and is treated separately as a change request.
- Risk minimisation: Technical decisions are thought through and approved before implementation begins, not just during the project.
- Acceptance basis: The test and acceptance concept in the requirements specification makes the success of the project objectively measurable.
In agile projects, the classic requirements specification is often replaced by technical specifications, definition of done and elaborated user stories with acceptance criteria. However, the basic idea remains the same: the contractor must document how it technically fulfils the requirements before and during implementation. Further information on the normative background can be found in the entry Requirements specification on Wikipedia.
Normative background: DIN 69901 and VDI 2519
Like the requirements specification, the functional specification is also standardised in German-speaking countries. The DIN 69901-5 provides the definition commonly used today, which identifies the functional specification as the contractor's realisation response. The guideline VDI/VDE 2519 Sheet 1 has described the structure of both booklets over the years and thus established a practical template for industrial and software projects. Both sources emphasise the sequence: the client's specifications are created first, followed by the contractor's requirements specification.
Historically, the pair of terms originated in German mechanical and plant engineering and migrated from there to software development. In an international context, the functional specification most closely corresponds to the Functional Specification or the Technical Design Document. Caution is advised when using the collective term specification: Depending on the project, it can sometimes mean the requirements specification, sometimes the functional specification. In the case of international collaboration, it should therefore be explicitly clarified which document is created and released by whom.How the requirements specification becomes a functional specificationThe requirements specification is created in a clearly defined step of the project chain. The typical process shows where it should be categorised:
- Check specifications: The contractor analyses the requirements and clarifies open questions with the client.
- Develop solution concept: A technical implementation is designed for each requirement.
- Write requirements specification: The realisation specifications are documented, each referenced to the requirements specification requirement.
- Effort & quotation: The contractor calculates the effort, price and schedule based on the requirements specification.
- Approval: The client checks and approves the requirements specification - it becomes a binding part of the contract.
- Implementation & acceptance: Realisation against the requirements specification, acceptance against the test concept defined therein.
It is important that the requirements specification is not created in secret. The best specifications are the result of queries, workshops and coordination with the client - because this is the only way to resolve the inevitable gaps and ambiguities in the specifications before they become expensive to implement.
Frequent errors in the requirements specification
There are also recurring pitfalls in the requirements specification that undermine its value:
- Mere copying of the requirements specification: A requirements specification that merely repeats the requirements without describing the specific implementation is worthless.
- Lack of traceability: Without clear referencing to the requirements specification, it is impossible to check later whether all requirements have been covered.
- Too vague: Vague formulations such as "performant" or "user-friendly" without measurable values lead to disputes during acceptance.
- No approval by the client: A specification that has not been approved has no contractual protective effect.
Specification of requirements in practice: What SMEs should look out for
Even if the specifications are the responsibility of the contractor, the client should never just nod them off. It is the document by which they measure the success of the project - and carefully reviewing it is one of the most important tasks in the initial phase. Practical tips for SMEs:
- Check completeness: Is every requirement from the specification sheet reflected in the functional specification? Identify gaps now, not during acceptance.
- Require measurability: Insist on concrete values instead of empty phrases - "loading time under 1.5 seconds" instead of "fast".
- Check assumptions: Where the contractor has interpreted requirements, this should be documented and confirmed.
- Understand the acceptance concept: Clarify early on how and against what testing and acceptance will ultimately take place.
- Determine the change process: Agree how subsequent change requests will be handled and priced.
A carefully created and jointly approved specification is the best insurance against what most often causes projects to fail: differing ideas about what should actually be delivered. It costs time at the start of the project - and saves it many times over the entire duration.
FAQ on the requirements specification
Who writes the requirements specification?
The requirements specification is created by the contractor - i.e. the service provider or agency providing the service. It is their technical response to the client's specifications.
The requirements specification describes the what and what for from the client's perspective (solution-neutral). The requirements specification describes the how and what from the contractor's perspective (concrete realisation).
Does the client have to approve the requirements specification?
Yes, this is strongly recommended. Only when it is approved does the specifications become a binding basis for realisation and acceptance. Formal acceptance protects both sides.
Do you still need a functional specification in an agile project?
In an agile environment, technical specifications, a definition of done and acceptance criteria often take the place of the classic functional specification. The core idea - the contractor documents the implementation - remains the same.
Ideally, the contractor clarifies any ambiguities before the functional specification is created. Any remaining deviations must be explicitly documented and approved by the client so that no disputes about the scope of services arise later.