What is a requirements specifica­tion (Lastenheft)?

Requirements specifica­tion: definition

The German standard DIN 69901-5 defines the Lastenheft as the entirety of the requirements specified by the client for the deliverables and services of a contractor. Put simply, the requirements specification is the customer's wish list—structured, traceable, and as complete as possible.

It forms the basis for quotes and for the functional specification (Pflichtenheft), in which the contractor then describes how it will implement the requirements. The clearer the requirements specification, the more accurately effort and costs can be estimated.

How a requirements specifica­tion is structured

There is no fixed template, but a structure that moves from the goal to the details has proven effective. It is important to describe requirements from the perspective of users and workflows rather than prescribing technical solutions.

Concrete examples from everyday work are helpful, such as: “A field sales representative should be able to create a quote on site at the customer's premises and have it signed.” Scenarios like these make requirements tangible and prevent misunderstandings.

• Initial situation and project goals
• Target groups and user roles
• Functional requirements: What should the system be able to do?
• Non-functional requirements: security, performance, accessibility, data protection
• Interfaces to existing systems, e.g., ERP or CRM
• Constraints: schedule, budget range, acceptance criteria

Benefits and limitations of a requirements specifica­tion

A good requirements specification forces you to think through your own requirements before the project starts. Quotes from different providers become comparable, misunderstandings surface early, and you get a common basis for discussions about scope and price.

Limitations become apparent in projects whose requirements only become clear during development. A very rigid, extensive requirements specification can then slow things down. In agile projects, it is therefore often supplemented by a leaner description of goals and a product backlog.

• Clarity about goals and scope
• Comparable quotes
• Basis for the functional specification and acceptance
• Overly rigid specifications slow down agile projects

Real-world example: a requirements specifica­tion for a customer portal

An insurance broker wants a portal where customers can view contracts, report claims, and upload documents. In the requirements specification, the broker describes which user groups exist, which workflows should be covered, which existing software needs to be connected, and which data protection requirements apply—without prescribing a technology. This leaves providers room to propose the right solution.

Many companies have little experience writing requirements specifications. In workshops, Nano Concepts helps capture requirements in a structured way and uses them to derive a reliable quote.