What should a software requirements document include?

A useful software requirements document covers the problem and the goal, the scope and what's out of it, the people who will use the software, each requirement as a testable statement, the business rules and exceptions, the data, the connected systems, security and access, acceptance criteria, the decisions made and questions still open, who will own the software, and who signed off.

Here's each part, and the question it answers.

The problem and the goal

What's wrong today, and what should be true when the software exists. This keeps everyone honest about which features matter.

Scope, and what's out of it

What this version will do, and a short list of what it won't. The "won't" list prevents many arguments later.

People and roles

Who uses it, what each role needs to do, what each is allowed to see and change, and who decides when people disagree.

Requirements

Each requirement as one statement that can be tested, with its own ID. "Easy to use" is a wish; "a dispatcher can reassign a delivery from the day's schedule" is a requirement.

Business rules and exceptions

The business rules: approval limits, deadlines, calculations, discounts. And the exceptions experienced staff handle from memory: the late order, the missing signature, the customer on credit hold. Most of the surprises in a build hide here.

Data and connected systems

The records the software keeps and how they relate, and the systems it reads from or sends to, such as accounting, payroll or a customer database. Include what should happen when a connected system is down.

Security and access

Who can see and change what, what needs an audit trail, and how long records are kept.

Acceptance criteria

For each requirement, how anyone can check it was built correctly. See what acceptance criteria are.

Decisions, assumptions and open questions

What was decided, by whom and why; what's assumed but not yet confirmed; and what's still unanswered. Marking these honestly is more useful than hiding them.

Ownership and sign-off

Who will host, support, secure and eventually retire the software, and who approved the document, and when.

How long should it be?

As long as it takes to answer a builder's questions, and no longer. A small tool may fit in a few pages; an application that touches several departments needs more. Mochlion produces documents with these parts from your experts' answers; see the sample.