Web App Requirements Document: A Simple SME Template

A website brief tells a designer what the pages should say and look like. That is a different document from the one a custom system needs, and swapping one for the other is where a lot of SME software money quietly goes.

A brochure site is judged by looking at it. A booking engine, a customer portal or a stock system is judged by whether the rules behind the screen are right — who may approve a discount, what happens when a payment half-clears, whether a cancelled order still counts towards a salesperson's target. None of that shows up in a mockup. It shows up in an argument three months later about whether it was in scope.

This guide is the template for that second document. It covers the six things a web app requirements document has to contain — roles, functional requirements, non-functional requirements, integrations, data rules and acceptance criteria — plus the section most SMEs skip, which is what to leave out of version one. If your project is a standard marketing site, the website brief template is the right starting point instead.

The video below walks through how a requirements specification is structured and why each part exists.

1. What Goes Into a Web App Requirements Document?

Quick Answer: Seven sections: purpose, user roles, functional requirements, non-functional requirements, integrations and data rules, acceptance criteria, and an out-of-scope list. Twelve to twenty pages is normal for an SME system. Most of it is written by you, not by the developer — which is why our web development team books client hours against it.

A requirements document is what a quotation gets priced against and what the finished build gets tested against. If it cannot do both jobs, it is a brief rather than a specification.

Here is the shape we use on SME builds, with a realistic sense of who writes each part and how long it takes.

Add the last column and it is roughly 21 to 37 hours of your team's time. That is a fortnight of somebody's attention spread over three or four weeks, and it happens before the build starts. Where that sits in the wider project is set out in the web development process from discovery to UAT.

Key takeaway: The functional requirements section belongs to your staff, not your supplier. A developer who writes it alone is guessing, and you will pay for the guesses in change requests.

2. Who Are the Users, and What Can Each Role Do?

Quick Answer: List every role that will touch the system, then write what each one may see, create, edit, approve and delete. Four to six roles is typical for an SME. The valuable column is the one nobody fills in — what a role must not be able to do. That column is what stops a clerk voiding an invoice at 11pm.

Roles are the first section people rush, because "staff and customer" feels obvious. It is not. Almost every Malaysian SME system we build ends up with more roles than the client first listed, and the extra ones appear the moment someone asks who approves what.

A workable role list for a mid-size system usually looks like this:

• Customer or member. Self-service only, sees their own records and nobody else's.
• Counter or operations staff. Creates and edits day-to-day transactions, cannot change prices or delete anything.
• Supervisor. Approves discounts, refunds and overrides, within a stated limit.
• Accounts. Reads everything financial, exports to the accounting system, edits nothing operational.
• Administrator. Manages users and settings — usually two named people, not a shared login.
• Auditor or owner. Read-only across the whole system, including the change history.

Write the limits as numbers rather than adjectives. "Supervisor can approve discounts up to 15% or RM 500, whichever is lower, and anything above goes to the owner" is buildable; "supervisor has more access" is not. Get the department heads in one room for this, the same way you would when collaborating with designers and developers. Role arguments are cheap now and expensive during testing.

Key takeaway: For every role, write one line beginning "must not be able to". Permission defects are cheap to fix in a document and awkward to explain to an auditor.

3. Functional vs Non-Functional Requirements: What Is the Difference?

Quick Answer: Functional requirements say what the system does — "issue a refund against a paid booking". Non-functional requirements say how well it must do it — speed, uptime, concurrent users, backup frequency, browser support. Functional gaps cause arguments about scope. Non-functional gaps cause arguments about quality, and those are harder to win.

The split matters because the two are written by different people. Your staff know the functional side, because they do the work. Only the developer can propose sensible non-functional numbers — but you have to confirm them, because they are commercial decisions dressed as technical ones.

• Functional — write as a sentence with an actor and an outcome. "A supervisor can void a same-day invoice and the system records who voided it and why."
• Non-functional — write as a number with a condition. "Any list page loads in under two seconds with 50,000 records and 20 concurrent users."
• Non-functional items SMEs forget. Daily backup with a tested restore, an audit trail on money-related actions, mobile browser support for counter staff, and what happens when the internet drops mid-transaction.

When a requirement is missed, it is almost never missed evenly. This is where the gaps actually sit on our SME builds.

Requirements missing from the first draft of Malaysian SME web app specifications, grouped by requirement class, showing the share of all missed requirements in each class and the phase at which the gap is usually discovered.

Requirement class	Share of missed requirements	Share	Usually found at
Exception handling on a normal task		28%	Acceptance testing
Reporting and export formats		21%	First month-end
Role limits and approvals		17%	Acceptance testing
Non-functional numbers		15%	After go-live
Integration behaviour on failure		13%	After go-live
Data migration rules		6%	Staging

Highlighted row is the largest single gap. Bars are proportional to the share column; shares total 100. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, requirements added after specification sign-off. Licence.

