En
Fr
De
It
Es
Uk
What should a software requirements specification contain?
A software requirements specification for a fixed-price project needs twelve sections: goal and success metrics, users and roles, scope and out of scope, user flows, functional requirements per feature, business rules, data and migration, integrations, non-functional requirements, acceptance criteria, assumptions and open questions, and milestones. Write each requirement as observable behaviour with a clear pass or fail test, list what is excluded as carefully as what is included, and keep the document to 5 to 20 pages for a typical business application.
Download: Software requirements specification template (Word, .docx). It contains all twelve sections with prompts and an example, ready to fill in.
Since 2020 we have quoted and delivered fixed-price projects for companies in the US, UK and EU. The single best predictor of a smooth project in our own records is a clear written scope before the contract; unclear scope caused almost all disputes about budget. This template is the structure we wish every buyer brought to the first call.
Why does a fixed-price project need a specification?
A fixed price is a promise to deliver a defined scope for a defined amount. If the scope is vague, one of three things happens: the vendor adds a large risk margin to the quote, the vendor quotes low and recovers the difference through change requests, or both sides argue at acceptance about what was meant. A good specification removes most of that uncertainty, so quotes from different vendors become comparable and the price you sign is the price you pay. Our guide on fixed price vs time and materials covers when a fixed price is the right model at all.
The twelve sections, and what to write in each
| # | Section | What to write | Typical length |
|---|---|---|---|
| 1 | Goal and success metrics | Why the project exists and the numbers that will show it worked | Half a page |
| 2 | Users and roles | Every type of user, what each may see and do | Half a page |
| 3 | Scope and out of scope | The features included, and explicitly what is not included | One page |
| 4 | User flows | The main journeys step by step, from trigger to result | 1 to 3 pages |
| 5 | Functional requirements | Per feature: what the user can do and what the system does | 2 to 8 pages |
| 6 | Business rules | Calculations, statuses, approvals, limits, exceptions | 1 to 3 pages |
| 7 | Data and migration | Main entities, data that exists today, what must be moved | 1 page |
| 8 | Integrations | Every external system, direction of data, who provides access | 1 page |
| 9 | Non-functional requirements | Users and volume, speed, availability, security, languages, devices | Half a page |
| 10 | Acceptance criteria | How each feature will be checked before you accept it | 1 to 2 pages |
| 11 | Assumptions and open questions | What you assume, what is not decided yet and who decides | Half a page |
| 12 | Milestones and delivery | Stages, what is delivered at each and how payment follows | Half a page |
1. Goal and success metrics
Two or three sentences on the business problem, then numbers. "Order entry takes 12 minutes per order and produces 4 percent errors; after launch it should take under 3 minutes with under 1 percent errors." A vendor who knows the goal can suggest a cheaper way to reach it.
2. Users and roles
List each role with its count and its rights: "Dispatcher (6 people): sees all orders, assigns couriers, cannot change prices." Roles drive a surprising share of the cost, because every permission rule is code and a test.
3. Scope and out of scope
The out-of-scope list is the most useful paragraph in the document. Write down what someone might reasonably expect and will not get in this phase: a mobile app, a customer portal, reporting beyond the three listed reports, data older than two years, a second language.
4. User flows
Describe the main journeys as numbered steps, including what happens when something goes wrong. A sketch or a screenshot of the current spreadsheet helps more than a page of text.
5. Functional requirements
Per feature, write short numbered statements in the form "The user can..." and "The system does...". Avoid words that cannot be tested, such as fast, intuitive or flexible, and replace them with the behaviour you mean.
6. Business rules
Calculations, status changes, approval chains, discounts, rounding, time zones, deadlines. Give an example with real numbers for every rule; examples catch misunderstandings that definitions hide.
7. Data and migration
List the main records the system keeps, where that data lives today and how much of it there is. Migration is often underestimated: say whether old data must move, how clean it is and who will check it after import.
8. Integrations
For each external system: its name, what data goes in which direction, how often, whether an API exists, and who provides credentials and a test account. An integration without a test account is the most common cause of delay in our projects.
9. Non-functional requirements
Number of users and records, expected peak load, required response time for key screens, availability expectations, backup and data retention, hosting region, security or compliance requirements, supported browsers and devices, languages.
10. Acceptance criteria
For each feature, the checks you will run before you accept it, written as given, when, then. See the example below.
11. Assumptions and open questions
Every assumption you make, and every question not yet answered, with the person who will answer it and by when. Open questions are normal; hidden ones are what break a fixed price.
12. Milestones and delivery
Stages with their deliverables, an acceptance window for each, and how payments follow accepted milestones. Add a short change-control rule: changes are described in writing, estimated and approved before they are scheduled.
A filled example: one feature
Here is how sections 5, 6 and 10 look for one feature of an order management system.
Feature: Approve large orders
Functional requirements
5.1 The system marks an order "Needs approval" when its total is above the
customer's approval limit.
5.2 A sales manager can approve or reject a marked order and must add a
comment when rejecting.
5.3 The system notifies the order owner by email within 1 minute of the
decision.
Business rules
6.1 Default approval limit is $5,000; a sales manager can set a different
limit per customer.
6.2 The limit compares the order total including tax.
Example: limit $5,000, order $4,600 + 10% tax = $5,060 -> needs approval.
Acceptance criteria
10.1 Given a customer with a $5,000 limit, when an order of $5,060 including
tax is saved, then its status is "Needs approval".
10.2 Given a marked order, when a sales manager rejects it without a comment,
then the system refuses and shows "Comment required".
10.3 Given an approved order, then the order owner receives an email within
1 minute that names the approver.
Every line can be checked by someone who has never seen the code, and every line can be estimated by a developer. That is the test for a good requirement.
How do you write acceptance criteria that hold up?
- Make them observable. Describe what a person sees or what data changes, never what the code does internally.
- Use real numbers. "Over the limit" invites debate; "$5,060 against a $5,000 limit" does not.
- Cover the unhappy path. Missing data, a rejected payment, a partner API that does not answer.
- Agree on test data. Name the sample customers, orders or documents that acceptance will use.
- Set an acceptance window. For example, 5 working days per milestone, after which delivered work counts as accepted unless defects are reported.
Mistakes that turn a fixed price into change requests
- No out-of-scope list. Every unstated expectation becomes a dispute.
- Integrations named but not described. "Sync with our ERP" can mean a nightly file or a real-time two-way API.
- Rules without examples. The vendor implements the rule as written, and the business meant something else.
- Migration left for later. Ten years of messy records move at the end, under time pressure.
- Design by adjective. "Modern and user-friendly" is a style wish; screens or a reference product are a requirement.
- One giant milestone. Payment and acceptance at the end make every disagreement expensive.
- Copying another product. "Like Salesforce, but simpler" has no boundary. Describe your own flows.
How do vendors turn a specification into a fixed quote?
A good vendor reads the document, asks questions about the gaps, and returns a quote broken into milestones with the assumptions written out. If a vendor quotes a fixed price without a single question, assume the risk has been priced in or postponed to change requests. Our guide on how to choose a custom software development company lists the questions worth asking at that stage, and custom software development cost shows typical ranges by project type.
With Lytvynov Production projects start from $10,000, and we give a fixed quote after a short scoping call. If the scope is still forming, a time-boxed format avoids the problem: our AI Sprint is a fixed $10,000 for 4 weeks with the goal agreed in advance, and our guide on fixed price AI development explains when that model works better than a fixed feature list.
How we use specifications in our projects
We are a software development company founded in 2020 that builds CRMs, ERPs, SaaS products and AI features for companies in the US, UK and EU. On an ERP for a US aircraft service company the scope covered client and order management, service scheduling, workforce shifts, warehouse inventory and compliance tracking; on a rebrand for a French IT freelance marketplace we delivered a fixed scope within a fixed budget.
Send us your filled template, or a rough draft, and we will come back with questions, a milestone plan and a fixed quote. You can also start with our estimate form for a first range in a few minutes.
