Requirements specification for an online shop: structure, examples and typical mistakes

The project specification is the agency's response to your requirements specification. It doesn't describe what you want, but rather how it will be built – and it's the document against which the project's success will later be measured. This page shows the structure that has proven effective in e-commerce projects, with sample wording from real-world examples.

The quickest way to create misunderstandings: using both terms synonymously. The client writes the requirements specification, the contractor the functional specification. Mixing them up will lead to arguments about obvious things later on.

This is how a specification document for an online shop is created – from the project overview to the acceptance criteria.

Requirements specification or functional specification – the difference in one sentence

The requirements specification states: "Customers should be able to order on account ." The functional specification specifies which payment service provider will be used, how the credit check will be carried out, the minimum order value at which it applies, what happens if it fails, and how this will be configured in the shop system.

In other words: The requirements specification is the order, the functional specification is the binding construction manual. Both belong together – but they are created sequentially and from different sources.

The nine chapters that a shop's specifications document needs

1. Project overview and initial situation

What is the goal, who are the stakeholders, what already exists? This section should also include what is not part of the project – the most important paragraph in the entire document. "The migration of existing customer data from the legacy system is not included in this offer" will save weeks of discussions later.

2. Technical basics

Shop system and version, hosting requirements, PHP and database versions, theme or custom development, interfaces to existing systems. Specifically, rather than generally: not "modern technology," but "Shopware 6.6, PHP 8.3, MariaDB 10.11, custom theme based on the standard theme."

3. Functional requirements

The most extensive part. Each function is described in terms of how it behaves in operation – not just that it exists. Example of a useful formulation:

"Tiered pricing: Customer groups receive different prices starting from defined quantities. The tier is maintained for each item, applies net, and is displayed in the shopping cart and on the product page. If customer group and quantity discounts overlap, the more favorable price for the customer applies."

This one bracket at the end – which applies in case of overlap – is the difference between a specification and a wish list.

4. Ordering process and checkout

This deserves its own chapter because this is where the money is made: guest ordering yes or no, mandatory fields, shipping methods and their rules, payment methods including availability per customer group, minimum order value, voucher logic.

5. Design and operation

This only becomes binding with reference to a result: layout designs for defined page types, mobile device behavior, accessibility requirements, and approval processes. "Modern and appealing" is not a verifiable requirement.

6. Interfaces

Regarding inventory management, accounting, shipping providers, and newsletters : For each interface: direction, data volume, frequency, and error handling. The last point is almost always forgotten and is almost always the most expensive.

7. Law and Data Protection

Mandatory information, cancellation policy, cookie consent, data processing agreement, data deletion policy. It must be explicitly clarified who provides the legal texts – the client's agency or their lawyer.

8. Testing and acceptance

What are the measurement criteria? Defined test cases, measurable loading times , browser and device matrix, duration of the acceptance phase, and handling of defects. Without acceptance criteria, there is no end to the project, only a stalling process.

9. Dates, participation and price

Milestones with deadlines – and the client's obligations to cooperate. Product data, images, texts, and approvals are the most frequent cause of delays. What the client needs to deliver and when should be included in the document, as well as what the agency will deliver.

Example: a paragraph, formulated three times

The same situation is shown in three versions to demonstrate how to recognize a good specification:

• Unusable: "The shop should be fast."
• Better: "The charging time should be optimized."
• Verifiable: "The Largest Contentful Paint of the article page is less than 2,5 seconds when measured on a mobile device using a 4G connection, as measured with..." Pagespeed Insights from three defined example articles.”

Only the third version can be removed – or not.

Five mistakes that make shop projects expensive

1. No chapter “not included”. Everything that is not ruled out will be expected later.
2. Data migration is underestimated. Old product data is rarely accurate. Anyone who doesn't check the scope and quality beforehand will miscalculate.
3. Error scenarios not described. What happens if the inventory management system doesn't respond? Without an answer in the document, it will be decided by chance later.
4. Approvals without a deadline. “The customer approves the designs” without a timeframe, rescheduling every appointment.
5. Too much detail too soon. A specification that prescribes every button prevents the better solution that only becomes apparent during construction.

Do you even need one?

Storetown-Media internal What is a requirements specification? Example: Online shop creation

For a standard, off-the-shelf shop with a standard theme and three payment methods, a good offer is sufficient. However, as soon as interfaces, customer groups, individual prices, or a migration are involved, the requirements specification is the most cost-effective insurance policy in the entire project – it costs a few days and prevents weeks of delays.

For larger projects, we write the requirements specification as our first service, before a single line of code is written. It's a standard component for shop projects costing €12.000 or more. You can calculate the total cost of a shop using our online shop cost calculator.

Frequently asked questions

Who writes the specifications – the client or the agency?

The agency. The client provides the specifications document outlining their requirements; the agency describes the implementation within this document. In practice, it is developed through discussions, but the contractor is responsible for it.

How long should a specification document for an online shop be?

As long as necessary. A standard online shop gets by with ten pages, while a B2B shop with ERP integration and customer groups quickly reaches fifty. Length isn't a measure of quality – verifiability of the information is.

How much does it cost to create?

If commissioned separately, we calculate the cost based on the time and effort required; for projects we handle, it's part of the concept phase. The comparison is crucial: a few days of concept development versus change orders that regularly reach five figures during an ongoing project.

Is there a template available for download?

The nine chapters above serve as a template – they can be directly adopted as an outline. We advise against using generic templates: they encourage filling chapters instead of clarifying requirements.