Requirements Specifications: Tendering a Shop Project Properly

Shop projects rarely fail because of technology. They fail because nobody wrote down, before the contract was awarded, what the result was supposed to be. That is what a requirements specification is for: a description of what you need, in your words, before the first bid arrives. Written carefully, it produces comparable offers instead of rough guesses, and it surfaces gaps while they are still cheap. A 2002 study (NIST) shows why this matters so much: an error that surfaces only during integration costs ten times as much to fix as the same error caught in the requirements stage. This guide shows how a requirements specification for an online shop is structured, how to separate must-have from nice-to-have requirements, and how to tell whether a requirement is written in a testable way.

Requirements specification and functional specification: two documents, two authors

The two terms get mixed up in everyday use, although they represent two different roles. The requirements specification is written by the client. It describes the task: which problem is to be solved, under which conditions, with which data, for which users. It deliberately contains no solution. The functional specification is written by the contractor after winning the contract. It describes how the task will be solved: system architecture, data model, processes, responsibilities, schedule. The requirements specification asks, the functional specification answers. Pressing both into one document destroys comparability: once a technical solution is prescribed, bidders can only quote a price for that one solution instead of proposing their own approach.

German procurement law shows how much weight a good description of the task carries. For public clients the document is called a description of the work, and the statute states precisely what it is for: the subject of the contract must be described as unambiguously as possible, so that all companies understand the description in the same sense and the bids can be compared with one another (GWB). That sentence is also the best short summary of what a requirements specification has to achieve for private clients. If two bidders read your document differently, their bids are not comparable, and the price difference tells you nothing about the scope.

In practice this creates a clean chain: publish the requirements specification, compare bids, award the contract, have the functional specification written, approve it, build, accept. Each step produces a result the next one needs. Skipping the first step and asking for a quote straight away gets you a quote for a task the bidder pieced together on their own. Our consulting and concept work starts exactly here: the requirements specification is written together with the business department, not after a technology has already been picked.

What belongs in a requirements specification

A requirements specification is neither a novel nor a bullet list. It is a numbered document in which every requirement carries its own identifier, so that questions, bids and later the acceptance test can point at it. The statute describes the substantive core briefly: the description of the work contains the functional or performance requirements, or a description of the task to be solved, knowledge of which is necessary for preparing the bid, together with the circumstances and conditions of performance (GWB). Translated: task, requirements and constraints, nothing else.

1. Starting point: what exists today, which systems are running, which figures describe operations (orders per day, articles, customer groups, languages, countries).
2. Goal of the project: what should be different afterwards, measured against what. A goal without a metric is a wish.
3. Scope boundary: what is explicitly not part of the project. This section saves the most arguments later on.
4. Roles and users: who works with the system, with which permissions, to what extent.
5. Functional requirements: numbered, prioritised, individually testable.
6. Data and interfaces: which systems supply data, which receive it, in which direction, at which interval.
7. Data migration: which records come across from the legacy system and in what quality they exist today.
8. Non-functional requirements: speed, availability, accessibility, security, data protection, operations.
9. Constraints: deadlines, budget range, approval paths, contacts, the client's own duties to cooperate.
10. Acceptance: how testing works, who tests, what counts as fulfilled and what happens if a requirement is not met.

The scope depends on the project. A relaunch with unchanged processes fits into 15 to 25 pages, while a shop with ERP integration, customer groups and a marketplace connection tends to need twice that. More important than the page count is precision: every requirement appears once, in one place, with one identifier. If the same demand appears in three places in slightly different words, three readings emerge. How such a document fits into project planning is described in our article on planning a website relaunch.

Must, should and could: priorities that hold

Without prioritisation every requirements specification is a wish list, and every wish list turns into a top-end price in the bid. Three levels are enough, and they have to be defined sharply before the first requirement is sorted. What matters is not the number of levels but that each level has a consequence: a must requirement decides acceptance, a could requirement does not.

The most common mistake is inflation of the top level. When 90 per cent of all requirements are marked as must, the marking says nothing any more, and the bidder adds a risk premium to everything. A workable rule of thumb from project practice: at most half of the requirements carry the must level, and each of them can be justified in one sentence. If you cannot write that justification, you are looking at a should requirement.

• Justify every must requirement with the damage that occurs without it: lost revenue, legal exposure, manual work in daily operations.
• Price could requirements separately. A bid with an option list can be compared, a lump sum with a wish list cannot.
• Record who may change a level. Without that rule every should requirement drifts upwards as the project runs.
• Check the distribution before you send the document out: how many must, should and could requirements does it actually contain?
• Mark requirements that depend on another one. A must requirement built on top of a could requirement is a contradiction.

Writing requirements so they can be tested

