====== Acceptance report ======
Acceptance report [[https://d1n2cq0xpqnd68.cloudfront.net/5e5300b4a20578943669fe94d45672ecdd7bad8d/abnahmeprotokoll.dotx|Word-Vorlage]]

Project name

|Classification| Select an element.|
|Status| Select an element.|
|Programme name| |
|Project number| |
|Project manager|Project manager|
|Version|0.1|
|Date| Click here to enter a date.|
|Client|Client|
|Author/authors| |
|Distributor| |

List of changes

^Version^Date^Change^Author|
|0.1| | | |

Table 1: Change control

Description

The acceptance report documents the fulfilment of the agreement on the product/system properties and existing defects. It is a legally binding document.

====== Subject of acceptance ======

^Subject of acceptance^Description|
|Software product xy|Application used in the xyz area|

Table 2: Acceptance object

====== Acceptance participants ======

^Role^Name|
|Client / Customer|Rolf Bühler|
|Project manager|Roland Frey|
|Supplier|Patrick Hoose|

Table 3: Acceptance participation

====== Basics ======

^Designation^Version no. / designation / date|
|Offer|30.12.2018|

Table 4: Basics

====== Acceptance procedure ======

Text.......

====== Acceptance criteria with defect classes ======

The defects found or the unfulfilled requirements (expectations) are categorised in classes from 1 to 4. Class 0 is only used if a flawless result is to be reported separately:

^No.^Defect classes^Description|
|0|flawless|Flawless and fulfils requirements|
|1|insignificant defect|Usage possible, usability is present, defects should nevertheless not occur|
|2|minor defect|Usage possible, usability is only slightly impaired|
|3|serious defect|Use is still possible, usability is severely impaired|
|4|critical defect|Unusable; \\ Essential functionality is not given; \\ Operation is not responsible (e.g. safety-related)|

Table 5: Defect classes

The classification reflects the severity of the consequences and the effort required to rectify any defects that can be identified. The assignment of the identified defects to a defect class also roughly prioritises the order in which the defects are to be rectified.

If a defect class between 1-3 is achieved, the system/product can be accepted with reservations. However, measures must be defined to rectify the defects. A follow-up inspection is mandatory.

If, on the other hand, class 4 defects are identified, the system/product cannot be accepted and the contractor must take immediate measures to rectify these defects. The contractor must also arrange for a new acceptance test.

====== Delivery results and defects ======

^Ref. no.^Delivery result - description - requirement^Defect description^Defect class^Measure^Responsible^Deadline|
|01|Customer management\\ Entry of new customers|Address is not saved correctly\\ saved correctly|3|Defect correction|Müller|15.06.2020|

Table 6: Delivery results and defects

====== Acceptance event ======

☐The acceptance object was inspected without notification of defects. Acceptance is without reservation.

The acceptance object was inspected and accepted with reservations. The defects must be rectified within the specified period and the solution must be inspected again for acceptance.

The acceptance object has been inspected. \\ Acceptance is refused.

====== Signature ======

|Name| | Function| | Place & date| | Signature|

Abbreviations and glossary

^Abbreviation / technical term^Explanation|
|HERMES|Procedure methodology for projects and programmes\\ HERMES 5 is an eCH standard|

Table 7: Abbreviations and glossary