In short
A software requirements specification sets out, from the client’s point of view, what the software should do, for whom and how you’ll tell at sign-off that it does. It covers the goal, users, workflows, prioritized requirements, data, quality requirements and acceptance criteria. The provider then describes in a functional specification how the software will do it.
Key takeaways
- The client writes the requirements specification: what the software should do. In the functional specification, the provider describes how.
- Every requirement needs a number and a priority. Every must-have needs an acceptance criterion with a defined expected result.
- Words like “fast” or “user-friendly” can’t be tested. Replace them with numbers and conditions.
- An acceptance criterion must be testable on the day of sign-off. Record anything that only shows in live operation as a goal.
- Small projects need only the goal, users, core workflows, must-haves and should-haves with acceptance criteria, data and scope limits.
How do requirements and functional specifications differ?
The client writes the requirements specification: what the software should do and how that will be checked. The provider draws up the functional specification with you, and it describes how your requirements will be implemented. The V-Modell XT Bund, the German federal administration’s reference model for systems development projects, separates the two this way.
In German, the requirements specification is called the Lastenheft and the functional specification the Pflichtenheft. In the V-Modell XT Bund (external site) (in German), the requirements specification is the basis for the call for tenders and the contract. That makes it the most important input for the providers’ quotes. The functional specification adopts these requirements and prepares them for development. It’s the central document the developers start from.
| Aspect | Requirements specification | Functional specification |
|---|---|---|
| Who writes it? | the client, meaning you | the provider, together with you |
| Key question | What should the software do, and why? | How will the requirements be implemented? |
| Contents | goal, users, workflows, requirements, deliverables, acceptance criteria | solution, software architecture, interfaces, refined acceptance criteria |
| When | before you request quotes | early in development |
| What you use it for | requesting and comparing quotes | checking that every one of your requirements is covered |
What goes into a software requirements specification?
A software requirements specification covers the goal and background, users and workflows, numbered requirements with priorities, data and integrations, quality requirements, constraints, deliverables and sign-off, and what’s out of scope. You can use the outline below as a template. Its last column shows what’s enough for a small project.
| No. | Section | What goes in | For small projects |
|---|---|---|---|
| 1 | Goal and background | reason for the project, today’s problem, goal with a metric, target date | one paragraph |
| 2 | People involved and users | point of contact, who decides, user groups with headcount and tasks | short list |
| 3 | Workflows | each core workflow step by step, with special cases and samples such as forms or lists | core workflows only |
| 4 | Functional requirements | numbered, each with a priority and an acceptance criterion | must-haves and should-haves |
| 5 | Data and integrations | types and volumes of data, legacy data, systems the software exchanges data with | required if you’re migrating legacy data |
| 6 | Quality requirements | data protection, security, availability, response times, devices and browsers, accessibility, backups | the most important ones, each with a number |
| 7 | Constraints | budget range, deadlines, existing systems, operations and maintenance, legal and contractual requirements | brief |
| 8 | Deliverables and sign-off | what will be delivered, such as software, documentation and training; who signs off and with which data | required |
| 9 | Out of scope | what is explicitly not included | required |
| 10 | Open questions and assumptions | what still needs to be clarified, by whom and by when | required if there are any |
| 11 | Glossary | terms and abbreviations used in your business | optional |
Put the project name, version, date and point of contact on the first page. That way, everyone involved is talking about the same version.
The outline is based on the Lastenheft in the V-Modell XT Bund, shortened for small and mid-sized projects. A template keeps you from forgetting things, but it has pitfalls. The syllabus of the International Requirements Engineering Board (external site) (IREB) names two of them. People tend to focus on filling in the template rather than on the content, and whatever the template doesn’t cover is more likely to be left out. So finish by asking what your project needs that the outline has no section for.
What problem should the software solve?
Start with the reason for the project: which workflow costs time or money today, who is affected and what should be better afterward. Give the goal a metric. You’ll measure every requirement against this goal later, because anything that doesn’t contribute to it doesn’t belong in the first release.
Write down how the workflow runs today, which tools it uses and where it gets stuck. Attach spreadsheets, forms and screenshots of your current solution. At this point, the V-Modell XT Bund also calls for an explanation of why existing systems can’t solve the problem.
So check early whether off-the-shelf software already covers your workflow. The V-Modell allows a first rough market survey even before the requirements specification is finalized. Our comparison Build or buy software? shows how to go about it. If you’re planning a product you want to sell yourself, our guide to SaaS explains what else such a product needs.
Example: “Our six field technicians record their hours and materials on paper. Once a week, the office types up the sheets and then writes the invoices. Goal: every invoice goes out no later than two business days after the job.”
Common mistake: The specification describes a solution, such as “We need an app with a database,” and leaves out the problem behind it. That locks in the solution before anyone has checked what best supports your workflow. In an international survey of 228 companies, one in four listed stakeholders’ difficulty separating requirements from known solutions among their five most critical problems.
Source: Méndez Fernández et al., Empirical Software Engineering (external site), · 2014/15 survey in 10 countries
Done when someone who doesn’t know your business can read it and say which problem the software solves and how you’ll measure success.
Who will work with the software, and in which workflows?
List every user group with headcount and tasks, such as the office, field technicians and management. Then describe each core workflow step by step: who does what, what data it produces and which special cases come up. To do this, ask the people who handle the workflow today.
For functional requirements, the V-Modell XT Bund always asks about four aspects: What is done? Who is involved? What data is used? Which other systems does the software interact with? Also note who may see and change what. That’s where your roles and permissions will come from later.
The people in day-to-day operations know the special cases: the order with two delivery addresses, the canceled invoice, the purchase order without a job number. The research project NaPiRE (Naming the Pain in Requirements Engineering) asked companies about their problems with requirements. The problem they named most often was incomplete or hidden requirements: 48% of the 228 companies counted it among their five most critical problems.
Source: Méndez Fernández et al., Empirical Software Engineering, · 2014/15 survey in 10 countries
Our how-to on digitizing business processes shows how to map a workflow the way it really runs and which one to tackle first.
Example: “Workflow: bill a job. 1. On site, the field technician records hours and materials. 2. The site manager reviews and approves the job. 3. The office creates the invoice from approved jobs. Special case: a job runs over several days.”
Common mistake: Management writes the specification alone. It then describes the workflows as they’re supposed to run, and the special cases from everyday work are missing.
Done when every user group is listed with headcount and tasks, and someone from day-to-day operations has read and confirmed each workflow.
How do you write testable requirements?
Write each requirement as a separate sentence with a number and a priority. Say who can do what under which condition, and replace words like “fast” or “simple” with numbers and conditions. Then you can decide clearly at sign-off whether the requirement has been met.
The IREB syllabus recommends six quality criteria for each individual requirement: adequate, necessary, unambiguous, complete, understandable and verifiable. Adequate means it describes what the stakeholders really need and have agreed on. The syllabus calls adequacy and understandability the most important of the six.
Source: IREB, CPRE Foundation Level syllabus 3.3.0,
NASA’s Systems Engineering Handbook (external site) lists words that can’t be verified, including “flexible,” “easy,” “sufficient,” “user-friendly,” “fast” and “robust.” The same checklist asks whether each statement expresses only one requirement. If an “and” joins two capabilities, you have two requirements.
| Unclear | Testable |
|---|---|
| “The software should be fast.” | “The list of open orders appears within 2 seconds for up to 5,000 orders, measured on an office PC.” |
| “The software should be user-friendly.” | “After a 30-minute introduction, a new office worker creates an order without help.” |
| “All data from Excel will be migrated.” | “Customer data and open orders from the file orders.xlsx are migrated, with duplicate customer entries merged beforehand. A random sample of 50 records matches the file.” |
| “The software must be secure.” | “Everyone signs in with their own account. Field technicians see only their own jobs.” |
| “The software should also work on mobile.” | “Field technicians record hours and materials on their smartphones, even without a cellular connection. Entries sync as soon as there’s a connection again.” |
| “The software works with our accounting system.” | “Approved invoices are sent to the accounting software once a day. If a transfer fails, the office gets an email.” |
A sentence template helps with the wording. A widely used pattern is EARS (Easy Approach to Requirements Syntax) (external site), developed at Rolls-Royce and first published in 2009. For events, the pattern is When <trigger>, the <system name> shall <system response>. An example: “When the site manager approves a job, the software shall add it to the office’s billing list.” Use the words your business uses, and explain terms outsiders won’t know in the glossary. According to the V-Modell, the glossary is binding for everyone involved and helps prevent misunderstandings.
For priorities, the MoSCoW method works well: must have, should have, could have and won’t have this time. For every must-have requirement, ask what happens if it’s missing. If launching without it isn’t worth it, it’s a must-have. Once a provider estimates the effort per requirement, check the share taken up by must-have requirements. The Agile Business Consortium (external site) recommends that must-haves typically account for no more than 60% of the effort. The could-have requirements are your reserve if time or budget runs short. Our article on fixed price vs. time and materials compares when each model fits.
Source: Agile Business Consortium,
Common mistake: Every requirement is marked “must have.” Then there’s no reserve, and when time or money runs short, there’s no way to decide what can wait.
Done when every requirement has a number, a priority and only one statement, and no untestable word appears without a number or condition.
What should you specify for data, integrations and quality?
State which data the software will manage, in what volume and where it comes from, including legacy data from Excel or an old database. List every system it exchanges data with. Make quality requirements such as data protection, availability or response times as measurable as the functions.
When software replaces an existing system, the V-Modell XT Bund provides for a legacy system analysis that determines the old system’s data model and assesses data quality. Make this easier: attach a sample file from which you’ve removed names and contact details, and note where you know of duplicate or incomplete entries. Our page Custom business software to replace spreadsheets describes what data migration and parallel running can look like when you move off Excel or Access.
For each integration, name the other system, the data, the direction, the frequency and a point of contact for the other system.
Quality requirements, which the V-Modell calls non-functional requirements, describe how well the software performs its functions. The V-Modell recommends wording them so they’re measurable, verifiable and decidable: it should be clear whether they’re met. The quality model in the standard ISO/IEC 25010:2023 (Product quality model) (external site) makes a good checklist, and it’s explicitly meant for requirements too. For a small project, settle at least these points:
- Data protection: Which personal data will the software process, who may see it, and when will it be deleted?
- Availability and backups: When does the software have to be available, how long may an outage last, and how often is data backed up?
- Response times: What’s the maximum time for loading a list or saving, and with how much data?
- Devices and browsers: On which devices and in which browsers does the software have to run?
- Accessibility: Will people with disabilities use the software, for example with a screen magnifier or a screen reader?
Common mistake: Volumes are missing, such as how many people work at the same time or how many records will pile up over three years. NASA’s checklist also asks about performance, including timing, throughput and storage size. Without these figures, a provider can only guess which design fits.
Done when every type of data has its volume and source, every integration has a direction and frequency, and every quality requirement contains a number or a testable condition.
How do you write acceptance criteria?
An acceptance criterion describes a test in three parts: initial situation, action and expected result. The V-Modell XT Bund recommends this structure and requires a defined expected result for every criterion. Write at least one criterion for each must-have requirement, and specify which data the test will use.
Before the contract is awarded, a general form is enough. Under the V-Modell, the provider refines the criteria in the functional specification, but the expected result of each must-have requirement should already be in your requirements specification. The same three parts appear in the keywords Given, When and Then. The language Gherkin (external site) uses them to write executable specifications: test cases that can also run automatically. The keywords exist in German, too. For the requirement “When the site manager approves a job, the software shall add it to the office’s billing list,” a criterion could look like this:
- Given: A job with 3.5 hours of work and two material items has been recorded.
- When: The site manager approves it.
- Then: It appears in the billing list within one minute, with the same hours and items.
For numbers such as response times, the measurement method is part of the criterion: which device, how much data and how many runs. Measured values vary, so the documentation of Google’s testing tool Lighthouse (external site) recommends basing thresholds on aggregate values such as the median of several runs.
An acceptance criterion has to be testable on the day of sign-off. A goal like “Every invoice goes out no later than two business days after the job” only shows once the software is in use. Record it as a goal and measure it after launch; at sign-off, you test the functions that make it possible. Also decide who on your side runs the tests and who signs off. Ask your lawyer what legal consequences sign-off has.
Common mistake: The criterion merely repeats the requirement, as in “The billing list works.” Then there’s no expected result for both sides to judge the test against.
Done when every must-have requirement has an acceptance criterion with a defined expected result, and it’s settled which data the tests will use.
What’s out of scope, and what happens next?
Write down what’s explicitly out of scope, which questions are still open and what constraints your budget, deadlines and operations impose. Then give every provider the same version and compare the quotes requirement by requirement. Later, check that each of your requirements reappears in the functional specification.
Listing what’s out of scope shows every provider what it doesn’t have to plan for, such as an app for your customers or connecting your warehouse in the first release. The constraints include your budget range, deadlines, existing systems that will stay, and operations after launch: who will run, maintain and extend the software? On this point, the V-Modell XT Bund asks about the whole life cycle, from use and operation through planned future releases to retirement. Our cost guide How much does software maintenance cost? explains what maintenance after launch costs.
Answer providers’ questions in writing and send every answer to all of them. That way, every quote is based on the same information. Our cost guide How much does custom software development cost? shows how to compare quotes and which price ranges providers publish.
According to the V-Modell, the functional specification adopts the requirements from the requirements specification and traces each one back to it. So check that every number in your requirements specification appears in the functional specification, and ask about any that are missing. If a requirement changes later, put the change in writing, with a new version, the date and the effect on price and schedule. Our software development page describes how a project runs with us, from the intro call to sign-off against criteria agreed in writing.
Common mistake: One provider gets the requirements specification, another only a description over the phone. Then you’re comparing quotes for two different projects.
Done when the scope limits, constraints and open questions are written down, and every provider has received the same version.
How much specification does a small project need?
A small project doesn’t need a thick document. The goal and background, the users, the core workflows, must-have and should-have requirements with acceptance criteria, the data and what’s out of scope are enough. Match the level of detail for each requirement to its value and the risk attached to it.
The IREB syllabus recommends the same graded approach: not every requirement has to meet all the quality criteria completely, but the higher its value, the more the criteria matter. So you describe a requirement your workflow depends on more precisely than the color of a button.
In agile development, the goal, users, constraints and scope limits can go in the requirements specification, and the requirements in an ordered list, the Product Backlog. The Scrum Guide (external site) calls this list “emergent”: its items are continually broken down and defined more precisely. Each item then gets its own acceptance criteria. That’s also how the IREB glossary (external site) defines acceptance criteria in agile development.
What applies to specifications in Germany and the EU?
Internationally, the standard ISO/IEC/IEEE 29148 specifies what requirements documents contain. Lastenheft and Pflichtenheft are German terms, described in the VDI 2519 Part 1 guideline and the V-Modell XT Bund, among others. Legal requirements that apply to your project belong in your requirements specification as constraints.
- Terms: In some situations, the IREB glossary distinguishes a customer requirements specification, typically written by the customer, from a system or software requirements specification written by the supplier. Its German edition uses Lastenheft for the first and Pflichtenheft for the software requirements specification, or SRS. On this page, a software requirements specification is the client’s document, the Lastenheft. If you’re working with a team in another country, agree at the start which document you mean.
- Standard and guideline: The current edition of ISO/IEC/IEEE 29148 (Requirements engineering) (external site) dates from 2018, and a revision is in progress. The German guideline VDI 2519 Part 1 (external site) (Procedures for the compilation of tender and performance specifications) was written for material flow and automation systems.
- Legal and contractual requirements: The V-Modell XT Bund explicitly takes information security and data protection into account when requirements are set. Check with your lawyer and tax advisor which obligations apply to your project before your requirements specification goes out to providers.
From our work: requirements for this website you can check yourself
We checked three requirements for this website on November 9, 2026, and all three were met; we haven’t yet measured the fourth against its criterion. For datafalke.de, we’re the client and the provider at the same time. We wrote down our technical requirements with thresholds and test methods, and the budgets and measurement targets are public on our methodology page. The table shows four of these requirements in the form we recommend for requirements specifications, and how you can check each one yourself.
| Requirement | Acceptance criterion | How to check it yourself | Result on Nov 9, 2026 |
|---|---|---|---|
| The pages work without JavaScript. | No page loads a JavaScript file. Content, links and forms are in the delivered HTML. | Open your browser’s developer tools (F12), go to the Network tab, filter by “JS” and reload the page | 98 of 98 pages in the sitemaps load no JavaScript file |
| Visiting the site creates no connections to third parties. | All fonts, styles and images come from datafalke.de. | In the Network tab, check the domain of every file loaded | 98 of 98 pages in the sitemaps load no file from another server |
| The website has a single address. | Requests via http:// and www. redirect with status 301 to https://datafalke.de/. | In a terminal: curl -I http://www.datafalke.de/ | 3 of 3 variants redirect with status 301 to https://datafalke.de/ |
| The pages load fast on a smartphone. | Lab: Lighthouse mobile at least 95 out of 100 in each category, median of five runs. Real visits: LCP at most 2.0 s, INP at most 150 ms, CLS at most 0.05, each at the 75th percentile. | Lighthouse in your browser’s developer tools; values from real visits in the Chrome UX Report | not yet measured against this criterion; there’s no measurement log yet |
Measured · Python 3.12.10, 98 pages and 3 address variants checked for scripts and external addresses
This gives you two rules for your requirements specification. First, “fast” only becomes testable with a number, a measuring tool and a method; with Lighthouse, that means the median of several runs. Second, an acceptance criterion has to be testable at sign-off. Values from real visits appear in the Chrome UX Report only once a page has a minimum number of visitors, and Google doesn’t disclose that number. So for a sign-off before launch, only the lab value will do. The value from real visits remains a goal for live operation.
Frequently asked questions
Who writes the requirements specification?
You, the client, are responsible for it. Others can write it for you, though: under the V-Modell XT Bund, the client can commission third parties to draw it up but remains responsible for its content and quality. Write it with the people who handle the workflow today, and approve every requirement yourself.
Is a requirements specification binding?
In the V-Modell XT Bund, the requirements specification is part of the contract. Also state in the quote or contract which document, in which version, defines the scope. In the same place, state what applies if the requirements specification and the functional specification contradict each other. Ask your lawyer what this means legally.
Can a requirements specification dictate the technology?
Only where the technology is already fixed, such as accounting software that stays in place or a requirement to store data in the EU. Otherwise, the V-Modell XT Bund advises against prescribing technical solutions in the requirements specification. That leaves the development team free to find the right one.
Does the template work for a website too?
Yes, the outline works for a website as well. There, the focus is on page structure, content, forms and how easily search engines can find the site. Our website migration checklist shows what’s involved when you rebuild an existing website.