Software Requirements Specifica­tion (Lastenheft): Structure, Example and Checklist

A requirements specification (Lastenheft) describes from the client’s perspective what software should do and why: goals, requirements and constraints in one document that the client, the service provider and the future users understand equally well. For many SME projects, a few well-structured pages are enough. The payoff: quotes become comparable, fixed prices become possible and acceptance can be tied to testable criteria.

Three quotes for the same software project – and the prices are far apart. That is rarely due to dubious providers; usually each of them simply understood something different. A good requirements specification solves exactly this problem. This article explains the difference from the functional specification, shows the proven structure, gives wording examples and ends with a checklist.

Requirements specifica­tion and functional specifica­tion: the difference

The requirements specification (Lastenheft) describes what the software should do and for what purpose. The German standard DIN 69901-5 defines it as the entirety of the requirements set by the client for a contractor’s deliverables and services. The functional specification (Pflichtenheft) is the contractor’s response: it describes how the requirements will be implemented – with which architecture, technologies and approaches. Internationally, this is called a software requirements specification; the standard ISO/IEC/IEEE 29148 covers requirements engineering as a whole.

Aspect	Requirements specification	Functional specification
Author	client	contractor, aligned with the client
Guiding question	what should the software do, and for what purpose?	how will it be implemented?
Contents	goals, requirements, constraints	architecture, technologies, approaches, implementation plan
Timing	before quotes are requested	after the order or as part of the quote
Benefit	quotes become comparable	binding basis for implementation and acceptance

In smaller projects, the two documents are often merged into one shared concept. What matters is not the document name but that requirements and the implementation proposal are clearly separated and related to each other.

Why a good requirements specifica­tion pays off

• Comparable quotes: All providers calculate on the same basis.
• A fixed price becomes possible: The clearer the scope, the more reliably a fixed price can be calculated.
• Fewer change requests: What has been described won’t come as a surprise later.
• Clear acceptance: You can check whether the result meets the requirements.
• Internal clarity: The very act of writing forces you to resolve open questions within your own organization.

If the requirements specification – or the functional specification derived from it – becomes part of the contract, it serves as the yardstick at acceptance. That protects both sides, especially in fixed-price projects, which are legally usually classified as a contract for work (Werkvertrag). How your contract is to be assessed in your individual case is a matter for your legal counsel.

The structure of a requirements specifica­tion

A requirements specification doesn’t have to be a thick document. This outline has proven its worth:

Chapter	Guiding question	Typical contents
1. Starting point and goals	How does the process run today, and what should change?	problems, verifiable goals, e.g. “quotes are created without manual retyping”
2. User groups and roles	Who works with the software, and who may do what?	inside sales, field staff, customers, administrators
3. Functional requirements	What should the software be able to do, specifically?	user stories with purpose, acceptance criteria
4. Non-functional requirements	How good does the software need to be?	response times, availability, security, data protection, accessibility, devices and browsers
5. Interfaces and data	Which systems does it exchange data with?	ERP, CRM, accounting, store; format and volume of legacy data
6. Volumes	How much is expected today and in a few years?	users, records, documents, transactions
7. Constraints	What constraints apply to time, budget and resources?	target date, budget range, contacts, time for testing, technical requirements
8. Scope of delivery and operation	What is part of the handover, and what happens afterward?	documentation, usage rights and source code, training, hosting, maintenance and support
9. Acceptance criteria	How do you know a requirement has been met?	testable criteria, ideally with concrete test cases

Many clients hesitate to name a budget range, worried that it will then be used up completely. Yet a range helps everyone involved: providers can propose solutions that fit it instead of calculating blindly. And you receive quotes that are realistic rather than embellished.

Wording requirements so that they can be tested

Functional requirements: describe purpose and behavior

The user story format has proven its worth: “As a dispatcher, I want to assign jobs to a technician by drag and drop so that I can create the daily schedule faster.” This clarifies not only the function but also its purpose. Add acceptance criteria to important stories in the form “Given – When – Then”: “Given a job without a technician, when the dispatcher assigns it, then it appears in the technician’s calendar.” A comparison shows how specific a requirement should be. Vaguely worded: “The system should manage jobs.” Well worded:

The inside sales team creates jobs with customer, service, requested date and attachments. Every job has a status – new, planned, completed, invoiced. When the status changes to ‘completed’, accounting automatically receives a task to issue the invoice.

The second version is longer, but every developer understands it the same way. That is exactly where the value lies: misunderstandings are cleared up before the project, not after it.

Making non-functional requirements measurable

Terms such as “fast,” “simple” or “modern” cannot be tested without a yardstick. Define values and boundaries instead:

• Performance: instead of “fast,” for example, “The job list loads in under two seconds with 10,000 records.”
• Availability: operating hours, tolerable downtime and maintenance windows
• Security and data protection: role concept, hosting location, deletion periods, logging
• Accessibility: For offerings aimed at consumers, the BFSG may apply, which has been in application since June 28, 2025.
• Devices and browsers: supported operating systems, browsers, screen sizes, offline capability
• Operations: monitoring, backups, support hours and response times

Prioritizing with must, should and could

Not every requirement is equally important. Label each requirement as must, should or could. Must requirements make up the first release, should requirements follow if budget is available, could requirements are ideas for later. A fourth group helps: anything deliberately not part of this release is stated explicitly – that prevents silent expectations. This classification makes quotes flexible and protects against an overloaded first release.

Requirements specifica­tion, contract type and agile development

Agile development thrives on sharpening requirements during the project. A requirements specification does not stand in the way. It describes goals, framework and the most important requirements – the details are then worked out together in short stages. That way you combine planning certainty with the freedom to react to new insights.

The contract type also depends on how precisely you can describe requirements in advance. If the scope is clear, a fixed price with defined acceptance fits. If much remains open, working on a time-and-effort basis in stages with regular deliverables is often more honest. The requirements specification shows which of the two situations you are in.

Typical mistakes and checklist

Typical mistakes in a requirements specifica­tion

• Solutions instead of requirements: “We need a table with twelve columns” instead of “We must be able to filter jobs by status.”
• Vague terms: “fast,” “simple,” “modern” – not testable without a yardstick.
• Missing special cases: What happens with cancellations, partial deliveries or substitutes?
• Users not asked: Whoever uses the software every day knows the stumbling blocks best.
• Everything is a must: Without priorities, the first release gets too big.
• Forgetting interfaces and legacy data: They often drive effort and risk more than the user interface does.
• Never updated: A requirements specification that is not maintained after the project starts loses its value as a yardstick.

Checklist: is your requirements specifica­tion complete?

• starting point and verifiable goals described
• all user groups and roles named
• functional requirements worded as user stories with acceptance criteria
• non-functional requirements defined measurably
• interfaces and data migration described
• volumes for today and tomorrow stated
• time and budget range stated
• scope of delivery, operation and usage rights clarified
• requirements prioritized as must, should and could
• testable acceptance criteria defined

No requirements specifica­tion? How Nano Concepts can help

Many companies have neither the time nor the experience to write a complete requirements specification. That is no obstacle. In the free initial consultation and, on request, in a follow-up workshop, we work out the requirements together with you and capture them in a clear concept. This technology consulting is often the most economical way in because it prevents misunderstandings later on.

Whether you come with a finished document or with a first idea, we translate your requirements into an actionable concept and support you in software development through to the running system. For projects that must fit your processes exactly, read more about our custom software. If the scope is clearly defined, we prefer to provide a fixed-price quote.

This article does not replace legal advice.