Software Requirements Document Template: How to Write Scope a Contract Team Can Build From
A specialty coffee roaster that sells wholesale to 300 cafes decides to replace its email-and-spreadsheet ordering with a portal. The first draft of the requirements says cafes can “place orders, set up standing orders and pay invoices online.” A contract team could build that sentence a dozen ways. What the roaster actually needs is buried in rules nobody has written down yet: orders placed after Tuesday noon roast the following week, a cafe on credit hold can browse but not order, and a standing order skips automatically when a cafe closes for a holiday.
A software requirements document that holds up with a contract team records decisions, and it says who made them. Use the template below to write each requirement as a behavior with a worked example, name who owns each business rule, list what is out of scope, and keep open questions visible with a date by which someone will decide them. The template has 11 sections. Fill the ones your project needs and say so explicitly when a section does not apply, because a missing section reads to a contract team as “no requirements here.”
What a Software Requirements Document Is For
A software requirements document (SRD) describes what a system must do, for whom and under what constraints, in enough detail that someone outside your company can build it and you can check the result. It sits between the business case, which explains why the system should exist, and the technical design, which explains how it will be built.
With an in-house team, many requirements live in conversation and the document can stay light. With a contract team, the document becomes the shared reference for estimates, priorities and acceptance. Every gap in it gets filled by someone, and the person filling it is usually the engineer writing the code that week. Writing the decisions down is how you keep those choices with the people accountable for the business.
The same structure works whether you call it an SRD, a software requirements specification (SRS) or a product requirements document. The labels differ by tradition; the job is the same.
The Software Requirements Document Template
Copy the 11 sections below. Each one says what to write and shows an example from the coffee roaster’s wholesale portal.
1. Problem and Purpose
What to write: The problem the system solves, who has it today and what changes when it is solved. Two or three paragraphs, in business language.
Example: “Wholesale orders arrive by email, text and phone, and the sales coordinator re-keys them into the roasting schedule and the accounting system. Missed cutoffs and re-keying errors cause short shipments. The portal lets cafes place and change their own orders against the real roast schedule, and sends confirmed orders to production and accounting without re-keying.”
2. Users and the Jobs They Do
What to write: Each type of user, what they are trying to get done and anything about their situation that affects the design.
Example: “Cafe owner: places orders, often on a phone between rushes, needs reorder in two taps. Cafe manager: can place orders but cannot change payment details. Sales coordinator (internal): approves new accounts, overrides cutoffs for key accounts. Production lead (internal): needs the week’s committed volume by origin and roast level each Wednesday morning.”
3. Scope and Non-Goals
What to write: What this release includes, and a separate list of what it explicitly does not. Non-goals prevent the most common scope dispute, where both sides assumed a feature was obviously in or obviously out.
Example: “In scope: account onboarding, one-time and standing orders, roast cutoffs, invoice viewing and card or ACH payment. Not in scope for this release: retail customer orders, green coffee inventory, subscription pricing tiers, a native mobile app.”
4. Requirements Written as Behaviors
What to write: Each requirement as an observable behavior with at least one concrete example, including an example of what should not happen. Number them so estimates, tests and change requests can refer to them.
Example: “R-12. A standing order generates a draft order seven days before its roast date. Example: a cafe with a weekly standing order roasting on Thursdays gets a draft on the prior Thursday that it can edit until the Tuesday noon cutoff. Counter-example: if the cafe has marked that week as closed, no draft is created and no invoice is issued.”
5. Business Rules and Their Owners
What to write: The rules the system enforces, each with the name of the person who decides it and its status: decided, assumed or open. The owner column matters more than it looks, because it tells the contract team whom to ask and tells you who has to answer.
| Rule | Owner | Status |
|---|---|---|
| Orders after Tuesday 12:00 Pacific move to next week’s roast | Head of production | Decided |
| Accounts 30 days past due cannot place new orders | Finance lead | Decided |
| Key accounts can exceed the cutoff by four hours | Sales coordinator | Assumed, confirm by sprint 2 |
| Minimum order is 10 pounds per origin | Head of sales | Open |
6. Data and Sources of Truth
What to write: The main records the system creates or reads, which system owns each one, and anything known to be wrong or missing in the current data.
Example: “Customer accounts and credit terms: accounting system is the source of truth; the portal reads them nightly. Roast schedule and capacity: production spreadsheet today, moving into the portal. Known issue: about one in ten cafe records has a shipping address that differs from the one on recent invoices.”
Many mid-build surprises start in this section. When Gun.io built a finance and operations layer around a manufacturer’s legacy ERP, the team discovered partway through the build that the spreadsheet process for commissions had been missing source data. Writing down what you know about data quality, and what you suspect, lets the contract team plan for it rather than discover it.
7. Integrations
What to write: Each external system, what flows in which direction, how often, who owns the other side and what happens when it is unavailable.
Example: “Accounting system: confirmed orders post as sales orders within 15 minutes; invoices and payment status flow back nightly. If the accounting system is down, orders queue and the coordinator gets an alert. Payment processor: card and ACH payments; the portal never stores card numbers. Shipping carrier: rate quotes at checkout, tracking numbers on shipment.”
8. Quality Requirements
What to write: Performance, availability, security, privacy and accessibility requirements, each stated with its context so it can be tested. “Fast” cannot be tested; “the order page loads within two seconds on a mid-range phone over a cellular connection” can.
Example: “The portal is used in business hours across U.S. time zones; planned maintenance happens on Sunday nights. Cafe users sign in with email and a one-time code. Internal users sign in through the company’s identity provider. The ordering flow meets the accessibility standard and conformance level the company has adopted for its website.”
9. Constraints and Assumptions
What to write: Fixed choices (hosting, languages, vendors already under contract), deadlines driven by the business, and assumptions the plan depends on.
Example: “Must use the payment processor already under contract. Launch before the holiday ordering season, when wholesale volume peaks. Assumption: the accounting system’s API allows creating sales orders; to be confirmed in the first week.”
10. Open Questions With Decide-By Dates
What to write: Every question that is not yet answered, who will answer it and by when. Keep this list in the document, not in someone’s inbox.
Example: “Q-4. Do cafes with multiple locations get one account or one per location? Owner: head of sales. Decide by: end of week 2, because it changes the account model.”
11. Done, Handoff and Change Rules
What to write: What counts as complete for this engagement, what the handoff includes, and how changes to this document are proposed, estimated and approved.
Example: “Done means deployed to production, with the first ten cafes ordering through the portal and sign-off from the sales coordinator. Handoff includes architecture notes, decision records, runbooks and admin access transferred to the roaster. Changes are logged as numbered change requests, estimated by the contract team and approved by the operations director before work starts.”
What Makes the Document Hold Up Once Building Starts
Most requirements documents fail in the same few ways, and each has a fix built into the template.
Requirements describe screens instead of behavior. “An order page with a date picker” tells an engineer what to draw. “A cafe cannot pick a roast date before the next available roast after the cutoff” tells them what the system must enforce. Behaviors with examples become test cases almost unchanged, which is the main reason section 4 insists on them.
Assumptions look like decisions. If the minimum order rule is a guess, mark it as assumed. A contract team that builds against an assumption and later learns it was wrong has done nothing wrong, and the rework is on your side of the ledger. The status column makes that visible before work starts rather than after.
The document is frozen or ignored. Requirements change as people see working software, and that is normal. The document holds up when it has a version history and a change rule, so every change has a number, an estimate and an approver. Without that, changes arrive in chat messages and the contract team has to guess which version of the truth to build.
Detail goes to the wrong places. A team can spend pages on the account settings screen and one line on the accounting integration, where most of the risk sits. Put the depth where the rules, data and integrations are.
How much detail is enough depends on the stage. An early product meant to test demand needs a sharp problem statement, a short scope and clear non-goals, and Gun.io’s guide to MVP development covers how to keep that first scope small. An extension of an existing system needs more on data and integrations, and if nobody can describe what the current codebase does, a technical due diligence review can document it before you write requirements against it.
How to Brief a Contract Team on the Document
Sending the document is not the same as briefing the team. A walkthrough of an hour or two, with the people who own the business rules in the room, often settles questions that would otherwise take days of written back-and-forth.
Walk through sections 1, 3 and 5 first, because they carry the reasoning behind everything else. Then ask the contract team to send back three things in writing: the questions the document raises for them, the assumptions they would make to estimate it, and the requirements they think are riskiest. Their questions show you where the document is thin, and their assumptions show you how they would fill the gaps if nobody told them. The risk list tells you whether they read the integrations section as carefully as you hoped.
Fold the answers back into the document before anyone estimates. If the contract team’s assumption about multi-location cafes differs from yours, settle it now, because an estimate built on the wrong account model is a number you will spend the project defending. Expect the estimate to arrive as a range that narrows as open questions close; the drivers behind the range are the same ones that drive cost generally, and Gun.io’s breakdown of what sets the timeline for an app build shows how scope, integrations and decisions move duration.
Agree on how the document will be maintained during the build: who edits it, where it lives, and how the contract team flags a requirement that turns out to be wrong, so the document still matches the system on launch day.
How Gun.io Works From a Requirements Document
Our first conversation with a client is about the problem itself, and only after that about who should work on it and how the engagement should be structured. A requirements document helps that conversation, and it does not have to be complete. When a client arrives with sections 1 through 3 written and the rest uncertain, that tells us the engagement needs someone who can clarify requirements and recommend an approach, which points toward scoped project delivery, where Gun.io takes the more extensive role. When the document is detailed and a technical lead owns it, staff augmentation often fits, with engineers working inside the client’s team against the plan.
Either way, scope, completion and handoff get agreed explicitly, because code can be finished well before it is deployed, approved by a third party or adopted by the people who will use it. If it helps to see where we work, Gun.io’s solutions are organized by engineering area.
Frequently Asked Questions
How Long Should a Software Requirements Document Be?
It should be as long as the decisions require, which is usually shorter than people expect for a first release and longer for integrations. A focused first release can fit in a handful of pages if the rules, data sources and non-goals are clear; length spent describing screens rarely helps.
Should the Contract Team Write the Requirements Document?
The contract team can draft parts of it, especially integrations and quality requirements, but the business rules and their owners must come from your side. A requirements document written entirely by the team that will build it tends to describe what they plan to build rather than what the business needs.
What Is the Difference Between an SRD and an SRS?
In practice there is little difference: both describe what a system must do and the constraints it works under. Some organizations reserve SRS for a more formal format with numbered functional and nonfunctional requirements, while SRD and product requirements document are used for lighter versions written by product teams.
Do User Stories Replace a Requirements Document?
User stories can carry the behaviors in section 4, but they rarely capture business rule ownership, sources of truth, integrations or non-goals. Teams that work in stories still benefit from a short document that holds those cross-cutting decisions and links to the backlog.
When Should You Freeze the Requirements?
Freeze the parts that drive architecture, such as the account model, the source of truth for each record and the integrations, before estimating. Leave behavior details open to change under the change rule, because people make better decisions once they can use working software.
How Do You Handle Requirements Nobody Can Decide Yet?
List them in the open questions section with an owner and a decide-by date tied to when the build needs the answer. If a question has no owner, that is a finding in itself, and naming one is usually the fastest way to get it answered.
Write Down the Decisions, Not Just the Features
A requirements document earns its keep when a contract engineer can find the answer to a business question in it instead of guessing. If you have a draft and want a second view on what a team would need to build from it, tell us about the system and the rules behind it, including who owns the decisions that are still open.
