Basics
Software specifications: what belongs in a functional specification and how detailed it needs to be
By Dominik Natter · Last updated on 5 November 2026 · 9 min read
In short
You write the requirements specification as the client: it describes what the software should do and why. The supplier writes the functional specification: it describes how your requirements will be implemented. For an SME, a lean requirements specification with clear goals, workflows and priorities, followed by a discovery phase, is usually enough. A complete software functional specification before the project starts rarely makes sense when the software is developed in agile stages.
Requirements specification vs functional specification: what is the difference?
In German-speaking countries the two terms, Lastenheft and Pflichtenheft, come from the project management standard DIN 69901-5. The requirements specification (Lastenheft) sets out what the client demands of the contractor's deliveries and services. The functional specification (Pflichtenheft) contains the implementation rules the contractor derives from it.
Put simply: the requirements specification says what the software should do and why you need it. The functional specification says how the supplier will build it and with what. You write the requirements specification; the supplier writes the functional specification, ideally together with your own specialists.
In practice the terms are often mixed up. Many companies call their requirements document a functional specification even though it is really a requirements specification. That is fine, as long as it is clear who describes what and who is responsible for what.
Requirements specification and functional specification compared
Requirements specification
- Written by the client, meaning you.
- Describes the problem, the goal and the requirements: what and why.
- Created before you approach suppliers.
- Serves as the basis for comparable quotes.
- Does not prescribe a technical solution.
Functional specification
- Written by the contractor, meaning the supplier.
- Describes the implementation: how and with what.
- Created after the requirements specification, often in a discovery phase.
- Serves as the basis for implementation, acceptance and a fixed price.
- Covers the solution design, interfaces, technology and stages.
Does an SME need a functional specification at all?
A complete functional specification that defines every screen and every special case before the project starts is not worth it for most SMEs. It takes a lot of time, and part of it is out of date as soon as the first users see the software. When software is developed in stages, the details are clarified anyway when each stage comes up.
What you need is a lean requirements specification: goal, workflows, volumes, interfaces and priorities. That is enough for suppliers to quote seriously. The implementation details are then worked out in a discovery phase with the supplier you have chosen.
A detailed functional specification makes sense if you have to run a formal tender, for example as a public body, if several suppliers need the same basis for an overall fixed price, or if the work is to be carried out largely without follow-up questions.
Functional specification template: what to include
The outline below works as a template for your requirements specification. In it you describe what you need. The supplier later adds how it will be built, in the functional specification or in the discovery phase. Not every point needs several pages. What matters is that none is missing.
Outline for requirements and functional specifications
1. Starting point and goal
How do you work today, and what is wrong with it? What should be better after the project, and how will you measure it? Example: quotes should go out the same day instead of after three days. Also state what is explicitly not part of the project.
2. User roles
Who works with the software, and who is allowed to do what? For example office staff, field staff, accounting, customers in the portal and administrators. Estimate the number of users per role.
3. Workflows
Describe the most important processes step by step, from enquiry to invoice. A simple flow chart or a list is enough. Note where Excel, paper or email are involved today.
4. Features with priorities
List the features and give each one a priority: must, should or could. Must means the software cannot go live without it. If everything is a must, the supplier cannot plan sensibly.
5. Data and volumes
What data does the software manage, and how much? For example the number of customers, products, orders per month and documents per year. Where does the existing data come from, and what state is it in? Data migration is often underestimated.
6. Interfaces
Which systems does the software need to exchange data with? Typical ones are ERP, accounting, online shop, payment provider, email and calendar. For each system, state the vendor, the version, who looks after it and which data flows in which direction.
7. Non-functional requirements
These are qualities rather than features: security and access control, availability and response times, use on mobile phones, languages and data protection.
For data protection, Switzerland has its Federal Act on Data Protection, and in Liechtenstein, and for many customers in the EU, the GDPR also applies. Record which personal data is processed and where the data may be stored, for example only with hosting in Switzerland.
8. Acceptance criteria
How will you know a feature is finished? Write testable criteria and, where possible, test cases using real examples from your day-to-day work. Define who signs off and how defects are reported.
9. Operation and maintenance
Who runs the software after go-live, who installs updates, and how quickly must someone respond to an incident? Budget 15 to 20 percent of the project cost per year for maintenance and further development.
10. Rights to the source code
State that you will have access to the source code and which rights you receive, for example so that another supplier can develop the software further. More on this in our guide «Who owns the source code of custom software?».
11. Timeline and budget range
Are there fixed dates, such as a trade fair, the start of a season or the end of support for an old system? Also give a budget range. It helps the supplier propose a suitable solution rather than the most expensive or the cheapest.
How detailed do software requirements need to be?
Precise enough that someone can later check whether the requirement has been met. And open enough that the supplier can propose the best way to get there.
A good requirement describes the problem and the result, not the screen layout. It gives volumes, times or examples where they matter. Words like fast, simple or user-friendly cannot be tested without a yardstick.
For a quote it is enough if scope and difficulty are clear. The finer points, such as which fields a screen has, are better settled with the users in the relevant stage.
Requirements: vague and better worded
| Vague | Better | Why |
|---|---|---|
| The software should be fast. | Customer search shows results in under two seconds, even with 20,000 customers. | Measurable, with a volume |
| Integration with our ERP. | Products, prices and stock come from the ERP every hour; orders go back immediately. | Data, direction and frequency are clear |
| We need a dashboard. | Every Monday, management sees open quotes, revenue per month and overdue invoices. | Describes the problem, not the solution |
| User-friendly for field staff. | A service report can be entered on a phone at the customer's site in three minutes, even offline. | Testable in daily work |
| Migrate data from the old system. | Customers and open orders from the last five years are migrated; older data stays in the archive. | Scope of legacy data defined |
| The software must be secure. | Access only with two-factor sign-in, field staff see only their own customers, data is stored in Switzerland. | Concrete rules instead of a wish |
Common mistakes in requirements specifications
We see these mistakes again and again. Each of them leads to quotes that cannot be compared, or to change requests during the project.
- Describing a solution instead of the problem: «a button that creates a PDF» instead of «the customer needs an order confirmation». This rules out better solutions.
- Marking everything as a must: the supplier can then neither prioritise nor propose a first stage that delivers value quickly.
- Forgetting interfaces: every system that exchanges data costs CHF 3,000 to 15,000 depending on the interface. If one is missing from the requirements, it is missing from the quote too.
- No acceptance criteria: without testable criteria, acceptance turns into a negotiation.
- Forgetting legacy data: records from Excel, FileMaker or an old application have to be cleaned up and migrated. That is often more work than expected.
- Writing at a desk instead of with the users: the people who run the process every day know the special cases. Involve them early.
From requirements specification to quote
A requirements specification on its own does not give you a reliable fixed price for the whole project. The price becomes reliable in two steps: first a discovery phase at a fixed price, then stages, each with its own cost ceiling. This is how it works with us:
01
Requirements specification
You describe the goal, workflows, volumes, interfaces and priorities. A few pages are enough if nothing important is missing.
02
Questions and first meeting
We ask about gaps and unclear points and give a first assessment of effort and approach.
03
Discovery phase with workshops
In two to three weeks we clarify requirements, solution design and interfaces with your specialists. Fixed price CHF 4,000 to 9,000.
04
Specification or backlog
The result is a prioritised list of requirements with a stage plan and a cost ceiling. You then decide freely whether to go ahead, and with whom.
05
Fixed price per stage
Each stage has its own cost ceiling and ends with acceptance. New requests go onto the list for the next stage.
How to recognise a good quote
When you receive several quotes based on your requirements specification, look for these points:
- The supplier asks questions before naming a price. Anyone who quotes an overall fixed price straight away has either built in a buffer or made assumptions you do not know about.
- Assumptions and exclusions are stated in the quote: what is not included, such as work by your ERP partner, hosting or licences?
- The quote proposes stages, and the first one already delivers value in daily work.
- Acceptance, maintenance and source code rights are covered, not just development.
What does a functional specification or discovery phase cost?
A requirements specification mainly costs you internal time: for talking to users, gathering volumes and examples, and writing.
With us, the content of a functional specification is produced in the discovery phase. It takes two to three weeks and usually costs CHF 4,000 to 9,000 at a fixed price, as a guide figure excluding VAT. You receive requirements, a solution design, a stage plan and a cost ceiling.
A detailed functional specification for a formal tender takes considerably more effort. What it costs depends on the size of the project. Ask for a separate quote for this work instead of having it hidden in a project price.
Requirements specification, discovery phase, functional specification and backlog at a glance
| Document | Who creates it | Result | Effort |
|---|---|---|---|
| Requirements specification | You as the client | Basis for comparable quotes | internal time |
| Discovery phase | Supplier with your specialists | Requirements, solution design, stage plan, cost ceiling | with us CHF 4,000 to 9,000, fixed price, 2 to 3 weeks |
| Functional specification | Supplier | Binding rules for implementation and acceptance | depends on scope, get a quote first |
| Backlog | jointly, maintained continuously | Prioritised list of requirements per stage | part of the stages |
Where this information comes from
Standards and guidelines
The terms Lastenheft (requirements specification) and Pflichtenheft (functional specification) are defined in the German standard DIN 69901-5:2009-01, Project management, Part 5: Concepts. The guideline VDI 2519 Part 1 of December 2001 describes how to compile both documents and contains a checklist covering, among other things, interfaces, commissioning and quality. Both texts are paid publications. We paraphrase the definitions, based on the catalogue entries at DIN Media and on a seminar paper from Ludwig-Maximilians-Universität München that quotes the standard.
Data protection
In Switzerland the Federal Act on Data Protection (FADP, SR 235.1) applies. In Liechtenstein the EU General Data Protection Regulation applies through the EEA Agreement, supplemented by Liechtenstein's Data Protection Act. Whether the GDPR also applies to a Swiss company depends on whether it offers goods or services to people in the EU or monitors their behaviour.
Prices and process
The duration and price of the discovery phase, the cost per interface and the share for maintenance match the information on our service pages and in our guide «What does custom software cost in Switzerland and Liechtenstein?». All amounts are guide figures excluding VAT.
No legal advice
This guide is not legal advice. Have contracts, acceptance rules and questions about source code rights reviewed by a lawyer where needed.
As of November 2026.
Frequently asked questions
Who writes the functional specification and who writes the requirements specification?
You write the requirements specification as the client: it describes what the software should do and why you need it. The supplier writes the functional specification: it describes how your requirements will be implemented. With us, the content of a functional specification is worked out in the discovery phase, together with your own specialists.
Do we need a functional specification if the software is developed in an agile way?
A complete functional specification before the project starts rarely makes sense with agile development, because many details only become clear once users see the software. What matters is a clear goal, prioritised requirements and testable acceptance criteria for each stage. With us, the discovery phase with its stage plan and cost ceiling replaces the thick specification, and the details follow stage by stage.
How long should a requirements specification be?
As short as possible, but precise enough for a supplier to estimate scope and effort without many follow-up questions. The goal, workflows, volumes, interfaces and priorities matter more than the page count. Detailed screen designs are not needed at this point; they are better worked out with the users in the relevant stage.
What is the discovery phase and why does it come first?
In two to three weeks, the discovery phase establishes what will be built, how it fits into your systems and what it will cost. You receive requirements, a solution design, a stage plan and a cost ceiling. The price is fixed, usually CHF 4,000 to 9,000. After that you are free to decide whether to go ahead, and with whom.
What happens if our requirements change during the project?
Changes are normal and planned for. New requests go onto a shared list and are estimated. You decide whether an item joins the current stage, is swapped for something else or moves to the next phase. That is how the cost ceiling stays binding.
What does a project with Natter Solutions cost?
A single automation or interface starts at around CHF 8,000. Business applications such as customer portals or the replacement of an Excel solution usually come to between CHF 25,000 and 100,000, larger platforms more. Every solution page shows a price range. It becomes binding after the discovery phase, which you receive at a fixed price.
Matching services:Custom software
Let us talk about your case.
20 minutes are enough to find out whether a custom solution is worth it for you.