Introduction
The process of defining what is necessary for compliance with a software engineering process standard such as “ISO/IEC Standard 12207 Software Life Cycle Processes” is often confusing and laborious because the directions contained in the standards are unclear or ambiguous. To aid in determining what is actually “required” by the document in the way of physical evidence of compliance, the experts at SEPT have produced this checklist. This checklist is constructed around a classification scheme of physical evidence comprised of policies, procedures, plans, records, documents, audits, and reviews. There must be an accompanying record of some type when an audit or review has been accomplished. This record would define the findings of the review or audit and any corrective action to be taken. For the sake of brevity this checklist does not call out a separate record for each review or audit. All procedures should be reviewed but the checklist does not call out a review for each procedure, unless the standard calls out the procedure review. In this checklist “manuals, reports, scripts and specifications” are included in the document category. When the subject standard references another standard for physical evidence, the checklist does not call out the requirements of the referenced standard. 

Notes concerning amendment 2: Amendment 2 has defined a new process, “Change Request Management Process,” (Reference page 4 of the amendment). Since this new process was not linked to an existing clause in the standard and all other processes were, SEPT has chosen to create a new clause, 6.11 Change Request Management Process, for the purpose of this checklist.  All artifacts called out by this process are found in that clause of the checklist.

SEPT has carefully reviewed the document “ISO/IEC Standard 12207 Software Life Cycle Processes” and Amendment 1 and 2 to identify the physical evidence required based upon this classification scheme. SEPT has conducted a second review of the complete list to ensure that the documents’ producers did not leave out a physical piece of evidence that a “reasonable person” would expect to find. It could certainly be argued that if the document did not call it out then it is not required; however if the standard was used by an enterprise to improve its process, then it would make sense to recognize missing documents. Therefore, there are documents specified in this checklist that are implied by the standard, though not specifically called out in the document, and they are designated by an asterisk (*) throughout this checklist. If a document is called out more than one time, only the first reference is stipulated. 

There are occasional situations in which a procedure or document is not necessarily separate and could be contained within another document. For example, the Software Detail Specification Document could be a subset of Software Design Specification.  SEPT has called out these individual items separately to ensure that the organization does not overlook any facet of physical evidence. If the organization does not require a separate document, and an item can be a subset of another document or record, then this fact should be denoted in the detail section of the checklist for that item. This should be done in the form of a statement reflecting that the information for this document may be found in section XX of Document XYZ. If the organizational requirements do not call for this physical evidence for a particular project, this should also be denoted with a statement reflecting that this physical evidence is not required and why. The reasons for the evidence not being required should be clearly presented in this statement. Further details on this step are provided in the Detail Steps section of the introduction. The size of these documents could vary from paragraphs to volumes depending upon the size and complexity of the software project or business requirements.

General Principles of the ISO/IEC Standard 12207 Software Life Cycle Processes” Checklist
This checklist was prepared by analyzing each clause of this draft document for the key words that signify a:

• Policy
• Procedure
• Plan
• Records
• Document ( Including Manuals, Reports, Scripts and Specifications)
• Audit 
• Review

Using the Checklist
When a company is planning to use “ISO/IEC Standard 12207 Software Life Cycle Processes” as their main software process standard, the company should review the evidence checklist. If the company’s present process does not address an “ISO/IEC 12207 Software Life Cycle Processes product, then this question should be asked: “Is the evidence product required for the type of software the business is producing? If in the view of the company the evidence is not required, the rationale should be documented and inserted in the checklist and quality manual. This rationale should pass “the reasonable person rule.”  If the evidence is required, plans should be prepared to address the missing item(s). 

Detail Steps
An enterprise should compare the proposed output of their software project or organization against the checklist. In doing this, they will find one of five conditions that exist for each item listed in the checklist. The following five conditions and the actions required by these conditions are listed in the table below.
 

• Section 1.  Introduction
• Section 2.  Composites of all required and suggested “ISO/IEC 12207 System Life Cycle Processes” evidence products.
• Sections 3-8.  Individual checklists for each evidence type.
• Section 9.  “About the Author”

