How to write a software requirements specification (SRS): template and examples

There are plenty of horror stories about outsourced software teams and clients clashing over project requirements, and one of the most common causes is ambiguous language. Vague terms like "urgent," "pending," or "ASAP" can mean one thing to the client and something else to the contractor. The 2 parties also often carry a different picture of which features matter most.

It is rarely anyone's fault. The customer has an idea for the product, its functions, and what the interface might look like. The developers think about the work behind the scenes: scalable and readable code, security, performance, and fewer bugs.

When those 2 viewpoints drift apart, the result is extra work, wasted budget, and a weaker product. A software requirements specification keeps them aligned from the first day. At Brocoders we write one for every project we build, and this guide uses examples from our own product development work rather than generic templates.

TL;DR: A software requirements specification (SRS) turns a product idea into something a team can build. It describes functional requirements (what the system does) and non-functional requirements (how well it does it). The current standard is ISO/IEC/IEEE 29148:2018, which replaced IEEE 830-1998. Below are the full structure, working examples, a template you can reuse, and 3 Brocoders builds where the spec decided what got built and what waited.

Last updated: Oct. 19, 2026.

Table of Contents
What a software requirements specification is
Basic elements of an SRS
Functional vs non-functional requirements: definitions and examples
How to write the documentation
Needs document
Architecture document
SRS document
How an SRS changes what gets built: 3 Brocoders builds
How AI helps you write an SRS or PRD
SRS design guidelines
An SRS is the first deliverable, not paperwork

What a software requirements specification is

A software requirements specification (SRS) is a document that describes a software system to be developed. Every party on the project can read it: stakeholders, investors, the project manager, developers, designers, and testers.

An SRS contains 3 types of requirements:

1. Top tier: the high-level business requirements. They state the business's measurable goals, define the purpose behind the project, and align project goals with stakeholder goals.
2. Middle tier: the user requirements. They reflect specific user needs, describe who uses the software, and show how users interact with it.
3. Bottom tier: the product's functionality in technical terms. They list functions, features, use cases, and non-functional requirements, and describe the project as functional modules plus non-functional attributes.

Combining all 3 tiers gives everyone the same picture of the project and measurable deliverables. This matters even more when you outsource, because a thorough SRS lets a development partner pass your requirements to its own team without losing detail.

Here is how an SRS helps each role:

In short, an SRS gives stakeholders, project managers, and engineers one source of information and expectations, which cuts down on misunderstandings.

Basic elements of an SRS

For an SRS to be useful to everyone involved, it needs 7 basic elements:

• Business drivers: the reasons the customer wants the software built. This rationale guides the decisions of business analysts, system architects, and developers.
• Business model: the business model the system must support, including organizational context, key business functions, current and future state diagrams, and process flows.
• Business and system use cases: usually a UML use case diagram showing the main external objects the system interacts with.
• Technical requirements: the non-functional requirements that make up the technical environment.
• System qualities: the non-functional requirements that set the system's quality.
• Constraints and assumptions: constraints the customer requires, used to rule options out of development.
• Acceptance criteria: how the customer signs off on the final system.

Functional vs non-functional requirements: definitions and examples

If you are ordering custom software, you and your development team need to agree on its requirements. Skip that, and you risk a product that is unreliable, slow, and insecure.

Software development has 2 types of requirements, and the SRS covers both:

• Functional requirements: the functions the software must perform.
• Non-functional requirements: the standards used to judge how well the system operates.

Functional requirements capture the intended behavior of the application as services, tasks, or functions. Non-functional requirements keep the whole system usable. When every functional requirement is met but the non-functional ones are weak, the system still fails its users.

Typical functional requirements include:

• If/then behaviors
• A description of the system's workflow
• Data inputs and their outputs
• The logic behind data handling

Typical non-functional requirements include:

• Performance and scalability
• Compatibility and portability
• Maintainability, availability, and reliability
• Security
• Usability
• Localization

What functional requirements are

Functional requirements specify which functions your system or system component must have. In other words, they define what your custom software needs to do. When they go unmet, the software fails, so they are not negotiable.

The most common ways to write functional requirements are use cases and written descriptions.

Use cases. A use case can be a numbered list or a diagram of user actions. Each one shows a behavioral scenario through one or more functional requirements. An analyst selects a set of use cases first, then derives the functional requirements each one needs.

