Writing requirements and functional specifications: Template + practical guide

Before a software project is commissioned, there is one question that decides budget, schedule and nerves: What exactly should the end result be? The requirements specification answers it from the client’s perspective, the functional specification from the contractor’s perspective. If you separate the two documents cleanly, you later compare offers that are genuinely comparable and argue less often about what “was actually clear”.

This guide clarifies the terms, shows the structure of both documents and takes you step by step through writing a requirements specification. At the end, you will find a template to download.

One distinction up front: this is about software and digital projects (custom software, online shops, apps, interfaces). In mechanical and plant engineering, the same terms apply, but some details of the standard differ. The definition used here follows DIN 69901-5, the German standard for project management terms.

Requirements specification vs. functional specification: the difference in one sentence

DIN 69901-5 defines the requirements specification as (in translation) “the entirety of the requirements set by the client for the deliveries and services of a contractor within a contract”. In simple terms: the what and the what for. The client writes it before putting the project out to tender.

The same standard describes the functional specification as (in translation) “the implementation specifications drawn up by the contractor on the basis of implementing the requirements specification provided by the client”. In simple terms: the how and the with what. The contractor writes it as an answer and thereby defines how it intends to solve the requirements technically.

So the order is fixed: first the requirements specification, then the functional specification. One is the question, the other the binding answer.

A common German mnemonic: the Lastenheft is the load (Last) that the client places on the contractor. The Pflichtenheft is the duty (Pflicht) that the contractor derives from it and accepts.

What belongs in the requirements specification?

A requirements specification does not have to be thick, but it does have to be complete. It describes requirements in an open-ended way, i.e. without anticipating the solution. “The system must automatically transfer orders to accounting” belongs in the requirements specification. “The system uses a REST interface to DATEV” is already a solution specification and therefore a question for the functional specification. This boundary is the most common stumbling block of all, and it runs through the rest of this text.

A robust requirements specification should contain these components:

1. Initial situation and goal. Why does the project exist? Which problem does the software solve, and which business goal is behind it? One or two paragraphs, not a novel.
2. Current state. Which systems, processes and data exist today? What remains and what will be replaced?
3. Target state and functional requirements. What must the solution be able to do? This is the heart of the document. Each requirement gets a unique number, a clear description and a priority (for example must, should, could).
4. Non-functional requirements. Performance, availability, security, data protection, scalability, accessibility. In concrete terms, for example: “The system supports 200 concurrent users without any response taking longer than two seconds.” Exactly these points are rarely on the first wish list and end up being retrofitted at great expense.
5. Interfaces. Which systems does the solution need to talk to? ERP, inventory management, CRM, payment, shipping. Example: “Connection to the existing inventory management system via a nightly batch export.” Name them, do not specify them in detail, because the how is the contractor’s job.
6. Framework conditions. Budget range, time frame, legal requirements (GDPR, industry-specific regulations), desired or excluded technologies.
7. Acceptance criteria. How is it measured whether the result is right? For example: “A test customer completes order, payment and invoice dispatch without errors in the live system.” If you do not define “done”, you will negotiate it later under time pressure, and usually to your disadvantage.

The most important part is the functional requirements, and that is exactly where corners are cut most often. A good requirement is testable. “The search should be fast” is not testable. “Search results appear in under 500 milliseconds for up to 50,000 items” is. Understanding the difference between these two sentences is half the way to a usable requirements specification.

What belongs in the functional specification?

The functional specification takes up every requirement from the requirements specification and answers it specifically. In it, the contractor shows that it has understood the requirements specification and defines the technical implementation bindingly. The principle is simple: every requirement in the requirements specification has exactly one answer in the functional specification.

Typical components:

• Solution concept for each requirement: how is requirement no. 12 implemented technically?
• System architecture: technologies used, components, data model, infrastructure.
• Interface specification: concrete protocols, data formats, endpoints.
• Volume and load assumptions: which data and user volumes are expected.
• Test and acceptance concept: how it is demonstrated that each requirement is met.
• Project plan: phases, milestones, delivery dates, responsibilities.

