# How to Write a Software Requirements Document | Vynix Digital > Learn how to write a software requirements document, with the key sections, functional vs non-functional examples, user stories and a free template. Canonical: https://vynix.digital/blog/software-requirements-document/ Updated: 2026-10-25 Published: 2026-09-07 Author: Vynix Digital Team Category: Guide When a software project runs late, goes over budget or ships the wrong thing, the cause can often be traced to the first step: nobody agreed, in writing, on what the software should do. A software requirements document is that written agreement. To write one, you state the business goal and the users, list what the system must do (functional requirements) and the standards it must meet (non-functional requirements), express features as user stories with acceptance criteria, and record scope, constraints and open questions. This guide is for founders, product owners and operations leads about to brief a development team. It covers each section, examples of both requirement types, how to write testable user stories, a fill-in template and the most costly mistakes. ## Why a requirements document matters A requirements document is cheap compared with what it prevents. A few days of writing and review can save weeks of rework, because changing a sentence is far easier than changing a database schema after launch. It also does three specific jobs: - It makes quotes comparable. Two vendors can only give you comparable estimates if they read the same description. This matters even more if you want a fixed price, since a [fixed-price contract is only as reliable as the scope behind it](https://vynix.digital/blog/fixed-price-vs-time-and-materials/). - It keeps stakeholders aligned. Sales, operations and finance often picture different products. Writing it down surfaces those differences before code does. - It becomes the test plan. Every requirement should be checkable, so QA and your own sign-off work from the same list. If you are still unsure what to build, start one step earlier. A [software discovery phase](https://vynix.digital/blog/software-discovery-phase/) turns rough ideas into decisions, and the requirements document is where those decisions get recorded. ## The sections of a good software requirements document The template further down lists every section. These are the ones people most often get wrong. ### Goals and success measures "Replace our spreadsheet-based ordering" is a description. "Cut manual order entry from 10 hours a week to under 1" is a goal you can measure after launch. Two to four goals is plenty. ### Users and roles List every type of user and what each one may see and do. A customer, a sales rep and an admin may use the same screen with very different permissions. Missing roles tend to surface late, when they are expensive to add. ### Scope, including what is out of scope Write what this release includes and, just as clearly, what it does not. "No mobile app in phase one" or "refunds stay in the existing payment dashboard" prevents arguments months later. If that list is long, our guide to [MVP development for startups](https://vynix.digital/blog/mvp-development-for-startups/) covers how to cut scope without cutting value. ### Integrations, data and constraints Name every system the software must talk to (accounting, CRM, payment provider, email), any data to migrate, and the fixed limits: deadline drivers, budget range, required hosting and regulations. Integrations are where many [custom software development](https://vynix.digital/services/custom-software-development/) projects find their hidden complexity, so describe them early, even if only in a sentence each. ### Open questions Unknowns are normal. List each one with an owner and a date, so it gets answered rather than assumed. ## Functional vs non-functional requirements Functional requirements describe what the system does: actions, rules, calculations and outputs. Non-functional requirements describe how well it does them: speed, security, availability, usability and compatibility. You need both. A feature that works but takes 20 seconds to load, or exposes customer data, has not met its requirements. Here is how they look for a wholesale ordering portal where retailers place orders with a distributor: | Type | Example requirement | | ------------------------------ | ----------------------------------------------------------------------------------------------------------- | | Functional | A retailer can search products by name or SKU and sees their own negotiated price. | | Functional | When an order is placed, the system emails a confirmation and creates the invoice in the accounting system. | | Functional | An admin can export all orders for a date range as a CSV file. | | Non-functional (performance) | Product search returns results in under 2 seconds with a catalog of 20,000 products. | | Non-functional (security) | All traffic uses HTTPS, passwords are stored hashed, and admin accounts require two-factor authentication. | | Non-functional (availability) | The portal is available 99.5% of each month, excluding maintenance announced 48 hours ahead. | | Non-functional (compatibility) | Works on current versions of Chrome, Safari, Edge and Firefox, and on phone screens from 375 pixels wide. | | Non-functional (usability) | A first-time retailer can place an order without contacting support. | Number each requirement (FR-01, NFR-01) so you can refer to it in quotes, tickets and test reports, and make every non-functional requirement measurable. "Fast" and "secure" cannot be tested, while "under 2 seconds" and "two-factor authentication for admins" can. For usability, a helpful checklist is the five quality components Nielsen Norman Group uses to [define usability](https://www.nngroup.com/articles/usability-101-introduction-to-usability/): learnability, efficiency, memorability, errors and satisfaction. Turn the one or two that matter most into a test, such as "a new user completes their first order in under five minutes." ## How to write user stories and acceptance criteria A user story describes a feature from the point of view of the person who uses it. The common format is: > As a [type of user], I want [an action], so that [a benefit]. For the ordering portal: - As a retailer, I want to repeat a previous order in one click, so that I do not rebuild my weekly order from scratch. - As a warehouse manager, I want today's orders grouped by delivery route, so that I can plan picking before the trucks arrive. The "so that" part matters most. It tells the developer why the feature exists, which helps them suggest a simpler way to get the same result. A useful quality check is INVEST, which the [Agile Alliance glossary](https://agilealliance.org/glossary/invest/) describes as a checklist for good stories: Independent, Negotiable, Valuable, Estimable, Small and Testable. If a story fails "Small", split it. "As an admin, I want to manage users" becomes separate stories for inviting a user, changing a role and deactivating an account. ### Acceptance criteria Acceptance criteria are the conditions a story must meet to count as done. The Given, When, Then format keeps them precise: - Given I am logged in and have a past order, when I click "Reorder" on that order, then a new cart opens with the same products and quantities. - Given a product from the old order is discontinued, when I reorder, then the cart contains the other items and a notice names the missing product. - Given a price has changed since the original order, when the cart opens, then it shows the current price. The second and third criteria are where the value lies: edge cases like these get missed when nobody writes them down.
Functional requirements describe what software does, non-functional requirements describe measurable quality constraints, and acceptance criteria define when a feature is done.
Describe both behavior and measurable constraints. For each user story, add acceptance criteria covering the normal journey and the edge cases that matter.
## A simple requirements document template Copy this into a document and fill in each row. For a small project, a sentence or two per row is enough. | Section | What to write | | --------------------------- | ----------------------------------------------------------------------------------------------------- | | Project overview | One paragraph: what you are building, for whom, and why now. | | Goals | Two to four measurable outcomes, such as "cut manual order entry to under 1 hour a week". | | Users and roles | Each type of user, what they need, and what they can and cannot do. | | In scope | The features in this release, in priority order. | | Out of scope | What you are deliberately not building yet. | | Functional requirements | A numbered list (FR-01, FR-02) of what the system must do. | | User stories | "As a..., I want..., so that..." with Given, When, Then acceptance criteria. | | Non-functional requirements | Performance, security, availability, usability, compatibility and data retention, each with a number. | | Integrations and data | Systems to connect, data to migrate, and who owns each account or API key. | | Constraints | Deadline drivers, budget range, required technology or hosting, regulations. | | Design references | Wireframes, brand guidelines and examples you like. | | Open questions | Each question with an owner and a due date. | | Sign-off | Name, role, date and document version. | Rough wireframes make almost any requirements document easier to understand. If you do not have them yet, our article on the [UI/UX design process](https://vynix.digital/blog/ui-ux-design-process/) explains how they fit in before development, and our [UI/UX design](https://vynix.digital/services/ui-ux-design/) team can produce them in Figma. ## Common mistakes - Using untestable words. "User-friendly", "fast", "scalable" and "modern" mean different things to everyone. Replace each one with a number or an observable behavior. - Skipping the out-of-scope list. Without it, every unstated assumption becomes a future argument about budget. - Forgetting the unhappy paths. Failed payments, cancelled orders, expired links and empty screens all need defined behavior. If you do not specify it, developers will have to guess. - Ignoring the admin side. Someone has to manage users, correct bad data and run reports, and those screens can be a large share of the work. - Writing it without a developer. A technical review catches impossible requirements and adds missing ones, such as audit logs or backups. - Over-documenting. An 80-page document nobody reads helps no one. Write the minimum that lets a team estimate and test. - Freezing it, or never settling it. Requirements will change. Keep a short change log that records what changed, why and who approved it. ## Conclusion A good software requirements document can be short and informal, as long as it has clear goals, named users, an honest scope, numbered functional requirements, measurable non-functional ones, and user stories with acceptance criteria anyone can test. Start with the template above, fill in what you know, and list what you do not. If you want help turning your notes into a document a team can estimate and build from, that work is part of the discovery and architecture stage of our [custom software development](https://vynix.digital/services/custom-software-development/) service. Share what you have so far through our [contact page](https://vynix.digital/contact/) and we can talk it through. ## Frequently asked questions ### How long should a software requirements document be? Long enough that a developer can estimate the work without guessing, and no longer. A small internal tool might need five pages, while a SaaS platform with several user roles can need thirty or more. Clarity matters more than page count. ### Who should write the software requirements document? The business owner or product lead should own it, because they know the goals and the users. A developer or technical lead should review it before it is final, so feasibility problems and missing technical requirements surface early. ### What is the difference between an SRS and a PRD? A product requirements document (PRD) usually focuses on the problem, the users and what the product should achieve. A software requirements specification (SRS) goes further into how the system must behave, with detailed functional and non-functional requirements. Many small teams combine both into one document. ### Can I use user stories instead of a requirements document? User stories describe features well, but on their own they tend to miss non-functional requirements, integrations and constraints. Most teams get better results by keeping their user stories inside a short requirements document that also covers those areas. ### Should the requirements document change after development starts? Yes, it should stay a living document, but changes need a simple process. Record what changed, why, and who approved it, so the team, the timeline and the budget stay aligned. ## Contact - Email: vynix.digital@gmail.com - Location: Dhaka, Bangladesh (working with clients worldwide) - Project form: https://vynix.digital/contact/