Most founders searching for a software requirements specification example find templates written for engineers, not for the person paying the bill. Those documents run to dozens of numbered sections, and it is hard to tell which ones matter for a web app, a booking portal or an online shop. This guide gives you a compact worked example, explains each line in plain language, and spends extra time on the part most briefs leave out: the quality requirements.
Here is the short version. A useful specification states what the product does, how well it must do it, which limits apply, and how you and your studio will agree it is finished. The first part is easy to write. The second part is where budgets quietly go wrong, so that is where we will spend most of our time.
A requirements specification states the functions the software must perform, the required level of performance, the nature of its interfaces to the environment, the constraints on design, and the quality of the final product. That wording comes from the requirements glossary printed alongside Rebecca Parsons' IEEE Software column on components. It is dry, but it hands you five boxes to fill. If a box stays empty, someone will fill it for you later, usually in the middle of a build.
The glossary also draws a line worth remembering. Functional requirements say what the software will do, while nonfunctional requirements describe how it does it. It adds that nonfunctional requirements are sometimes difficult to test, so people tend to judge them subjectively. That single sentence explains many disputes at handover, and we come back to it below.
Take a hypothetical regional training company. Customers should book course seats online, and staff should manage courses and waiting lists. The table below shows how a single page of requirements can look. The bracketed values are placeholders, because the real numbers come from your traffic, your budget and a feasibility check with your team.
| ID | Requirement statement | Type | How you will accept it |
|---|---|---|---|
| F-01 | A customer can search courses by date, location and topic, using each filter alone or combined. | Functional | A tester finds one named course using every filter alone and in combination. |
| F-02 | A customer can book and pay for a seat, and the system sends one confirmation email. | Functional | A test booking with each agreed payment method produces exactly one confirmation. |
| F-03 | Staff can close a course to new bookings and see its waiting list. | Functional | A staff user closes a course, and a customer then sees it listed as full. |
| P-01 | Search results appear within [X] seconds of a query, measured on the agreed test device and connection. | Performance | Timed on a test environment loaded with the agreed volume of courses. |
| I-01 | Each completed booking passes to the accounting tool the company already uses. | Interface | A booking appears in the accounting tool in the agreed format. |
| C-01 | Customer data is hosted in the region the company names, and the hosting provider is documented. | Constraint | The provider and location are written down and approved before launch. |
| Q-01 | A new staff member can create a course without training, within [X] minutes. | Quality attribute | Two unfamiliar staff members complete the task unaided in a test session. |
Each row has an identifier, a statement, a type and an acceptance test. The identifier lets you refer to F-02 in a change request instead of arguing about what 'the booking thing' meant. The type column keeps functions, quality targets, interfaces and constraints in one list without mixing them up. The last column matters most, because a requirement you cannot test is an opinion.
This software requirements specification example runs to seven lines, but the pattern scales, since you add rows rather than new ideas. Notice what it leaves out. It does not specify colours, typography or screen layouts, because those live in a design file. Nielsen Norman Group's guidance on design specs describes the pairing of a design file and a development issue, and the issue carries the requirements. Keeping the two apart stops a layout comment from turning into a hidden functional change.
Quality requirements are the ones most often missing, and published research backs that up. An IEEE Software study republished by InfoQ interviewed 13 architects at 12 software-intensive organizations, each about a single project. The authors note that the sample was not random, that most organizations were small or medium sized and all in Spain, and that most projects were noncritical. So treat it as a pointer, not a statistic about the whole industry. Still, the pattern is instructive.
In 10 of the 13 projects, the software architect was the main source of nonfunctional requirements. Some clients never mentioned them at all. One respondent described a client who never said that webpages could not take more than two seconds to load, but complained about it afterward. Others gave only broad indications, usually about cost or efficiency, and even where clients led, the architects added requirements from experience.
That is not a criticism of those teams. It is simply how gaps get filled when the buyer stays silent. The practical consequence for you is plain: if you do not state your quality targets, a studio will assume some, and its assumptions may differ from yours.
Nine of the 13 respondents had not documented their nonfunctional requirements, and one said plainly that documentation costs money. Only two expressed their requirements in measurable form. The authors link that to low validation, citing earlier work which found that non-measurable terms make testing time-consuming or even impossible. Eleven respondents said all requirements had been met, yet only eight had validated any type, and then against just one to three of them. Nobody mentioned validating security.
The authors separate perceived compliance from real validation, and that distinction is useful in your own contract. Respondents also agreed that elicitation continues through the life cycle, often until a prototype exists, and that some requirements, security among them, cannot be fully checked before deployment. So write a first version, plan a revision after the prototype, and budget time for it.
Every measurable requirement has the same four parts: the behavior, a number, the conditions and the method of checking. Jama Software's functional requirements examples show the shape with a statement that the system shall display search results within 0.5 seconds of the user entering a query. The number belongs to their example, not to your product, but the structure carries over. Conditions matter as much as the figure, since a number without a test setup cannot be checked.
| Vague wish | Measurable version | Who sets the number |
|---|---|---|
| It must be fast | Search results appear within [X] seconds of a query on the agreed test setup. | You, based on expected traffic, after the studio confirms feasibility. |
| It must be reliable | An agreed availability target during business hours, and no booking lost if the payment provider times out. | You and the studio together, once the cost of each option is visible. |
| It must be easy to use | A new staff member completes the course-creation task unaided within [X] minutes in a test session. | You, based on how often staff change and how much training you can afford. |
| It must be secure | Access by role, personal data handled to GDPR duties, and checks run on the deployed system. | You, with the studio and a data protection professional. |
ISO/IEC 25000 defines performance efficiency as performance relative to the amount of resources used under stated conditions. The phrase 'stated conditions' does the work. The InfoQ authors found respondents using 'performance' and 'efficiency' interchangeably, which forced extra clarification, so define your terms in a short glossary at the end of the document.
Some targets resist pre-launch proof, and availability and security are the usual examples. For those, write the target, the agreed method of checking and a review date, instead of pretending a single test settles it. Data protection belongs in this group too. Costs and obligations vary by product, so a data protection professional should confirm what GDPR requires for your case.
ReqView publishes a worked specification based on ISO/IEC/IEEE 29148:2018. It opens with purpose, scope, product perspective, product functions, user characteristics, limitations, assumptions and dependencies, and definitions, then moves on to external interfaces and functions. That structure suits regulated or contract-heavy work. For most small and mid-sized builds, you can trim it and keep the discipline.
The ReqView example also breaks out memory constraints, hardware interfaces and site adaptation requirements. Unless your product runs on specialised devices or in a restricted environment, a single line saying 'not applicable' is enough. If a contract, a regulator or a tender requires a full structure, ask your partner and whoever owns the contract before you cut anything.
Give the assumptions section real attention, because cost surprises hide there. Think of a data migration nobody sized, a content set that arrives late, or an approval that depends on a third party. Each assumption you write down is a risk you can price or remove before kickoff.
Nielsen Norman Group notes that many development teams treat the development issue as a contract between design and development: what the issue outlines is what the developer must deliver. In that same article, an issue typically holds the goal, what is in and out of scope, functional and nonfunctional requirements, relevant use cases, and risks with mitigations. That content should come from the product owner or tech lead, which on your side usually means you.
Size matters too. The article observes that small specs are easier to create and implement than one very large spec, and it suggests breaking up a spec that becomes hard to maintain. For a buyer, that translates into slicing by release. The first release gets its own requirements and acceptance tests, while later releases are listed but not detailed.
State exclusions in writing, such as a native mobile app or a second language, so nobody has to guess. Changes will come, of course. When a design changes, the team should discuss the update and its timeline, and the document should record it. A requirement that changes silently is how a fixed quote turns into a dispute.
Rebecca Parsons makes a point in her IEEE Software column that applies directly to acceptance. Defining expected behavior at the component level is not enough to ensure correct behavior at the system level, and the most rigorous component-level testing will not give assurance that the desired result has been achieved. Her subject was component-based systems, but the lesson travels well. Write acceptance scenarios that cross features instead of checking each feature alone.
In the booking example, that means one scenario running from search through payment, the confirmation email and the entry in the accounting tool. A demo of each feature on its own proves less. Write the scenarios into the specification, name who runs them, and state what counts as a pass. Agree up front how defects are handled and what sign-off means, then link payment milestones to those sign-offs in the contract.
A Gartner Peer Community discussion asks a useful question: if you use GenAI for software requirements gathering, which parts of the process need a human in the loop? The answer depends on who owns each decision. An AI tool can plausibly help you tidy wording, flag ambiguous terms such as 'fast' or 'user-friendly', and spot rows that contradict each other. It cannot know your budget ceiling, your tolerance for downtime or which feature you would drop first.
Those are business decisions, so the numbers and priorities stay with you. If the product itself includes an AI feature, the same discipline applies, so give the feature a measurable quality line and an acceptance test. Our guide to connecting AI to your business infrastructure covers the integration side of that decision.
If the build replaces existing software, the old system is a source of requirements. Rules that nobody wrote down often live inside it: a rounding convention, a monthly report finance relies on, or a manual workaround one long-serving employee performs every Friday. List the reports, the integrations and the workarounds, then mark each as keep, change or retire. Not sure whether your system counts as legacy? Our piece on what a legacy software system is lists the signs to look for.
A studio prices uncertainty. When a brief says 'fast' and 'secure', the quote has to carry a wide margin or a stack of assumptions, because nobody knows what you meant. Measurable lines narrow that margin and show where the cost sits. There is an honest trade-off, though: precise requirements take your time up front, and they can reveal that a target costs more than you hoped, which is better to learn before kickoff.
Quality targets also shape architecture. The InfoQ authors describe nonfunctional requirements as selection criteria among designs, for instance a layered architecture justified by maintainability or a database technology chosen for efficiency. They also found that about 40 percent of the requirements respondents considered were nontechnical, such as licensing or cost, and one respondent said money rules and everything has to adapt to it. So write your budget ceiling and licensing preferences into the limitations section, where they can steer decisions.
Send your draft to your studio with one request: return it with every line marked as clear, needs a number, or needs a decision. That marked-up copy makes a better first working session than another round of general discussion.
There is no fixed page count. It should be long enough that every requirement has an identifier and a test, and short enough that you will keep it current. For many small builds, a few pages covering purpose, scope, functions, interfaces, limits and definitions are enough.
The standard is a useful reference for structure, and ReqView publishes a worked example based on it. Most small and mid-sized projects can use a trimmed version. If a contract, tender or regulator requires the full structure, confirm that with your partner and whoever owns the contract.
You own the numbers, because they reflect your budget, traffic and risk tolerance. The studio should advise on what is feasible and what each target costs. An IEEE Software study of 13 architects found that in 10 projects the architect was the main source of these requirements, so state yours early.
AI tools can help tidy wording and flag ambiguous terms or contradictions. Decisions about budget, priorities, quality targets and acceptance remain yours, so review every line before it goes to a studio.
No. A design spec, as Nielsen Norman Group describes it, covers the functionality, behavior and appearance of a design, usually as a design file plus a development issue. The requirements specification states what the whole system must do and how well, and the two should stay consistent.
Keep reading
A quote for a headless shop looks larger than the platform price suggests. Here is where the money goes, what founders underestimate, and when the spend pays back.
A plain-language guide for founders and business owners on writing a specification your studio can price, build and test against, without writing any code.
A stage-by-stage plan for deciding what to build, what to rent and how to brief a development partner, so each euro buys learning or revenue.