A requirement is testable when two people arrive independently at the same result when they test it. That sounds trivial, but half the sentences in a typical requirements specification fail it. Words such as user-friendly, performant, modern or intuitive are not requirements but moods. They cannot be accepted, and they cannot be priced either: the bidder either calculates too tightly and argues later, or calculates the worst case and is too expensive.

• An actor: who triggers the function, a customer, an employee, a system?
• A trigger: what happens beforehand for the function to apply?
• A result: what exists afterwards, and where can it be seen?
• A metric: quantity, duration, format, count, threshold.
• A boundary condition: what applies when the normal case does not occur?
• A source: which rule, which process, which role demands this?

The right-hand column is longer, and that is the point. Every extra line in the requirements specification saves clarification work during the build. The connection is well documented: an error created in the requirements stage and found there costs one unit; if the same error is discovered only during integration, the fix costs ten times as much (NIST). At national level, the same 2002 study puts the annual cost of an inadequate infrastructure for software testing in the United States at 22.2 to 59.5 billion dollars (NIST).

id: A-014
title: Order import into the ERP
level: must
actor: shop system
trigger: payment confirmed
result: order exists in the ERP with line items, prices and delivery address
metric:
  deadline_minutes: 15
  basis: timestamp of the payment confirmation
boundary:
  - ERP unreachable: retry after 1, 5 and 15 minutes
  - after three failed attempts: log entry and email to operations
acceptance:
  - 20 test orders, 3 of them with a differing delivery address
  - evidence via log extract with order and ERP document number
source: order processing, section 3.2

Whether you use structured files, a spreadsheet or numbered paragraphs is secondary. What matters is that every requirement has the same fields, so that nothing is quietly missing when the bids are compared. Requirements written this way can be translated directly into test cases later; what that looks like in automated form is shown in our article on end-to-end test automation for online shops.

Settling interfaces and data migration up front

The biggest cost block in shop projects is rarely the shop itself. It sits at the edges: in the ERP system, in accounting, in shipping, in product data management. Handling interfaces with a single sentence in the requirements specification moves the most expensive unknown into the build phase. Every interface needs its own description with direction, interval, data scope, key field and error behaviour. That applies to the DATEV connection just as much as to stock synchronisation with a marketplace.

• Direction and ownership: which system owns which field? The price comes from the ERP, the description from the product data system, the stock level from the warehouse. Conflicts are decided up front, not in production.
• Interval and volume: every five minutes, hourly, daily? How many records per run, how large is the initial synchronisation?
• Key field: how do both systems recognise the same record? Without a stable key, duplicates appear and the synchronisation cannot be repeated.
• Error behaviour: what happens on timeout, on invalid data, on a duplicate handover? Who gets notified and how often?
• Access and environments: is there a test system, who provides access, from when? A test system that only appears after project start moves every deadline.
• Data quality today: how many articles have a maintained EAN, how many customers a valid billing address? Those numbers belong in the requirements specification, not in the first project week. Our article on ERP integration between Shopware and SAP shows what such connections typically hinge on.

The same view pays off for data migration. State quantities instead of adjectives: number of articles, variants, images, customers, orders, reviews, redirects. Define which history comes across and which stays in the legacy system. And write down what happens to records that fail validation: are they rejected, corrected or written to a rework list? For projects with customer groups and price lists, our page on B2B e-commerce records the typical special cases.

Non-functional requirements: speed, accessibility, operations

Non-functional requirements describe how well something works, not what it does. They are the ones most often left out of a requirements specification, and they cause the most unpleasant renegotiations later. For speed, a look at the field helps: in 2025, 48 per cent of mobile websites and 56 per cent of desktop sites reached good Core Web Vitals scores (HTTP Archive Web Almanac). For server response time, the share with good values on mobile stands at 44 per cent (HTTP Archive Web Almanac). Naming target values in the requirements specification moves that discussion ahead of the award, where it belongs.

• Speed: target values per page type, measured with a defined device profile and a defined number of repetitions. Our page on PageSpeed optimisation names the usual measuring points.
• Availability: monthly target, maintenance windows, response times by severity of the incident.
• Accessibility: conformance level, tested against a named list of page types, with evidence.
• Security: role and permission concept, handling of credentials, logging, retention periods.
• Data protection: records of processing activities, data processing agreement, deletion concept, consent.
• Operations: who updates, who backs up, how long are backups kept, how is a restore rehearsed?

Since the German Accessibility Strengthening Act came into force, accessibility is no longer optional. The act applies to services in electronic commerce provided to consumers after 28 June 2025 (BFSG), and it states the duty briefly: products that an economic operator makes available on the market and services that it offers or provides have to be accessible (BFSG). Procurement law has carried the same idea for a long time: for services intended for use by natural persons, accessibility criteria for people with disabilities have to be taken into account when drawing up the description of the work, except in duly justified cases (GWB). Our page on accessibility optimisation sorts the requirements, and the article on accessible invoices and data sheets shows that the duty does not stop at the edge of the page.