• Acquisition Plan Procedure*
• Acquisition Procedure
• Concept Document Procedure*
• Purchasing Requirements Document Procedure*
• Purchasing Specification Document Procedure*
• Software and System Acceptance Document Procedure*
• Software and System
• Acceptance Plan Procedure*
• Software and System Acceptance Procedure*
• Supplier Selection Plan Procedure*
• User Requirements Document Procedure*

Acquisition Plan

Software and System Acceptance Plan

Supplier Selection Plan

• Acquisition Records
• Customer Request Response Records
• Requirements Used to Control the Risk -- Records
• Residual Risk Records

• Concept Document
• Purchasing Requirements Document*
• Purchasing Specification Document*
• Software and System Acceptance Document
• User Requirements Document

• Acquisition Plan Review*
• Concept Document Review*
• Purchasing Requirements Document Review*
• Purchasing Specification Document Reviews*
• Risk Management File Audit*
• Software and System Acceptance Document Review*
• Software and System Acceptance Plan Review*
• Supplier Selection Plan Review*
• User Requirements Document Review*

• Contract Milestone Document Procedure*
• Request for Proposal (RFP) Procedure*

• Contract Milestone Document
• Request for Proposal (RFP)

• Contract Milestone Document Review*
• Request for Proposal (RFP) Review*

• Contract Procedure*
• Supplier Selection Procedure

• Contract Change Records
• Supplier Selection Notification Records

• Contract

• Contract Review*

• Joint Supplier Audits and Reviews

• Customer-Supplied Software and Data Products Procedure*

• Customer-Supplied Software and Data Products Records*
• Software Product Release Records

• Software Policy*

• Requirements Review
• Software Policy Review*

• Proposal Procedure*

• Proposal

• Proposal Review*

• Hazard Analysis Plan Procedure*
• Life Cycle Selection Procedure
• Project Management Plan Procedure*
• Regulations and Standards Requirements Document Procedure*
• Resource and Schedule Plan Procedure*
• Risk Management Plan Procedure*
• Risk Management Procedure*
• Risk Management Summary Document Procedure*
• Safety Plan Procedure*
• Security Plan Procedure*
• Sub-Contractors Management Plan Procedure*
• Verification and Validation Plan Procedure*

• Hazard Analysis Plan*
• Project Management Plan
• Quality Plan
• Resource and Schedule Plan
• Risk Management Plan
• Safety Plan
• Security Plan
• Sub-Contractors Management Plan
• Verification and Validation Plan

• Evaluation of Effectiveness of the Risk Controls – Records*
• Evaluation of Effectiveness of the Risk Controls Methods – Records*
• Preliminary Risk Analysis Records*

• Regulations and Standards Requirements Document
• Risk Management Summary Document*

• Hazard Analysis Plan Review*
• Project Management Plan Review*
• Regulations and Standards Requirements Document Review*
• Resource and Schedule Plan Review*
• Risk Management Plan Review*
• Risk Management Summary Document Review*
• Safety Plan Review*
• Security Plan Review*
• Sub-Contractors Management Plan Review*
• Verification and Validation Plan Review

• Audit Records
• Evaluation and Test Records
• Problem Resolution (All) Records

• Problem Resolution Audit*

• Configuration Item Baseline Document Procedure*
• Life Cycle Activities and Tasks Mapping Document Procedure
• Life Cycle Development Plan Procedure*
• Methods, Tools, and Techniques Document Procedure
• Methods, Tools, and Techniques Plan Procedure
• Off the Shelf Software (OTS) Plan Procedure*

• Life Cycle Development Plan
• Methods, Tools, and Techniques Plan
• Off the Shelf Software (OTS) Plan*

• Life Cycle Phase Transition Records
• Methods, Tools, and Techniques Used Records
• Off the Shelf Software (OTS) Receipt Records*

• Configuration Item Baseline Document
• Life Cycle Activities and Tasks Mapping Document
• Methods, Tools, and Techniques Document

• Configuration Item Baseline Document Review*
• Life Cycle Activities and Tasks Mapping Document Review*
• Life Cycle Development Plan Review*
• Methods, Tools, and Techniques Document Review*
• Methods, Tools, and Techniques Plan Review*
• Off the Shelf Software (OTS) Plan Review*