Checklist for Standard

ISO/IEC/IEEE 12207:2017
Systems and Software Engineering – Software Life
Cycle Processes
The World Standard for Developing Quality
Software Systems

This Checklist Defines:

• The physical evidence,
policies, procedures, plans,
Waterfall records, documents, audits,
and reviews necessary for
compliance with the 12207
software standard
• The processes that must be
validated and verified to
ensure compliance
Spiral
• The life cycle suited to your
business

Stan Magee & Andrew Coster

SEPT Product 95
ISBN 978-0-9770309-0-3
Agile

Cover Design by Michael A. Magee

3/31/2018 1
 Checklist for Standard ISO/IEC/IEEE
12207:2017 – Systems and software
engineering – Software life cycle processes
SEPT Product 95

ISBN 978-0-9770309-0-3

Authors: Andy Coster CQI and Stan Magee CCP (Ret.)

Produced by Software Engineering Process Technology (SEPT)

1705 16th Lane NE Suite P203
Issaquah WA 98029
Tel. 425-391-2344
E-mail: [email protected]
Web Site: www.12207.com

© 2018. Software Engineering Process Technology (SEPT) All rights reserved.

3/31/2018 2
 Change Page History

Date Change Reason

January 2004 First Version Based on the 1995 version of ISO/IEC
12207 (Original Release
May 2009 Second Version Updated to the 2008 version of ISO/IEC
12207
March 2018 Third Version Updated to the 2017 version of
ISO/IEC/IEEE 12207. At this update the
IEEE Computer Society joined the editing
process and the standard title includes
IEEE to denote this. The checklist has
been totally rewritten using the revised
standard. The number of artifacts has
remained almost the same, but most titles
have changed to reflect the changes in the
2017 version

3/31/2018 3
 Contents
Change Page History .......................................................................................................................................3
Section 1 - Introduction ...................................................................................................................................5
Components of the Checklist ...........................................................................................................................5
Information on ISO/IEC/IEEE 12207:2017 (Base Standard) ..........................................................................5
Scope ...........................................................................................................................................................5
Purpose of ISO/IEC/IEEE/ 12207:2017 ......................................................................................................6
Relationship to other key Standards ................................................................................................................6
SEPT checklist for ISO/IEC/IEEE/ 12207:2017 .............................................................................................6
Purpose ........................................................................................................................................................6
Exclusions ...................................................................................................................................................7
General Principles of the Checklist for ISO/IEC/IEEE Standard 12207:2017 ................................................8
Using the Checklist..........................................................................................................................................8
Detail Steps ..................................................................................................................................................9
Condition .....................................................................................................................................................9
Action Required...........................................................................................................................................9
Product Support ...............................................................................................................................................9
Guarantees and Liability ..................................................................................................................................9
Section 2 ISO/IEC/IEEE 12207:2017 Evidence Products Checklist by Clause……………………...…….10
Section 3 ISO/IEC/IEEE 12207:2017 Policies and Procedures Checklist by Clause……………………..160
Section 4 ISO/IEC/IEEE 12207:2017 Plans Checklist by Clause………………........................................288
Section 5 ISO/IEC/IEEE 12207:2017 Records Checklist by Clause……………………………………...293
Section 6 ISO/IEC/IEEE 12207:2017 Documents Checklist by Clause…………………………………..313
Section 7 ISO/IEC/IEEE 12207:2017 Audits Checklist by Clause………………………………………..342
Section 8 ISO/IEC/IEEE 12207:2017 Reviews Checklist by Clause……………………………………...343
Section 9 About the Authors…………………………………………………………….…………….…...395

Note –Section 2-9 references above were manually generated.

3/31/2018 4
 Section 1
Introduction

Components of the Checklist

This checklist is composed of 9 sections:
 •Section 1. Introduction
 •Section 2. Composites of all required and suggested “ISO/IEC/IEEE
12207:2017 artifacts.
 •Sections 3-8. Individual checklists for each type of artifact (policies &.
procedures, plans, records, documents, audits and reviews)
 •Sections 9. About the authors

Information on ISO/IEC/IEEE 12207:2017 (Base Standard)

Scope
ISO/IEC/IEEE 12207:2017 establishes a common framework for software life cycle
processes, with well-defined terminology, that can be referenced by the software
industry. It contains processes, activities, and tasks that are to be applied during the
acquisition of a software system, product or service and during the supply, development,
operation, maintenance and disposal of software products. This is accomplished through
the involvement of stakeholders, with the ultimate goal of achieving customer
satisfaction. The Standard applies to the acquisition of software systems, products and
services, to the supply, development, operation, maintenance, and disposal of software
products and the software portion of any system, whether performed internally or
externally to an organization. Software includes the software portion of firmware. Those
aspects of system definition needed to provide the context for software products and
services are included. The Standard also provides processes that can be employed for
defining, controlling, and improving software life cycle processes within an organization
or a project. The processes, activities and tasks of this International Standard may also be
applied during the acquisition of a system that contains software, either alone or in
conjunction with ISO/IEC/IEEE 15288, Systems and software engineering--System life
cycle processes. In the context of this International Standard and ISO/IEC/IEEE 15288, it
is recognized that there is a continuum of human-made systems from those that use little
or no software to those in which software is the primary interest. It is rare to encounter a
complex system without software, and all software systems require physical system
components (hardware) to operate, either as part of the software system of interest or as
an enabling system or infrastructure. Thus, the choice of whether to apply the Standard
for the software life cycle processes, or ISO/IEC/IEEE 15288:2015, Systems and
software engineering--System life cycle processes, depends on the system of interest.
Processes in both standards have the same process purpose and process outcomes, but
differ in activities and tasks to perform software engineering or systems engineering,
respectively.

3/31/2018 5
Purpose of ISO/IEC/IEEE/ 12207:2017
The purpose of ISO/IEC/IEEE 12207:2017 is to provide a defined set of processes to
facilitate communication among acquirers, suppliers and other stakeholders in the life
cycle of a software system. The Standard is written for acquirers of software systems,
products and services and for suppliers, developers, integrators, operators, maintainers,
managers, quality assurance managers, and users of software systems and products. It can
be used by a single organization in a self-imposed mode or in a multi-party situation.
Parties can be from the same organization or from different organizations and the
situation can range from an informal agreement to a formal contract. The processes in the
Standard can be used as a basis for establishing business environments, e.g., methods,
procedures, techniques, tools and trained personnel. Annex A provides normative
direction regarding the tailoring of these software life cycle processes

Relationship to other key Standards

ISO/IEC/IEEE 12207:2017 is a companion document and is harmonized with
ISO/IEC/IEEE 15288:2015. The wording in both standards is mostly the same although
ISO/IEC/IEEE 12207:2017 includes many different Annexes, one of which shows the
relationship to ISO/IEC/IEEE/ 12207:2008.
There are a number of elaboration standards for single or groups of processes in
ISO/IEC/IEEE 12207:2017 such as ISO/IEC/IEEE/IEEE 16326 Project Management and
ISO/IEC/IEEE/IEEE 16085 – Risk Management.

SEPT checklist for ISO/IEC/IEEE/ 12207:2017

Purpose
Getting software life cycle processes under control for an organization is a daunting task.
The last thing an organization wants in its management operation is to call in a Notified
Body for certification and to find out that the organization is lacking the correct records
or documents for the auditor to examine. If you do not read the standard correctly it could
cause a problem or could increase the cost to become certified. That is why we believe a
checklist is important.

For 20 + years Software Engineering Process Technology (SEPT) has produced

checklists for standards that address software issues. To reduce the fog surrounding these
types of standards SEPT has produced checklists for standards since 1994. This is another
checklist related to standards for the IT industry that will aid an organization’s
compliance with an international software code of practice.

The first step that an organization has in meeting the requirements of a standard such as
Standard ISO/IEC/IEEE 12207:2017 is to determine what is required and what is
suggested. Often these types of technical standards are confusing and laborious because
the directions contained in the standards are sometimes unclear to a lay person. The
checklists lift this fog around a standard and state what is required and suggested by the
standard in a clear and concise manner.

3/31/2018 6
To aid in determining what is “required” by the document in the way of physical
evidence (artifact) of compliance, the experts at SEPT have produced this checklist. The
SEPT checklists are 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. In the procedure category, guidelines are included
when the subject standard references another standard for physical evidence. The
checklist does not call out the requirements of the referenced standard.

The authors have carefully reviewed the Standard ISO/IEC/IEEE 12207:2017 and
defined the physical evidence required based upon this classification scheme. SEPT’s
engineering department has conducted a second review of the complete list and baseline
standard 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 by it, 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 "Acquisition
Data Rights Procedure" could be a part of the "Acquisition Procedure." The authors have
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 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.

Exclusions
In compiling the checklist the authors decided not to include any item referenced in Notes
to any clause of the Standard for two reasons:

3/31/2018 7
 1. There are over 1000 artifacts identified which the authors considered onerous for
an organization to digest (without including probably 600 based on suggestions
from the Notes).
2. The Notes contain no normative contents.
Some clauses go to a fourth level of list e.g., 6.4.1.3a)1)i), but these fourth level artifacts
have not been included in the checklist for two reasons:
1. The large number of artifacts – 981 previously mentioned
2. This fourth level only occurs on a limited number of sections, usually a detailed
list of a “Strategy” where the Strategy itself contains the listed items.

