A software requirements specification (SRS) describes everything a system must do in enough detail for whoever builds it. Write it in nine sections: overview, users and roles, first-release scope, numbered functional requirements, user stories with acceptance criteria, data, non-functional requirements, out of scope, and open questions. Make every requirement one testable sentence. In Fanann, the product owner Noura asks the questions that settle scope, then writes the document and the task list and hands them to the builder.
- how to write an SRS
- software requirements specification template
- how to write requirements for an app
- SRS vs PRD
- user story and acceptance criteria examples
- how to write a requirements document for a developer
What is a requirements document, and do you really need one?
A software requirements specification (SRS) describes what a system must do: who uses it, what each user can do, what data it holds and which rules apply. It names no programming languages. It is a written agreement between whoever wants the system and whoever builds it.
You need one whenever there is a second party: a freelancer pricing the work, a company you will sign with, or an AI building from your description. Without it, each side builds the system in their own head.
- It answers
- What exactly does the system do?
- Its readers
- Whoever builds, tests and approves
- Length for a small app
- Two to four pages
- It leaves out
- Programming languages and technical choices
SRS, PRD or a one-page brief: which should you write?
The difference is the question each document answers:
Pick the one that sounds like you to see the advice.
A project brief: one page with the problem, audience and solution. If the idea will not fit a page, it is not ripe yet.
A product requirements document (PRD): problem, audience, goals and success metrics. See writing a PRD with AI.
An SRS: everything the system does, in the detail a builder needs. It is what a developer asks for before quoting.
A release roadmap: what goes into the first release and what waits.
What sections does an SRS contain? A ready template
This template suits most small and mid-sized apps. The example is an appointment system for a dental clinic.
| Section | What goes in it | Example |
|---|---|---|
| 1. Overview | What the system is and for whom, in a paragraph | Patients book appointments; reception manages the doctors' schedule |
| 2. Users and roles | A table: role and what it can do | Patient, receptionist, doctor, manager |
| 3. First-release scope | A list of what release one includes | Booking, cancelling, today's schedule, reminders |
| 4. Functional requirements | Numbered sentences for what the system does | R-12: the system prevents two appointments at one time for one doctor |
| 5. User stories and acceptance criteria | A story per feature with its conditions for done | See the next section |
| 6. Data | The things stored, their fields and relations | Appointment: patient, doctor, date, time, status |
| 7. Non-functional requirements | Language, devices, security, privacy | Arabic right-to-left, works on phones |
| 8. Out of scope | What will explicitly not be built now | Online payment, medical records |
| 9. Open questions | What is undecided, and who decides | Can a patient book without an account? |
How do you write a clear functional requirement?
A good requirement can be ticked or crossed after the build. If judging it needs a discussion, it is a wish.
- The system is easy to use
- Patients can manage their appointments
- Notifications for patients
- Comprehensive reports for the manager
- The system is secure
- A patient completes a booking in at most three steps
- A patient can cancel up to 6 hours before; after that the clinic's number is shown
- The patient receives a reminder one day before the appointment
- The report shows appointments and no-shows per doctor per month
- A doctor sees only their own patients' appointments
Five rules of wording
- One requirement per sentence. If you see 'and', it is probably two.
- Number every requirement (R-1, R-2) so you can refer to it.
- Start with the actor: 'The receptionist can…', 'The system prevents…'.
- Write the numbers: hours, attempts, characters.
- Write what happens on failure too.
How do you write user stories and acceptance criteria? Ready examples
A user story ties a feature to its owner and goal: As a [role], I want [action], so that [benefit]. Acceptance criteria say when the story counts as done: given a situation, when an action happens, then a result appears.
| User story | Acceptance criteria |
|---|---|
| As a patient, I want to book from my phone, so that I do not have to call the clinic | Given I am signed in, when I pick a doctor and a day, then only free slots appear. When I confirm, then it shows under 'My appointments' and I get a confirmation |
| As a receptionist, I want to see today's schedule, so that I can prepare files | Given appointments exist today, when I open the schedule, then they appear sorted by time with patient, doctor and status. When there are none, 'No appointments today' shows |
| As a patient, I want to cancel my appointment, so that someone else can use it | Given it is more than 6 hours away, when I cancel and confirm, then its status becomes 'cancelled' and the slot is free again. With less than 6 hours left, the button is hidden and the clinic's number shows |
What are non-functional requirements, and what goes out of scope?
Functional requirements say what the system does; non-functional ones say how it behaves while doing it. They are often forgotten until complaints arrive.
If your system collects personal data in Saudi Arabia or the UAE, data protection laws apply; check their official sources. A starting point is the PDPL checklist for apps.
Under 'out of scope', list what someone will ask about and you will not build now, marked 'later' or 'never': online payment later; medical records never; the mobile app in release two.
How do you write a document AI builds well from?
A document a new developer understands without phoning you works for AI too. Four extra habits help:
- State the data explicitly. A person infers that an appointment has a status; a tool may or may not. Write: appointment status: confirmed, attended, no-show, cancelled.
- Put roles in a table. A row per role and a column per ability: view, add, edit, delete.
- Separate release one from the rest. Forty unordered features all get half built. Say: these eight first.
- Use the same names throughout. If you wrote 'appointment', do not later call it 'booking' or 'visit'.
Hand over release one, review it, then add, as in build one feature at a time. If you draft with a general chat assistant, read plan your app with ChatGPT or Claude.
How does Noura write the document for you in Fanann?
The blank page is the hardest part. Product Owner Noura in Fanann starts from the other end: you tell her your idea as you would a friend, she asks the questions that settle the decision, then writes the document.
- 1Explain the idea
In the chat, or from a suggested opener such as 'Write a requirements document (SRS) for…'.
- 2Answer her questions
Who are the users, what goes into release one? She tells you frankly what to start with and what to drop.
- 3Receive the document and tasks
The document appears in the Documents tab (SRS, PRD, brief or release roadmap), with a prioritized list in the Tasks tab.
- 4Revise one part
Select a passage, choose 'Edit this part' and ask: expand, shorten, add examples. Only that passage changes. You can also edit it yourself.
- 5Approve and hand off
Mark the document final, then send it to the builder: web or mobile, a new app or a change to an existing one, with a plan first or a direct build.
Write an SRS for an appointment system for a dental clinic with three doctors and one receptionist. Patients book from their phones with a phone number and can cancel up to 6 hours before. Reception sees each doctor's schedule for today and adds appointments for people who call. A doctor sees only their own appointments and marks attended or no-show. The manager sees a monthly report of appointments and no-shows. Out of scope for now: online payment and medical records. Ask me about anything missing first, then write numbered sections: roles table, functional requirements, user stories with acceptance criteria in given, when, then form, data, and non-functional requirements. Suggest what to defer to release two.
Try it in FanannWhat are the common mistakes, and how do you review before handing over?
Illustration- Describing the solution, not the need: 'a blue button at the top' rather than 'booking is reachable from any screen'.
- Everything is high priority: then nothing is.
- A document that is never updated: after the first verbal change it is history, not a reference.
- Forgetting the admin panel: who adds doctors or changes opening hours?
- Guessing legal requirements: check invoices, tax and privacy at official sources.
Building and testing follow, and your acceptance criteria are what gets tested. The full picture is in an AI product team: plan, build and test.
Key takeaways
- An SRS answers 'what exactly does the system do'; a PRD answers 'why are we building it, and for whom'.
- Each requirement is one numbered sentence you can test with a yes or no.
- Acceptance criteria define 'done': the situation, the action, the expected result.
- The 'out of scope' section protects you from disputes more than any other.
- A document a new developer understands without calling you also works for building with AI.
Frequently asked questions
What is the difference between an SRS and a PRD?
How many pages should a requirements document be?
Do I need a requirements document if I build with AI?
Who writes the requirements document?
Should it be written in Arabic or English?
What do I do when requirements change after work starts?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “How to write a requirements document (SRS) for people and AI” https://fanann.com/en/blog/write-a-requirements-document/ My question: how to write an SRS Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.