Ecommerce Requirement Specifications (ERS)

An Ecommerce Requirement Specification is a written, testable list of what the online store must actually do - catalogue, checkout, payments, fulfilment, tax - agreed before anyone writes code, so scope gets fixed on paper instead of discovered mid-build.

A spoken brief moves along a chain of stages until it lands as a document everyone has signed.

Turning a verbal brief into a signed, testable requirements document.

Reach for this when…

You're briefing a developer or agency and the brief is still a conversation, not a document.
The build keeps growing features nobody asked for while missing the one the warehouse actually needs.
Marketing and fulfilment disagree about how checkout is supposed to work.

How to run it

List every business process the store must support: catalogue, cart, checkout, payment, fulfilment, returns, tax.
Write each as a testable requirement, not a wish - a number or a yes/no, not 'should be flexible'.
Separate must-haves from nice-to-haves.
Get sign-off from whoever owns fulfilment and finance, not only marketing.
Hand the signed document to developers as the single source of truth.
Freeze scope once build starts; log any change formally instead of just asking for it.

A worked example

Situation. Aisha Rahman runs Kain Rumah, a batik homeware retailer in Penang, Malaysia, moving from a market stall to an online shop.

Applied. She'd briefed a freelance developer verbally, and three months in the site had a wishlist feature nobody needed but no way to handle her hand-blocked made-to-order items. She rewrote the brief as an ERS, forcing herself to specify make-to-order lead times and regional shipping rules as testable requirements before any code was touched.

Result. The second build matched how she actually fulfilled orders. The scope-freeze step, once written down, stopped her adding 'just one more thing' every week.

Wełna's second build worked once scope was frozen and logged, not re-argued weekly.

The catch

An ERS written by the business alone misses technical constraints, and one written by developers alone misses how the business actually operates - it needs both in the room. It also ages fast: sign it and guard it with a change log, or it's fiction within a month of the first client request.

If the person who owns fulfilment never signs it, the spec describes the website you imagine, not the business you run.

Origin: Rooted in IEEE 830 software requirements practice

connecteddale