Reporting sits at 21% and surfaces only at the first month-end, because nobody asked what the finance team currently opens in Excel. The two rows found after go-live, non-functional numbers and integration failure behaviour, make up 28% of gaps between them, and they are the two shortest sections to write.

Key takeaway: Ask your finance and admin staff for every spreadsheet and report they produce by hand each month, and attach the files to the document. That one request closes the second-biggest gap on the list.

4. Which Integrations and Data Rules Must Be Written Down?

Quick Answer: Every system your app must talk to, named with its version, plus what happens when that system is unreachable. For Malaysian SMEs the usual list is a payment gateway, accounting software, WhatsApp or e-mail, and e-invoicing. The sentence that saves the most money is the one describing the failure case, not the happy path.

Integrations are priced per connection, so an unnamed one is an unpriced one. Name the actual product and the actual version — "SQL Accounting, desktop edition, on our office server" is a very different job from "any accounting software".

The list to work through:

• Payments. Which gateway, which methods — FPX, cards, e-wallets — and who reconciles a payment that leaves the bank but never reaches the order. Start from payment gateway integration from FPX to Stripe, and what a payment gateway actually is if the term is new to your team.
• Accounting. Direction of sync, how often, and which record is the master when both sides disagree. The practical shape is in connecting a website to SQL Accounting or AutoCount.
• Messaging. Which notifications go by WhatsApp, which by e-mail, who they go to, and whether a failed send is retried or logged.
• Customer records. Whether the app owns them or your CRM does — see what a CRM is and what it stores.
• Stock and fulfilment. Where the quantity of truth lives, especially if you already run a custom inventory system alongside a shopfront.
• E-invoicing. Malaysia's LHDN e-Invoice guidelines are being applied to businesses in phases by turnover, so any system that issues invoices needs its position written into the document rather than assumed.

Data rules sit alongside the integrations and answer duller questions that still cost money: how long records are kept, who may export them, what a deletion actually does, and which fields count as personal data. Systems holding customer records fall under the seven principles published by Malaysia's Personal Data Protection Department, which are far easier to build in than to retrofit. Where several systems are involved, API project budgets for system integration price each connection.

Key takeaway: For each integration, write one sentence for success and one for failure. The failure sentence is what stops a silent gap between your orders and your bank statement.

5. How Do You Write Acceptance Criteria a Developer Can Build To?

Quick Answer: Turn each requirement into a sentence somebody can pass or fail without an opinion. Name the starting state, the action and the expected result, including what the record and the notification should say afterwards. If two reasonable people could disagree about whether it passed, it is not acceptance criteria yet.

Acceptance criteria are the bridge between the document and user acceptance testing. Without them, sign-off is a mood. With them, it is a list.

We track how requirements were worded at sign-off against what happened later in the same projects.

Malaysian SME web app requirements compared by how they were worded at specification sign-off, showing for vague wording and for testable acceptance criteria the share of requirements that passed acceptance testing at the first attempt, the average change requests raised per ten requirements, and the average extra build days caused.

Measure	Vague wording	Testable criteria	Example wording
Passed acceptance testing first time	54%	86%	"Refund works" vs "Refund of a paid booking restores the slot and e-mails the customer"
Change requests per 10 requirements	3.4	1.1	"User friendly" vs "Booking completes in under four screens"
Extra build days per project	11	3	"Reports as needed" vs "Daily sales report by outlet, exportable to CSV"
Disputes reaching the contract	9%	2%	"Fast enough" vs "Search returns in under two seconds"

Highlighted row is the headline difference. Requirements were classified at sign-off, before any outcome was known. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom web application requirements and their acceptance results. Licence.

Roughly three times fewer change requests, and eight fewer build days per project, from a wording change that costs an afternoon. That is the best return available anywhere in a software budget.

If a requirement cannot fail, it cannot be delivered either. It can only be argued about.

How to turn a requirement into acceptance criteria

Five steps, each one short.

1. Write the starting state. Name the record the tester begins with — a paid booking from last month, a customer with an unpaid balance, an order already part-shipped.
2. Write the action and who does it. One role, one action. "The supervisor issues a full refund" beats "a refund is processed".
3. Write what must be true afterwards. Include the screen, the stored record, the report and any message sent. Most missed requirements hide in the last two.
4. Add one failing version. The same job where something goes wrong — the gateway times out, the slot has since been rebooked, the amount exceeds the approval limit.
5. Number it and keep the number. The same reference travels from the document to the quotation to the test script to the sign-off sheet, so nothing is delivered under a different name.

Keep the whole thing in one shared document rather than in e-mail threads. When a system is later handed to somebody else, that numbered list is the artefact that makes switching web developers without breaking your system possible at all, and it belongs with the source code you own.

Key takeaway: Give every requirement a number and keep that number all the way to sign-off. Renaming a requirement halfway through is how "delivered" and "what we asked for" drift apart.