Annex B
In the second review of the base line standard by our engineering department they
recommended that we include 33 artifacts from Annex B as suggested items to give the
checklist more continuity to the old base standard (ISO/IEC 12207:2008). And what our
customers are using today to be in conformance with 12207.

General Principles of the Checklist for ISO/IEC/IEEE Standard

12207:2017
This checklist was prepared by analyzing each clause of the Standard for the key words
that signify a:
 Policy
 Procedure (Including Guidelines)
 Plan
 Records
 Document (Including Manuals, Reports, Scripts and Specifications)
 Audit
 Review

This checklist specifies evidence that is unique. After reviewing the completed
document, the second review was conducted from a common sense “reasonable person”
approach. If a document or other piece of evidence appeared to be required, but was not
called out in the document, then it is added with an asterisk (*) after its notation in the
checklist. The information was transferred into checklist tables based on the type of
product or evidence.

In total, there are over 1000 artifacts included in the SEPT ISO/IEC/IEEE 12207:2017
checklist of which 696 are “Required”.

Using the Checklist

When a company is planning to use ISO/IEC/IEEE 12207:2017 standard, the company
should review the evidence checklist. If the company’s present process does not address
an ISO/IEC/IEEE 12207:2017 standard product, then the following question should be
asked: “Is the evidence product required for the type of business of the organization?” If,
in the view of the organization, the evidence is not required, the rationale should be
documented and inserted in the checklist and quality manual. This rationale should pass
3/31/2018 8
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.

