ISO/IEC 12207:1995/Amd 1:2002

INTERNATIONAL ISO/IEC
STANDARD 12207
First edition
1995-08-01
AMENDMENT 1
2002-05-01
Information technology — Software life
cycle processes
AMENDMENT 1
Technologies de l'information — Processus du cycle de vie du logiciel
AMENDEMENT 1
Reference number
ISO/IEC 12207:1995/Amd.1:2002(E)
©
ISO/IEC 2002
ISO/IEC 12207:1995/Amd.1:2002(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of the joint technical committee is to prepare International Standards. Draft International Standards
adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this Amendment may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to International Standard ISO/IEC 12207:1995 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software engineering.

© ISO/IEC 2002 – All rights reserved iii

ISO/IEC 12207:1995/Amd.1:2002(E)
Introduction
ISO/IEC 12207 was published on 1 August 1995 and is the first international standard to provide a comprehensive
set of life cycle processes, activities and tasks for software that is part of a larger system, stand alone software
product, and software services. The standard provides common software process architecture for the acquisition,
supply, development, operation and maintenance of software. The standard also provides the necessary
supporting processes, activities and tasks, and organizational processes, activities and tasks for managing and
improving the processes.
This Amendment provides an interim revision to ISO/IEC 12207 that establishes a co-ordinated set of software
process information that can be used for process definition and process assessment and improvement. The
Amendment accommodates the requirements of current and developing SC 7 standards and technical reports,
notably ISO/IEC 12207 and ISO/IEC/TR 15504, and considers other standards, e.g., ISO/IEC 14598 and
ISO/IEC 15939. Experience in using ISO/IEC 12207 as the basis for organizations’ software life cycle process and
in two-party situations, has resulted in some lessons learned and has provided some valuable inputs to the update
process.
During the development of ISO/IEC/TR 15504-2, issues were highlighted in regard to the granularity of the process
definition in ISO/IEC 12207, i.e.; it was difficult to derive a process rating component for the purpose of process
assessment and improvement. This Amendment resolves this granularity issue and provides process purpose and
outcomes to establish a Process Reference Model in accordance with the requirements of ISO/IEC 15504-2. A
Process Reference Model provides definitions of processes in a life cycle described in terms of process purpose
and outcomes, together with an architecture describing relationships between the processes. A Process Reference
Model provides the mechanism whereby externally defined assessment models are related to the assessment
framework defined by ISO/IEC 15504.
The current ISO/IEC 12207 process architecture defines the hierarchical relationship among processes, activities
and tasks and the invocation rules for the software life cycle processes. Inclusion of a process, an activity, or a task
for the Amendment is in accordance and consistent with the existing architecture of ISO/IEC 12207.

iv © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Information technology — Software life cycle processes
AMENDMENT 1
Throughout the text:
Change the name of the “Training”process to the “Human Resource”process.
Modify the last sentence of the Foreword to read as follows:
“Annexes A and F form an integral part of this International Standard. Annexes B, C, D, E, G and H are for
information only.”
Modify subclause 1.2, paragraph 4, to read as follows:
1.2 Field of Application
This clause does not prevent the use of ISO/IEC 12207 by suppliers or developers of off-the-shelf software.
In subclause 1.4, change “compliance” to read “conformance”.
Add the following text to subclause 1.4:
1.4.1 Conformance to Purposes and Outcomes
Annex F provides an alternative form of conformance useful in situations where implemented processes are
intended to achieve the same goals of those described in this standard, but which may not implement the detailed
provisions prescribed in the body of this standard. To claim conformance, it shall be demonstrated that, for any
process from the set of processes declared by the organization, implementation of the processes results in the
realization of the corresponding Purpose and Outcomes provided in Annex F. Any organization shall define the set
of processes applicable for it, taking into account the proposed set of processes described in Annex F and its own
environmental parameters. Application of the standard allows the creation of additional outcomes.
NOTE In ISO/IEC 12207:1995, the term “compliance”is used in clause 1.4, however, in accordance with ISO/IEC Guide 2,
Standardization and Related Activities — General Vocabulary, conformance is the appropriate term for this clause.
Conformance is the fulfilment by a product, process or service of specified requirements.
Modify subclause 1.5, paragraph 6, to read as follows:
1.5 Limitations
In this International Standard, there are a number of lists for tasks; none of these is presumed to be exhaustive —
they are intended as examples unless introduced by a clause containing a “shall”or a “will.”
Add the following reference to clause 2:
ISO/IEC 15504-2, Software Engineering — Software process assessment — Part 2: Performing an assessment
Add the following definitions to clause 3:
3.38 Process Purpose: The high level objective of performing the process and the likely outcomes of effective
implementation of the process. The implementation of the process should provide tangible benefits to the
stakeholders.
© ISO/IEC 2002 – All rights reserved 1

ISO/IEC 12207:1995/Amd.1:2002(E)
3.39 Process Outcome: an observable result of the successful achievement of the process purpose.
NOTE An outcome statement describes one of the following:
• Production of an artefact;
• A significant change in state;
• Meeting of specified constraints, e.g., requirements, goals, etc.
NOTE A list of the principal process outcomes forms part of the description of each process in the reference model.
Add the following subclause to clause 4:
4.2 Relationship of Annex F to the main text of this International Standard
Annex F defines a Process Reference Model (PRM) at a level of abstraction higher than that of the detailed
requirements contained in the main text of this International Standard. The PRM is applicable to an organization
that is assessing its processes in order to determine the capability of these processes. The Purpose and Outcomes
provided in Annex F are a statement of the goals of the performance of each process. This statement of goals
permits assessment of the effectiveness of the processes in ways other than simple conformity evaluation. For
example, novel process definitions can be evaluated against the statements of Purpose and Outcomes in Annex F
rather than against the detailed provisions in the main text of this International Standard.
NOTES
1) The term “process reference model”is used with the same meaning as the planned revision of ISO/IEC 15504-2.
2) The PRM is intended to be used to develop assessment model(s) for assessing processes using ISO/IEC 15504-2
3) The processes described in Annex F contain extensions, elaborations and some new processes where there is no
corresponding development of activities and tasks in ISO/IEC 12207:1995. This will be rectified during the full revision
of ISO/IEC 12207:1995. In the meantime, new subclauses 6.9, 7.1.6 and 7.4 to 7.7 provide activities and tasks for the
“new”processes of Annex F.
Add the following text to subclause 5.1.1.5:
The acquirer may use Requirements Elicitation sub-process described in Annex F to establish the customer
requirements.
Modify subclause 5.1.3.5, sentence 2, as follows:
Subclause 5.1.3.5, “Shall” should be changed to “will”
Add the following text to subclause 5.3.1.2, list item e):
e) Establish baselines for each configuration item at appropriate times, as determined by the acquirer and the
supplier.
Delete sentence 2 of subclause 5.3.4.3.
Delete subclause 5.3.9.5.b.
Delete subclause 5.3.11.4.b.
2 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Add the following text as a second paragraph to the preamble of subclause 6.1:
Execution of this process by an organization results in the establishment of internal documentation standards (such
as standards for program management plan and software design document) in a suitable media. The terms used in
this process need to be interpreted accordingly for a given media or domain.
Modify line 2 of the preamble of subclause 6.2 as follows:
“Baseline” should be deleted. The resulting sentence should read as follows:
The Configuration Management Process is a process of applying administrative and technical procedures to
support the software life cycle to: identify and define software items in a system; control modifications and releases
of the items; record and report the status of the items and modification requests; ensure the completeness,
consistency, and correctness of the items, and control storage, handling, and delivery of the items.
Replace subclause 6.3.4.1 with the following:
Additional quality management activities can be assured in accordance with the clauses of ISO 9001.
Add the following note to subclause 6.5.2:
NOTE Other means besides testing (such as, analysis, modelling, simulation, etc.) may be employed for validation.
Replace list item e) in subclause 6.6.3.1 with the following:
e) They are ready for the next planned activity.
Add the following references to annex D:
IEEE Std 1517 — 1999, IEEE Standard for Information Technology — Software Life Cycle Processes — Reuse
Processes
ISO 9000-3, Quality management and quality assurance standards -- Part 3: Guidelines for the application of ISO
9001:1994 to the development, supply, installation and maintenance of computer software
ISO 9000: 2000, Quality management systems — Concepts and vocabulary
ISO 9001: 2000, Quality management systems — Requirements
ISO 9004: 2000, Quality management systems — Guidance for performance improvement
ISO/IEC 9126:1991, Software Product Evaluation — Quality Characteristics and Guidelines for their Use
ISO 13407:1999, Ergonomics — Ergonomics of human-system interaction — Human-centred design process for
interactive systems
ISO/IEC 14598:1998, Software Engineering — Product Evaluation
ISO/IEC/TR 15504:(all parts), Information technology — Software process assessment
ISO/IEC 15504-1, (to be published) Software Engineering — Software process assessment — Part 1: Concepts
and Vocabulary
ISO/TR 18529, Ergonomics — Ergonomics of human-system interaction — Human-centred lifecycle process
descriptions
ISO/IEC 15939 Software Engineering — Software process measurement
Add the following annexes E, F, G and H:
© ISO/IEC 2002 – All rights reserved 3

