Ask five software companies to quote for “a system to manage our orders and billing” and you will get five numbers that are far apart. That is rarely because one vendor is honest and the others are not. Each one is guessing what you mean, and each guess carries a different price.
A written requirements document removes most of that guessing. This guide explains what to put in it section by section, how to write requirements that can be tested, which exceptions to capture, and what you can safely leave to the vendor's discovery phase.
Quick answer: A software requirements document (SRS) describes what the software must do, for whom and under what limits, without deciding how it is coded. For business software, cover the problem and goals, users and roles, step-by-step workflows with exceptions, business rules, data and reports, integrations, non-functional needs such as security and devices, and what is out of scope. Number each requirement so it can be quoted and tested.
Why write requirements before you hire a developer
A software requirements document, often called an SRS (software requirements specification), is written in business language, not code. It pays for itself in four ways:
- Comparable quotes: every vendor prices the same scope, so you compare approach and team rather than guesses.
- Fewer disputes: when something is unclear later, there is a written reference both sides agreed to.
- Acceptance testing: each numbered requirement becomes something you can check before you sign off and release the final payment.
- Continuity: a new developer or a new vendor can understand the system years later.
It does not need to be a heavy, formal document. If your IT team prefers a standard structure, ISO/IEC/IEEE 29148 is the international standard for requirements engineering that replaced the older IEEE 830 SRS format. For most business software, a plain-language document written by the people who run the process is more useful than a polished one written by someone who has never seen your billing counter.
What to include: a section-by-section outline
Use this outline as your template. Fill each section with real examples from your business, not generic statements.
| Section | What to write | Example |
|---|---|---|
| Background and goals | The problem today and what success looks like | Dispatch staff re-type WhatsApp orders into Tally; orders should be entered once |
| Users and roles | Who uses it, roughly how many, what each may see and do | A branch manager approves discounts above the price list; a salesperson cannot |
| Workflows | Step-by-step scenarios from start to finish | Order placed, credit check, approval, dispatch, invoice, payment |
| Business rules | Calculations, validations and approval limits | Credit check uses outstanding plus dispatched but unbilled goods |
| Data and reports | Masters, records, reports, exports and print formats | Branch-wise sales report emailed to the owner every morning |
| Integrations | Systems to connect, direction and timing of data | Push invoices to Tally; receive payment status from the gateway |
| Non-functional needs | Security, devices, languages, users, hosting, backups | Warehouse screens work on Android phones with Hindi labels |
| Out of scope | What you are deliberately not building now | Payroll stays in the current software for phase one |
How to write requirements a developer can test
A requirement is useful only if someone can check whether the software meets it. Follow these rules:
- Number every requirement: REQ-014 is easier to discuss in a meeting, a quote and a test sheet than “the discount thing”.
- One requirement per line: “the system creates invoices and sends reminders” is two requirements with two test results.
- Mark priority: use Must, Should, Could and Won't (the MoSCoW method) so vendors can price a first phase separately.
- Replace vague words: “fast”, “easy” and “user-friendly” cannot be tested. “An item search by code shows results within two seconds for a counter user” can.
- Add acceptance criteria: describe the expected result for a specific situation.
A format that works well is a user story with acceptance criteria. For example: “As a branch manager, I want to approve discounts above 5% from my phone, so that orders are not held overnight.” Acceptance criteria: “Given an order with a 7% discount, when the salesperson submits it, then the branch manager receives a notification, and the order cannot be invoiced until it is approved or rejected.”
Capture the exceptions, not only the normal flow
Most people describe the normal day: an order comes in, goods go out, an invoice is raised and payment arrives. The cost and the risk sit in the exceptions. List the ones that actually happen in your business, even if they are rare:
- Part dispatch when only some items are in stock.
- A customer returns goods after the invoice has already been reported in your GST return.
- One customer with two GST registrations in different states.
- A price change while an order is waiting for approval.
- The internet drops at the billing counter or in the godown.
- An employee leaves with open approvals in their name.
- A payment arrives without a reference and must be matched by hand.
For each exception, write what should happen and who decides. If you do not know yet, say so in the document. An open question that is visible is far cheaper than an assumption discovered during testing.
Mistakes that make requirements documents fail
- Describing screens instead of needs. “Add a dropdown with all branches” fixes a design too early. “A user sees only their own branch's orders unless they hold the regional role” states the need.
- Copying a competitor's feature list. You pay for features nobody in your team will use.
- Leaving out reports. Reports decide which data must be captured. Attach samples of the MIS reports management reads today.
- Ignoring data migration. State how many years of history must move, from which systems, and in what format it sits today.
- No single owner. When accounts and sales disagree, someone must decide. Name that person in the document.
- Treating the document as frozen. Requirements will change. Agree a simple change request process: what changes, the effect on cost and time, and who approves it.
What to leave to the vendor's discovery phase
You own the “what”. A capable vendor owns the “how”: technology stack, database design, architecture, hosting and security controls. Your document should state real constraints, such as “must run on our existing AWS account” or “accounts must stay in Tally”, but it should not pick frameworks unless you have a reason.
A discovery phase then turns your document into a technical specification. On our software development projects, discovery typically takes 1–2 weeks and produces entity relationship diagrams, user story maps, API contract specifications and a milestone roadmap that you sign off before development begins. Review that output line by line, because it is what the software will be built and tested against. If budget is your next question, our guide to custom software development cost in India explains what drives an estimate.
How EthicsComputer can help
If you have a rough list, a set of spreadsheets or simply a clear picture of the problem, our software development team can run discovery with your staff and turn it into a written scope with fixed milestones. For systems with many integrations, software architecture consulting can review the technical design before you commit, and custom software development covers the build itself, with source code and IP handed over to you.
Have a rough list of what your software must do?
Send it as it is, even as a spreadsheet or a page of notes, and we will help you turn it into a scope you can get quoted.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
