SRS Document: How to Write a Software Requirements Specification

An agreed specification gives your team a shared basis for estimates and acceptance tests. Here's how to write a software requirements specification your development partner can price, build and verify.

Highlights

• An SRS turns business goals into requirements a team can estimate and test.
• Testable criteria and mapped integrations make an estimate defensible.
• Mobile apps add store rules, OS targets, offline behavior and privacy disclosures.

An SRS document (software requirements specification) describes what software must do, how well it must do it and which constraints it works within. The team agrees on requirements for the planned release before implementation begins, then updates them as decisions change.

Growing companies usually feel the cost of a thin specification at the worst moment. It might be an estimate that doubles mid-project, or a feature that passes QA and still misses a business rule nobody wrote down. Both disputes start with requirements that existed only in someone's head.

We've run discovery and business analysis on products such as the FITR coaching platform and the Mulki property app for landlords in the MENA region.

If your requirements are spread across a deck, a backlog and a few email threads, the first question is which of those requirements a team could estimate today.

What is an SRS document?

An SRS is the agreed, versioned record that sits between business goals and design. Teams also call it a software requirements document. Requirement IDs tie scope to estimates and acceptance tests, so when a disagreement comes up, the team checks the requirement and the assumptions behind it.

Several groups read the same SRS:

• You and your stakeholders: confirm it solves the business problem within budget.
• Engineers: choose the architecture and estimate effort.
• QA: write test cases from the acceptance criteria.
• The project manager: controls scope and judges change requests.

SRS vs BRD, PRD and technical specification

These four documents connect business goals, release scope, system requirements and implementation decisions.

On smaller projects the BRD and PRD often become the first section of the SRS. That works as long as every requirement can still be traced to a written goal.

SRS document template

A workable SRS template (a software requirements specification template, in full) has five sections: introduction, overall description, requirements, verification and appendices. Our outline draws on the information items in the ISO/IEC/IEEE 29148:2018 standard, adapted for teams that need a practical working document.

The examples follow one hypothetical product through this guide: a field service app that technicians use on site, synced with the company's CRM. Each section below comes with sample wording from that app.

• 1. Introduction: purpose, scope, definitions and glossary, references.

  Example wording for the business goal and release scope: "Release 1 lets technicians close work orders on site; invoicing stays in the CRM."

• 2. Overall description: product perspective, users and roles, assumptions and dependencies, constraints.

  Example wording for roles and dependencies: "Roles: technician, dispatcher, admin. Depends on the CRM work order API."

• 3. Requirements: functional requirements with ID and priority, interfaces, data, non-functional requirements, compliance. Each statement also states its limits and failure cases.

  Example wording: "FR-012 (Must): A technician can attach up to 10 photos, each up to 10 MB, to a work order."

• 4. Verification: acceptance criteria for each requirement and traceability to tests.

  Example wording: "FR-012 passes when 10 photos of up to 10 MB each sync to the CRM record, and an 11th photo or a larger file is refused with a message."

• 5. Appendices: risks, open questions, change log.

  Example wording for an open question: "Open: does the CRM rate limit allow a sync every 5 minutes?"

Mind Studios' recommendation: Start the glossary in the first workshop. Engineers who join mid-project don't know your business terms, and one agreed definition of "job," "visit" or "work order" prevents many acceptance disputes.

Adapting the template for documents and mobile apps

The outline copies cleanly into Word or Google Docs as a software requirements document template, with one table per section and requirement IDs in the first column.

For a mobile product, add the block from the mobile section below, and the file becomes a mobile app requirements document template. Teams that keep specs in Word can save that version as a mobile app requirements document Word template for later releases.

Ready-for-estimate checklist

Before the document goes out for an estimate, run five checks:

• Every requirement has an ID, an owner and a priority.
• Every non-functional requirement has a testable criterion and an agreed verification method.
• Every integration names the system, the direction of the data and an owner on your side.
• Open questions sit in the appendix with an owner and a due date.
• The glossary covers every business term used more than once.

What goes into an SRS document

An SRS answers four questions: what the system does, how well it does it, which systems it connects to and which data, rules and constraints it must respect.

The table maps the main types of software requirements to the field service app.