The diagram below shows a navigational use-case model for a conference management system, where each main function maps to user roles:

And here is a use case numbered list for a subway ticket machine:

Written descriptions. A written functional requirement has a unique name and number, a short summary, and a rationale. The reader sees why the requirement exists, and the team can trace it. Written functional requirements include:

• Interface requirements
• Data manipulation and processing requirements
• Verification requirements
• Documentation requirements
• Security requirements
• Acceptance criteria

Who prepares functional requirements. A business analyst, system analysts, and the implementation team usually write them together. The project manager makes sure they are delivered on time and signed off by the system owner and QA.

What non-functional requirements (NFRs) are

Non-functional requirements define how the software fulfills its functional goals. They describe how the system behaves rather than what it does, and they set the criteria for judging performance, reliability, and maintainability. They also impose external constraints on the software and on the development process.

A non-functional requirement describes a specific aspect or a general property of the whole system rather than an exact function:

• Aspect: a feature linked to many parts of the system but not tied to its primary function.
• Property: a characteristic of the software, such as integrity, reliability, or accuracy.

Non-functional requirements fall into 2 categories, performance qualities and evolutionary qualities:

Performance qualities show at runtime, while evolutionary qualities live in the system's static structure. A classic IEEE paper groups non-functional requirements this way:

• Performance: efficiency (how well the system uses resources), integrity and security (how well it resists cyberattacks), reliability (how much you can trust its functions), and survivability (how it performs under poor conditions).
• Design: correctness (how well it conforms to requirements), verifiability (how easy it is to verify its performance), and maintainability (how easy it is to repair).
• Adaptation: expandability, interoperability, flexibility, portability, and reusability (how easily it grows, connects to other systems, changes, moves, and serves another system).

Who prepares non-functional requirements. Functional requirements can live in a functional requirements document (FRD), while a product requirements document (PRD) combines functional and non-functional ones. Developers, software architects, and other technical experts usually define the non-functional requirements, and the product manager typically prepares the PRD.

Functional vs non-functional requirements compared

The table sums up the difference:

Your software needs both sets. The first lets it run, and the second makes it worth using. Thin documentation of either one leads to a disappointing product, or to a decent one that runs over budget and schedule.

How to write the documentation

You now know the main elements of an SRS. The next step is putting them in order as one document. We built a template that covers the requirements each party needs, and we use it across our product development projects.

Requirements engineering rests on 4 activities:

• Requirements elicitation (interviews with stakeholders and decision makers)
• Requirements analysis (checking that requirements are consistent)
• Requirements documentation
• Requirements verification and validation (are we building the system right, and are we building the right system)

Requirements engineering in the SDLC

Requirements engineering is the first stage of the software development life cycle (SDLC), and each of its 4 activities can send you back to elicitation.

To write an SRS you need a framework, and standards exist for that. IEEE 830-1998 is the classic one, and many templates still follow its contents. IEEE lists it as superseded by ISO/IEC/IEEE 29148:2011.

The current edition is ISO/IEC/IEEE 29148:2018, edition 2, last confirmed in 2024. As of Oct. 19, 2026, ISO marks it "to be revised," with a new draft (ISO/IEC/IEEE DIS 29148) in development. The 2018 edition stays current until that draft is published. We adapted 29148 for our own needs, and the examples below come from ReqView, the tool we use to organize requirements in line with it.

We also use Confluence by Atlassian for requirements management.

Product documentation splits into 4 parts:

1. Needs document: high-level user needs, written as user stories.
2. SRS: the software requirements specification.
3. Tests: the test cases that verify functionality against the requirements.
4. Architecture: the architecture of the application.

Below we show how to create the Needs, Architecture, and SRS documents. At a minimum, prepare a Needs document you can send to potential vendors before you commit to a build, whether you plan MVP development or a full platform.

Needs document

The Needs document describes the high-level functional requirements of the software in 3 sections.

Contact us for a free consultation and technical expertise

Need help documenting business requirements?

Contact us

1. Introduction

1.1 Purpose. An informational section describing the purpose of the document. A common opener is "The purpose of this document is to describe the software that is going to be built for..."

