Sample pages of
Evidence Product Checklist for
ANSI/UL 1998-2004 Standard for Software in Programmable Components, Revision 1

The process of defining what is necessary for compliance with a software engineering process standard such as “ANSI/UL 1998 Standard for Software in Programmable Components” 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. 

The Author has carefully reviewed the document “ANSI/UL 1998 Standard for Software in Programmable Components” and defined 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 organization 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 “Verification Plan" could be a part of the "Design and Development Plan".  The Author 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 project or business requirements.

General Principles of the “ANSI/UL 1998 Standard for Software in Programmable Components” Checklist
This checklist was prepared by analyzing each clause of this 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 "“ANSI/UL 1998 Standard for Software in Programmable Components” standard, the company should review the evidence checklist.  If the company’s present process does not address an ANSI/UL 1998 standard product, then this question should be asked:  Is the evidence product required for the type of business of the company?  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 organization should compare the proposed output of their 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.
 

• Checklist revision page
• Section 1.  Introduction
• Section 2.  Composites of all required and suggested “ANSI/UL 1998 Standard for Software in Programmable Components” evidence products.
• Sections 3-8.  Individual checklists for each evidence type.
• Section 9.  “About the Author”

Warranties and Liability
Software Engineering Process Technology (SEPT) makes no warranties implied or stated with respect to this checklist, and it is provided on an “as is” basis.  SEPT will have no liability for any indirect, incidental, special or consequential damages or any loss of revenue or profits arising under, or with respect to the use of this document.