How to Write a Software Requirements Document

A software requirements document (often called an SRS) is a written description of what a system must do, who it is for and the conditions it must work under, agreed before the build begins. To write a good one, state the purpose and scope, list the users, describe each requirement in clear and testable terms, add non-functional needs such as security and performance, record assumptions and exclusions, and get the people who will use and pay for the system to review it. Below is a practical outline, with examples of good and weak wording.

Why a requirements document matters

Most arguments in software projects come from two people remembering a conversation differently. A written document gives everyone something to point at. It also lets a development team estimate honestly, because they can see what is in and what is out, and it gives you a basis for checking the finished work.

It does not have to be heavy. It has to be specific enough that two different developers reading it would build roughly the same thing.

A practical outline

1. Purpose and background. What problem is being solved and why now.
2. Scope. What the system includes and, equally important, what it does not.
3. Users and roles. Who uses it, and what each role may do.
4. Functional requirements. The behaviours the system must provide.
5. Non-functional requirements. Performance, security, availability, accessibility, compliance.
6. Data. What is stored, where it comes from, how long it is kept.
7. Integrations. Other systems it must exchange data with.
8. Constraints, assumptions and dependencies. Budget, deadlines, technology limits, things outside your control.
9. Acceptance criteria. How each requirement will be checked.
10. Open questions and glossary. Unresolved items and definitions of business terms.

Step 1: Start with purpose and scope

Write a short paragraph on the problem, then a scope statement in two lists: in scope and out of scope. For example, an order-tracking tool might include customer order status pages and staff updates, and explicitly exclude payment processing and a mobile app in the first release. This single section prevents more disputes than any other.

Step 2: Identify users and roles

List every type of user: customer, staff member, manager, administrator, external auditor. For each, note what they need to achieve. Roles drive permissions, screens and security rules later, so missing one now means rework later.

Step 3: Write functional requirements clearly

Describe each behaviour in one sentence that says who does what and what happens. Give each a unique ID so it can be referred to in testing and change discussions (for example FR-12).

Weak	Better
The system should be user-friendly.	A new staff member can create an order in under ten steps without training material. (Agree the target with real users.)
Support reporting.	A manager can export orders for a chosen date range to CSV, including order number, customer, status and total.
Fast and secure login.	Users sign in with email and password plus a second factor; accounts lock after repeated failed attempts.
Handle many users.	The system supports a stated number of concurrent users that you agree with the business.

Notice that the better versions can be tested. If you cannot imagine how someone would check a requirement, it is not finished.

User stories as a format

Many teams phrase requirements as user stories: "As a [role], I want [action] so that [benefit]". They keep the focus on value. Add acceptance criteria underneath, often in a "given, when, then" shape:

As a customer, I want to see my order status so that I do not need to phone the office.

Given I am signed in and have an open order
When I open the Orders page
Then I see each order with its current status and last-updated date

Step 4: Do not forget non-functional requirements

These are the requirements people forget and then complain about. Prompt yourself with this list:

• Performance: acceptable response times for key actions, and expected data volumes.
• Security: authentication, roles, encryption of data in transit and at rest, audit logging. The OWASP project publishes widely used guidance on common web application risks.
• Availability and backup: acceptable downtime, how quickly you need to recover after a failure.
• Compatibility: browsers, devices, operating systems.
• Accessibility: for web, the WCAG guidelines are the usual reference.
• Privacy and compliance: GDPR obligations if you hold personal data. Take legal advice on specifics; this is not legal advice.
• Maintainability: documentation, code ownership and how updates will be deployed.

Step 5: Record assumptions, constraints and dependencies

Write down what you are taking for granted: "The existing accounting system offers an API", "Product data will be supplied as a clean spreadsheet by the client", "Users have modern browsers". When an assumption turns out false, you then have a documented reason to revisit time or cost. Also record hard constraints such as a legal deadline or a mandated technology.

Step 6: Review, prioritise and baseline

Circulate the draft to users, the sponsor and the technical team. Ask each: "What is missing? What is wrong? What would you remove?" Then prioritise using a method like MoSCoW (must, should, could, will not). Once agreed, mark a version and date on the document. From that point, changes go through a simple change process so the effect on time and cost is visible. For how this sits within the whole journey, see how to plan a custom software project.

Checklist for a good requirements document

• Every requirement is specific, testable and has an ID.
• Scope states what is out as well as what is in.
• Each user role is described.
• Non-functional needs are covered, not just features.
• Terms are defined in a glossary so "customer" means one thing throughout.
• Priorities are marked, and open questions are listed with an owner.
• The document has a version, a date and named approvers.

Common mistakes

• Describing the solution instead of the need. "Use a dropdown" constrains designers; "the user selects one of a short list of options" states the need.
• Vague adjectives. Words like fast, simple, flexible and robust mean different things to different people. Replace them with something checkable.
• Mixing several requirements in one sentence. Split them so each can be tested and prioritised alone.
• Writing it alone. A document produced without talking to users reflects how managers think the work happens.
• Treating it as set in stone. Requirements change. The aim is to change them deliberately.
• Never reading it again. Use it during testing and acceptance; otherwise it is wasted effort.

A short worked example

Suppose a small distributor wants a tool that lets customers check order status. A thin requirements document might say "customers can track orders". A useful one breaks it down:

• FR-1: A customer can sign in with an email address and password.
• FR-2: After signing in, a customer sees only their own orders.
• FR-3: Each order shows its number, date, status (received, packed, dispatched, delivered) and a delivery tracking link where one exists.
• FR-4: A staff member can change an order's status, and the change appears to the customer immediately.
• NFR-1: Customer data is accessible only over HTTPS and is not visible to other customers.
• Out of scope: online payment, returns handling, a mobile app.

Each line can be tested, discussed and estimated on its own. When the business later asks "can customers also pay online?", the answer is a clear change request with a visible effect on cost and time, instead of an argument about what was promised.

Getting help with requirements

Writing requirements is a skill, and an outside view often finds gaps that insiders have stopped noticing. At Soch Tech, planning and requirement analysis is the first stage of how we approach every build, and we can help you turn a rough idea into a document a team can estimate and deliver against. You can read more about our custom software development service, or bring us your draft and we will tell you what we would clarify.