Software requirements specification: structure, examples, template

What a requirements specification is and why you need one

A requirements specification (Lastenheft) describes, from your company's perspective, what a piece of software needs to do before you hire an agency. It records the starting situation, goals, requirements, and constraints, without yet defining what the technical solution looks like in detail. That's exactly what distinguishes it from a functional specification (Pflichtenheft), which the agency then produces in response.

The benefit shows up most clearly when comparing proposals. Send three agencies the same vague description of a project, and all three will calculate something different, leaving the proposals far apart without telling you which one is cheaper or better. A requirements specification forces you to create clarity upfront, and forces agencies to respond on the same basis. That applies whether the project is custom software, a web application, or an app.

Without this foundation, clarifying requirements simply shifts into the middle of the project, usually at a point where changes already cost money. A real-world example: a department only realizes after three months of development that an export function for auditors is missing, because nobody named it as a requirement beforehand. Adding it later costs many times what a single line in the requirements specification would have.

Requirements specification or functional specification: the difference

The two terms are often confused, but they refer to different documents written by different parties. The requirements specification comes from you as the client and describes the what: which problem needs solving, which functions are needed, which constraints apply. The functional specification comes from the agency as the contractor and describes the how: which architecture, which stack, which approach will be used to implement the requirements.

In practice, the line often blurs on smaller projects, where a single document covers both sides in an iterative process. For projects with a budget above roughly €40,000, keeping them separate still pays off, because the functional specification then becomes part of the proposal and both sides know exactly what they're agreeing to. Feel free to ask the agency to present its functional specification before signing the contract, even after you've already accepted the proposal. That way you can check upfront whether the agency understood your requirements correctly, instead of finding out at acceptance testing.

When a requirements specification is worth the effort

Not every project needs a full document. For a small change to an existing application, a short briefing and a conversation are often enough. But once several stakeholders are involved, multiple agencies are being asked for proposals, or the budget reaches five figures, the effort pays off. A requirements specification keeps proposals comparable, and it also prevents misunderstandings during implementation, because requirements exist in writing rather than only in one person's head.

For public tenders and larger corporate projects, a requirements specification is usually mandatory anyway. At mid-sized companies it's optional, which is exactly what makes it a competitive advantage: agencies calculate more precisely when they receive precise information, and that shows up in the price.

A typical example: a mid-sized machine builder wants to replace its spare-parts portal. Instead of sending "we need a new portal" to four agencies, the IT lead describes the existing weaknesses, the desired search functions, the connection to the inventory system, and the timeline up to the spring trade show in a two-page requirements specification. The proposals that come back then differ mainly in price and approach, not in what needs to be built in the first place.

Structure: an outline with example wording

A requirements specification doesn't follow a legally mandated format, but a fairly stable structure has emerged in practice. Before you start writing, it's worth doing a short round of the affected departments: who works with the old system or process today, which workarounds have become routine, which data flows where. These conversations usually turn up more usable requirements than an afternoon alone at a desk. The following seven sections work as a basic framework that you can shorten or extend depending on the project.

1. Starting situation and reason. Describe why the project exists. Example: "Order entry currently happens in a spreadsheet maintained in parallel by three employees. Version conflicts regularly lead to incorrect delivery dates."
2. Project goals. Formulate measurable goals rather than statements of intent. Example: "Turnaround time from order receipt to confirmation should drop from an average of two days to under four hours."
3. Functional requirements. List what the system needs to do, ideally as individual, testable points. Example: "The system must be able to assign orders to multiple staff and show the status in real time for everyone involved."
4. Non-functional requirements. These include performance, availability, security, and usability. Example: "The application must work on warehouse tablets without an internet connection and sync data automatically once a connection is available."
5. Interfaces to existing systems. Example: "Orders must be transferred automatically to the existing ERP system, without manual double entry."
6. Constraints. These include budget, timeline, legal requirements, and the people involved. Example: "The budget is €60,000 to €90,000, with a production launch expected by the third quarter."
7. Acceptance criteria. Define how you'll know the project is done. Example: "Acceptance occurs once all functions listed in section 3 run without errors on the test system and have been confirmed by three named testers."

The more concrete the wording, the easier it is to measure later proposals, and ultimately the delivered software, against it.

How detailed the requirements specification should be

A requirements specification that's too brief leaves too much room for interpretation; one that's too detailed takes away the agency's ability to bring its own solution ideas and inflates the effort of writing it unnecessarily. As a rule of thumb: describe what should be achieved and under what conditions, not how a database is structured or which framework gets used. Those decisions belong in the agency's functional specification. If you don't yet know exactly what the solution should do, an upfront discovery phase with user interviews and a prototype is often more useful than a premature requirements specification.

For a mid-sized project with a budget between €40,000 and €150,000, five to fifteen pages is realistic. Smaller projects need only two to four pages, while larger platform projects with several modules can run to thirty pages, in which case splitting the document by module is worthwhile. For a first sense of what your project will roughly cost before you get into detail, see What does software cost?

Common mistakes when writing it

The most common mistake is describing solutions instead of requirements. "We need an app built with React Native" isn't a requirement, it's a technical directive, and you're usually better off leaving that decision to the agency. Describe instead what behavior the application should show.

A second mistake is missing prioritization. If all forty requirements appear equally important, no agency can judge where compromises are possible if the budget gets tight. A simple breakdown into "must," "should," and "could" helps more here than a long, unweighted list. It's just as useful to state who makes the final call when departments want conflicting things, otherwise the agency ends up negotiating those conflicts with your own colleagues.

Third, constraints like budget or timeline often get left out, out of concern that naming a number will drive proposals up. Usually the opposite happens. Without any guidance, agencies calculate generously just to be safe; with a realistic ballpark figure, they can scope the project accordingly. For how to check agencies on references and credentials afterward, see How to vet an agency.

The template for download

So you don't have to start from scratch, a free template with the structure described above and placeholders for all seven sections is available: template as a Word file and as a PDF. Both versions can be used directly for your project request to suitable agencies, either as an attachment or as the basis for the free-text field. For how to compare the proposals you receive afterward in a structured way, see Comparing agency proposals.

If you're unsure whether your requirements specification is sufficient, you can also discuss it informally with one or two agencies from search before sending out the actual request. Most agencies will give you non-binding feedback on what information they'd still need for a solid proposal.