Business Analysis
Lastenheft or Pflichtenheft? What to set out as the client before you procure
If you want to compare offers and decide with confidence, you first have to clarify your own needs. What belongs in which document, and how the terms are used in Switzerland.
You are about to procure something: new software, a system, a service. Before requesting offers, you need to set out what you require. In Germany this document is called a Lastenheft, in German-speaking Switzerland often a Pflichtenheft; the English edition of HERMES, the federal project management method, simply calls it the “specifications”. In most cases they all mean the same thing: your requirements as the client.
A good requirements document achieves three things: clarity before you procure, offers that can be compared, and a decision you can still justify later. This article shows which document serves which purpose, how the terms are used in Switzerland and what belongs in your document.
Key points
- Your requirements document describes what you need and why. Under the German standard it is called a Lastenheft; in public procurement in German-speaking Switzerland it is usually called a Pflichtenheft.
- Suppliers respond with an offer; in public procurement this is a tender. An offer is not automatically a Pflichtenheft as defined in the standard.
- Responsibility for defining your needs lies with you. You can draw up the document with support.
Five documents that are often confused
The German standard DIN 69901-5 distinguishes the client's Lastenheft (requirements specification) from the contractor's Pflichtenheft (implementation specification). In requirements engineering, the term Pflichtenheft is sometimes used differently: the German edition of the glossary of the International Requirements Engineering Board (IREB) also uses it for system and software requirements specifications, without assigning it across the board to the supplier. Here too, it pays to clarify which document is meant. In practice, further documents come into play.
| Document | Who prepares it? | When? | What is it for? |
|---|---|---|---|
| Requirements document (Lastenheft; in German-speaking Switzerland often Pflichtenheft) | you as the client, with support | before requesting offers or issuing an invitation to tender | sets out needs, objectives, requirements and criteria |
| Offer or proposal (in public procurement: tender) | the supplier (in public procurement: the tenderer) | in response to your request or invitation to tender | sets out the services offered, the price and the conditions |
| Implementation concept or proposed solution | the supplier, often as part of the offer | with the offer | shows how the supplier intends to meet your requirements; basis for your comparison |
| Pflichtenheft as defined in DIN | the contractor | if agreed, usually after the contract has been awarded | specifies, on the basis of your Lastenheft, how the solution will be implemented; may become part of the contract |
| Detailed specifications | those responsible for implementation, depending on the project the supplier or your own IT, involving your business units, for example for processes, acceptance and tests | during implementation | describe the solution in enough detail for it to be implemented and tested |
Important: settle in the contract whether a Pflichtenheft as defined in DIN is to be drawn up after the award, who prepares it and which document prevails in the event of conflict. In HERMES, the detailed specifications are a separate outcome.
In German-speaking Switzerland, your document is often called a Pflichtenheft
In Swiss public procurement, in municipalities and in many companies in German-speaking Switzerland, “Pflichtenheft” usually refers to the client's document; in Italian-speaking Switzerland, the same document is called a “capitolato d'oneri”. This usage is well documented, including in the federal project management method, HERMES:
- The German edition of HERMES uses the term Lastenheft and adds explicitly that in Switzerland it is also called a Pflichtenheft. The Lastenheft, called the “specifications” in the English edition, is the core of the tender documentation. In HERMES, the requirements are developed as a separate outcome, the solution requirements, and feed into the call for tenders from there.
- In the German version of its recommendations, the Federal Procurement Conference (FPC; German abbreviation BKB) calls the procurement office's document a Pflichtenheft.
- The guide for public procurement of the French-speaking cantons (Guide romand) lists, in the German version of its model tender documentation, the Pflichtenheft among the documents that the contracting authority sends to all tenderers, and devotes a separate annex to it.
- The Canton of Zurich speaks of a “Leistungsbeschrieb” or “Devis”; the Canton of Solothurn uses Lastenheft in its HERMES guide.
- The Federal Act on Public Procurement uses neither term. It regulates the content of the tender documentation and refers to technical specifications and to the description of the goods, work or services.
None of these usages is wrong. Misunderstandings arise when a supplier, a standard or a template from Germany comes into play and both sides mean something different by “Pflichtenheft”. You should therefore state in the tender documentation or in the contract which document is meant. If your procurement office has its own templates, these take precedence; HERMES recommends the same.
Responsibility and preparation
Responsibility for defining the needs lies with you as the client. Only you can decide what is needed and what it is worth. HERMES therefore assigns the task to the client side.
You can share the work of drawing up the document: business units contribute their processes, IT the technical constraints, and a business analysis brings the perspectives together and formulates the requirements. The sequence remains the same:
- Clarify objectives and needs. What should be better after the project, and for whom?
- Draw up the requirements document. Set out requirements, framework conditions and criteria, distinguishing mandatory from optional.
- Request offers or issue an invitation to tender. Suppliers respond to your document with offers or, in public procurement, with tenders.
- Compare, decide, agree. Measure the offers against your requirements, decide and record in the contract which documents apply.
External support in public procurement: prior involvement
Anyone who was involved in preparing a public award procedure, for example by drawing up the tender documentation, is regarded as having prior involvement. This does not automatically lead to exclusion. At federal level, this is governed by Art. 14 of the Federal Act on Public Procurement (PPA); for cantons that have acceded to the Intercantonal Agreement on Public Procurement (IVöB 2019), and thus for their municipalities, by Art. 14 IVöB, which has the same content.
- When exclusion applies: A tenderer with prior involvement is only excluded from tendering if both of the following conditions are met. First, the competitive advantage gained from the preparation cannot be offset by appropriate means. Second, the exclusion does not jeopardise effective competition.
- How an advantage can be offset: The Act lists, in particular, the disclosure of all material information about the preparatory work, the disclosure of the parties involved in the preparatory work and the extension of minimum deadlines.
- Market clarification: If the contracting authority carries out a market clarification before the public invitation to tender, this does not give the tenderers concerned prior involvement. The authority discloses the results of the market clarification in the tender documentation.
For you, this means: clarify at an early stage whether a person or firm you bring in might later also want to submit a tender in the same procedure. You can then plan and document offsetting measures from the outset. Whether exclusion is necessary in an individual case is assessed by the contracting authority under the applicable law. This section is general information, not legal advice.
Example: how a Lastenheft can be structured
The following structure is an example, not a binding template. It is based on the structure of the tender documentation in HERMES and can be adapted for companies as well as public bodies.
- Background: organisation, reason, current situation; what does not work today and what that costs.
- Objectives: what should change, with measurable results.
- Scope: what is part of the project and what is explicitly excluded.
- Users and stakeholders: who works with the solution and who decides.
- Functional requirements: processes, functions and data from the users' perspective, each marked as mandatory or optional.
- Quality and security requirements: availability, performance, usability, data protection, information security.
- Framework conditions: existing systems and interfaces, legal requirements, budget, deadlines.
- Operation and support: who operates, maintains and supports the solution after its introduction.
- Acceptance: criteria and procedure.
- Structure of the offer and evaluation: what suppliers must submit and the criteria on which you will decide. In public procurement, this is where the eligibility criteria, the award criteria with their weighting and, where applicable, a weighting of the eligibility criteria belong.
- Appendices: draft contract, general terms and conditions, volume data (for example numbers of users, cases or transactions), process descriptions.
For a small project, a few pages are often enough. More important than the length is that every requirement is justified and prioritised. A long list of functions without priorities makes offers hard to compare.
When you procure software
With software, there are additional points that are often missing from general templates and become expensive later:
- Interfaces: Which systems must the solution exchange data with, in which direction and how often?
- Data migration: Which data will be migrated from the existing system, and who cleans it up?
- Operation, maintenance and support: Who operates the solution, which response times do you need, how are updates installed?
- Costs over the entire service life: licence or subscription model, operation, customisation and exit, not just the purchase price.
- Data protection and data storage: Where is the data stored, who has access, which requirements of Swiss data protection law apply?
- Exit: How do you get your data back if you change supplier?
- Acceptance: Which test cases will you use to check whether the software actually supports your processes?
A typical mistake: the list of functions from a product brochure becomes the requirements document. The supplier then describes your problem in the language of its product, and you can hardly compare the offers any more. Describe your processes and objectives first; check afterwards whether standard software covers them.
Typical mistakes and how to avoid them
The solution is already in the requirements document. “We need system X” is not a requirement. Describe what is to be achieved.
Going out to tender before the target state is clear.
Nobody checks the offers against your requirements. Every deviation is a decision. It must be made deliberately, not by chance.
How a business analysis supports you before you procure
A requirements document is not a form-filling exercise but the clarification that precedes an important decision. A business analysis supports you with three results:
- Clarity before you procure: business units and IT jointly clarify objectives, processes and requirements before a supplier dictates the solution.
- Comparable offers: the requirements are prioritised and worded so that offers and proposed solutions can be measured against them.
- Decisions you can justify: the evaluation of the offers and the review of the subsequent implementation concept are based on your requirements. You can show later why you decided as you did.
Support is particularly worthwhile if business units and IT see the situation differently, if a supplier has already proposed a solution before your needs are clear, or if you lack the time or experience internally for sound requirements elicitation. Responsibility for your needs and for the decision remains with you.
Frequently asked questions
- What is the difference between a Lastenheft and a Pflichtenheft? Under the German standard, the Lastenheft describes the client's needs and the Pflichtenheft the contractor's implementation. In German-speaking Switzerland, “Pflichtenheft” is often used for the client's document, especially in public procurement.
- Is there a template for a Lastenheft? A template helps with the structure but does not replace clarifying your needs. Above you will find a sample structure that you can adapt. Public bodies first use the templates of their procurement office.
- Can someone who helps draw up the Pflichtenheft in a public procurement procedure later submit a tender? Exclusion is not automatic. Anyone who was involved in the preparation is regarded as having prior involvement. They are only excluded from tendering if their competitive advantage cannot be offset by appropriate means and the exclusion does not jeopardise effective competition (Art. 14 PPA, Art. 14 IVöB). Whether this applies is assessed by the contracting authority in the individual case.
- Do I need both documents even for a small project? Not necessarily as separate documents. You still need to answer both questions: What do we need? How will it be implemented?
Conclusion
A Lastenheft, in German-speaking Switzerland often called a Pflichtenheft, is not a form but a clarification. If you first understand what is needed, you receive comparable offers, can justify your decision and can later accept the solution on a sound basis. If you are about to procure and want to clarify your requirements, I can support you with a business analysis.
Further reading: Transparency that enables action. Not just clean documentation. · HERMES and Scrum: how they work together
Sources: HERMES 2022, outcome Tender documentation (Federal Chancellery) · HERMES 2022, Ausschreibungsunterlagen, German edition with the note on the term Pflichtenheft (Federal Chancellery, in German) · HERMES 2022, task Prepare call for tenders (Federal Chancellery) · HERMES 2022, outcome Solution requirements (Federal Chancellery) · HERMES 2022, outcome Detailed specifications (Federal Chancellery) · Federal Act on Public Procurement (PPA), SR 172.056.1, Art. 14, 30, 35 and 36, English translation without legal force · Intercantonal Agreement on Public Procurement (IVöB 2019), Art. 14, BPUK (in German) · Federal Procurement Conference (FPC) and KBOB, recommendations on SME-friendly procurement (in German) · Guide romand for public procurement (CROMP), Canton of Vaud (German version) · Canton of Zurich, procurement tools and advice (in German) · Canton of Solothurn, project management guide (in German) · IREB, CPRE glossary (German edition) · DIN 69901-5:2009-01, Project management, project management systems, Part 5: Concepts (DIN Media, in German)