ISO/IEC 12207:1995/Amd.1:2002(E)
Annex E
(informative)
Relationship to ISO 12207:1995
E.1 Relationship of Purpose and Outcomes to ISO/IEC 12207:1995
ISO/IEC 12207:1995 documents the set of software engineering processes that are fundamental to good software
engineering and cover best practices. The Processes of the Life Cycle are described in Annex F in terms of the
achievement of defined Purposes and Outcomes; these descriptions constitute a reference model, which describes
processes that an organization can use to acquire, supply, develop, operate and maintain software. The reference
model is also used to provide a common basis for different models and methods for software process assessment,
ensuring that the results of the assessments can be reported in a common context. The substantive part of
ISO/IEC 12207:1995 sets out the activities and tasks required to implement the high level life cycle processes to
achieve desirable capability for acquirers, suppliers, developers, maintainers and operators of systems containing
software.
Annex F groups the Purposes and Outcomes into the three life cycle process categories of ISO/IEC 12207:1995,
i.e., Organizational, Primary and Supporting. Within each of the process categories are descriptions in terms of a
purpose statement, which comprise unique functional objectives when instantiated in a particular environment. The
purpose statement includes additional material identifying the outcomes of successful implementation.
Annex F does not define how, or in what order, the elements of the purpose statements are to be achieved. The
outcomes will be achieved in an organization through various detailed practices being carried out to produce work
products. These performed practices, and the characteristics of the work products produced, are indicators that
demonstrate whether the specific purpose is being achieved.
The structure of Annex F and its relationship to the existing International Standard, ISO/IEC 12207:1995, is
depicted in Table E-1. For those Purpose and Outcomes that are an “new” to ISO/IEC 12207:1995, descriptions of
their activities and/or tasks are provided in new subclauses 6.9, 7.1.6 and 7.4 to 7.7. The activity and task
descriptions provided in these new subclauses are in accordance with process structure of ISO/IEC 12207:1995.
E.2 Purpose and Outcomes
The Purpose and Outcomes in Annex F are at the appropriate process, activity or task level to align with the
process structure of ISO/IEC 12207. The definition of purpose and outcomes is provided in clause 1.1.2 of this
Amendment.
E.3 Process Type
Table E-1 provides a detailed mapping of the content of Annex F to the existing International Standard,
ISO/IEC 12207:1995, the source of the information, the structure of the content and the content type. The process
structure relationship of Annex F to ISO/IEC 12207 :1995 is defined by process type as follows:
• Basic — These processes and sub-processes are identical to the processes and activities of
ISO/IEC 12207:1995.
• New — These processes and sub-processes are an expansion to the process definition of
ISO/IEC 12207:1995.
• Extended — These processes and sub-processes are elaborations of the existing processes and activities
of ISO/IEC 12207:1995.
• Component — These are groupings of existing activities of ISO/IEC 12207:1995.
4 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Table E.1 — Correlation of ISO/IEC 12207:1995 to Annex F
Process
12207 12207 Processes & activities Annex F Source Annex F Process Structure
Type
5. Primary life cycle processes
5.1 Acquisition process ISO/IEC 12207 Acquisition process basic
ISO/IEC/TR 15504-2 Acquisition preparation component
ISO/IEC/TR 15504-2 Supplier selection component
ISO/IEC/TR 15504-2 Supplier monitoring component
ISO/IEC/TR 15504-2 Customer acceptance component
5.2 Supply process ISO/IEC 12207 Supply process basic
5.3 Development process ISO/IEC 12207 Development process basic
5.3.1 Process implementation
ISO/IEC/TR 15504-2 Requirements elicitation extended
5.3.2 System requirements analysis ISO/IEC 12207 System requirements analysis basic
5.3.3 System architectural design ISO/IEC 12207 System architectural design basic
5.3.4 Software requirements analysis ISO/IEC 12207 Software requirements analysis basic
5.3.5 Software architectural design ISO/IEC/TR 15504-2 Software design component
5.3.6 Software detailed design ISO/IEC/TR 15504-2 Software design component
5.3.7 Software coding and testing ISO/IEC/TR 15504-2 Software construction component
5.3.8 Software integration ISO/IEC 12207 Software integration basic
5.3.9 Software qualification testing ISO/IEC/TR 15504-2 Software testing component
5.3.10 System integration ISO/IEC/TR 15504-2 System integration component
5.3.11 System qualification testing ISO/IEC/TR 15504-2 System testing component
5.3.12 Software installation ISO/IEC 12207 Software installation basic
5.3.13 Software acceptance support ISO/IEC 12207 Supply process basic
5.4 Operation process ISO/IEC 12207 Operation process basic
ISO/IEC/TR 15504-2 Operational use extended
ISO/IEC/TR 15504-2 Customer support extended
5.5 Maintenance process ISO/IEC 12207 Maintenance process basic
6. Supporting life cycle processes
6.1 Documentation process ISO/IEC 12207 Documentation process basic
6.2 Configuration management ISO/IEC 12207 Configuration management basic
process process
6.3 Quality assurance process ISO/IEC 12207 Quality assurance process basic
6.4 Verification process ISO/IEC 12207 Verification process basic
6.5 Validation process ISO/IEC 12207 Validation process basic
6.6 Joint review process ISO/IEC 12207 Joint review process basic
6.7 Audit process ISO/IEC 12207 Audit process basic
6.8 Problem resolution process ISO/IEC12207 Problem resolution process basic
ISO 13407 Usability process new
ISO/IEC 14598 Product evaluation process extended
© ISO/IEC 2002 – All rights reserved 5

