Requirements Specification Example
A complete, fictional requirements specification for a small booking application that you can adapt section by section for your own project.
1 Overview
A requirements specification describes what a web application has to do, written from the point of view of the organisation that commissions it. In German-speaking projects it is called the Lastenheft. The client writes it, and the supplier answers with a proposal or a functional specification (Pflichtenheft) that explains how each requirement will be met. The document is the basis for comparable quotes, for the contract and, at the end, for deciding whether the delivered application is accepted.
For a small web application the document does not need to be long. Five to ten pages are usually enough, as long as every requirement can be checked.
What the document must contain
- Context: who you are, how the work is done today, and what goes wrong. A developer who understands the problem will propose better solutions than one who only receives a feature list.
- Goals: the few results the application must achieve, stated so that you can tell later whether they were reached.
- Users and roles: who uses the application, how often, on which devices, and what each role may see and change.
- Functional requirements: what the application does. Give every requirement its own number and describe one behaviour per number.
- Non-functional requirements: how well it does it. Loading time, supported browsers, accessibility, data protection, backups, hosting location, languages.
- Out of scope: what is deliberately not part of this project. This section prevents more disputes than any other.
- Acceptance criteria: the concrete checks that decide whether the work is finished.
- Open questions: everything you have not decided yet, with the name of the person who will decide.
How to write a requirement
Describe the result, not the technology. "A customer can cancel a booking up to 24 hours before pick-up without calling us" is a requirement. "Use a React calendar component" is a solution, and it removes the supplier's freedom to suggest something cheaper or more robust. Exceptions are real constraints, such as an existing accounting system that the application must exchange data with. State those as constraints and say why they exist.
Mark the priority of each requirement. Three levels are enough: must, should, could. When the quote is higher than your budget, the priorities tell both sides where to cut without endangering the purpose of the project.
Common mistakes
- Adjectives instead of measures. "Fast", "modern" and "user-friendly" cannot be tested. Write what a user must be able to do and how long it may take.
- Missing roles and permissions. Who may delete a record, who may see prices, and who may export customer data are questions that become expensive when they appear during development.
- No statement about existing data. If customer lists, products or old bookings have to be imported, say how many records there are and in what form.
- Forgetting the unhappy paths. What happens when a payment fails, an item is double-booked or an e-mail cannot be delivered?
- Acceptance criteria that only repeat the requirements. A criterion names a situation, an action and the expected result.
- Treating the document as final. Requirements change once people see a first version. Agree in advance how changes are requested, estimated and approved.
How to use the example
Copy the structure and replace the content. Keep the numbering, because it lets you refer to a requirement in quotes, in meetings and in the acceptance record. If personal data is processed, involve your data protection officer early; questions of contract law and liability belong with a lawyer, not in a template.
2 Example
The following requirements specification is entirely invented. Brackenfold Tool Hire, the people named and all figures are fictional and serve only to show the structure and level of detail.
Requirements Specification: Online Booking for Brackenfold Tool Hire
Version 1.0, prepared by Imogen Tarrant (Operations Manager)
1. Context
Brackenfold Tool Hire rents out construction and garden equipment from two depots. We have 14 employees and around 380 hire items. Bookings are taken by phone and e-mail and entered into a shared spreadsheet. In the last season we counted 37 double bookings, and staff spend roughly two hours a day answering availability questions.
2. Goals
- Customers can check availability and book online without calling us.
- Double bookings no longer occur.
- Phone time spent on availability questions drops by at least half within six months of launch.
3. Users and roles
- Customer: private or trade, mostly on a phone, books a few times a year.
- Depot staff (8 people): confirm handover and return, record damage.
- Administrator (2 people): maintain items, prices and user accounts.
4. Functional requirements
- F-01 (must): A customer can search items by category and see availability for a chosen date range and depot.
- F-02 (must): A customer can book one or more items and receives a confirmation by e-mail.
- F-03 (must): The system prevents an item from being booked twice for overlapping periods.
- F-04 (must): A customer can cancel free of charge up to 24 hours before pick-up.
- F-05 (must): Depot staff can mark an item as handed over, returned or in repair.
- F-06 (should): Trade customers can log in and see their past bookings and invoices.
- F-07 (should): The deposit is paid online by card at the time of booking.
- F-08 (could): Customers receive a reminder by e-mail the day before return.
5. Non-functional requirements
- N-01: The availability search shows results within 2 seconds on a normal mobile connection.
- N-02: The application works on current versions of Chrome, Safari, Firefox and Edge, on phones and desktops.
- N-03: Personal data is stored on servers within the EU; a daily backup is kept for 30 days.
- N-04: Customer-facing pages meet WCAG 2.1 level AA.
- N-05: Administrators can change items and prices without help from a developer.
6. Out of scope
- Delivery route planning.
- Integration with the accounting software (planned for a later phase).
- A native mobile app.
7. Existing data
About 380 items and 1,150 customer records exist as spreadsheets and must be imported once.
8. Acceptance criteria
- A-01: Two test users try to book the same item for overlapping dates at the same time; exactly one booking succeeds and the other user sees a clear message.
- A-02: A test customer completes a booking on a phone in under 3 minutes without assistance.
- A-03: A cancellation 25 hours before pick-up is accepted; one 23 hours before is refused with an explanation.
- A-04: All 380 items are imported with correct category, depot and daily rate, checked on a sample of 40.
- A-05: An administrator changes a price and the new price appears in the search immediately.
9. Open questions
- Which payment provider is used for deposits? Decision: Callum Reddish (Finance), by 15 March.
- Do trade customers get individual price lists? Decision: Imogen Tarrant, by 22 March.
3 Who this is for
Founder
You see how to turn an idea for an internal tool or customer portal into a document that developers can quote on, without having to decide on technology yourself.
Project manager
You get a numbered structure with priorities and testable acceptance criteria that carries through from the request for quotes to the final acceptance meeting.
Procurement lead
You receive a format that makes quotes from several suppliers comparable, because each one has to answer the same numbered requirements and state what is excluded.
4 Questions and answers
How long should a requirements specification for a small web application be?
Five to ten pages are usually enough. Length is not the measure. What matters is that every requirement has a number, describes one behaviour, carries a priority and can be checked at acceptance. A short document with twenty testable requirements is worth more than forty pages of description.
What is the difference between a Lastenheft and a Pflichtenheft?
The Lastenheft is written by the client and states what is needed and why. The Pflichtenheft is written by the supplier and states how the requirements will be implemented. In small projects the second document is often replaced by a detailed proposal that refers to the requirement numbers.
Do I have to specify the technology in the requirements specification?
No. Describe the results and name only real constraints, for example an existing system the application has to connect to, a required hosting location or a platform your team already maintains. The choice of framework and architecture is part of the supplier's answer, and you can ask them to justify it.
Planning a project like this?
Tell us what you are building. You get a straight answer on scope, approach and effort.