If a requirement from the requirements specification remains unanswered in the functional specification, that is a warning sign, not a detail. It means either that the provider has overlooked the requirement or that it has deliberately not planned for it. You want to know either before you place the order, not afterwards.

Important for the contract: in many projects, the functional specification becomes part of the contract. What it contains is the service owed. What it does not contain is, if in doubt, not owed. That is why it is worth reading the service provider’s functional specification just as seriously as it reads your requirements specification.

Writing a requirements specification: step by step

As the client, you write the requirements specification yourself, because only you know your processes. This is how you create a requirements specification in six steps:

1. Record goals and framework. Start with the why, not with features. A project without a clear business goal produces a requirements specification that can later be extended at will. That is exactly what drives effort and costs.
2. Gather stakeholders. Talk to the people who will work with the solution every day. The specialist department knows requirements that management is not even aware of. This round saves you the most expensive changes later on.
3. Collect and structure requirements. Collect broadly first, then organise. Group by topic, assign unique numbers and phrase each requirement as a testable sentence.
4. Prioritise. Not everything is equally important. A simple must/should/could classification (or MoSCoW: Must, Should, Could, Won’t) turns a wish list into a basis for decisions. The test: if everything is a “must”, nothing is a “must” any more, and when things get tight, the budget quietly decides instead of you.
5. Add non-functional requirements. Go through the list deliberately: data protection, security, performance, availability, accessibility, maintainability. These points are rarely on the first wish list and still determine the quality.
6. Have it reviewed. Give the requirements specification to someone who was not involved. If they understand what is to be built, the providers will understand it too. If they do not, you will get offers back that cannot be compared.

A rough guide to length: in our experience, a usable requirements specification for a medium-sized custom software project runs to around 10 to 30 pages. This is not a standard value but a rule of thumb. Much shorter usually means too vague; much longer often means that solutions belonging in the functional specification have already been specified. If you are planning the implementation as well as the requirements specification: our custom software development starts with exactly this requirements phase.

Creating a functional specification: step by step

The functional specification is usually created by the contractor as an answer to the requirements specification. It translates each requirement into a concrete technical implementation. It is often created together with a partner. If you want to have your requirements specification created, we take care of the workshop, specification and acceptance criteria. A proven process:

1. Analyse the requirements specification and clarify questions. Go through every requirement and mark gaps, contradictions and ambiguities. Whatever remains open here later becomes an expensive change.
2. Define the solution for each requirement. Every must requirement in the requirements specification has exactly one traceable answer: how it is implemented, with which technology, in which system. No requirement remains unanswered.
3. Define architecture and interfaces. Describe the data model, interfaces (APIs, ERP, payment), roles and permissions. This is where it is decided whether the project will scale later or get stuck on every extension.
4. Formulate acceptance criteria and test cases. Every requirement needs a measurable “done”. Without testable acceptance criteria, you end up with discussion instead of acceptance.
5. Document effort, milestones and assumptions. Record what the estimate is based on. Assumptions that nobody writes down turn into change requests during the project.
6. Have it approved jointly. The functional specification only becomes binding when the client confirms: yes, this is exactly what solves my problem. This approval is the most important moment before the first day of development.

Rule of thumb: the functional specification is usually more extensive than the requirements specification, because it translates every requirement into a solution. If it grows disproportionately, solutions have often been specified that were never in the requirements specification, which is expensive scope creep.

The mistakes that cost the most in practice

The same stumbling blocks come up again and again when writing requirements specifications. They are all avoidable if you know them:

The most expensive mistake is to describe the solution instead of the requirement. If you already prescribe the technology in the requirements specification, you waste the providers’ expertise and rule out better solutions before they are even proposed. Describe the goal, not the route.

Almost as common are untestable requirements. “User-friendly”, “modern” and “high-performance” are wishes, not requirements. What cannot be measured cannot be accepted, and in the end you argue about whether the result is “modern enough” without ever having had a common yardstick.

A third classic: forgetting non-functional requirements. Discovering security and data protection only shortly before go-live means, in the worst case, that parts of the architecture have to be rebuilt. That is the most expensive moment for an insight that belonged in the requirements specification.