ISO/IEC 12207:1995/Amd.1:2002(E)
Table E.1 — (continued)
Process
12207 12207 Processes & activities Annex F Source Annex F Process Structure
Type
7. Organizational life cycle
processes
7.1 Management process ISO/IEC 12207 Management process basic
ISO/IEC/TR 15504-2 Organizational alignment extended
ISO/IEC 12207 Organizational management basic
ISO/IEC/TR 15504-2 Project management extended
ISO/IEC/TR 15504-2 Quality Management extended
ISO/IEC/TR 15504-2 Risk Management extended
ISO/IEC 15939 Measurement new
7.2 Infrastructure process ISO/IEC 12207 Infrastructure process basic
7.3 Improvement process ISO/IEC 12207 Improvement process basic
7.3.1 Process establishment ISO/IEC/TR 15504-2 Process establishment component
7.3.2 Process assessment ISO/IEC/TR 15504-2 Process assessment component
7.3.3 Process improvement ISO/IEC/TR 15504-2 Process improvement component
7.4 Training process ISO/IEC/TR 15504-2 Human Resource process new
ISO/IEC/TR 15504-2 Human resource management new
ISO/IEC 12207 Training basic
Knowledge management new
7.5 IEEE 1517 Asset management process new
7.6 IEEE 1517 Reuse program management new
process
7.7 IEEE 1517 Domain engineering process new