Condition Action Required

1. The title of the documented evidence Record in checklist that the organization
specified by the checklist (document, is compliant.
plan, etc.) agrees with the title of the
evidence being planned by the
organization.
2. The title of the documented evidence Record in the checklist the evidence title
specified by the checklist (document, the organization uses and record that the
etc.) disagrees with the title of the organization is compliant, and the
evidence planned by the organization evidence is the same although the title is
but the content is the same. different.
3. The title of the documented evidence Record in the checklist the title of the
specified by the checklist (document, evidence (document, etc.) in which this
etc.) is combined with another piece of information is contained.
evidence.
4. The title of the documented evidence Record in the checklist that the evidence
specified by the checklist (document, is not required and the rationale for this
etc.) is not planned by the organization decision.
because it is not required.
5. The title of the documented evidence Record in the checklist when this
called out by the checklist (document, evidence will be planned and reference a
etc.) is not planned by the organization plan for accomplishing the task.
and should be planned by it.

Product Support
All reasonable questions concerning this checklist or its use will be addressed by SEPT
free of charge for 60 days from time of purchase, up to a maximum of 4 hours
consultation time.

Guarantees and Liability

Software Engineering Process Technology (SEPT) makes no guarantees 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.

3/31/2018 9
 Section 2
ISO/IEC/IEEE 12207:2017 Evidence Products Checklist by Clause

ISO/IEC/IEEE Policies and Plans Records Documents Audits and Reviews

12207:2017 Clause Procedures
Number and Name
6 Software life cycle
processes
6.1 Agreement
processes

3/31/2018 10
* Suggested item CM – Configuration Management
 Section 2
ISO/IEC/IEEE 12207:2017 Evidence Products Checklist by Clause

ISO/IEC/IEEE Policies and Plans Records Documents Audits and Reviews

12207:2017 Clause Procedures
Number and Name
6.1.1 Acquisition process  Acquirer and  Acquirer  Acquirer and  Acquirer and
Supplier Obligation Supplier Supplier
Agreement Satisfaction Agreement Agreement
Document Records* Document Document
Procedure*  Agreement  Acquisition Review*
 Acquisition Closure Records Advertisement  Acquisition
Advertisement  Confirmation of Document Advertisement
Document the Agreed  Acquisition Document
Procedure* Delivered Strategy Review*
 Acquisition Data Product or Document  Acquisition
Rights Service Records  Agreement Strategy
Procedure*  Payment or Change Request Document
 Acquisition Other Agreed Document Review*
Licensing Rights Consideration  Requirements  Agreement
Procedure* for the Product for Supply Change Impact
 Acquisition Records Request Evaluation
Procedure  Supplier Document Review
 Acquisition Selection  Supply Request  Agreement
Strategy Notification Document Change Request
Document Records* Document
Procedure*  Supplier Review*
 Acquisition Selection  Requirements
Trade Off Records* for Supply
Procedure* Request
 Agreement and Document
Acceptance Review*
Criteria  Supply Request
Development Document
Procedure Review*
3/31/2018 11
* Suggested item CM – Configuration Management
 Section 2
ISO/IEC/IEEE 12207:2017 Evidence Products Checklist by Clause

ISO/IEC/IEEE Policies and Plans Records Documents Audits and Reviews

12207:2017 Clause Procedures
Number and Name
6.1.1 Acquisition process  Agreement
(Cont. 1) Change Request
Document
Procedure*
 Agreement
Change Request
Procedure*
 Agreement
Execution
Assessment
Procedure
 Agreement
Update
Procedure
 Product or
Service
Acceptance
Procedure
 Requirements
for Supply
Request
Document
Procedure*

3/31/2018 12
* Suggested item CM – Configuration Management