If you do not prioritise, you lose the basis for decisions when conflicts arise. Without must/should/could, cuts are made by gut feeling when the budget gets tight, and often the wrong things are cut.

And finally: leaving acceptance criteria open. If “done” is not defined, project completion is postponed until one side gives in. That rarely costs only money; it also costs the trust between client and service provider.

Do I still need this in an agile project?

A fair question, because classic requirements and functional specifications come from waterfall thinking: specify everything in advance, then build. Agile approaches (Scrum, Kanban) instead work with a product backlog, epics and user stories that are refined over the course of the project.

The honest answer: it depends on the type of contract, specifically on two cases.

With a contract for work (Werkvertrag) with a fixed scope of functions, you need a robust requirements specification. The provider owes a defined, defect-free result, so it must be able to calculate, and you must be able to compare offers. Neither is possible without a clear basis of requirements.

With an agile approach based on a service contract (Dienstvertrag; dedicated team, billed by effort), the level of detail shifts. Instead of a complete functional specification, a product vision plus a roughly prioritised backlog that is refined sprint by sprint is often enough. But even then, a lean requirements specification pays off: it clarifies the business goal, the framework and the non-functional requirements, which are not negotiable in agile projects either. Data protection is not invented “in the next sprint”.

A clarification that often gets mixed up in practice: the remuneration model (fixed price or billing by effort) does not necessarily determine the type of contract. A contract for work can also be remunerated by effort, and a fixed price can also be based on a service contract. What matters is whether a result or an activity is owed, not the price.

In short: in an agile context, the document has a different name and is leaner, but the thinking behind it, i.e. clarifying goals, requirements and priorities, does not go away. If you skip it, you only shift it to later project phases, in which corrections are far more laborious. If you want to create clarity about goals and processes early on, you benefit from a structured requirements and process analysis at the start of the project.

Template: requirements specification & functional specification

So that you do not have to start from scratch, we provide a template that contains the structure described above as a fillable framework: goal description, current/target state, a prepared requirements table with numbering and prioritisation, a block for non-functional requirements and acceptance criteria. You can find it here: requirements and functional specification template as a Word download.

How to get the most out of it:

• Delete whatever does not fit your project. A template is a starting point, not a mandatory form.
• Fill in goals and framework first, then the requirements. The order keeps the focus.
• Keep every requirement testable. If you could not test it, rephrase it.

If you then want to have your requirements specification checked by an experienced eye before you put it out to tender, an outside view often helps more than the tenth internal round. That is exactly what an initial consultation on software architecture is for, in which we go through requirements and custom software solution paths together.

Conclusion

Requirements and functional specifications are not a bureaucratic ritual but the tool with which you make a software project manageable. The requirements specification clarifies what you need and makes offers comparable. The functional specification records how the provider solves it and becomes the yardstick for acceptance. Separated cleanly, this means comparable offers and far fewer disputes about what was “actually agreed”. The effort up front is always smaller than the cost of a project built on a misunderstanding.

Download the template, fill in the goals and the most important requirements, and within a few hours you will have a basis on which you can obtain serious offers.

Frequently asked questions

Who writes the requirements specification, and who writes the functional specification? The client writes the requirements specification, because only the client knows its goals and processes. The contractor writes the functional specification as the binding answer to it.

What is the difference between a requirements specification and a functional specification? The requirements specification describes the what and what for (the requirements), the functional specification the how and with what (the concrete technical implementation). First the requirements specification, then the functional specification.

Do I need both documents? With a contract for work with a defined scope of functions, yes. With an agile approach, a prioritised backlog often replaces the functional specification, but a lean requirements specification (goals, framework, non-functional requirements) still makes sense.

How long should a requirements specification be? There is no standard value. As a rough guide, around 10 to 30 pages are realistic for a medium-sized custom software project. What matters is completeness and testability, not length.

What belongs in a requirements specification? Seven components: initial situation and goal, current state, functional requirements (numbered and prioritised), non-functional requirements such as performance and data protection, interfaces, framework conditions such as budget and schedule, and acceptance criteria. What matters is that every requirement is phrased so that it can be tested.