6 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Annex F
(normative)
Purpose and Outcomes
Annex F provides a process reference model that is characterized in terms of process purposes and outcomes,
together with an architecture describing the relationships between processes, that describe the expected results
from the implementation of this Annex by an organization or a project. The process reference model is applicable to
an organization that is assessing processes needed for business success and the subsequent continuous
improvement of these processes.
The process model does not represent a particular process implementation approach nor does it prescribe a
system/software life cycle model, methodology or technique. Instead the reference model is intended to be tailored
by an organization based on its business needs and application domain. The organization’s defined process is
adopted by the organization’s projects in the context of the customer requirements.
The reference model’s purpose and outcomes are indicators that demonstrate whether the organization’s
processes are being achieved. These indicators are useful to process assessors to determine the capability of the
organization’s implemented process and to provide source material to plan organizational process improvement.
The reference model is strongly aligned with ISO/IEC 12207:1995, provides detailed process expectations and
includes additional processes determined as essential to enable a reliable and repeatable assessments of software
organizations.
NOTE Copyright release: Users may freely reproduce the detailed descriptions of process purpose and outcomes in this
annex as part of any Assessment Model based upon the Process Reference Model, or as part of any demonstration of
compatibility with the Process Reference Model, so that it can be used for its intended purpose.
F.1 Primary Life Cycle Processes
F.1.1 Acquisition Process
Purpose:
The purpose of the Acquisition Process is to obtain the product and/or service that satisfies the need expressed by
the customer. The process begins with the identification of a customer need and ends with the acceptance of the
product and/or service needed by the customer.
NOTE Annex H provides an extension of the acquisition process that may be used in lieu of the acquisition process
provided in Annex F.
Outcomes:
As a result of successful implementation of the Acquisition Process :
1) acquisition needs, goals, product and/or service acceptance criteria and acquisition strategies are defined;
2) an agreement is developed that clearly expresses the expectation, responsibilities and liabilities of both the
customer and the supplier;
3) a product and/or service is acquired that satisfies the customer’s stated need;
4) the acquisition is monitored so that specified constraints such as cost, schedule and quality are met;
5) supplier deliverables are accepted;
6) any identified open items have a satisfactory conclusion as agreed to by the customer and the supplier.
© ISO/IEC 2002 – All rights reserved 7