1.2 Project scope. Briefly describe the scope of the product. For a tool used to create an SRS (such as ReqView), users should be able to:

• Record requirements specifications
• Use custom attributes to manage requirements
• Set up requirements traceability and browse the matrix
• Review, comment on, filter, and search for requirements
• Import requirements from Excel and Microsoft Word
• Export requirements to PDF, HTML, DOCX, XLSX, or CSV, and print them
• Analyze requirements coverage and change impact

1.3 User roles. Name the user roles for the product, and describe a typical user for each. Consider personas with real names, described well enough that the whole team feels it knows them.

Here is a user role definition in ReqView:

And here is an example from our own product documentation:

2. Product functions

2.1 User stories. We use user stories to describe a product and its functionality, and we group them into epics for easier navigation. To write a user story, set these attributes:

• Heading: a short story name
• As a(n): the type of user
• I want: a goal
• So that: a reason
• Acceptance criteria: how the story should be verified
• Priority: "High" for fundamental features, "Medium" for important features with a short-term workaround, "Low" for features needed in a later release
• Risk: "High," "Medium," or "Low"
• Estimation: story points that give relative estimates of complexity, effort, or duration
• Status: "New," "Planned," "Implemented," or "Verified"

User stories in ReqView:

User stories in Confluence (source: Atlassian documentation):

2.2 User status flow. Sometimes a flow is clearer as a diagram, as in this user status flow:

And here is a deal or order creation and status flow:

3. Constraints

Here you describe constraints that act as global requirements, such as application speed or limited development resources.

Example from ReqView:

Architecture document

The architecture document has 3 sections: an introduction, the architecture itself, and references. Here is how we describe the architecture section for the energy sales platform from the user roles table above.

Overall architecture. The system serves 6 user types through 3 interfaces:

Staging environment. Hosted on Brocoders AWS resources and run by our team. The infrastructure includes a Redis instance for delayed jobs, an Amazon S3 bucket for system files, and general instances for the admin panel and web app.

Production environment. Hosted on the client's AWS resources and set up the same way. For platforms that serve many tenants from one codebase, this is also where you plan multi-tenant SaaS architecture.

References. List the SRS and any documents or websites the architecture document refers to.

SRS document

The SRS itself has 5 sections. Ours follow ISO/IEC/IEEE 29148:2018.

1. Introduction

1.1 Purpose. The purpose of this document is to give a working example of a software requirements specification based on ISO/IEC/IEEE 29148:2018.

1.2 Scope. As in the Needs document, describe the problem the software solves and how people will use it. Repeat or link the user capabilities from section 1.2 of the Needs document.

1.3 Product perspective. Describe how the product relates to other parts of the system, for example whether it belongs to a larger system. You can include requirements for user, system, hardware, software, and communication interfaces, plus memory constraints.

• System interfaces: list each system interface and the software functionality behind it. For example, the application runs on the latest version of Chrome or Firefox on Windows, Linux, and Mac.
• User interfaces: list the logical characteristics of every interface between users and the software, such as GUI standards and sample screens.

1.4 Product functions. Link this section to section 2 of the Needs document (user stories).

2. Requirements

Product functions are summarized in section 2 of the Needs document. This section turns them into requirements.

2.1 Functions. This section holds the functional requirements. Link every function to the Needs, Tests, and Architecture documents, and to its Jira task where that helps.

Here is how it looks in ReqView:

2.2 Usability requirements. Define usability and quality-in-use requirements, including measurable effectiveness, efficiency, satisfaction, and avoidance of harm in specific contexts of use. A usable interface supports these goals for its primary users:

• Efficiency: few setbacks and goals reached quickly.
• Intuitiveness: an interface that is easy to learn, with clear navigation, headings, buttons, and error messages.
• Low perceived workload: an interface that feels simple rather than intimidating or demanding.

2.3 Performance requirements. Performance requirements define how well the system performs functions under specific conditions: response speed, throughput, execution time, and storage capacity. They usually come from end-user tasks and drive both design and testing. This section can also cover:

• Database requirements
• Design constraints
• Standards compliance
• Software system attributes

3. Verification

Verification tests live in the Tests document.

4. Supporting information

Give the information and define the terms a reader needs to understand the document. Define abbreviations and acronyms, add diagrams and models, and keep a numbered list of every TBD item.

