What to Include in a Software Requirement Document

Start with the reason. Write why the project exists in two sentences that a non-technical director would sign, naming the problem it removes and the person who feels it daily. Then list who will use the system and how, because a warehouse operator on a handheld scanner is a different user from an accountant reviewing month-end reports. Name every group separately. A system built around the accountant’s needs will quietly fail the operator at the loading bay, and nobody will notice until stock counts drift.

State what is out of scope. Leaving the boundary vague feels flexible, but an unstated boundary becomes a disagreement during a budget or timeline conversation, which is the most expensive moment to settle it. Write the exclusions as plain sentences, such as no mobile app in this phase, no migration of records older than two years and no customer-facing portal. Each one prevents an argument.

Describe each process as it runs today. Go step by step and include the parts that feel too obvious to write down, because those are exactly the parts a vendor builds wrong when nobody mentions them. A rule such as “orders above a set value need a second approval” must name the approver and the fallback when that person is away. Rules without owners fail quietly.

Give exceptions their own list. Examples are a customer cancelling after a part payment, stock running out mid-order, and a discount clashing with a promotion that was already applied to the same invoice. Most requirement documents fall short here, and most rework later starts with an exception that nobody on the team thought to write down at the start. Ask the people at the counter.

List the data the system must hold, where it comes from and roughly how much of it there is, because volume changes the design more than most owners expect. Order of magnitude is enough. Sources include manual entry, an import from the old system and a third-party feed, and each one carries its own cleaning work before go-live. Note every system it must connect to and whether a known method exists, such as an API or a file export, or whether it must be worked out.

Permissions are easy to underspecify. Decide who can view, create, edit or delete each type of record, and whether any of that depends on role, branch or approval level. Getting this wrong in version one usually means rebuilding the access model once real usage exposes the gaps, which costs far more than writing a table now. A simple grid works.

Write the numbers down. A branch that handles forty orders a day and one that handles four hundred need different screens, different reports and different hosting, even when the process looks identical. Scale shapes the price. Ask each branch manager for a typical day and a worst day, and record both figures next to each workflow so the vendor sizes for the worst day.

Non-functional needs describe behaviour. They cover how many people use the system at once, how quickly a screen must load during a busy counter hour, and what should happen during an outage. Add the devices and browsers your team actually owns, since first drafts often omit these details and they cause the loudest arguments at delivery. Write them down early.

Acceptance criteria close the loop. For every major feature, write what must be true for it to count as finished, in a form that someone can test without asking the author. “The order form works” is useless. “An order cannot be submitted without a valid customer and one line item, and the total updates as items are added” can be tested.

Add a short glossary. Terms such as customer, account, dealer and member often mean different things in sales and in finance, and a vendor will pick one and build the database on it. Define each term once.

Every document carries assumptions. They cover who approves the final design, what “acceptable performance” means and how a dispute over interpretation gets resolved when two people read one line differently. Writing them down turns a silent risk into a list that both sides can check later, instead of a memory that each side recalls differently. Date and sign the list.

Consider a furniture manufacturer. It is specifying an order system for its dealer network, and midway through the build a dealer asks for partial shipment tracking, which nobody had scoped. With a change-request process, that becomes a bounded decision about who approves it and what it does to timeline and cost, handled in a day. Without one, it becomes an argument about whether the original quote should have covered it, and the working relationship with the vendor takes the damage.