ISO/IEC 12207:1995/Amd.1:2002(E)
NOTE Numbering of outcomes is for identification only and does not imply priority or sequence.
The Acquisition Process includes purposes and outcomes for the following sub-processes:
• Acquisition Preparation
• Supplier Selection
• Supplier Monitoring
• Customer Acceptance
F.1.1.1 Acquisition preparation
Purpose:
The purpose of Acquisition preparation is to establish the needs and goals of the acquisition and to communicate
these with the potential suppliers.
Outcomes:
As a result of successful implementation of Acquisition preparation:
1) the concept or the need for the acquisition, development, or enhancement is established;
2) the needed acquisition requirements defining the project needs are defined and validated;
3) the customer’s known requirements are defined and validated;
4) an acquisition strategy is developed; and
5) supplier selection criteria are defined.
F.1.1.2 Supplier selection
Purpose:
The purpose of Supplier selection is to choose the organization that is to be responsible for the delivery of the
requirements of the project.
Outcomes:
As a result of successful implementation of Supplier selection:
1) the supplier selection criteria are established and used to evaluate potential suppliers;
2) the supplier is selected based upon the evaluation of the supplier’s proposals, process capabilities, and other
factors; and
3) an agreement is established and negotiated between the customer and the supplier.
F.1.1.3 Supplier monitoring
Purpose:
The purpose of Supplier monitoring is to track and assess performance of the supplier against agreed
requirements.
8 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Outcomes:
As a result of successful implementation of Supplier monitoring:
1) joint activities between the customer and the supplier are performed as needed;
2) information on technical progress is exchanged regularly with the supplier;
3) performance of the supplier is monitored against the agreed requirements; and
4) agreement changes, if needed, are negotiated between the acquirer and the supplier and documented in the
agreement.
F.1.1.4 Customer acceptance
Purpose:
The purpose of Customer acceptance is to approve the supplier's deliverable when all acceptance criteria are
satisfied.
Outcomes:
As a result of successful implementation of Customer acceptance:
1) the delivered software product and/or service are evaluated with regard to the agreement
2) the customer’s acceptance is based on the agreed acceptance criteria; and
3) the software product and/or service is accepted by the customer.
F.1.2 Supply Process
Purpose:
The purpose of the Supply process is to provide a product or service to the customer that meets the agreed
requirements.
Outcomes:
As a result of successful implementation of the Supply process:
1) a response to customer's request is produced;
2) an agreement is established between the customer and the supplier for developing, maintaining, operating,
packaging, delivering, and installing the product and/or service;
3) a product and/or service that meets the agreed requirements are developed by the supplier; and
4) the product and/or service is delivered to the customer in accordance with the agreed requirements.
F.1.3 Development Process
Purpose:
The purpose of the Development Process is to transform a set of requirements into a software product or software-
based system that meets the customer’s stated needs. The activities of the Development Process are composed
for Systems Developer role and Software Developer role.
© ISO/IEC 2002 – All rights reserved 9

