Requirements SpecificationDefining Requirements Precisely and Steering Procurement
Procurement glossary · Updated · 8 min read
Also known as: requirements specification, specification document, requirements specification/functional specification, requirements catalogue, functional specification
Short answer
- A requirements specification is the customer's requirements document, describing what a product or service must achieve.
- It defines functions, quality, quantities, deadlines and acceptance criteria – but not the technical solution.
- The supplier responds with the functional specification, in which they describe how they will fulfil the requirements.
The requirements specification (Lastenheft) is a structured requirements document with which the customer or buyer bindingly describes their requirements for a service, product or investment. It forms the basis for tenders, bid comparisons and subsequent contracts. In industrial procurement, it ensures that suppliers and internal departments share the same understanding of scope, quality and deadlines from the outset.
Key facts
- As the customer's document, the requirements specification describes what is to be delivered – the supplier's functional specification responds with how it will be implemented.
- It reduces misunderstandings, change orders and disputes because requirements are documented in writing, verifiable and unambiguous.
- Typical contents include functional requirements, technical specifications, quality criteria, interfaces, deadlines and scope of delivery.
- In practice, the requirements specification often follows the SMART principle: requirements should be specific, measurable, agreed, realistic and time-bound.
- It is a central steering instrument in procurement RFX and accompanies the entire Source-to-Contract (S2C) process.
- Good requirements specifications are as precise as necessary and as open as possible in order to allow suppliers alternative solutions.
Contents
- Definition: requirements specification
- Methods and approach for creating a requirements specification
- Important KPIs and inspection criteria for the requirements specification
- Risks and controls when handling requirements specifications
- Current developments: digitalised and agile requirements documents
- Typical metrics
- Practical example
- Conclusion
- Frequently asked questions
Definition: requirements specification
The requirements specification is the detailed description of the requirements for the product, service or project to be procured, created by the requisitioner or customer. It does not use concrete specifications regarding the solution, but rather defines the objective and the framework conditions. The contractor's response to this is the functional specification, in which they set out how they intend to fulfil the requirements.
Distinction from the functional specification
While the requirements specification reflects the perspective of the user department and procurement, the functional specification is the supplier's technical implementation statement. In practice, procurement checks in a reconciliation of both documents whether all requirements have been fully addressed. This target/actual comparison format makes it possible to identify gaps at an early stage and to clarify them specifically in the supplier meeting. Only once the requirements specification and functional specification are in agreement should the procurement move into the contract phase.
Legal and contractual significance
The requirements specification is not legally standardised, but it regularly forms part of the contract and the basis for acceptance. The more precisely it is formulated, the more clearly it can be assessed in a dispute whether a service was provided in accordance with the contract. Buyers should therefore anchor clear acceptance criteria, warranty provisions and documentation obligations. Whether individual formulations prevail over general terms and conditions must be examined legally on a case-by-case basis.
Typical components
An industrial requirements specification typically contains functional and technical requirements, quantities and bills of materials, quality requirements including inspection planning, interface descriptions, deadline and milestone specifications as well as commercial framework conditions. Frequently added are requirements on documentation, training, spare parts availability and evidence. For suppliers with high cyber risk at the supplier, requirements on IT security and data protection are added.
Methods and approach for creating a requirements specification
A usable requirements specification rarely emerges from a single department. In practice, an interdisciplinary approach has proven successful, in which user departments, engineering, quality, logistics and procurement jointly capture requirements, prioritise them and convert them into a uniform format.
Requirements capture and prioritisation
At the outset is the systematic capture of requirements from production, design, quality assurance and, where applicable, end-customer requirements. Each requirement is given an identifier, a source and a priority, for example as a must, should or could criterion. This allows offers to be compared in a structured manner later and deviations to be documented. The degree of standardisation of the requirement indicates whether a scope of services can be represented via a catalogue or whether an individual specification is necessary.
Integration into the procurement process
The finished requirements specification is the centrepiece of every enquiry and thus of procurement RFX. It flows into the tender, steers bid evaluation and serves as a reference for contract negotiations. Within the Source-to-Contract (S2C) chain, it forms the transition from demand clarification to market approach along the sourcing pipeline. A cleanly maintained requirements specification with versioning and release via an approval workflow in procurement ensures that only reviewed versions go to suppliers.
Coordination with suppliers
Before placing the order, it is advisable to discuss the requirements specification in a supplier meeting in order to clarify ambiguities, feasibility questions and alternative proposals. Many suppliers propose sensible technical or cost-related changes, which the customer can review and, if necessary, incorporate into the requirements specification as a change request. A transparent change history prevents later disputes about the agreed status.
Important KPIs and inspection criteria for the requirements specification
Whether a requirements specification is qualitatively fit for purpose can be measured – for example via the completeness of the requirements, the number of subsequent changes or delivery performance against the agreed criteria. These key figures help to continuously improve the creation process.
Quality of the requirements documentation
A common practical benchmark is that far more than 90 per cent of all requirements in the requirements specification are formulated measurably and are unambiguously verifiable. The key figure can be determined by spot checks per document. In addition, it counts whether each requirement has a clear source and priority. Unclear requirements should be discarded or sharpened by procurement before the tender, as they typically trigger renegotiations and change orders later.
Rate of deviations and change orders
The central impact key figure is the number of change requests or change orders after the order is placed that can be attributed to unclear or missing requirements in the requirements specification. In well-structured organisations, this share is typically in the low single-digit percentage range of all orders. Equally proven is the target/actual comparison between requirements specification, functional specification and the realised service at acceptance. Those who systematically analyse the causes of change orders sustainably improve the template for future tenders.
Deadline and quality compliance with the requirements specification
The fulfilment of the requirements specification is reflected in the classic delivery key figures, such as delivery reliability and the defect rate at incoming inspection. For series parts, the series release process supplements the requirements specification with binding release criteria including statistical process control (SPC). If process capability falls below the agreed values, the requirements specification shows which specifications were originally agreed – an important basis for escalations and supplier rating.
Risks and controls when handling requirements specifications
The requirements specification only unfolds its value if it is up to date, complete and binding. Typical risks arise from outdated documents, unclear responsibilities and a lack of coordination between engineering and procurement.
Typical sources of error
Common errors include contradictory requirements, missing acceptance criteria, unnecessarily narrow specifications instead of functional descriptions and incomplete interface information. Copying old requirements specifications without adapting them to current requirements also regularly leads to incorrect procurement. Such errors have an impact along the entire supply chain – from incorrect delivery concepts to missing safety capacity for critical components.
Controls and release process
A multi-stage release process has proven its worth: the specialist department drafts, procurement checks for completeness and procurability, quality adds inspection and release criteria. A four-eyes release before sending to suppliers significantly reduces correction loops. For critical upstream products, the requirements specification should also contain requirements on supplier management, for example on audit rights, evidence obligations and reporting intervals.
Risks in long-term supply relationships
With multi-year framework agreements, a frozen requirements specification can run ahead of reality if standards, technologies or legal situations change. Buyers should therefore provide for revision clauses and regularly reconcile the requirements specification against the current order history and actual requirements. In outsourcing transition projects, it is particularly important that requirements, knowledge documentation and handover criteria are fully captured in the requirements specification so that the transition to external partners succeeds without loss of quality.
Current developments: digitalised and agile requirements documents
Requirements specifications are increasingly moving from static text documents to structured, digital formats. Increasingly, requirement lists are maintained as machine-readable data objects that can be automatically transferred into ERP and e-procurement systems.
Digital templates and system support
Modern procurement systems link requirements specification content with article data, material master records and Material Requirements Planning (MRP) logic, so that demand notifications can draw directly on defined requirements. Automatic account assignment in the subsequent purchase order simplifies allocation to projects and cost centres, provided the requirements specification contains the relevant details. Standardised data structures also facilitate the comparison of offers and subsequent contract monitoring.
Agile and iterative approaches
Agile procurement increasingly uses leaner, iteratively maintained requirements documents instead of one-off, extensive requirements specifications. For development contracts with a high degree of uncertainty, a hybrid approach has proven successful: a stable framework in the requirements specification plus iteratively supplemented backlogs for individual requirements. This maintains binding force while still allowing freedom for technical further development.
Sustainability, resilience and compliance
In practice, requirements on sustainability, supply chain reliability and information security are increasingly moving into the requirements specification. Buyers formulate measurable requirements, for example on material origins, energy consumption, recyclability and IT security standards. This makes the requirements specification an instrument for actively managing reputational risk in procurement – documented requirements demonstrably provide an important mitigating argument in audits and customer surveys.
Typical metrics
| Metric | Benchmark | Context |
|---|---|---|
| Proportion of measurable requirements | > 90 % | Proportion of unambiguously verifiable requirements in the requirements specification; common practical benchmark |
| Rate of change orders due to gaps in the requirements specification | < 5 % of orders | Proportion of orders with change orders resulting from unclear requirements |
| Deadline and delivery reliability in accordance with the requirements specificat | > 95 % | Fulfilment of the documented deadline and quantity requirements |
| Deviations in the target/actual comparison | 0 significant deviations | Target value at acceptance; deviations must be documented and approved |
Typical practical benchmarks – they vary by industry, part and contract.
Practical example
A medium-sized mechanical engineering company commissioned the new procurement of a machining cell for a new production line. A previous similar project had caused considerable change orders because acceptance criteria and interfaces had remained unclear. This time, a team from design, production, quality and procurement created a structured requirements specification with prioritised requirements, defined inspection procedures and clear milestones.
- All requirements were given an identifier, source and priority (must/should/could).
- Acceptance criteria with measurable tolerances and test methods were established before the tender.
- The requirements specification was included as an annex to the RFQ tender and the subsequent contract.
- After the order was placed, a target/actual comparison was carried out between the requirements specification, functional specification and the delivered item; change orders fell to almost zero.
Conclusion
The requirements specification is more than a form – it is the central steering instrument with which buyers bindingly define demand, quality and responsibilities. A cleanly formulated document reduces change orders, speeds up bid comparisons and creates a clear basis for acceptance and warranty. Prerequisites are interdisciplinary collaboration, consistent versioning and an orderly release process. Those who maintain requirements specifications digitally and reconcile them regularly against actual demand sustainably reduce procurement risks. This makes the requirements specification one of the fundamental tools of every professional procurement organisation.
Frequently asked questions
What is a requirements specification in simple terms?
A requirements specification (Lastenheft) is a document in which the customer describes what they wish to procure – i.e. which functions, qualities, quantities and deadlines they expect. It describes the objective, not the solution. The supplier responds with a functional specification (Pflichtenheft) explaining how they intend to implement the requirements.
What is the difference between a requirements specification and a functional specification?
The requirements specification comes from the customer and defines the requirements for the service. The functional specification comes from the supplier and describes how they will fulfil these requirements technically and organisationally. Both documents are used in a reconciliation to identify gaps and deviations at an early stage and to make them binding in the contract.
What belongs in a requirements specification?
Typical contents include functional and technical requirements, quantities, quality and inspection criteria, interfaces, deadlines, documentation obligations, acceptance and warranty provisions as well as commercial framework conditions. Depending on the project, requirements on IT security, sustainability or spare parts availability may be added. It is important that every requirement is formulated in an unambiguous, measurable and prioritised manner.
Who creates the requirements specification?
Formally, the customer or user department is responsible; in practice, it is created interdisciplinarily by the specialist department, engineering, quality and procurement. Procurement checks it for completeness, procurability and usability for tenders and contracts. It should only be sent to suppliers after a defined release has been granted.
Does a requirements specification always have to be created?
As a rule, there is no statutory obligation, except in certain public procurement procedures where binding requirements must be documented. For simple, standardised requirements, a brief specification or a catalogue extract may suffice. For complex capital investments, development and service contracts, however, a full requirements specification is indispensable in practice in order to manage risks.
How should requirements be formulated correctly in a requirements specification?
Requirements should be specific, measurable, agreed, realistic and time-bound – often summarised under the SMART principle. Instead of vague formulations such as 'high quality'
