Software Requirements Specification Example for a B2B Application

Why the document matters more than the format

A useful software requirements specification example is less about templates and more about agreement: who needs what, why, and how you'll know it works. That distinction matters commercially. The Project Management Institute surveyed more than 2,000 practitioners and found that nearly half of unsuccessful projects missed their goals because of poor requirements management.

The people who understand the business process rarely write specifications, and the people who write specifications rarely run the process. An SRS document closes that gap when it's written in language that allows both sides to state their case. Frederick Brooks put it bluntly in 1987: "The hardest single part of building a software system is deciding precisely what to build." That's still true, and it's why the document deserves care.

What an SRS does

An SRS document is a working artefact shared between the business and the delivery team. It records what everyone currently agrees on. It doesn't predict every implementation detail, and a good software requirements specification example makes no attempt to.

The international standard for this work, ISO/IEC/IEEE 29148:2018, defines what a well-formed requirement looks like and sets out nine characteristics each requirement has. Those characteristics are useful as a review filter rather than a writing formula. If a statement can't be tested, it isn't a requirement yet.

The document earns its keep by connecting three things that usually live in separate heads. Business intent sits with the sponsor. Behaviour sits with the people who do the work today. Verification sits with whoever signs off the release. Write it so all three can read the same page and recognise their own concerns in it.

Set the right certainty

Before discovery, you can confidently specify the business problem and the people affected. You can confidently specify the regulatory constraints you already operate under and the outcomes you're paying for. What you can't confidently specify is how a third-party system behaves under load, how long a data migration takes, or whether an existing process survives contact with a new interface.

Pretending otherwise is expensive. The NIST report on software testing infrastructure found that a requirements error not caught until after release costs roughly 15 times more to correct than the same error caught in the requirements stage itself. False certainty is how those errors survive.

Label every statement in your software requirements template so the certainty is visible on the page:

• Confirmed: agreed by the named decision owner and backed by evidence or policy.

• Assumed: believed true, not yet checked, with the person who can check it named.

• To be validated: depends on a technical investigation, a prototype, or a supplier answer.

• Excluded: deliberately out of scope for this release, with the reason recorded.

Four labels cost nothing and change how the document reads. Nobody argues about a line marked "assumed" the way they argue about a line that looks like a commitment.

Software requirements specification example

What follows is a single coherent software requirements specification example built around Northfield Logistics, a fictional UK freight broker replacing a spreadsheet-and-email process with a bespoke software customer service portal. Each section below explains why it exists and models wording you can adapt without a technical background.

The portal lets Northfield's 340 business customers raise service requests and track delivery exceptions. Right now those requests arrive by email into a shared inbox. Keep that picture in mind as the sections build.

SRS document context

Start with the problem. Northfield's context section reads: "Service requests arrive through a shared mailbox handled by four coordinators. There is no queue, no ownership, and no record of response time. In the twelve months to March, 19% of customer complaints referenced a request that was never answered."

Then the outcomes, each one measurable. Cut unacknowledged requests to under 2%. Give customers self-service access to proof-of-delivery documents so the coordinators stop retrieving them manually. Every capability proposed later in this software requirements specification example must trace back to one of these, or it doesn't belong in this release.

Scope boundaries and exclusions do the heaviest lifting in this section. Northfield's excludes invoicing and any change to the transport management system itself. Write exclusions as sentences with reasons attached, because an exclusion without a reason gets quietly reversed in month three. The dependencies sit alongside them: the portal reads consignment status from the existing transport management system, which means the project can't move faster than that system's API work allows.

Users and workflows

Four user groups appear in the Northfield software requirements specification example. Customer users raise and track requests. Coordinators triage and resolve them. Account managers review activity for their own clients. A small administration group manages accounts and permissions.

Describe each group by what they're trying to achieve, then map the journey as numbered steps. The raise-a-request journey runs from the customer selecting a consignment to resolution. Numbering the steps is what exposes the handoffs, and handoffs are where the unanswered questions live. Who owns a request when the assigned coordinator is on leave? What happens when a customer replies to a closed request?

Record those questions inside the workflow. A software requirements template that hides open questions at the back of the document guarantees nobody reads them. Permissions belong here too, written as a simple matrix of role against action, because "account managers can view all accounts" and "account managers can view their own accounts" are two different products.

Functions and information

Functional requirements get an identifier and a priority. The Agile Business Consortium's guidance on MoSCoW prioritisation recommends no more than 60% effort allocated to Must Have items, with roughly 20% held as Could Haves. That ratio is a discipline, and applying it forces the honest conversation early.

A workable entry from the Northfield set:

• FR-014 (Must): The portal shall allow a customer user to attach up to five files to a service request at the point of submission. Source: coordinator interviews, 12 March. Traces to outcome O2. Status: confirmed.