ISO/IEC 12207:1995/Amd.1:2002(E)
Outcomes:
As a result of the successful implementation of the Development Process :
1) requirements for the development of software are gathered and agreed;
2) a software product or software-based system is developed;
3) intermediate work products are developed that demonstrate that the end product is based upon the
requirements;
4) consistency is established between the products of the development process;
5) system quality factors are optimized against system requirements, e.g., speed, development cost, usability,
etc.;
6) evidence (for example, testing evidence) is provided that demonstrates that the end product meets the
requirements; and
7) the end product is installed in accordance with the agreed requirements.
The Development Process includes purposes and outcomes for the following sub-processes:
• Requirements Elicitation
• System Requirements Analysis
• System Architecture Design
• Software Requirements Analysis
• Software Design
• Software Construction (Code and Unit Test)
• Software Integration
• Software Testing
• System Integration
• System Testing
• Software Installation
F.1.3.1 Requirements elicitation
Purpose:
The purpose of Requirements elicitation is to gather, process, and track evolving customer needs and
requirements throughout the life of the product and/or service so as to establish a requirements baseline that
serves as the basis for defining the needed work products. Requirements elicitation may be performed by the
acquirer or the developer of the system.
Outcomes:
As a result of successful implementation of Requirements elicitation:
1) continuing communication with the customer is established;
2) agreed customer requirements are defined and baselined;
10 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
3) a change mechanism is established to evaluate and incorporate changes to customer requirements into the
baselined requirements based on changing customer needs;
4) a mechanism is established for continuous monitoring of customer needs;
5) a mechanism is established for ensuring that customers can easily determine the status and disposition of
their requests; and
6) enhancements arising from changing technology and customer needs are identified and there impact
managed.
F.1.3.2 System requirements analysis
Purpose:
The purpose of System requirements analysis is to transform the defined stakeholder requirements into a set of
desired system technical requirements that will guide the design of the system.
Outcomes:
As a result of successful implementation of System requirements analysis:
1) a defined set of system functional and non-functional requirements describing the problem to be solved are
established;
2) the appropriate techniques are performed to optimize the preferred project solution;
3) system requirements are analyzed for correctness and testability;
4) the impact of the system requirements on the operating environment are understood;
5) the requirements are priortized, approved and updated as needed;
6) consistency and traceability is established between the system requirements and the customer’s requirements
baseline;
7) changes to the baseline are evaluated for cost, schedule and technical impact; and
8) the system requirements are communicated to all affected parties and baselined.
F.1.3.3 System architectural design
Purpose:
The purpose of System architectural design is to identify which system requirements should be allocated to which
elements of the system.
Outcomes:
As a result of successful implementation of System architectural design:
1) a system architecture design is defined that identifies the elements of the system and meets the defined
requirements;
2) the system’s functional and non-functional requirements are addressed;
3) the requirements are allocated to the elements of the system;
4) internal and external interfaces of each system element are defined;
© ISO/IEC 2002 – All rights reserved 11

