What does acceptance mean in a software project?

Acceptance: definition and significance

With acceptance, the client confirms that the work has essentially been delivered in conformity with the contract and accepts it as performance. For software projects that are classified as a contract for work (Werkvertrag), this is a key step under German law (Section 640 of the German Civil Code, BGB): payment generally falls due with it, important time limits for defect claims begin to run, and the burden of proof for defects shifts.

What is accepted is not perfection but conformity with the contract. Minor defects do not entitle the client to refuse acceptance; they are recorded in a defect list and rectified. Whether and how acceptance takes place should be stated in the contract, including for partial acceptance of individual modules. That protects both sides, because the yardstick is set in advance.

How an acceptance works

The basis is acceptance criteria, ideally already set out in the functional specification or the quote: which functions must work how, what speed is expected, which browsers and devices are supported? The contractor reports completion, the client tests in a test environment using test cases, and findings are classified by severity.

At the end comes the acceptance report with date, participants, result and open items including deadlines. If the client does not respond despite a request and a deadline, acceptance can under certain circumstances be deemed to have occurred (Section 640(2) BGB); you should not rely on that.

• Set acceptance criteria in writing in advance
• Provide test cases and a test environment
• Involve the business users in testing
• Classify defects by severity and record them with deadlines
• Have both sides sign the acceptance report
• Regulate the handover of access, documentation and source code

Real-world example: a wholesaler’s ordering portal

A wholesaler has an ordering portal developed. At the end of the project, two employees from sales and accounting check the functions against a list of test cases in the staging environment. They find an incorrectly calculated discount and a layout that is hard to read on a smartphone. Both findings are documented with screenshots and the steps to reproduce them.

The discount error is material and is fixed before acceptance; the display issue goes into the report as a minor defect with a deadline. Then the portal is accepted, goes live, and the time limits for defect claims begin. Without criteria set beforehand, by contrast, people often argue over whether an item is an error or a wish.

Common mistakes and imple­menta­tion

Acceptance is often delayed because nobody has time to test, or replaced by use: whoever puts the software into productive use may thereby accept it tacitly, without it having been consciously decided. Equally risky is acceptance without reservation although defects are known. Such reservations belong in the report.

Nano Concepts plans acceptance from the start with criteria, test cases and a report and cleanly separates bug fixing from new requests. A joint acceptance session with everyone involved saves follow-up questions and creates commitment. Legal questions should be reviewed in each individual case. This article does not replace legal advice.