5. References

The references section includes:

• A complete list of all documents referenced elsewhere
• Each document's title, report number (if any), date, and publisher
• The sources where each reference can be obtained

Once every section is complete, get the SRS approved by the project's key stakeholders, and make sure everyone reviews the latest version.

How an SRS changes what gets built: 3 Brocoders builds

A template shows the shape of an SRS. These 3 builds show what a spec does to hours, budget, and scope once a team starts work.

Every module in the spec carries an hour estimate

In our hour-by-module breakdown of a 9-module SaaS MVP, built for a fintech accounting client in 23 working days, each module in the spec maps to its own estimate. The authorization module (registration, email verification, session handling, password recovery, and lockout) models at about 60 hours. The whole build models at about 600 hours, or about $27,000 at a $45 blended hourly rate, with 90 of those hours on QA and security.

The spec also makes extra work visible. The admin module was contracted at 3 screens and delivered as 10, and the build added 2 stretch goals on top of the 9 contracted modules.

A written Iteration 2 list kept an MVP under budget

For a martech AI client in spring 2025, we scoped a video-to-brief generator: an n8n workflow that picks up new video ads, transcribes them, and drafts a creative brief. The estimate was 90 hours. The MVP shipped in 75 hours for $3,375, 17% under the estimate, with the full parse-to-brief flow working.

The spec held because the features that would have stretched it went onto a written Iteration 2 list instead of into the build:

• Prompt pipelines for each content type
• A category selector that adjusts tone and structure
• A style classifier and a similarity-scoring quality loop
• Reusable templates and personalization

A non-goals list set the MVP boundary

For a construction staffing marketplace in October 2025, discovery ran 2 weeks: 3 workshops, a requirements session, and a scope finalization meeting, ending in a requirements document the founder approved. It stated what the MVP would not do: take payments (invoices are uploaded for record-keeping only), hold escrow, show maps, ship mobile apps, run advanced matching, or verify licenses.

Later we put a deferral list in front of the founder, with the price and the days for each item. He chose what to cut and what to keep, and he kept the admin panel, the SMS notifications, and the re-confirmation flow. The spec turned a scope argument into a priced decision.

How AI helps you write an SRS or PRD

Requirements work used to be the slowest part of a project. Workshops were followed by days of manual note-taking, email clarifications, and document assembly, and the PM's notes, the analyst's reading, and the developer's understanding still drifted apart. AI has compressed that cycle, and the same shift is reshaping every phase of the agile software development life cycle. On our projects, requirements elicitation and specification used to take 4 to 8 weeks. With AI, the same foundational documents now take 1 to 2 days.

The shift starts with one decision: the workshop transcript becomes the source of truth. We record and transcribe every discovery session in full, so the documentation rests on what the client said rather than on someone's memory of it. Anton Pushkin, project manager at Brocoders, describes the change:

"Everything comes from the transcript. The client explains their business, we discuss functionality, all decisions get captured. Then we feed all of that to AI, and the documentation writes itself, correctly, because it's grounded in what was actually said."

From that transcript, we run AI agents in parallel to draft the foundational documents:

• A product-owner agent drafts the PRD: user stories, business requirements, and user flows that connect the client's language with the developers' language.
• A software-architect agent drafts the SRS: the technical stack, architecture, and integration requirements. We keep it short on purpose, so it defines what to build without re-explaining patterns the team already knows.

We then cross-audit all documents against each other and against the original transcript, and we settle any conflict by going back to the transcript. By the time developers open Jira, the epics and sprint structure come from the same transcript the client signed off on.

AI helps at 6 points in the requirements process:

• Capture: transcribing and structuring workshops so nothing said is lost.
• PRD drafting: first-pass user stories, acceptance criteria, and user flows.
• SRS drafting: functional and non-functional requirements mapped to those user stories.
• Cross-checking: finding contradictions and gaps between the PRD, SRS, and design documents.
• Backlog: turning approved requirements into Jira epics, sprints, and tickets.
• Language: flagging vague terms so they get replaced with measurable criteria.

