Three quotes for the same app idea rarely disagree about hourly rates; they disagree about what each software company assumed you meant. A good SRS removes the guesswork. Still shaping the idea? Start with a founder's path from idea to first release.
What is an SRS, and how is it different from a BRD and a PRD?
An SRS (software requirements specification) states what the software must do and how well, precisely enough to build, test and price. A BRD explains why the business wants it, and a PRD describes the product and its users. They are layers of one decision, not competing formats.
| BRD (business requirements) | PRD (product requirements) | SRS (software requirements) | |
|---|---|---|---|
| Usually written by | Founder, business owner or business analyst | Product manager or founder | Business analyst or senior engineer, with the founder deciding |
| Main reader | Leadership, investors, the board | Design and engineering leads | The vendor's engineers and testers, and the contract |
| Contains | Goals, the business problem, high-level scope, success measures, constraints | Users, journeys or user stories, prioritised features, release scope, product metrics | Numbered functional requirements, measurable non-functional requirements, interfaces, data, constraints, acceptance criteria |
| When | Before deciding to invest | Before design starts | Before quoting and contracting; kept current during the build |
The requirements-engineering standard, ISO/IEC/IEEE 29148:2018, describes four specifications: business (BRS), stakeholder (StRS), system (SyRS) and software (SRS). "PRD" is not among them; it is a product-management convention that each company shapes differently. For a startup I usually fold the BRD and PRD into a short product brief and spend the real effort on the SRS, which gets priced, built and tested.
What does a software company need from the SRS to give you a real quote?
Enough to estimate effort without guessing: the users, every feature as a numbered requirement with a priority, every integration, quality targets and what is out of scope. Whatever a vendor has to guess, it prices as risk.
Typical gaps: one quote includes an admin panel, another doesn't; one assumes Arabic and English, another English only. Before sending the SRS, check it answers each of these:
- Platforms and order: iOS, Android, web, admin dashboard, and which ships first.
- Roles and permissions: who can see and do what, from customer and provider to operations, finance and support.
- Features: numbered requirements, each tagged Must, Should or Later.
- Integrations: payment gateway, SMS and one-time passwords, maps, accounting or ERP, e-invoicing, and who owns each account.
- Data: what you store, your own estimate of first-year volumes, and anything migrating from an old system.
- Quality targets: performance, uptime, security and languages, each with a number.
- Non-goals: what this release will deliberately not do.
- What you provide: designs, content, brand assets, Apple and Google developer accounts, the merchant account.
- Acceptance: how each requirement will be verified and who signs off.
That last item matters most for your contract: tie milestone payments to acceptance criteria, not dates. More on that in what to check before signing with a software company.
What sections should an SRS include? A template you can copy
Use the outline below, which I adapted from the SRS content clause of ISO/IEC/IEEE 29148 and trimmed for a startup. Keep the numbering so every requirement can be cited in the contract, tickets and tests.
- Purpose and scope: the problem, this release, and an explicit list of non-goals.
- Product perspective: the apps, the admin side, and every external system the product talks to.
- Users and roles: who uses it and where (a courier on a phone in the sun is not an accountant at a desk), plus the permissions matrix.
- Assumptions, dependencies and constraints: an ERP that must stay, a hosting location you have chosen, launch languages.
- Functional requirements: grouped by module and numbered (FR-BOOK-01, FR-PAY-03), each with a priority and acceptance criteria.
- External interfaces: payments, SMS, maps, accounting, government platforms; for each, the account owner and test environment.
- Data requirements: main entities, an inventory of personal data, retention and deletion rules, reports.
- Non-functional requirements: performance, uptime and recovery, security, usability and accessibility, localisation, each with a target and a measurement method.
- Compliance: personal data protection, e-invoicing and any sector rules, written as requirements rather than footnotes.
- Verification and acceptance: test approach, environments, who runs user acceptance testing, the definition of done.
- Appendices: a bilingual glossary, links to wireframes, open questions with an owner and a due date.
The bilingual glossary is not decoration: when "booking" means one thing in the app, another in the contract and a third in the database, disputes start there. For Saudi products I fix each business term in Arabic and English and use it consistently. If you want the SRS written or reviewed by a senior engineer before vendors see it, that is part of my advisory work.
How do you write acceptance criteria a vendor can't argue with?
Write each criterion as a pass-or-fail check: given a starting state, when something happens, then an observable result. Cover the failure paths as well as the happy path, and put a number wherever you were about to write "fast".
A hypothetical requirement from a Saudi salon-booking app, written the way I would hand it to a vendor:
FR-PAY-03 (Must): The customer shall pay the booking deposit with a mada card or Apple Pay before the booking is confirmed.
- Given a customer with an unpaid booking, when they pay with a mada card and the bank's 3D Secure check succeeds, then the booking becomes "Confirmed" and an Arabic confirmation arrives by push notification and SMS within one minute.
- Given the 3D Secure check fails or the customer abandons it, when they return to the app, then the booking stays "Awaiting payment", the slot is held for ten minutes, and an Arabic message offers a retry.
- Given the gateway confirms the payment but the app loses its connection before the callback, when the reconciliation job runs, then the booking is confirmed and the customer is never charged twice.
- Given the salon cancels a confirmed booking, when the cancellation is saved, then a full refund starts to the original payment method and the event appears in the admin audit log.
The criteria name states, timing and language, and turn three expensive arguments (a failed bank check, a lost callback, a refund) into lines a tester can tick. The one-minute and ten-minute values are placeholders; what matters is that the business chose a number.
Which non-functional requirements matter most for apps in Saudi Arabia and the Gulf?
Five come up on almost every Gulf product: Arabic as a first-class language, performance on mid-range phones, personal data, local payments, and e-invoicing if you issue tax invoices. Each needs a measurable line in the SRS; each is expensive to add later.
| Area | What to write in the SRS | Why it can't wait |
|---|---|---|
| Arabic and right-to-left (RTL) | Every screen, notification, email, PDF and admin page in Arabic and English; mirrored layouts; mixed-direction text and numbers rendered correctly; search tolerant of Arabic spelling variants. | RTL touches every screen; retrofitting means reworking them all. |
| Performance | A named mid-range Android phone and network condition, with targets for app start and key screens. For web pages, Core Web Vitals: LCP within 2.5 s, INP of 200 ms or less, CLS of 0.1 or less, at the 75th percentile, mobile and desktop measured separately. | Your users are not on the developer's flagship phone. |
| Personal data | Personal data per feature, its purpose, retention, storage location and who can access it; audit logs; breach detection and an incident runbook. | Article 24 of the Implementing Regulation of Saudi Arabia's Personal Data Protection Law (PDPL) gives a controller no more than 72 hours from becoming aware of a qualifying breach to notify the competent authority. |
| Payments | Which methods (mada cards, Apple Pay, credit cards), which gateway, full and partial refunds, daily reconciliation. | The Saudi Central Bank (SAMA) owns mada, lists a service for adding mada cards to Apple Pay, and says mada online payments run through 3D Secure, so the bank's verification step and its failures belong in your flow. |
| E-invoicing | If the system issues tax invoices: which types (tax invoices, usually B2B; simplified tax invoices, usually B2C) and who builds and owns the integration. | ZATCA, the Zakat, Tax and Customs Authority, has enforced its generation phase since 4 December 2021; its integration phase, rolled out in waves from 1 January 2023, requires integration with ZATCA's systems. |
This is engineering guidance, not legal advice; confirm your obligations with a lawyer, and see my PDPL engineering checklist for the data side.
Which standard should an SRS follow: IEEE 830 or ISO/IEC/IEEE 29148?
ISO/IEC/IEEE 29148. IEEE 830-1998 was superseded by ISO/IEC/IEEE 29148:2011, and the second edition, 29148:2018, replaced that one. ISO confirmed the 2018 edition in 2024 and marked it for revision in 2026; a draft successor, ISO/IEC/IEEE DIS 29148, is expected within months.
Even if you never adopt it formally, it gives you:
- A vocabulary separating business, stakeholder, system and software requirements, which ends arguments about what "the requirements" means.
- Characteristics of good individual requirements and of a good requirement set, plus criteria for requirement language.
- An example SRS outline and the content each section should carry.
Use it as a checklist, not a format to imitate: a tight SRS that follows its logic beats a long one copying its headings. If a template or vendor still cites IEEE 830 as current, ask when they last revisited their process.
What mistakes make an SRS useless?
The three I see most: design detail where behaviour should be, technology choices without reasons, and no non-goals. Each becomes either a constraint the vendor cannot price or a gap they will price high.
- Pixel-level design. Fonts, colours and spacing belong in the design files. The SRS states behaviour and refers to screens by ID; otherwise every design tweak becomes a change request.
- Technology without reasons. "Must use microservices" or "must be built in Flutter" removes the vendor's judgment and your ability to compare quotes. If a real constraint exists, such as your team's stack or a required cloud region, write it with the reason.
- No non-goals. Without "this release will not include…", every assumption expands scope. Write them down: no customer web app in release one, no loyalty programme, an English-only admin.
- Everything is a Must. If nothing can move to a later release, the vendor cannot offer you a smaller first version.
- A forgotten back office. Refunds, disputes, content moderation and reports are features, and operations need them on day one.
How are PRDs and SRSs changing with AI coding tools in 2026?
Specs are becoming the input AI coding agents build from, so precision matters more. A vague requirement used to prompt a developer's question; an agent may instead produce plausible code that does the wrong thing.
Spec Kit, the open-source toolkit GitHub announced in September 2025, is one example: work moves through Specify, Plan, Tasks and Implement, it works with coding agents such as GitHub Copilot, Claude Code and Gemini CLI, and the announcement says specs become "the shared source of truth". What I change in practice:
- Keep the SRS as versioned Markdown in the repository, next to the code it governs.
- One requirement per line, with a stable ID that tests and commits can reference.
- Acceptance criteria concrete enough to become automated tests.
- Explicit non-goals and non-functional targets, because an agent will not guess that your users read Arabic on mid-range phones.
None of this removes the need for a senior person to own the trade-offs. An agent can write the code a spec describes; it cannot tell you whether the spec describes the right business.