ISO/IEC 12207:1995/Amd.1:2002(E)
5) verification between the system requirements and the system architecture is performed;
6) the requirements allocated to the system elements and their interfaces are traceable to the customer’s
requirements baseline;
7) consistency and traceability between the system requirements and system architecture design is maintained;
and
8) the system requirements, the system architecture design, and their relationships are baselined and
communicated to all affected parties.
F.1.3.4 Software requirements analysis
Purpose:
The purpose of Software requirements analysis is to establish the requirements of the software elements of the
system.
Outcomes:
As a result of successful implementation of Software requirements analysis:
1) the requirements allocated to the software elements of the system and their interfaces are defined;
2) software requirements are analyzed for correctness and testability;
3) the impact of software requirements on the operating environment are understood;
4) consistency and traceability are established between the software requirements and system requirements;
5) prioritization for implementing the software requirements is defined;
6) the software requirements are approved and updated as needed;
7) changes to the software requirements are evaluated for cost, schedule and technical impact; and
8) the software requirements are baselined and communicated to all affected parties.
F.1.3.5 Software design
Purpose:
The purpose of Software design is to provide a design for the software that implements and can be verified against
the requirements.
Outcomes:
As a result of successful implementation of Software design:
1) a software architectural design is developed and baselined that describes the software elements that will
implement the software requirements;
2) internal and external interfaces of each software elements are defined;
3) a detailed design is developed that describes software units that can be built and tested; and
4) consistency and traceability are established between software requirements and software design.
12 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
F.1.3.6 Software construction
Purpose:
The purpose of Software construction is to produce executable software units that properly reflect the software
design.
Outcomes:
As a result of successful implementation of Software construction:
1) verification criteria are defined for all software units against their requirements;
2) software units defined by the design are produced;
3) consistency and traceability are established between software requirements and design and software units;
and
4) verification of the software units against the requirements and the design is accomplished.
F.1.3.7 Software integration
Purpose:
The purpose of Software integration is to combine the software units, producing integrated software items,
consistent with the software design, that demonstrate that the functional and non-functional software requirements
are satisfied on an equivalent or complete operational platform.
Outcomes:
As a result of successful implementation of Software integration:
1) an integration strategy is developed for software units consistent with the software design and the prioritized
software requirements;
2) verification criteria for software items are developed that ensure compliance with the software requirements
allocated to the items;
3) software items are verified using the defined criteria;
4) software items defined by the integration strategy are produced;
5) results of integration testing are recorded;
6) consistency and traceability are established between software design and software items; and
7) a regression strategy is developed and applied for re-verifying software items when a change in software units
(including associated requirements, design and code) occur.
F.1.3.8 Software testing
Purpose:
The purpose of Software testing is to confirm that the integrated software product meets its defined requirements.
Outcomes:
As a result of successful implementation of Software testing:
1) criteria for the integrated software is developed that demonstrates compliance with the software requirements;
© ISO/IEC 2002 – All rights reserved 13

ISO/IEC 12207:1995/Amd.1:2002(E)
2) integrated software is verified using the defined criteria;
3) test results are recorded; and
4) a regression strategy is developed and applied for re-testing the integrated software when a change in
software items is made.
F.1.3.9 System integration
Purpose:
The purpose of System integration is to integrate the system elements (including software items, hardware items,
manual operations, and other systems, as necessary) to produce a complete system that will satisfy the system
design and the customers’ expectations expressed in the system requirements.
Outcomes:
As a result of successful implementation of System integration:
1) a strategy is developed to integrate the system according to the priorities of the system requirements;
2) criteria is developed to verify compliance with the system requirements allocated to the system elements,
including the interfaces between system elements;
3) the system integration is verified using the defined criteria;
4) a regression strategy is developed and applied for re-testing the system when changes are made;
5) consistency and traceability are established between the system design and the integrated system elements;
and
6) an integrated system, demonstrating compliance with the system design and validation that a complete set of
useable deliverable system elements exists, is constructed.
F.1.3.10 System testing
Purpose:
The purpose of Systems testing is to ensure that the implementation of each system requirement is tested for
compliance and that the system is ready for delivery.
Outcomes:
As a result of successful implementation of System testing :
1) criteria for the integrated system is developed that demonstrates compliance with system requirements;
2) the integrated system is verified using the defined criteria;
3) test results are recorded; and
4) a regression strategy is developed and applied for re-testing the integrated system should a change be made
to existing system elements.
F.1.3.11 Software Installation
Purpose:
The purpose of Software installation is to install the software product that meets the agreed requirements in the
target environment.
14 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Outcomes:
As a result of successful implementation Software installation:
1) a software installation strategy is developed;
2) criteria for software installation is developed that demonstrates compliance with the software installation
requirements;
3) the software product is installed in the target environment; and
4) assure that the software product is ready for use in its intended environment.
F.1.4 Operation Process
Purpose:
The purpose of the Operation Process is to operate the software product in its intended environment and to provide
support to the customers of the software product.
Outcomes:
As a result of the successful implementation of the Operation Process:
1) conditions for correct operation of the software in its intended environment are identified and evaluated;
2) the software is operated in its intended environment; and
3) assistance and consultation is provided to the customers of the software product in accordance with the
agreement.
The Operation Process includes purpose and outcomes for the following sub-processes:
• Operational Use
• Customer Support
F.1.4.1 Operational use
Purpose:
The purpose of Operational use is to ensure the correct and efficient operation of the product for the duration of its
intended usage and in its installed environment.
Outcomes:
As a result of successful implementation of Operational use:
1) operational risks for the product introduction and operation are identified and monitored;
2) the product is operated in its intended environment according to requirements; and
3) criteria for the operational use are developed that demonstrates compliance with the agreed requirements.
© ISO/IEC 2002 – All rights reserved 15

