A customer requirements specification for software defines what a software project has to deliver before the first vendor submits a proposal. It is the client's document. It describes goals, processes and requirements from a business perspective and deliberately leaves open how the solution is built technically. The cleaner it is, the more comparable the proposals become and the less the parties argue about scope later.
A customer requirements specification for software describes, from the client's perspective, what the software has to do, not how it is built. A proven structure divides it into eight chapters: background and goal, current state, target state, business requirements, quality requirements, constraints and interfaces, exclusions, and deliverables and acceptance. On this basis, the contractor writes the requirements specification.
What a customer requirements specification for software is
The standard DIN 69901-5 defines the customer requirements specification (Lastenheft) as "the entirety of the client's requirements for the deliveries and services of a contractor within an order" (quoted from LMU Munich, Seminar Paper, 01/2017). The older DIN 69905 standard, which is still often referenced, was incorporated into the DIN 69901 series of standards in 2009 (DIN Media).
For software projects, this means the customer requirements specification answers the questions of what and what for: which business problem is to be solved, who works with the system, which processes it has to support and which conditions apply in operation. The question of how, meaning architecture, technologies and data model, is answered by the contractor in the requirements specification. How the two documents differ in detail is shown in our article on the requirements specification template.
| Belongs in the customer requirements specification | Belongs in the requirements specification |
|---|---|
| Business Objective and Success Criteria | Architecture and Components |
| User Groups and Their Workflows | Programming language, frameworks, database |
| Business requirements with priority | Technical implementation of every requirement |
| Existing systems that need to be integrated | Interface Protocols and Data Formats in Detail |
| Budget and Timeline | Effort Estimate and Project Plan |
The customer requirements specification template for software: eight chapters
The following outline covers the points a provider needs to include in a robust proposal. It works just as well for an internal tool as it does for a platform with multiple locations; only the level of detail varies.
All eight chapters as a fill-in template in German, with guidance and a fictitious example for each chapter: Word (.docx) · OpenOffice/LibreOffice (.odt). Free, no sign-up.
- Background and Project Objective. What business problem needs to be solved, why now, and how the client will measure success after implementation.
- Current status. How the process works today, including the tools, volume structures, and known vulnerabilities. Metrics such as the number of users, transactions per day, or locations are more helpful to the provider than any description.
- Target state. Who will be using the system in the future and what the process should look like going forward, described from the users' perspective, not the technical one.
- Business requirements. Each requirement on its own, numbered and prioritized, for example MUST, SHOULD and COULD. Numbered requirements make proposals comparable (wiki.induux.de).
- Quality Requirements. Availability, response times, data protection, accessibility, multilingual support. Preferably with specific numbers so they can be verified.
- Framework Conditions and Interfaces. Existing systems such as ERP or Active Directory; IT policies governing operations in the cloud or in the company’s own data center; legal requirements.
- Exclusions. What is expressly not included in the scope of the contract. This chapter prevents more misunderstandings than any other.
- Scope of Delivery, Acceptance, and Framework. What is included in the delivery (software, documentation, training, operation), how the acceptance process works, and what the timeframe and budget are.
Customer requirements specification example: a maintenance portal
A mechanical engineering company with three plants currently documents maintenance in Excel spreadsheets and on paper. The goal is to create a maintenance portal where technicians can process work orders on tablets and plant managers can view pending maintenance tasks for each piece of equipment. An excerpt from Chapter 4 might look like this:
| No. | Priority | Requirement | Verifiable by |
|---|---|---|---|
| A-01 | MUST | Technicians can view all the maintenance jobs assigned to them for the day on their tablets. | Test with three technician accounts |
| A-02 | MUST | An order can be completed without an internet connection and will be transmitted later. | Test in Airplane Mode |
| A-03 | SHOULD | Photos and measurement data are directly assigned to the order. | Acceptance Testing at a Prototype Facility |
| A-04 | COULD | Plant management receives a weekly overview of overdue maintenance tasks via email. | Two-week sample |
What is striking is what is missing: no database, no app technology, no architecture. Requirement A-02 states that the technician must be able to work offline; it does not specify how synchronization is implemented. That is up to the vendor to decide in the requirements specification.
Who writes the customer requirements specification
The client writes the customer requirements specification. In practice, this is usually someone from the business department or project management who knows the process and can obtain decisions. IT supplies the constraints, the future users supply the processes. An external partner can help with the structure but should not dictate the content. If you let the future vendor write the customer requirements specification, you often get requirements that happen to fit exactly that vendor's solution.
Common mistakes in a customer requirements specification
- Technology over need. "The software shall be built with React" is not a business requirement. Specifications of this kind only belong in the document if your own IT actually requires them, and then under constraints.
- Continuous text instead of a list. Requirements that are hidden within paragraphs cannot be prioritized or approved.
- No priorities. If everything is a "must," every provider will charge for the full scope of services, and the package will end up costing more than necessary.
- No volume figures. Whether there are ten or ten thousand users, or one location or twelve, the architecture and price change fundamentally.
- No exclusions. Anything that isn't ruled out is quickly considered to have been included. This results in Scope Creep.
How the customer requirements specification supports the comparison of proposals
A customer requirements specification usually goes to several vendors. Each responds with a proposal or an initial solution concept. These responses only become comparable when all of them refer to the same numbered requirements. Then you can check requirement by requirement who covers what, where a vendor makes assumptions and where it quietly leaves points out.
A simple comparison table is enough: requirement numbers as rows, vendors as columns, and "covered", "partial" or "not included" in each cell. Large price differences are often explained not by hourly rates but by different assumptions about scope. We describe the other factors that drive the price in our article on Costs of Custom Software.
Have your customer requirements specification reviewed before you send itWe read it the way a vendor would read it, and highlight the points where the proposals will differ.
Frequently Asked Questions
What belongs in a customer requirements specification for software?
Background and goal, current and target state, numbered business requirements with priorities, quality requirements, constraints and interfaces, exclusions, plus deliverables, acceptance and the time and budget frame. Technical solutions do not belong in it.
Who creates the customer requirements specification?
The client. According to DIN 69901-5, it contains the requirements the client sets for the contractor's services. The business department, IT and future users supply the content; an external partner can help with the structure.
Is the customer requirements specification part of the contract?
Usually, yes. The customer requirements specification is created by the client and is typically part of the contract or the tender (LMU Munich, 01/2017; wiki.induux.de). Requirements should therefore be worded so that they can be verified unambiguously at acceptance.
Does an agile software project need a customer requirements specification?
Yes, but a leaner one. Goal, user groups, constraints, exclusions and the most important MUST requirements should be settled before the start, even in an agile project. The details then emerge in the backlog. How to cut a sensible first scope is shown in our article on the MVP.
The Next Step
torck reads customer requirements specifications from a development perspective and asks the follow-up questions before they turn into assumptions in a proposal. Our teams in Maxhütte-Haidhof, Vienna and Rabat build software, data and AI solutions for industry and retail, with torck GmbH as the German contracting party. In an Initial Consultation we go through your customer requirements specification or your first requirements together.
German 
English 
French