Example Templates:
   Evaluation Plan
   Project Diary
   Risk Management Plan

    
  

Templates

Change Request Form
Use this form to request a change to a baselined product. The completed form should be sent to the Project Manager. Documented requests for change should cover all documents that have been placed under formal controls.

This Change Request Form is based on a form published in AS 3563.2 Software Quality Management Standard now superseded by ISO 9000.3.

Design Statement
A detailed Design Statement is the blueprint for the development of the product and should describe the project in detail . The design statement is developed from the client brief, or the request for proposal document following a needs assessment. The costing, time line and prototype should all be able to be developed from this document.

Multimedia Project Plan
The Project Plan is a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, to facilitate communication among stakeholders, and to document approved scope, cost, and schedule baselines. A project plan may be summary or detailed. The primary requirement in the project plan is a structured approach to planning, with consistently applied principles. The emphasis should be on a logical and well thought out overall approach.

This Multimedia Project Plan is adapted from MILSTD-498 Distribution Statement A; Approved for public release; distribution is unlimited.

Risk Factor Memorandum
Unresolved risk factors influencing the multimedia project may be recorded in this memorandum. It identifies the Project, the risk factor and its potential impact, and what minimisation strategies have been put in place. Contingency plans in the event that the risk is realised are documented.

Test Case Specification
The purpose of the Test Case Specification is to define a test case identified by a test design specification. There will normally be several test cases (and specifications) associated with each test design. A test case specification can be expressed very briefly, and it may be possible - for some designs - to document several test cases on a single page.

This Test Case Specification conforms to ANSI/IEEE Standard 829-1983, IEEE Standards for software test documentation.

Test Design Specification
The purpose of the Test Design Specification is to specify the requirements of the test approach and to identify the features to be tested by this design and its associated tests. It is possible for there to be several different test designs involved in testing a single multimedia product. Each test design will normally be associated with the testing of one feature of the system.

This Test Design Specification conforms to ANSI/IEEE Standard 829-1983, IEEE Standards for software test documentation.

Test Plan
The purpose of the Test Plan is to document the approach to be used for testing the multimedia product at the different stages of its development. It is normal for there to be a hierarchy of test documents covering the different stages of testing; thus, there might be an Integration Test Plan (with associated documentation); a System Test Plan (with associated documentation); and a Customer Acceptance Test Plan (again with associated documentation). The basic principles and contents of each set of documents is the same.

This Test Plan conforms to ANSI/IEEE Standard 829-1983, IEEE Standards for software test documentation.

Test Procedure Specification
The purpose of the Test Procedure Specification is to specify the steps for executing a set of test cases or, more generally, the steps used to analyse a software item in order to evaluate a set of features. A test procedure specification may include descriptions of how to establish specific environmental requirements for a set of test cases - e.g. loading a specific test database.

This Test Procedure Specification conforms to ANSI/IEEE Standard 829-1983, IEEE Standards for software test documentation.

Traceability Matrix
The Traceability Matrix enables the requirements to be traced to their final implementation, identifying at each stage the product components, modules and units and their contribution to each of the requirements. The Traceability Matrix provides a powerful validation tool; requirements with no annotations have most probably not been met, while modules with no confirmed requirements are of doubtful purpose.