Acceptance report

Project name

Classification	Select an element
Status	Select an element
Program name
Project number
Project manager	Project manager
Version	0.1
Date	Click here to enter a date
Project sponsor	Project sponsor
Author(s)
Distribution

List of changes

Version	Date	Change	Author
0.1

Table 1:	Change control

Description

The acceptance report documents compliance with the agreement with regard to product/system features and existing defects. It is a legally binding document.

Item being accepted

Item being accepted	Description
Software product xy	Application used in the xyz area

Table 2:	Item being accepted

Those involved in acceptance

Role	Name
Project sponsor/customer	Rolf Bühler
Project manager	Roland Frey
Supplier	Patrick Hoose

Table 3:	Those involved in acceptance

Basis

Designation	Version no./designation/date
Offer	30.12.2018

Table 4:	Basis

Acceptance procedure

Text…….

Acceptance criteria with defect categories

The defects found, or the requirements not fulfilled (expectations), are classified from 1 to 4. Category 0 is used only if a faultless outcome is to be shown separately:

No.	Defect category	Description
0	Flawless	Flawless and in line with requirements
1	Insignificant defect	Use possible, proven usability, no defects should occur
2	Minor defect	Use possible, usability is only slightly impaired
3	Major defect	Use still possible, usability is greatly reduced
4	Critical defect	Unusable Key functionality missing Operation is not acceptable (e.g. security reasons)

Table 5:	Defect categories

The classification reflects the severity of the consequences and the time and effort required to remedy the defects that can be identified. The allocation of the defects found to a defect category also roughly determines the order of priority for remedying the defects.

In the case of defect category 1 to 3, the system/product can be accepted with reservations. However, measures to remedy the defects must be defined. A supplementary review is mandatory.

If, instead, category 4 defects are found, the system/product cannot be accepted and the provider must take immediate measures to remedy these defects. The provider must also arrange for another acceptance procedure.

Delivery outcomes and defects

Ref. no.	Delivery outcome – description – requirement	Defect description	Defect category	Measure	Person responsible	Deadline
01	Customer administration New customer entry	Address is not stored correctly	3	Correction of defect	Müller	15.06.2020

Table 6:	Delivery outcomes and defects

Acceptance outcome

☐	The item to be accepted was inspected without defects being found. Acceptance is without reservation.

☐	The item to be accepted was inspected and accepted with reservations. The defects are to be remedied within the specified timeframe and the solution is to go through the acceptance procedure again with a supplementary review.

☐	The item to be accepted was inspected.
Acceptance is refused.

Signature

Name	Function	Place & date	Signature

Abbreviations and glossary

Abbreviation/specialist term	Explanation
HERMES	Methodology for projects and programs HERMES 5 is an eCH standard

Table 7:	Abbreviations and glossary

Contents

List of changes	1

Description	1

1	Item being accepted	2

2	Those involved in acceptance	2

3	Basis	2

4	Acceptance procedure	2

5	Acceptance criteria with defect categories	3

6	Delivery outcomes and defects	4

7	Acceptance outcome	5

8	Signature	5

Abbreviations and glossary	6

Contents	7

Tables	7

Tables

Table 1:	Change control	1

Table 2:	Item being accepted	2

Table 3:	Those involved in acceptance	2

Table 4:	Basis	2

Table 5:	Defect categories	3

Table 6:	Delivery outcomes and defects	4

Table 7:	Abbreviations and glossary	6