• FR-022 (Should): The portal shall notify the assigned coordinator when a request has been open for longer than the agreed response window. Response window values to be validated with operations. Status: to be validated.

• FR-031 (Could): The portal shall let account managers export request history for their own accounts as a spreadsheet file. Status: confirmed, deferred if capacity is short.

Notice what's missing. No database tables and no screen layouts. Karl Wiegers, who wrote the standard reference text on this subject, describes requirements development as "a discovery and invention process, not just a collection process", and premature technical design shuts that process down before it starts.

Information requirements sit next to the functions. What data comes in and what records are created. On retention, the Information Commissioner's Office is clear that UK GDPR sets no fixed periods and the organisation must justify its own choices. So write the justification into the specification. Reporting outputs follow the same rule: name the decision each report supports, or drop it.

Quality and acceptance

Non-functional requirements decide whether anyone enjoys using the thing. ISO/IEC 25010:2023 organises product quality into nine characteristics, from performance efficiency through to security, and running down that list is a quick way to find the categories you forgot.

For accessibility, name the standard and the level. WCAG 2.2 became a W3C Recommendation on 5 October 2023, and "the portal shall conform to WCAG 2.2 Level AA" is testable in a way that "the portal shall be accessible" never is. Security deserves the same treatment. The NCSC's collection sets out five secure design principles, which begin with the need to establish the context before designing anything, and referencing them tells the delivery team which conversations to expect.

Acceptance criteria turn all of it into something a tester can execute. Northfield's performance entry reads: "Search results for consignment lookup shall return within 2 seconds for 95% of queries at a load of 60 concurrent users. Target to be validated against transport management system response times during technical spike." That last sentence is the important one. It's a number with an honest caveat attached, which beats a number that quietly becomes a contractual obligation nobody can meet. Gojko Adzic's work on Specification by Example makes the case that concrete examples create shared understanding between business and delivery better than abstract statements do, and acceptance criteria are where that shows.

Keep the SRS flexible

A software requirements specification example that can't change is a specification people work around. Build the mechanics of change into the software requirements template itself. Every open question gets an owner's name and a date by which an answer is needed. Every requirement carries a validation date, so anyone reading it in month six knows whether it was last confirmed in week two or last week.

The GOV.UK Service Manual describes the alpha phase as the point at which teams test their riskiest assumptions, and that's the right instinct for an SRS document too. When a requirement depends on something unknown, the correct response is a prototype or a technical spike. A discovery phase typically runs 4 to 8 weeks, which is shorter than the delay caused by building the wrong integration.

Keep a change history at the front of the software requirements template that logs the date of each change and who approved it. It takes two minutes per entry and settles arguments that would otherwise take an afternoon.

Review before sharing

A review is not a proofread. Send the draft to the business owner who holds the budget and to two or three people who actually do the work today. Send it as well to a delivery specialist who can estimate it and to whoever owns security and data protection in your organisation. Each of them reads for something different, and each of them will find something the others missed.

Give them a filter rather than a blank page. For every requirement in the software requirements specification example, ask whether it's necessary and understandable without a glossary. Then check that it is consistent with the requirements around it. Confirm it is feasible within the constraints you've stated and testable by someone who wasn't in the room. Those five checks map closely to the quality criteria in the ISO standard, and they catch most of what matters. PMI's 2018 research found inaccurate requirements gathering was a primary cause in 35% of failed projects, which is a strong argument for spending an extra week on review.

One practical rule: if a reviewer asks what a requirement means, rewrite it.

Download the checklist

Work through your draft against the sections below. Anything you can't complete is a discovery question.

1. Context: business problem and measurable outcomes. Name the stakeholders and the scope boundaries. Record dependencies and explicit exclusions with reasons.

2. Users and workflows: user groups and their goals. Cover journey steps with handoffs and a permissions matrix for each role.

3. Functions and information: prioritised functional requirements with identifiers and sources. Cover integrations and the records created from data inputs. Include retention justification and reporting outputs tied to decisions.

4. Quality: performance and reliability. Cover security and the accessibility standard and level. Include compliance obligations and acceptance criteria with validation status.

5. Governance: assumptions and open questions with owners and dates. Keep a change history and the date each requirement was last confirmed.

Turn that into a reusable software requirements template for your organisation, and the second specification you write will take half the time of the first.

Validate the requirements

A finished software requirements specification example is the start of an informed conversation. The strongest versions are the ones a delivery team has already pushed back on, because pushback is where the untested assumptions surface.

Evolved Ideas has spent 19 years building bespoke software for organisations including the NHS and Bridgestone, and we start every engagement by understanding the problem before proposing anything. If you've drafted a software requirements specification example and want it challenged before development begins, get in touch with our team.