How wide the gap between ambition and reality is shows in the annual review of the one million most visited home pages: 95.9 per cent of them had detected WCAG 2 failures (WebAIM Million 2026). On average, 56.1 detected errors fell on each home page (WebAIM Million 2026). Those are automatically detectable findings, so they are the lower bound; everything that only surfaces in testing with people comes on top. For the requirements specification this means one line about accessibility is not enough. It needs the conformance level, the list of page types to be tested and the question of who supplies the evidence.

What makes bids comparable

Comparability is created in the tender, not in the bid. If you give all bidders the same structure, you can lay the results side by side line by line. Procurement law puts the yardstick plainly: the contract is awarded to the most economically advantageous bid, and that is determined by the best price-performance ratio (GWB). For that ratio to be calculable at all, the performance side has to be described as clearly as the price side.

1. Prescribe the bid structure: one price sheet with the same line items for everyone. Free-form bids cannot be added up.
2. Separate options: could requirements as separate items with their own price, so that the main price stays comparable.
3. Name the cost drivers: data volumes, languages, customer groups, marketplaces. Withholding those numbers gets you estimates with a premium.
4. Record cooperation duties: which work do you contribute yourself, with which staff and by when? That is part of the price.
5. State award criteria beforehand: the award criteria and their weighting have to be listed in the contract notice or the tender documents (GWB). The rule is worth following privately as well.
6. Bundle questions: all questions and answers go to all bidders. One bidder with an information advantage makes the bids incomparable.

The weights are an example, not a law. What matters is that you fix them before sending the documents out and state them in the tender papers. Deciding the weighting only after the bids arrive means picking the bidder first and justifying the choice afterwards. For delivery with Shopware, our page on the Shopware agency records the approach, including the questions that should be settled before the award.

From requirements specification to contract

A requirements specification only takes effect once it becomes part of the contract. Software projects with a defined result are as a rule contracts for work: under a contract for work the contractor is obliged to produce the promised work and the client to pay the agreed remuneration (BGB). The promised work is exactly what stands in the requirements specification and in the functional specification built on it. If a requirement is missing there, it is not owed, however obvious it seemed in conversation.

• Schedule of annexes: requirements specification, functional specification and bid as numbered annexes with version status and date.
• Order of precedence: what applies when annexes contradict each other? Without precedence, two documents argue against one another.
• Change procedure: who requests a change, who assesses the effort, who approves, within which deadline?
• Acceptance: partial acceptance per milestone, review period, handling of open points, start of the warranty period.
• Cooperation: which contribution is a precondition for which date, and what happens if the client is late?
• Handover to operations: who runs the system after go-live, with which access, which backups and which response times? Our services for hosting and maintenance describe the usual split.

One point often comes as a surprise: the effort of preparing a detailed bid is not automatically free. The statute only says that a cost estimate is in case of doubt not to be remunerated (BGB). If you expect several bidders to carry out a deep pre-analysis, for example of your legacy data, a paid preliminary assignment is the more honest route. It costs a small amount and delivers numbers instead of assumptions. What a technically grounded run-up looks like is shown in our section on programming and development.

Typical mistakes when putting a project out to tender

Most failed tenders do not fail for lack of expertise but on six recurring patterns. All of them can be fixed before sending the document out. Cart abandonment is one example of what unresolved requirements lead to: across more than 50 collected studies the average cart abandonment rate is 70.22 per cent (Baymard Institute). Part of that goes back to flows that were described nowhere in the requirements specification, such as missing payment methods, unclear shipping costs or a guest checkout that nobody thought about.

1. Solution instead of task: the document names technology before the task is settled. Bids then describe the same technology at different prices, and nobody is allowed to propose the better idea.
2. Adjectives instead of metrics: fast, modern, intuitive. Each of these words turns into a risk premium in the bid.
3. Missing scope boundary: without a chapter on what is out of scope, everything unclear ends up in the client's expectation rather than in the bid.
4. Interfaces as a footnote: one sentence about the ERP, three pages about the home page. The effort is usually distributed the other way round.
5. No quantities: without article, customer and order figures every bidder calculates a different order of magnitude.
6. Acceptance considered last: if the test criteria are written after go-live, you negotiate them against a finished build instead of against a document.

The same exercise helps against all six patterns: give the finished requirements specification to a person who does not know the project and ask them to write three requirements up as test cases. Whatever they cannot turn into a test case is not yet a requirement. If a migration follows, our guide to Shopware 6 migration is worth a look, because many requirements there already exist in testable form.