ISO/IEC 12207:1995/Amd.1:2002(E)
F.1.4.2 Customer support
Purpose:
The purpose of Customer support is to establish and maintain an acceptable level of service through assistance
and consultation to the customer to support effective use of the product.
Outcomes:
As a result of successful implementation of Customer support:
1) service needs for customer support are identified and monitored on an ongoing basis;
2) customer satisfaction with both the support services being provided and the product itself is evaluated on an
ongoing basis;
3) operational support is provided by handling customer inquiries and requests and resolving operational
problems; and
4) customer support needs are met through delivery of appropriate services.
F.1.5 Maintenance Process
Purpose:
The purpose of the Maintenance process is to modify a system/software product after delivery to correct faults,
improve performance or other attributes, or to adapt to a changed environment.
NOTE The objective is to modify and/or retire existing system/software products while preserving the integrity of
organizational operations.
Outcomes:
As a result of successful implementation of the process:
1) a maintenance strategy is developed to manage modification, migration and retirement of products according
to the release strategy;
2) the impact of changes to the existing system on organization, operations or interfaces are identified;
3) affected system/software documentation is updated as needed;
4) modified products are developed with associated tests that demonstrate that requirements are not
compromised;
5) product upgrades are migrated to the customer’s environment;
6) on request, products are retired from use in a controlled manner that minimizes disturbance to the customers;
and
7) the system/software modification is communicated to all affected parties.
F.2 Supporting Life Cycle Processes
F.2.1 Documentation Process
Purpose:
The purpose of the Documentation process is to develop and maintain the recorded software information produced
by a process.
16 © ISO/IEC 2002 – All rights reserved

ISO/IEC 12207:1995/Amd.1:2002(E)
Outcomes:
As a result of successful implementation of the Documentation process:
1) a strategy identifying the documentation to be produced during the life cycle of the software product or service
is developed;
2) the standards to be applied for the development of the software documentation are identified;
3) documentation to be produced by the process or project is identified;
4) the content and purpose of all documentation is specified, reviewed and approved;
5) documentation is developed and made available in accordance with identified standards; and
6) documentation is maintained in accordance with defined criteria.
F.2.2 Configuration Management Process
Purpose:
The purpose of the Configuration management process is to establish and maintain the integrity of all the work
products of a process or project and make them available to concerned parties.
Outcomes:
As a result of successful implementation of the Configuration management process:
1) a configuration management strategy is developed;
2) all items generated by the process or project are identified, defined and baselined;
3) modifications and releases of the items are controlled;
4) modifications and releases are made available to concerned parties;
5) the status of the items and modification requests are recorded and reported;
6) the completeness and consistency of the items is ensured; and
7) storage, handling and delivery of the ite
...