Spec-driven coding tools now write requirements in this format themselves. Kiro, for example, turns a prompt into a spec of 3 files: requirements.md with user stories and acceptance criteria in EARS notation ("WHEN [condition] THE SYSTEM SHALL [behavior]"), design.md for the architecture, and tasks.md for implementation tasks (Kiro documentation). An SRS with numbered, testable requirements gives a coding agent the same input it gives a developer.

Best practices for AI-assisted requirements

The tools are fast, and 7 practices keep their output trustworthy:

• Keep one source of truth. Anchor every document to the recorded transcript or a confirmed brief, so the AI drafts from real decisions instead of plausible guesses.
• Treat the spec as a living document. Update it whenever a decision changes, so it stays the ground truth for the team and for any AI development agents that read it. Addy Osmani puts it as "Don't write it and forget it" (O'Reilly, Feb. 20, 2026).
• State non-goals in writing. Spell out what is out of scope for this phase. An agent that does not see "authentication is out of scope for phase one" may add it anyway, because most apps have it (ChatPRD).
• Blend PRD and SRS thinking. Give the model PRD-style user context so it aims at the right outcome, and SRS-style specifics (database, APIs, constraints) so it makes correct technical decisions.
• Phase the requirements. Break work into sequential phases with clear dependencies and testable outcomes, which humans and coding agents both follow more reliably.
• Match detail to complexity. A trivial task does not need an exhaustive spec, while an OAuth flow with token refresh and error handling does.
• Validate every draft by eye. Every AI draft gets a human pass before it ships. "It looks plausible" is not a standard we accept, because a model can skim a long document or return something confident and wrong.

Use AI as a first-pass reviewer

One of the most useful jobs for AI in requirements work is catching gaps before a document reaches an expensive human review. In May 2026, Uber Engineering described the first-pass AI PRD reviewer its product teams built (Uber Engineering). It scores a draft PRD dimension by dimension, including opportunity and hypothesis, product scope, user experience and impact, and metric and data rigor. It then returns a launch-readiness scorecard with one "start here" fix, and it is designed to support senior judgment, not replace it.

We apply the same pattern to an SRS or PRD with 6 checks:

• Problem clarity: is the problem real, evidenced, and worth solving now?
• Success definition: is there a primary metric with a baseline and a target, plus guardrail metrics?
• Scope and decision readiness: are the boundaries of version 1 explicit, with no open questions left?
• User impact and edge cases: does it hold up across user segments, regions, and failure states?
• Dependencies and cross-functional risk: are downstream systems and legal, compliance, and operations impacts named?
• Rollout and validation: is there a release plan, a rollback plan, and a credible way to measure success?

Treat the document as not ready when it has no success metric, no baseline or target for that metric, an unclear primary user, or no rollback plan for changes that touch payments or core user flows.

We also ask the model to challenge its own output, and Anton Pushkin describes the habit:

"We ask the model to argue why the plan will fail, not why it will work. Then we decide for ourselves."

Because the same transcript drives the backlog, the handoff to development stays clean:

"We don't write tickets manually anymore. By the time the development team opens Jira, the sprint structure is already there, built from the same transcript the client signed off on."

Anton Pushkin, project manager, Brocoders

AI removes the blank page, the manual assembly, and the avoidable gaps. Experienced people still decide what the product should be.

SRS design guidelines

With the structure in place, 10 guidelines keep the document clear:

• Include diagrams and models, since they make processes easier to follow.
• Avoid ambiguity, so the parties skip endless discussion. A formal peer review reliably surfaces it.
• Keep sections consistent, with the same terminology and format, so one section never contradicts another.
• Use precise language. Replace "the app needs to be released as soon as possible" with dates, figures, and goals.
• Create a glossary, especially when you rely on internal definitions.
• Save the change history, so anyone can trace edits back to the first version.
• Give each requirement an identifier so it is easy to trace.
• Prioritize the product's main functions.
• Keep a clear portrait of the average end user in view.
• Keep the SRS flexible enough to update as the project evolves.

An SRS is the first deliverable, not paperwork

An SRS looks long and complicated at first. Follow the template above and it becomes manageable, and the payoff in clearer communication and shared goals outweighs the effort of drafting and approving it.

At Brocoders the SRS is the first deliverable on every project: it sets the hours, it holds the budget, and it records what waits for the next iteration. If you are planning a first release, our MVP development team starts with that document, and our SaaS case studies show where it leads.