Short answer
Specify what the site must do, the constraints and the tests used to accept it. Give each requirement an identifier, a priority and measurable pass criteria.
The answer in detail
An e-commerce website specification describes what the site must do, the constraints it must meet and the tests you will use to accept the work. Leave implementation choices open where possible. Give each requirement an identifier, a priority and a measurable acceptance criterion.
The benchmark
An agency brief helps select a supplier. A delivery specification turns the selected scope into something both sides can check. Agree how it fits into the contract; a document's title alone does not determine its legal effect.
| Section | What the merchant specifies | What the delivery partner proposes |
|---|---|---|
| 1. Context and objectives | Revenue context, mobile share and measurable goals | How its proposal addresses them |
| 2. What must not regress | Valuable pages, journeys and operations identified in the audit | How to preserve them |
| 3. Scope and exclusions | Markets, languages, currencies, channels, B2B needs and excluded work | Feasible delivery boundaries |
| 4. Journeys and functionality | Identified, prioritized requirements | Implementation approach |
| 5. Catalog and content | Product/variant volume, attributes and editing responsibilities | Data model and editing tools |
| 6. Integrations and operations | ERP, PIM, fulfillment, email, reviews, payments and accounting flows | Suitable connectors and architecture |
| 7. Design | Brand requirements and constraints | Designs that satisfy them |
| 8. Market-specific obligations | Applicable accessibility, privacy and consumer/product requirements | How agreed requirements will be implemented |
| 9. Performance and measurement | Targets, tracked events and reconciliation criteria | Tools and implementation |
| 10. Migration | Redirects, order history and customer accounts to preserve | Migration method |
| 11. Acceptance | Test cases, pass criteria and named approvers | Detailed test execution plan |
For web experience, Google's Core Web Vitals guidance defines good thresholds of LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Assess the 75th percentile separately for mobile and desktop. Agree how those field targets and pre-launch checks will be evaluated; three fast demonstrations are not a field measurement.
A rebuild described by the Club's contributors discovered important fulfillment, PIM and operational integrations during development because they were absent from the specification. At a budget review, the team had “180 hours left for development we had originally estimated at 250 hours.” It then distinguished tolerable launch compromises from order-blocking failures. Hard-coded product content could temporarily be accepted; orders that could not reach fulfillment could not.
The rule
Describe the outcome and let the partner propose the method. “Search handles common misspellings and suggests products after the third character” is a requirement. “Install app X” names a solution and may exclude a better one.
Assign each requirement an identifier, a priority and an acceptance criterion before development. When budget becomes tight, discuss identified lines. At delivery, test the agreed outcomes instead of debating what a broad wish meant.
| ID | Journey | Requirement | Priority | Acceptance example | Approver |
|---|---|---|---|---|---|
| CART-07 | Cart | A signed-in customer's cart is available across devices | Must have | Add on mobile, sign in on desktop the next day, verify the agreed persistence behavior | Customer service |
| LANG-03 | Markets | The German-market storefront is complete | Must have | Review templates, translated content and migrated data with no missing strings | Market owner |
| INT-02 | Fulfillment | Paid orders reach the fulfillment system | Must have | All 20 agreed test orders appear correctly in the fulfillment tool | Operations |
These are examples, not ready-made requirements for every store. Specify any limits, timing and exceptions that matter to your own architecture.
Write exclusions as clearly as inclusions. A craft brand described in the source explicitly deferred its heaviest automation and loyalty work unless budget remained. If those requests return during acceptance, the team can refer to an agreed decision rather than reconstruct a conversation.
The steps
- Start with the audit. Use the pre-rebuild audit to identify what already generates sales and which operational flows must survive. A wish list alone will miss those constraints.
- Write requirements by journey. Follow a shopper from arrival through navigation, search, product selection, cart, payment, account, emails and delivery. Record what must be possible at each step.
- Define obligations by destination and activity. List the privacy/consent behavior, accessibility and product information applicable to the intended markets. Assess environmental product information, consumer pricing and review requirements only for the markets and products actually in scope. Use the EU-focused review/pricing guide only where that regional scope fits.
- Specify analytics and operations together. List tracked events and acceptable Shopify/GA4 reconciliation differences. Add accounting exports, invoices, credit notes and integration frequency. The accounting-after-migration article supplies operational questions to adapt to your accounting setup.
- Write acceptance tests. Cover required product/collection performance, redirects for valuable old URLs, test orders by supported payment method and destination, and order reconciliation over the agreed period. Define the test data, environment and approver.
- Cross-review. Have customer service, fulfillment and finance review the requirements against incidents they actually handle. They will find omissions the project team misses.
The pitfall
Thirty pages of wishes without priorities or pass criteria encourage either a high contingency price or a low initial quote followed by change requests.
Ambiguity also makes it difficult to distinguish a defect from a scope addition. A footwear brand quoted by the contributors described its concern: a newly requested cart shortcut could reasonably be extra, but existing behavior that did not work was a different issue. Written acceptance criteria help establish that distinction. Agree the correction and change-control terms in the contract rather than assume every disputed item automatically falls inside the original price.
The opposite mistake is specifying every screen to the pixel and leaving no room for the partner's expertise. Ask whether you can verify a requirement at delivery without prescribing how it must be implemented. That usually identifies the useful boundary.
What to tell your team
“Our specification has 64 requirements, including 22 must-haves, each with an acceptance test. The three functions linked to 38% of revenue are protected against regression. Any request added after signature will be reviewed against this scope and change process.”
The counts and revenue share are fictional source examples. Replace them with your actual inventory and evidence before briefing suppliers.
