[The introduction of the Product Acceptance Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Product Acceptance Plan.]

1.1 Purpose

[Specify the purpose of this Product Acceptance Plan.]

1.2 Scope

[A brief description of the scope of this Product Acceptance Plan; what Project(s) it is associated with and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Product Acceptance Plan. This information may be provided by reference to the project's Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Product Acceptance Plan. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

1.5 Overview

[This subsection describes what the rest of the Product Acceptance Plan contains and explains how the document is organized.]

2. Responsibilities

[Explicitly identify the responsibilities of both the customer and the development team in preparing and performing the product acceptance activities.]

3. Product Acceptance Tasks

3.1 Product Acceptance Criteria

[Identify the objective criteria for determining acceptability of the deliverable artifacts from this project. These criteria should be formally agreed by the customer and the development team.]

3.2 Physical Configuration Audit

[Identify and list here the artifacts that are to be delivered to and accepted by the customer resulting from the work on this project.]

3.3 Functional Configuration Audit

[For each artifact identified in the Physical Configuration Audit, identify the evaluation methods and the level of detail that will be used to determine if it meets the product acceptance criteria.

Methods can include software execution testing, product demonstration, documentation reviews, and so on.]

3.4 Schedule

[A schedule indicating the start and end times for each of the product acceptance tasks, including preparation and setup activities.]

4. Resource Requirements

4.1 Hardware Requirements

[For example, hardware items, interfacing equipment, firmware items.]

4.2 Software Requirements

[For example, operating systems, compilers, test drivers, test data generators.]

4.3 Documentation Requirements

[For example, test documentation, technical references.]

4.4 Personnel Requirements

[For example, development team members, customer representatives, third-party party authorities.]

4.5 Test Data Requirements

[For example, size, type, and composition of data to support acceptance tests.]

4.6 Other Requirements

[For example, special equipment.]

5. Problem Resolution and Corrective Action

[This section describes the procedures for reporting and handling problems identified during the Product Acceptance activities. Usually this is addressed by enclosing the Problem Resolution Plan artifact by reference.]

6. Product Acceptance Environment

[Describe the plans for setting up the product acceptance environment.]

7. Identification of Required Artifact Evaluations

[Based on the Functional Configuration Audit description, identify each individual artifact evaluation that will be carried out. For each one, list the type of evaluation (test, review, and so on), and its objectives.

Note: A Test Case artifact will be prepared for each test identified here.]

8. Tools, Techniques, and Methodologies

[A list of any specific tools, techniques, and methodologies that are to be used when performing the Product Acceptance activities.]