The four parts below take those questions one at a time.

Functional requirements

Functional requirements describe how the system responds to a user action or an external event. Each has an ID, a priority and a rationale. User stories feed these statements, and the SRS adds the limits and failure cases the stories leave out.

Non-functional requirements

Non-functional requirements set the quality bar, and vague wording is costly here because these criteria shape the architecture. "The app must be fast" can't be estimated. NFR-004 can: "95% of work order screens load in under 2 seconds on the agreed 4G test profile" (an illustrative threshold), because the profile fixes devices, data volume and network conditions.

Some qualities are pass/fail rules rather than measurements. "Customer signatures and job photos are encrypted on the device and in transit" is as testable as a load time.

For a CTO reviewing the draft, these criteria drive the scalable architecture choices that are hardest to reverse later.

External interfaces and integrations

For a company with a working product, this section is the contract for every connection to systems you already run, such as a CRM, ERP, EHR or payment provider.

Each entry names the system and version, the API or file format, data direction and frequency, error behavior and a contact who can grant sandbox access.

Mind Studios' insight: When an integration is described only as "sync with the CRM," the estimate has to guess at the effort. API documentation and sandbox access let the team investigate authentication, data mapping and error handling before estimating.

Data, business rules and constraints

This part records what the system must respect: data entities, reports, retention and disposal, plus rules from policy, regulation and industry standards. Budget and deadlines belong here as constraints the solution has to fit.

Which regulations apply depends on your users, markets and data, so the SRS states those facts first and derives requirements from them:

• EU personal data: if the product falls under GDPR, Article 25 GDPR requires data protection by design and by default, which becomes minimization and retention rules.
• US health data: if you're a HIPAA covered entity or business associate handling electronic protected health information, the HIPAA technical safeguards each map to a requirement.
• Card payments: a system that stores, processes or transmits cardholder data falls under PCI DSS, which shapes how payment flows are specified.
• Saudi personal data: Article 18 of the Saudi PDPL requires destroying personal data once its purpose ends, with exceptions such as statutory or judicial retention, so deletion triggers need their own requirement.

Who writes the SRS and what your development partner adds

The SRS is a joint document. You bring the business context: goals, rules, constraints and final sign-off. The partner's business analyst turns that context into numbered software requirements that can be tested, and the tech lead checks that each can be built.

With an external team, the work usually splits like this:

Anton Baryshevskyi, Head of Business Development and Co-Founder at Mind Studios, explains what founders should bring to their first session with a business analyst:

Founders usually arrive with a feature list and a platform already chosen. In the first session we sort those into two piles: business constraints, which apply whatever we build, and assumptions about the solution, which discovery should test. So write your constraints as facts about users, money and rules, and let discovery decide how to deliver them.

How deep the document goes depends on risk. A full SRS pays off when the product has integrations, regulated data, several roles or an external team estimating against it. An internal prototype that won't touch production data needs only goals, roles, key scenarios and non-functional criteria.

On our projects this work happens in a business analysis phase before development starts.

If you're unsure which half of the SRS your team can write alone, mapping that split is the first job of discovery.

How to write an SRS document in 7 steps

You write an SRS in seven steps: set goals, define users, write functional requirements, set non-functional criteria, map interfaces and data, review with the development team and baseline the document.

1. Set goals. Define success criteria: describe the business problem, the outcome the release must deliver and the metric that proves it, such as fewer return visits per job.

   Who: founder or product owner with the BA.

   Output: section 1, with scope in and scope out.

2. Define users and roles. List every role and write user stories as "As a…, I want…, so that…". Figma wireframes help each role's representatives agree on flows early.

   Who: product owner, BA, designer and one representative per role.

   Output: role matrix and story map.