6. What Should You Leave Out of Version One?

Quick Answer: Anything that does not block daily operations on launch day. Dashboards, loyalty schemes, multi-language, a mobile app, and most automation belong in version two. Write them into an out-of-scope list rather than deleting them, so the conversation is "later" instead of "no" and nobody re-adds them by accident.

That single page saves more money than any other part of the document, and it works precisely because it is written down. A feature that is merely unmentioned drifts back into scope during a demo; a feature listed under "version two" does not.

What happens to those extra version-one features is measurable.

Year by year from 2021 to 2026 on Malaysian SME custom web application projects, the median number of features specified for version one, the share of those features not used at all in the first twelve months after launch, whether an out-of-scope list was included in the requirements document, and the median working days from kickoff to first live use.

Year	Features in version one	Unused after 12 months	Had an out-of-scope list	Days to first live use
2021	42	34%	18%	104
2022	39	31%	26%	98
2023	36	29%	38%	91
2024	31	24%	52%	85
2025	28	21%	64%	79
2026	26	19%	71%	76

Highlighted row is the current position; 2026 covers January to August, with the unused-feature share measured on projects launched in 2025. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2021–2026, custom web application scope and first-year usage. Licence.

Version-one scope has fallen by nearly two-fifths since 2021, and the share of features nobody touched in the first year has fallen with it. Even so, roughly one built feature in five still goes unused after being paid for, tested and maintained. The out-of-scope list column moved fastest, and it is the cheapest of the three to copy.

Sensible things to defer on an SME build:

• Dashboards and analytics. You cannot design a useful dashboard before the system has produced any data.
• A second language. Ship in the language most of your customers use, then translate once the wording has settled.
• A mobile app. A responsive web app covers most SME cases — the comparison is in mobile app against website.
• Loyalty, promotions and referral schemes. Rules change quickly in the first year; build them once they are stable.
• Automation of a rare task. If it happens twice a month, a person can keep doing it for now.

If cost is the reason for cutting scope, size the first release deliberately rather than by trimming at the end — budgeting an MVP build and the hidden costs of custom software cover the licences and servers that arrive with each extra feature.

Key takeaway: Put every deferred feature on a written version-two list with a date to review it. Deferred and forgotten look identical in month three, and only one of them keeps your team's trust.

7. The Document Is the Cheapest Part of the Build

Quick Answer: Three or four weeks of part-time work, mostly meetings you would have had anyway, against a build measured in months and ringgit. Every quotation you collect afterwards is priced against the same document, so the comparison is finally like for like — which is the second reason to write it.

A web app requirements document does two jobs at once. It tells a developer what to build, and it lets you compare suppliers fairly, because three quotations against three different verbal briefs are not comparable at all.

Bring the finished document to every conversation and watch what each supplier does with it. The useful ones argue with it: they question a rule, spot a missing failure case, push back on a non-functional number. Then make sure the same document survives into delivery, the way a pre-approval checklist and ownership of your domain and files do on a website contract. If your project is really a shop rather than a system, an e-commerce site that sells or an online booking system may get you there faster.

When you are ready to price a real system, start with ZenWeb web development — we write this document with clients before quoting, not after. You can see how we work across the rest of the business at ZenWeb.

8. Frequently Asked Questions

1. What is a web app requirements document?

It is the written specification a custom system is quoted, built and tested against. It names the user roles and their limits, lists the functional requirements, sets non-functional numbers such as speed and backup frequency, records every integration and data rule, attaches testable acceptance criteria, and states what is out of scope for version one. Twelve to twenty pages suits most Malaysian SME systems.

2. How is it different from a website brief?

A website brief describes pages, content and look, which is what a marketing site is judged on. A requirements document describes rules, roles and results, which is what a system is judged on. A booking engine or a portal can look exactly as designed and still be wrong, because the error lives in an approval limit or a refund rule rather than on the screen.

3. Who should write the requirements — us or the developer?

The functional requirements belong to your staff, because only the people doing the work know the exceptions. The developer drafts the non-functional numbers and the integration detail, then you confirm them. Acceptance criteria are written jointly and signed by you. Expect to spend 21 to 37 hours of your own team's time on a mid-size SME system.

4. What are functional and non-functional requirements?

Functional requirements state what the system does — "a supervisor can void a same-day invoice and the system records who did it and why". Non-functional requirements state how well it must do it — page load under two seconds with 50,000 records, daily backups with a tested restore, support for the browsers your counter staff actually use. Missing non-functional numbers usually surface only after go-live.

5. How long does a requirements document take to write?

Three to four weeks part-time for a mid-size SME system, running alongside your normal work. Most of that is workshop time with the people who handle the exceptions, plus one round of review. The time is spent before the build starts rather than added to it, and testable wording cuts change requests sharply.