A software selection often starts like this: three systems on the list, the demos booked, and the open question of who helps compare them. What those appointments are meant to prove is rarely written down anywhere.
A requirements document closes that gap, and it does not have to be a book. A document a vendor reads in half an hour and answers point by point carries a selection better than a volume nobody finishes.
How do you write a requirements document for a software selection?
By describing your own workflows instead of the software you would like. For each workflow write down what happens today, who is involved, which data it produces and how you would recognise that a system carries it. Anything a vendor cannot answer with yes, no or a price stays out.
A Lastenheft, the German term for a requirements document, is defined in DIN 69901-5 as the entirety of the requirements for a contractor's deliveries and services as laid down by the client. It states the what and the why. The vendor's answer, the how and the with what, is called a Pflichtenheft and comes later.
What belongs in a requirements document for a small business?
Seven sections are enough in a small company. Each one answers a question a vendor would otherwise invent on your behalf.
- Goal and trigger: which problem should be gone, and how you would notice that in daily work.
- The workflow today: the affected steps in order, with the volume per week.
- People involved: who works with it daily, who rarely, who only looks in.
- Functional requirements: what the system has to do, one sentence per requirement.
- Data and connections: which systems stay, which data has to be carried over.
- Frame: budget as a range, target date, legal obligations, languages, sites.
- Acceptance: which cases have to run through before you sign the system off.
The usual mistake sits in the fourth section. What grows there is a list of features copied from vendor material. A requirement is not the words document management. It reads: a quote is created from the order data and can be found at the customer record.
How do you word a requirement you can test later?
In one sentence, with a trigger, a result and a figure you can measure. A sentence that fails as a test case fails as a requirement.
- Weak: the system should speed up quoting.
- Testable: a confirmed order produces a quote in at most three steps, without customer data being typed again.
The glossary of the International Requirements Engineering Board calls a requirement a need perceived by a stakeholder, or a capability a system shall have. Both belong in the document: the need explains why the capability is listed, under the name of the person who raised it.
Rate every requirement as must, want or later. Without that column every line weighs the same, and the price decides in the end, because the differences between the offers never become visible in the document.
Which Austrian obligations belong in the requirements document?
The ones a tool can fail on later, even after a good demo. Four of them are the same for almost every business in Austria.
- Invoices in structured form: according to WKO, federal offices have accepted only electronic invoices since 1 January 2014, in the ebInterface format through the Austrian business service portal. WKO also reports that 98 percent of invoices sent in Austria in 2025 were PDF files, a format no longer allowed between businesses in the EU from 2030.
- Retention: electronic invoices have to be kept for seven years as well, according to WKO. So the system has to keep them readable that long or hand them out.
- Processing on your behalf: where a provider processes personal data for you, WKO points to a contract under Article 28 GDPR, in writing, with electronic form counting as writing. It covers documented instructions, approval of further processors, plus deletion or return of the data when the contract ends.
- Getting out again: under the Data Act, Regulation (EU) 2023/2854, which according to WKO applies since 12 September 2025, customers have a right to switch provider. RTR names a notice period of at most two months, then a transition period of at most 30 calendar days. No switching charges may be levied from 12 January 2027.
These points belong in the frame, not in an annex, because they can rule an offer out. A system with no route to structured invoices is usable today and a building site in five years. Where the software carries AI features that talk to people or produce content, Article 50 of the AI Act has provided for transparency duties since 2 August 2026. Whether that applies in a given case is a legal question.
How long should a requirements document be?
As a guide five to ten pages for one area of the business, ten to twenty for a company changing several areas at once. Length is not a mark of quality. Testability is. Five steps lead to a document that size.
- 1.Two hours with the people who run the workflow every day. You take the notes, not them.
- 2.One page per workflow: trigger, steps, systems involved, volume per week, known sources of error.
- 3.Derive the requirements from those pages and rate each one as must, want or later.
- 4.Add the frame: budget as a range, target date, legal obligations, number of workplaces.
- 5.Have someone who does not know the business read it. What they do not understand, the vendor will not understand either.
After that the same questions go to every vendor, and the answers land in a comparison matrix, row by row. How we gather requirements and build a selection on them is on our page about tool selection and rollout, and the post on documenting processes covers the workflows behind them.
How do you recognise a weak requirements document?
At three places. It names products instead of requirements, so the decision was made long ago and the selection is a performance. It carries no volumes, so no vendor can name a price. And it has no priority column, so every line is a must and no offer fits.
A requirements document is not a formality. It is the one part of a software selection that lies entirely in your hands, and it decides whether you compare offers or admire demos.