3. Write functional requirements. Turn stories into numbered statements with IDs, limits and failure cases, and rank them with MoSCoW (must, should, could, won't).

   Who: BA, reviewed by the product owner.

   Output: prioritized list in section 3.

4. Set non-functional criteria. Cover load at launch and at scale, performance, availability, security and offline behavior, each with a verification method.

   Who: BA and tech lead, with your input on markets and compliance.

   Output: testable quality requirements.

5. Map interfaces, integrations and data. Document every system the product reads from or writes to, plus data entities and retention.

   Who: BA, tech lead and admins of your current systems.

   Output: integration list, data dictionary, open questions.

6. Review with the development team. Engineers and QA check feasibility, flag risks and estimate. Anything they can't estimate goes back to the BA as a question. Many development cost drivers surface at this step, while changing them still means editing a document.

   Who: tech lead, engineers, QA, BA.

   Output: estimate, assumptions and risk list.

7. Baseline v1.0. Agree on change rules: decide who approves changes and where the change log and document live. Word works for a first draft. Once requirements link to tickets, the Confluence and Jira integration connects the requirements page with delivery tasks.

   Who: you and the partner's project manager.

   Output: signed baseline.

How to write requirements developers can build and test

A good requirement is a single statement with one possible reading and a clear pass or fail condition. Developers can estimate it because the limits are written down, and QA can verify it without asking what was meant.

Eight qualities of a good requirement

We check software requirements against eight qualities before an estimate.

Vague wording and how to fix it

Vague wording fails the last check fastest. Reviewers call such patterns requirement smells: "etc.," "user-friendly," "as needed" and statements about what the system shouldn't do. The fixes below use illustrative thresholds, so agree on values that fit your product.

• "The app should be fast." → A load-time target with a percentile, a limit and a test profile, as in NFR-004 above.
• "User-friendly sign-off." → "A technician captures a customer signature in no more than 3 taps."
• "Supports photos, documents, etc." → Each file type listed with its size limit and the message shown when it's exceeded.
• "The app shall not lose data." → "FR-021: Unsynced changes are saved on the device and survive an app restart." Then a separate "NFR-009: Queued changes sync within 60 seconds of reconnecting."

EARS, Gherkin and traceability

EARS syntax gives sentence patterns such as "When [trigger], the [system] shall [response]." Gherkin scenarios frame acceptance criteria as Given, When and Then, which QA can automate. This is one failure case for FR-012:

• Given a work order with 10 attached photos
• When the technician attaches an 11th photo
• Then the app refuses it with the message "Limit of 10 photos reached," and the 10 saved photos stay attached

Traceability connects these pieces. Each requirement points back to a goal and forward to a test, so a change request shows right away what it affects. In the field service app, each chain runs from goal to requirement ID, acceptance criterion and test:

Fewer return visits → FR-012 photo attachments → 10 photos of up to 10 MB each sync, and an 11th or a larger file is refused → T-031 count and size limit test.

Faster dispatch → NFR-004 list load time → load-time target met on the test profile → T-047 performance run.

Mobile app requirements: what to add to the SRS for iOS and Android

A mobile app requirements document is the SRS plus a mobile block covering platforms and OS versions, store rules, offline behavior, push notifications, permissions, privacy disclosures, accessibility and analytics. These mobile application requirements sit in section 3 of the template, next to the shared functional and non-functional ones.

Many mobile app development requirements come from Apple, Google and regulators. Which ones apply depends on how the app is distributed, how it makes money and where it's offered, so your app development requirements record those facts first.

Store rules for iOS and Android

Apple's App Review Guidelines generally require in-app purchase to unlock digital features or content. Under guideline 3.1.3(c), an app sold only directly to organizations or groups for their employees or students can let enterprise users access previously purchased content or subscriptions.

Consumer, single-user and family sales still need in-app purchase. Apps that support account creation must also offer account deletion inside the app.

Google Play's target API rules require new apps and updates to target Android 16 (API level 36) since August 31, 2026. Permanently private apps distributed inside one organization are exempt. The oldest OS version you support is a separate decision based on your users' devices, and the Developer Policy Center sets monetization and privacy rules.

For public store releases, Apple's App Privacy details and Google Play's Data safety form also cover data that third-party SDKs collect. So the SRS lists every SDK and the data it collects.

Accessibility and market rules

WCAG 2.2 gives testable accessibility criteria any team can adopt, and legal duty is a separate question. The European Accessibility Act covers listed products and services such as e-commerce, banking services and passenger transport. The Act has applied since June 28, 2025, so check a consumer app's category with counsel.

The table turns these points into SRS lines for the field service app. Add them to the shared template, and it works as a mobile app spec template.

Each line then gets its own ID and a MoSCoW priority.

Tip: Apple and Google update store policies regularly. Name one person on your mobile development team to reread both policy pages before every major release and log any change in the SRS.

Keeping the SRS alive during development and after launch

An SRS document stays useful only while it changes with the product. One named owner keeps the version history and change log. Every change request lists the requirement IDs it touches, the BA assesses its impact on scope, cost and tests, and the approver signs a new version before work starts.

The requirements work itself runs as a loop that continues after the baseline and after launch:

• Elicitation: asking users and stakeholders what they need and watching how they work.
• Analysis: sorting that input against existing requirements.
• Specification: writing it down as numbered, testable statements.
• Validation: confirming with stakeholders that it's accurate and complete.

If you ever need to switch development vendors mid-project, an up-to-date SRS gives the incoming team a record of agreed behavior and open decisions.

How discovery shapes platform and localization requirements

Discovery decisions become part of the baseline, and some reshape the product before any code exists. The initial idea for FITR was a mobile app, but during discovery we decided to switch the platform to the web.

Coaches were the main audience, and managing programs and clients was more convenient on the web. Customer acquisition cost was also significantly lower for web fitness platforms than for mobile apps. Athletes preferred mobile, so their app came after the coach platform.

Market rules enter the baseline the same way. For Mulki, we analyzed existing workflows and compliance needs to align with local lease regulations and financial practices.

Payment dates follow the Hijri calendar, contracts follow government lease templates, and Arabic text runs right to left while numbers stay left to right. We designed a modular architecture to support fast feature expansion.

Mind Studios' approach: After launch, we check each bug report against the baseline and its acceptance criteria. Behavior that breaks an agreed criterion is a defect. A case the SRS never covered is a requirements gap that we log and estimate with you, and anything that changes agreed behavior goes through change control.

Before you hand the SRS to a development partner

The estimate that doubled and the feature that missed a business rule are both cheaper to settle in a document than in a sprint. A software requirements specification moves the scope argument to the point where changing your mind costs an edit.

Send the draft with its open questions visible. The estimate should name the SRS version and the assumptions behind it, so both sides can assess the impact of later changes.

If you have a draft, the next question is which gaps still stop a team from estimating against it.

FAQ

Who writes an SRS document?

A business analyst usually leads the writing, but agree up front on who settles conflicts between requirements:

• Business rules and priorities: you or your product owner.
• Feasibility and non-functional criteria: the tech lead.
• Testability: QA.
• Changes after the baseline: the approver named in the change rules.

What's the difference between a BRD and an SRS?

A business requirements document explains why the company needs the product and which business outcome counts as success. The SRS describes the system behavior, quality criteria and constraints that deliver that outcome.

Can you share a software requirements specification example?

The template section shows the full structure; here is a pair from the field service app:

• Functional: "FR-018: A dispatcher can reassign a job; a technician can only request reassignment."
• Non-functional: "NFR-011: Every reassignment is logged with user, time and previous assignee, and log entries are read-only for every role."

What does an SRS example look like for a mobile app?

It's the same five-section software requirements specification with a mobile block. A typical line reads: "The app shall request location access only when a technician starts a job and shall keep working if access is denied."

How do you gather requirements for a mobile app?

Gathering requirements for mobile app development combines several sources:

• Interviews with each user role.
• Observing field work on real devices and real networks.
• Analytics and support tickets from your current product.
• A review of Apple and Google store policies.
• Clickable prototypes that each role tests before requirements are written.

Is there a difference between mobile app requirements and software requirements?

Mobile app requirements are software requirements with a device layer. Business rules, roles, data, integrations and server-side performance usually stay shared, so a web portal and an app can trace to the same IDs. Offline storage, permissions, battery use, push delivery and OS targets depend on the device, so they get their own IDs and device tests.

Can you start development without a full SRS?

Yes, with a lighter version (goals, roles, key scenarios, quality criteria), as long as the remaining unknowns don't block the estimate. Unknowns that do block it include integrations without API access, unclear regulatory scope and an undecided platform. Re-baseline when an answer to one of them changes scope.

6