Start With the Right Structure, Not a Blank Page
If you have been handed an ecommerce project and told to produce a business requirements document, the first challenge is not figuring out what the site needs to do. It is figuring out how to organise what you already know, and what you still need to find out, into a document that stakeholders will actually read and sign off on. I have written BRDs for ecommerce builds across retail, government services, and utilities billing portals, and the ones that worked had a consistent structure. The ones that caused trouble were usually missing one or two critical sections that only became obvious later, when a developer asked a question no one had thought to answer.
This article gives you that structure, explains what goes in each section, and walks through a real example of where things got complicated. If you want a ready-made starting point, the BRD template in Word format on this site is worth downloading before you start drafting.
The Core Sections of an Ecommerce BRD
An ecommerce BRD covers more ground than a standard internal system BRD because it sits at the intersection of customer-facing experience, payment processing, fulfilment logic, and back-office integration. These are the sections you need to cover, and what belongs in each one.
- Document purpose and scope: State clearly what the document covers and what it deliberately excludes. For an ecommerce site, scope typically includes the storefront, checkout, payment gateway integration, and order management. It usually excludes warehouse management systems and marketing campaign tooling unless those are in scope.
- Business context and opportunity statement: Explain why this project is happening now. This is not background padding. It is the section that justifies every requirement that follows. Is the business replacing a legacy platform? Introducing online sales for the first time? Reducing manual processing of phone orders?
- Stakeholder consultation: List who you spoke to, in what format, and what process areas they covered. This protects you later when someone claims a requirement was never discussed.
- Business requirements: High-level objectives stated as outcomes the business needs to achieve. These are not system features. They are the reasons the system needs to exist.
- User requirements: What each user type needs to be able to do. For an ecommerce site, you typically have at minimum a customer, a store administrator, and a finance officer. Each has a distinct set of needs.
- System requirements: The capabilities the system must have to support those user requirements. This is where payment gateway behaviour, GST or VAT logic, order status workflows, and notification rules live.
- Rules and constraints: Non-negotiable conditions that the solution must operate within. Accepted payment methods, refund policy, geographic restrictions, and data retention obligations all belong here.
- Fee types, pricing, and tax logic: In any ecommerce context, you need a clear table of what is being sold, at what price, and how tax is applied. This is one of the most disputed sections in practice.
- Financial processing and reporting: How transactions flow from the payment gateway into the finance system. Who reconciles, how often, and what data fields need to match across systems.
Worked Example: Project X, Organisation B
I worked on a BRD for Organisation B, a government-adjacent entity that processed applications from external users and wanted to introduce online payment as part of the submission workflow. The situation maps closely to ecommerce: there were multiple product types (application categories), variable pricing, a payment gateway integration, and a finance team that needed clean reconciliation data.
The document covered nine application types with prices ranging from $125 to $750 excluding tax, with GST applied only to applications submitted from within Australia. That tax rule sounds simple until you realise the system had no way of knowing where the user was located unless they declared it. The initial draft requirement said the system would apply GST automatically. The finance officer, when she reviewed it, pointed out that this would create compliance problems for offshore applicants who might inadvertently be charged tax they were not liable for.
That created a genuine point of friction. The operations manager wanted a simple rule: charge GST to everyone, refund if challenged. The finance officer refused to accept that on the grounds that it would create a reconciliation nightmare and potentially breach tax obligations. I had to go back to both stakeholders separately, document the disagreement, and escalate to the project sponsor before the rule was settled: GST would be applied only where the applicant declared an Australian address at the point of submission, and the system would display a clear prompt asking for that declaration before the payment screen loaded.
That single requirement took three rounds of revision and went through four document versions before it was signed off. The lesson I took from it is that tax and payment rules always look simple in a stakeholder workshop and reveal their complexity in the detailed review. In an ecommerce BRD, never assume the pricing and tax section is straightforward just because the numbers are clear.
Business Requirements vs System Requirements: Why Both Matter
One of the most common mistakes I see in early-career BA work is conflating business requirements with system requirements. They serve different purposes in the document and they speak to different audiences. If you want a clear breakdown of how these two layers relate to each other, the article on BRD vs FRD covers this well.
For an ecommerce site, the difference looks like this:
| Requirement type | Example for an ecommerce site | Who cares about this |
|---|---|---|
| Business requirement | Collect payment from customers at point of order submission to reduce manual invoicing workload | Sponsor, operations manager, finance |
| User requirement | The customer must be able to view the payment status of a submitted order | Customer experience owner, operations |
| System requirement | The payment gateway must be embedded within the checkout flow; payment must be accepted via Visa and Mastercard only | Developer, solution architect, tester |
| Rule | No refunds will be issued for processing fees once an order is submitted | Finance, legal, customer service |
| Policy | Payment cannot be made by cash, cheque, or direct debit | Operations, finance |
Keeping these separate in your document is not just an exercise in neatness. It determines how the document gets used. Business requirements drive scope decisions. System requirements drive build decisions. Rules drive test cases. If you mix them together, reviewers cannot tell what they are approving.
What Ecommerce BRDs Get Wrong Most Often
Based on my experience reviewing and writing these documents, the gaps that cause the most downstream pain are not the obvious functional ones. They tend to cluster around the edges of the transaction flow and the handoff between systems.
- Payment failure handling: Most BRDs describe the happy path in detail and say almost nothing about what happens when a payment fails. You need to specify the status the order takes, whether the customer can retry, what notification they receive, and how long the order remains available before it expires.
- Session timeout behaviour: If a customer closes the browser mid-payment, the system needs to know what to do. In the Project X work, the requirement was that the interface engine would query the payment gateway using the payment ID to check status on reconnect. This is not a technical detail to leave to the developer. It has direct customer experience and financial reconciliation implications.
- Traceability between systems: Every ecommerce build that involves a payment gateway and a back-office finance system needs a clear chain of IDs. The payment ID in the gateway must link to the order ID in the commerce system, which must link to the transaction reference in the finance system. Document this explicitly or you will spend weeks in UAT trying to reconcile records that do not match.
- GST and tax logic for international transactions: As the Project X example shows, this is almost always more complicated than it looks. Document the rule, the trigger for applying it, and the edge cases.
- Fee configuration and maintenance: In a real ecommerce environment, prices change. Your BRD should include a requirement for how fees are updated, who can do it, and whether it requires a software release or can be done through an admin interface. This has operational cost implications that the business owner will care about.
Structuring the Financial Processing Section
This section is often skipped entirely or given a single line. In practice, it is one of the most important parts of an ecommerce BRD because it defines how money moves from the customer through to the organisation’s books, and who is responsible for each step.
At minimum, the financial processing section should cover:
- Transaction recording: What data fields the payment gateway must capture and store, including merchant ID, general ledger code, transaction date, revenue amount, and tax amount separately.
- Reconciliation process: How often reconciliation occurs, who performs it, and what systems they use. In the Project X work, a weekly batch file was sent from the payment gateway to the finance team for journal processing. That frequency was a business decision with cost implications, not a technical default.
- Reporting requirements: What reports the finance team needs, at what cadence, and what they need to contain. End-of-month reporting requirements often only surface when you ask the finance stakeholder directly and specifically.
- Receipt generation: Whether the system generates a tax-compliant receipt automatically, what it must contain (ABN, GST amount, reference number), and whether only one receipt is issued per transaction.
How to Handle Scope That Keeps Expanding
Ecommerce projects attract scope creep because every stakeholder can picture using the site and therefore has ideas about what it should do. I have seen BRDs for online stores grow from a focused payment integration into a full loyalty programme, personalisation engine, and CRM integration in the space of six weeks. If you are working on a project where the scope keeps shifting, the article on managing scope creep as a BA covers practical governance approaches worth reading alongside this one.
In the BRD itself, the best defence is an explicit exclusions section. State what the project does not cover. Name the systems, the features, and the processes that are out of scope. This is not negative framing. It is the clearest way to protect the project from the next stakeholder who arrives with a new idea and says “I assumed that was included.”
Getting the Document Approved
An ecommerce BRD that never gets formally approved is essentially a wish list. Build the approval process into the document itself. Include a named approvals table at the front. Make it clear who needs to sign, not just who receives a copy. In the Project X work, the document went through four revision versions across three months before final sign-off, and each version was driven by a specific reviewer raising a specific objection. That process was frustrating at the time, but the friction was doing real work: it was surfacing decisions that would otherwise have been made under pressure during build.
The discipline of writing a complete ecommerce BRD, with business requirements separated from system requirements, with tax logic documented precisely, with payment failure scenarios covered, and with financial reconciliation mapped end to end, is not about producing a long document. It is about making decisions visible before they become expensive to reverse. Every section you skip is a conversation you will have at a worse time, under more pressure, with fewer options.
Frequently asked questions
What should be included in a business requirements document for an ecommerce website?
An ecommerce BRD should include a scope statement, business context, stakeholder consultation log, business requirements, user requirements, system requirements, rules and constraints, pricing and tax logic, and a financial processing section. Each layer serves a different audience, so keeping them separate in the document matters. Payment failure handling, session timeout behaviour, and traceability between systems are the sections most commonly left incomplete.
What is the difference between business requirements and system requirements in an ecommerce BRD?
Business requirements describe the outcomes the organisation needs to achieve, such as reducing manual invoicing or recovering processing costs. System requirements describe the capabilities the software must have to enable those outcomes, such as embedding the payment gateway within the checkout flow or storing a unique transaction ID in both the commerce system and the finance system. Mixing the two makes it harder for reviewers to know what they are actually approving.
How do I document payment gateway requirements in a BRD?
Specify which payment methods are accepted, how the gateway is integrated into the user interface, what happens when a payment fails, and what data fields the gateway must capture and store. You also need to document how the gateway ID links to identifiers in your commerce platform and finance system for reconciliation purposes. The session timeout scenario, where a user closes the browser mid-payment, is a specific edge case that must be covered explicitly.
Do I need to include tax rules in an ecommerce business requirements document?
Yes, and in more detail than most people expect. Tax applicability often depends on the location of the buyer, the type of product, or whether the transaction is domestic or international, and each of these triggers different system behaviour. In practice, tax logic is one of the most disputed sections of any ecommerce BRD because it sits at the intersection of finance compliance and system design. Document the rule, the trigger condition, and the edge cases explicitly.
How long should an ecommerce website BRD be?
Length should be driven by the complexity of the project, not by a target page count. A focused payment integration onto an existing platform might be covered in 15 to 20 pages, while a full ecommerce build with multiple user types, variable pricing, and finance system integration will typically run longer. What matters more than length is that each section is complete enough for a developer or tester to act on without needing to ask follow-up questions.
Try Ash, Your Virtual BA
If you have read through this article and you are now staring at a blank document wondering how to get your ecommerce BRD started, Ash can help you move from nothing to a structured first draft. Ash is trained on BA methodology and can guide you through the sections covered here, including business context, user requirements, system requirements, payment rules, and financial processing, asking you the right questions to pull out the detail your stakeholders will need to review. Try Ash Virtual BA and get your ecommerce BRD underway today.
Further reading
- Free Download of Business Requirement Document (BRD) Template
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.