ISO/IEC TR 15504-2:1998

Information technology - Software process assessment - Part 2: A reference model for processes and process capability

Technologies de l'information — Évaluation des procédés du logiciel — Partie 2: Modèle de référence pour les processus et l'aptitude de processus

General Information

• Status: Withdrawn
• Publication Date: 26-Aug-1998
• Withdrawal Date: 26-Aug-1998
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 10 - Process assessment
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 28-Oct-2003
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15504-2:2003 - Information technology - Process assessment - Part 2: Performing an assessment
• Effective Date: 15-Apr-2008

Standards Content (Sample)

TECHNICAL ISO/IEC
REPORT TR 15504-2
First edition
1998-08-15
Information technology — Software process
assessment —
Part 2:
A reference model for processes and process
capability
Technologies de l’information — Évaluation des procédés du logiciel —
Partie 2: Un modèle de référence pour les procédés et l’aptitude de procédé
Reference number
B C
Contents
1 Scope .1
2 Normative references .1
3 Terms and definitions.2
4 Structure of the reference model .3
4.1 Process dimension .3
4.2 Process capability dimension.3
5 The process dimension.5
5.1 Primary life cycle processes.7
5.1.1 Customer-Supplier process category (CUS).7
5.1.2 Engineering process category (ENG) .10
5.2 Supporting life cycle processes.14
5.2.1 Support process category (SUP).14
5.3 Organizational life cycle processes .17
5.3.1 Management process category (MAN).17
5.3.2 Organization process category (ORG).19
6 The capability dimension .23
6.1 Level 0: Incomplete process.24
6.2 Level 1: Performed process.24
6.2.1 PA 1.1 Process performance attribute.24
6.3 Level 2: Managed process .24
6.3.1 PA 2.1 Performance management attribute .24
6.3.2 PA 2.2 Work product management attribute.24
© ISO/IEC 1998
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 micro-
film, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
© ISO/IEC
6.4 Level 3: Established process. 24
6.4.1 PA 3.1 Process definition attribute . 25
6.4.2 PA 3.2 Process resource attribute . 25
6.5 Level 4: Predictable process . 25
6.5.1 PA 4.1 Measurement attribute . 25
6.5.2 PA 4.2 Process control attribute . 25
6.6 Level 5: Optimizing process . 26
6.6.1 PA 5.1 Process change attribute. 26
6.6.2 PA 5.2 Continuous improvement attribute. 26
6.7 Rating process attributes. 26
6.7.1 Process attribute rating scale. 26
6.7.2 Process attribute rating scale calibration . 26
6.7.3 Process attribute ratings. 27
6.7.4 Referencing of process attribute ratings . 27
6.8 Process capability level model. 27
6.8.1 Achievement of process capability levels. 27
7 Compatibility with the reference model. 28
7.1 Introduction. 28
7.2 Model purpose . 28
7.3 Model scope . 28
7.4 Model elements and indicators . 29
7.5 Mapping . 29
7.6 Translation. 29
Annex A (informative) Mapping of ISO/IEC 12207 to the reference model. 30
Annex B (informative) Process and process attribute tables . 34
Annex C (informative) Style guide for defining processes . 37
iii
© ISO/IEC
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.
The main task of technical committees is to prepare International Standards, but in exceptional circumstances a
technical committee may propose the publication of a Technical Report of one of the following types:
— type 1, when the required support cannot be obtained for the publication of an International Standard, despite
repeated efforts;
— type 2, when the subject is still under technical development or where for any other reason there is the future
but not immediate possibility of an agreement on an International Standard;
— type 3, when a technical committee has collected data of a different kind from that which is normally published
as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they
can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to be
reviewed until the data they provide are considered to be no longer valid or useful.
ISO/IEC TR 15504-2, which is a Technical Report of type 2, was prepared by Joint Technical Committee ISO/IEC
JTC 1, Information technology, Subcommittee SC 7, Software engineering.
ISO/IEC TR 15504 consists of the following parts, under the general title Information technology — Software
process assessment :
 Part 1: Concepts and introductory guide
 Part 2: A reference model for processes and process capability
 Part 3: Performing an assessment

Part 4: Guide to performing assessments
 Part 5: An assessment model and indicator guidance
 Part 6: Guide to competency of assessors
 Part 7: Guide for use in process improvement
 Part 8: Guide for use in determining supplier process capability
 Part 9: Vocabulary
Annexes A to C of this part of ISO/IEC TR 15504 are for information only.
iv
© ISO/IEC
Introduction
This part of ISO/IEC TR 15504 documents the set of universal software engineering processes that are
fundamental to good software engineering and that cover best practice activities, providing a reference model which
can be used by the other parts of ISO/IEC TR 15504. The reference model describes processes that an
organization may perform to acquire, supply, develop, operate, evolve and support software, and the process
attributes that characterize the capability of those processes. In performing a process assessment, an assessor
uses a model(s) of the processes being assessed that is compatible with this reference model, so that a common
basis for judgment is employed. This document also describes the requirements that an assessment model(s)
needs to address to be compatible with the reference model.
The purpose of the reference model is to provide a common basis for different models and methods for software
process assessment, ensuring that results of assessments can be reported in a common context. The use of
models compatible with the reference model will ensure a common context for the reporting of assessment ratings.
The use of a common reference model forms a basis on which assessments can be compared.
The reference model architecture is two dimensional. The first dimension is the process dimension which is
characterized by a set of purpose statements. The process purpose statements describe in measurable terms what
has to be achieved in order to attain the defined purpose of the process. The processes have been defined in
alignment with ISO/IEC 12207:1995, Information technology - Software life cycle processes. The second dimension
is the process capability dimension which characterizes the level of capability that an organization unit has attained
for a particular process, or which may be used by the organization unit as a target to be attained.
Within this part of the ISO/IEC TR 15504:
 clause 4, titled “Structure of the reference model”, provides a detailed description of the structure and key
components of the reference model;
 clause 5, titled “The process dimension”, categorizes life cycle processes into groups of process categories
and then describes each process in terms of its purpose;
 clause 6, titled “The capability dimension”, defines the capability levels and process attributes that describe the
capability of the processes listed in clause 5;
 clause 7, titled “Compatibility with the reference model”, contains the requirements for demonstrating that a
model of software processes and process capability is compatible with this reference model;
 annex A contains a detailed mapping of the ISO/IEC 12207 to ISO/IEC TR 15504 processes;
 annex B contains summary lists of the processes and the process attributes that comprise the reference model;
 annex C contains a style guide for defining additional processes.
v
©
TECHNICAL REPORT  ISO/IEC ISO/IEC TR 15504-2:1998(E)
Information technology — Software process assessment —
Part 2:
A reference model for processes and process capability
1 Scope
This part of ISO/IEC TR 15504 defines a reference model for software processes and process capability that forms
the basis for software process assessment. The reference model defines at a high level, the fundamental
objectives that are essential to good software engineering. The high-level objectives describe what is to be
achieved, not how to achieve them.
This reference model is applicable to any software organization wishing to establish and subsequently improve its
capabilities in the acquisition, supply, development, operation, evolution and support of software. The model does
not presume particular organizational structures, management philosophies, software life cycle models, software
technologies, or development methodologies.
The architecture of this reference model organizes the processes to help software personnel understand and use
them for continuous improvement of the management of software processes.
For software process assessment, an assessor uses a more detailed model(s) compatible with this reference
model, containing a comprehensive set of indicators of process performance and process capability, to make
judgments about the capability of the organization’s processes. This part of ISO/IEC TR 15504 specifies the
requirements to be met in order for a model(s) to be compatible with the reference model.
ISO/IEC TR 15504 is not intended to be used in any scheme for the certification/registration of the process
capability of an organization.
Table 1 shows the main audiences for this part of ISO/IEC TR 15504, why each group needs the reference model,
and how and when it will be used.
NOTE Copyright release for the Reference Model: Users of this part of ISO/IEC TR 15504 may freely reproduce the
detailed descriptions contained in the reference model as part of any Assessment Model based upon the reference model, or
as part of any demonstration of compatibility with this reference model, so that it can be used for its intended purpose.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC TR 15504. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC TR 15504 are encouraged
to investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO 9001:1994, Quality systems — Model for quality assurance in design, development, production, installation and
servicing.
ISO/IEC 12207:1995, Information technology — Software life cycle processes.
ISO/IEC TR 15504-9:1998, Information technology — Software process assessment — Part 9: Vocabulary.
© ISO/IEC
Table 1 — Use of this reference model
Who Why How When
Assessment
Develop models compatible As a reference for the structure of During the development of a
Model with the reference model the model model
Developers
Demonstrate compatibility of As a set of criteria for demonstration Following development, and prior
a developed model with the of capability to use in conducting assessments
reference model
Software
Understand what to do to As a working guide to management During the implementation of the
organization
improve software processes about software processes and organization’s software processes
capabilities to implement
As a reference guide to highlight During the development/review of
process and process capability the organization’s software
considerations processes and as a part of
continuous improvement activities
As a training document During the development/review of
the organization’s software
processes and as a part of
continuous improvement activities
Determine the capability of As a reference framework to permit As an internal initiative for
its processes for a valid basis for comparison marketing actions
demonstration to customers
During response to call for
proposal
Understand which As a process and process capability Prior to an assessment
processes and capabilities checklist
an assessor may evaluate
Software Conduct a conformant As a process and process capability Prior to and during a software
process software process checklist & develop the knowledge process assessment
assessors assessment of an of the reference model
organization
Establish compatibility of an As a reference for the purpose of Prior to an assessment or
assessment model performing model compatibility assessment program
Tool Develop a software process As a reference for and requirements Prior to and during the
Developers assessment tool of an assessment tool development of an assessment
tool
3 Terms and definitions
For the purposes of this part of ISO/IEC TR 15504, the terms and definitions given in ISO/IEC TR 15504-9 apply.
© ISO/IEC
4 Structure of the reference model
The reference model architecture is made up of two dimensions:
 the process dimension, which is characterized by process purpose statements which are the essential
measurable objectives of a process;
 the process capability dimension, which is characterized by a series of process attributes, applicable to any
process, which represent measurable characteristics necessary to manage a process and improve its
capability to perform.
4.1 Process dimension
The reference model groups the processes in the process dimension into three life cycle process groupings which
contain five process categories, according to the type of activity they address.
The Primary life cycle processes consist of the process categories Customer-Supplier and Engineering and are
described as follows:
The Customer-Supplier process category consists of processes that directly impact the customer, support
development and transition of the software to the customer, and provide for the correct operation and use of
the software product and/or service.
The Engineering process category consists of processes that directly specify, implement, or maintain the
software product, its relation to the system and its customer documentation.
The Supporting life cycle processes consist of the process category Support and this category is described as
follows:
The Support process category consists of processes which may be employed by any of the other
processes (including other supporting processes) at various points in the software life cycle.
The Organizational life cycle processes consist of the process categories Management and Organization and
are described as follows:
The Management process category consists of processes which contain practices of a generic nature
which may be used by anyone who manages any type of project or process within a software life cycle.
The Organization process category consists of processes that establish the business goals of the
organization and develop process, product, and resource assets which, when used by the projects in the
organization, will help the organization achieve its business goals.
Process categories and processes provide a grouping by type of activity. Each process in the reference model is
described in terms of a purpose statement. These statements comprise the unique functional objectives of the
process when instantiated in a particular environment. The purpose statement includes additional material
identifying the outcomes of successful implementation of the process. Satisfying the purpose of a process
represents the first step in building process capability.
The reference model does not define how, or in what order, the elements of the process purpose statements are to
be achieved. The process purposes will be achieved in an organization through various detailed activities, tasks
and practices being carried out to produce work products. These performed tasks, activities and practices, and the
characteristics of the work products produced, are the indicators that demonstrate whether the specific process
purpose is being achieved.
4.2 Process capability dimension
Evolving process capability is expressed in terms of process attributes grouped into capability levels. Process
attributes are features of a process that can be evaluated on a scale of achievement, providing a measure of the
capability of the process. They are applicable to all processes. Each process attribute describes a facet of the
© ISO/IEC
overall capability of managing and improving the effectiveness of a process in achieving its purpose and
contributing to the business goals of the organization.
A capability level is characterized by a set of attribute(s) that work together to provide a major enhancement in the
capability to perform a process. Each level provides a major enhancement of capability in the performance of a
process. The levels constitute a rational way of progressing through improvement of the capability of any process.
There are six capability levels in the reference model.
Level 0: Incomplete.
There is general failure to attain the purpose of the process. There are few or no easily identifiable work
products or outputs of the process.
Level 1: Performed.
The purpose of the process is generally achieved. The achievement may not be rigorously planned and
tracked. Individuals within the organization recognize that an action should be performed, and there is
general agreement that this action is performed as and when required. There are identifiable work products
for the process, and these testify to the achievement of the purpose.
Level 2: Managed.
The process delivers work products according to specified procedures and is planned and tracked. Work
products conform to specified standards and requirements. The primary distinction from the Performed
Level is that the performance of the process now delivers work products that fulfil expressed quality
requirements within defined timescales and resource needs.
Level 3: Established.
The process is performed and managed using a defined process based upon good software engineering
principles. Individual implementations of the process use approved, tailored versions of standard,
documented processes to achieve the process outcomes. The resources necessary to establish the
process definition are also in place. The primary distinction from the Managed Level is that the process of
the Established Level is using a defined process that is capable of achieving its process outcomes.
Level 4: Predictable.
The defined process is performed consistently in practice within defined control limits, to achieve its defined
process goals. Detailed measures of performance are collected and analyzed. This leads to a quantitative
understanding of process capability and an improved ability to predict and manage performance.
Performance is quantitatively managed. The quality of work products is quantitatively known. The primary
distinction from the Established Level is that the defined process is now performed consistently within
defined limits to achieve its process outcomes.
Level 5: Optimizing.
Performance of the process is optimized to meet current and future business needs, and the process
achieves repeatability in meeting its defined business goals. Quantitative process effectiveness and
efficiency goals (targets) for performance are established, based on the business goals of the organization.
Continuous process monitoring against these goals is enabled by obtaining quantitative feedback and
improvement is achieved by analysis of the results. Optimizing a process involves piloting innovative ideas
and technologies and changing non-effective processes to meet defined goals or objectives. The primary
distinction from the Predictable Level is that the defined and standard processes now dynamically change
and adapt to effectively meet current and future business goals.
The reference model alone cannot be used as the basis for conducting reliable and consistent assessments of
process capability since the level of detail is not sufficient. The descriptions of process purpose and capability
attributes in the reference model need to be supported with a comprehensive set of indicators of process
© ISO/IEC
performance and capability. In this way, consistent ratings of process capability will be possible. An exemplar
model that incorporates such a set of indicators is provided as ISO/IEC TR 15504-5. Clause 7 of this part of
ISO/IEC TR 15504 sets out the requirements to be met by other process assessment models to be compatible with
this reference model.
5 The process dimension
This clause provides a classification of the processes normally undertaken by organizations concerned with the
development, maintenance, acquisition, supply and operation of software. The classification recognizes five
process categories each of which contains a number of processes. The process categories and processes are
strongly aligned with those defined in ISO/IEC 12207, Information technology - Software life cycle processes (refer
to Annex A for a mapping of 15504 to ISO/IEC 12207) but some additional processes not included in
ISO/IEC 12207 are introduced.
Figure 1 provides an overview of the structure of the process dimension. It shows the three principal groupings of
life cycle processes - primary, supporting and organizational - as defined in ISO/IEC 12207, and shows the process
categories and processes within each grouping. Figure 1 is designed in a similar fashion to Figure 1 in
ISO/IEC 12207, so that the similarities and differences between the two models are apparent. In particular, the
linkage between the Supporting Processes concerned with Quality Assurance and Quality Control can be seen.
Primary life cycle processes Supporting life cycle processes
SUP.1 Documentation
CUS.1 Acquisition CUS.2 Supply
Acquisition preparation
SUP.2 Configuration management
Supplier selection
Supplier monitoring
CUS.4 Operation
Customer acceptance
SUP.3 Quality assurance
Operational use
Customer support
CUS.3
SUP.4 Verification
Requirements elicitation
SUP.5 Validation
ENG.1 Development
System requirements Software construction SUP.6 Joint review
analysis and design
Software integration
Software requirements
Software testing
SUP.7 Audit
analysis
System integration and
Software design
testing
SUP.8 Problem resolution
ENG.2 System and softw are maintenance
Organizational life cycle processes
ORG.1 Organizational alignment
MAN.1 Management
ORG.2 Improvement
Process establishment
Process assessment
MAN.2 Project management
Process improvement
MAN.3 Quality management
ORG.3 Human resource management
MAN.4 Risk management
ORG.4 Infrastructure
ORG.5 Measurement
ORG.6 Reuse
Figure 1 — The processes in the Process Dimension
© ISO/IEC
The principal difference evident from Figure 1 is the presence in this reference model of a number of additional
processes and the definition of two levels of process definition. The details of the differences are further described
later in this clause. A complete list of the process categories and processes in the model is provided in Annex B.
The three life cycle process groupings are:
The Primary life cycle processes consisting of the process categories Engineering and Customer-
Supplier.
The Supporting life cycle processes consisting of the process category Support.
The Organization life cycle processes consisting of the process categories Management and
Organization.
The five process categories are:
CUS Customer-Supplier MAN Management
ENG Engineering ORG Organization
SUP Support
The description of each process category includes a characterization of the processes it contains, followed by a list
of the process names.
The individual processes are described in terms of six components:
Process Identifier This identifies the process category and the sequential number within that category. The
numbering scheme distinguishes between top-level processes and second-level
processes. The identifier consists of two parts: a process category abbreviation (e.g. ENG
for the Engineering process category) and a number (e.g. CUS.1 denotes the Acquisition
process and CUS.1.2 denotes the Supplier Selection Process, a second level process
which is a component process of the Acquisition Process).
Process Name A descriptive phrase that encapsulates the principal concern of the process (e.g. Supplier
Selection).
There are five types of process. 3 top-level (basic, extended and new) and 2 second-level
Process Type
(component and extended component), and these are as follows:
1. Processes identical in intent to the processes in ISO/IEC 12207;
Basic
2. Processes that are expansions of ISO/IEC 12207 processes;
Extended
3. Processes that are outside the scope of ISO/IEC 12207;
New
4. Processes (a group of one or more ISO/IEC 12207’s activities from the
Component
same process);
5. Processes that are one or more of ISO/IEC 12207’s activities from
Extended Component
the same process, with additional material. These would normally be Component
Processes of Extended Processes.
Process Purpose A paragraph that states the purpose of the process indicating at a high level the overall
objectives of performing the process. Optionally an additional paragraph may be included
to further define the purpose statement.
Process Outcomes A process outcome is an observable result of the successful implementation of a process.
The process outcomes for each process are contained in a list which appears in the
description of each process immediately after the phrase, “As a result of successful
implementation of the process:”
© ISO/IEC
Process Notes An optional list of informative notes regarding the process and its relation to other
processes.
The style guide in Annex C provides guidelines which may be used when extending process definitions or defining
new processes.
5.1 Primary life cycle processes
The Primary life cycle processes consist of two process categories:
CUS Customer-Supplier
ENG Engineering
5.1.1 Customer-Supplier process category (CUS)
The Customer-Supplier process category consists of processes that directly impact the customer, support
development and transition of the software to the customer, and provide for the correct operation and use of the
software product and/or service.
The processes belonging to the Customer-Supplier process category are:
CUS.1 Acquisition Process
CUS.1.1 Acquisition Preparation Process
CUS.1.2 Supplier Selection Process
CUS.1.3 Supplier Monitoring Process
CUS.1.4 Customer Acceptance Process
CUS.2 Supply Process
CUS.3 Requirements Elicitation Process
CUS.4 Operation Process
CUS.4.1 Operational Use Process
CUS.4.2 Customer Support Process
5.1.1.1 CUS.1 Acquisition process
Basic process
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. As a result of successful implementation of the process:
 acquisition needs, goals, acceptance criteria and acquisition strategies will be defined;
 a contract will be developed that clearly expresses the expectation, responsibilities and liabilities of both the
customer and the supplier;
 a product and/or service will be produced that satisfies the customer’s stated need;
 the acquisition will be monitored so that specified constraints such as cost, schedule and quality are met;
 supplier deliverables will be accepted.
© ISO/IEC
5.1.1.2 CUS.1.1 Acquisition preparation process
Component process of CUS.1 - Acquisition process
The purpose of the Acquisition preparation process is to establish the needs and goals of the acquisition. As a
result of successful implementation of the process:
the concept or the need to acquire, develop, or enhance a system, software product, or software process will

be established;
 the customer’s software and/or system requirements will be produced;
 an acquisition strategy will be developed;
 acceptance criteria will be defined.
5.1.1.3 CUS.1.2 Supplier selection process
Component process of CUS.1 - Acquisition process
The purpose of the Supplier selection process is to choose the organization that will be responsible for the
implementation of the project identified in CUS.1.1. As a result of successful implementation of the process:
 the acquisition requirements (e.g. request for proposal) will be produced;
 the supplier will be selected based upon the evaluation of the supplier’s proposals;
 a contract will be established and negotiated between the customer and the supplier.
5.1.1.4 CUS.1.3 Supplier monitoring process
Component process of CUS.1 - Acquisition process
The purpose of the Supplier monitoring process is to monitor the supplier's activities during the development of the
software product and/or service. As a result of successful implementation of the process:
 joint activities between the customer and the supplier will be performed as needed;
 information on technical progress will be exchanged regularly with the supplier;
 performance of the supplier will be monitored against the agreed requirements.
5.1.1.5 CUS.1.4 Customer acceptance process
Component process of CUS.1 - Acquisition process
The purpose of the Customer acceptance process is to approve the supplier's deliverable when all acceptance
conditions are satisfied. As a result of successful implementation of the process:
 acceptance will be based on the acquisition strategy and conducted according to the agreed acceptance
criteria;
 the delivered software product and/or service will be evaluated with regard to the agreed requirements.
5.1.1.6 CUS.2 Supply process
Basic process
The purpose of the Supply process is to provide software to the customer that meets the agreed requirements. As a
result of successful implementation of the process:
© ISO/IEC
 a response to customer's request will be produced;
 a contract will be established between the customer and the supplier for developing, packaging, delivering, and
installing the software product and/or service;
 a software product and/or service that meets the agreed requirements will be developed by the supplier;
 the software product and/or service will be delivered to the customer and installed in accordance with the
agreed requirements.
5.1.1.7 CUS.3 Requirements elicitation process
New process
The purpose of the Requirements elicitation process is to gather, process, and track evolving customer needs and
requirements throughout the life of the software product and/or service so as to establish a requirements baseline
that serves as the basis for defining the needed software work products. As a result of successful implementation
of the process:
 continuing communication with the customer will be established;
 agreed customer requirements will be defined;
 a mechanism will be established to incorporate new customer requirements into the established requirements
baseline;
 a mechanism will be established for continuous monitoring of customer needs;
 a mechanism will be established for ensuring that customers can easily determine the status and disposition of
their requests;
 enhancements arising from changing technology and customer needs will be identified and their impact
managed.
5.1.1.8 CUS.4 Operation process
Extended process
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. As a result of successful implementation of the process:
 correct operation of the software in its intended environment will be evaluated;
 the software will be operated in its intended environment;
assistance and consultation will be provided to the customers of the software product.

5.1.1.9 CUS.4.1 Operational use process
Extended component process of CUS.4 - Operation process
The purpose of the Operational use process is to ensure the correct and efficient operation of the software product
for the duration of its intended usage and in its installed environment. As a result of successful implementation of
the process:
 operational risks for the software introduction and operation will be identified and monitored;
 the software will be operated in its intended environment according to requirements;
 assurance will be provided that software capacities are adequate to meet customer needs.
© ISO/IEC
5.1.1.10 CUS.4.2 Customer support process
Extended component process of CUS.4 - Operation process
The purpose of the Customer support process is to establish and maintain an acceptable level of service to the
customer to support effective use of the software product. Assistance and consultation to the customer is provided
as requested to support the operation of the software product. As a result of successful implementation of the
process:
 customer support service needs will be identified and monitored on an ongoing basis;
 customer satisfaction with both the support services being provided and the product itself will be evaluated on
an ongoing basis;
 operational support will be provided by resolving operational problems and handling customer inquiries and
requests;
 customer needs will be met through delivery of appropriate services.
5.1.2 Engineering process category (ENG)
The consists of processes that directly specify, implement or maintain the software
Engineering process category
product, its relation to the system and its customer documentation. In circumstances where the system is
composed totally of software, the Engineering processes deal only with the construction and maintenance of such
software.
The processes belonging to the Engineering process category are:
ENG.1 Development process
ENG.1.1 System requirements analysis and design process
ENG.1.2 Software requirements analysis process
ENG.1.3 Software design process
ENG.1.4 Software construction process
ENG.1.5 Software integration process
ENG.1.6 Software testing process
ENG.1.7 System integration and testing process
ENG.2 System and software maintenance process
5.1.2.1 ENG.1 Development process
Basic process
The purpose of the Development process is to transform a set of requirements into a functional software product or
software-based system that meets the customer’s stated needs. As a result of successful implementation of the
process:
 a software product or software-based system will be developed;
 intermediate work products will be developed that demonstrate that the end product is based upon the
requirements;
 consistency will be established between requirements and designs;
© ISO/IEC
 evidence (for example, testing evidence) will be provided that demonstrates that the end product meets the
requirements;
 the end product will be installed in the target operating environment and accepted by the customer.
NOTE The requirements may be provided by operation of the Acquisition process, (CUS.1) or the Requirements elicitation
process (CUS.3).
5.1.2.2 ENG.1.1 System requirements analysis and design process
Component process of ENG.1 - Development process
The purpose of the System requirements analysis and design process is to establish the system requirements
(functional and non-functional) and architecture, identifying which system requirements should be allocated to which
elements of the system and to which releases. As a result of successful implementation of the process:
 requirements of the system will be developed that match the customer's stated needs;
 a solution will be proposed that identifies the main elements of the system;
 the requirements will be allocated to each of the main elements of the system;
 a release strategy will be developed that defines the priority for implementing system requirements;
 the system requirements will be approved and updated as needed;
 the requirements, proposed solution, and their relationships will be communicated to all affected parties.
5.1.2.3 ENG.1.2 Software requirements analysis process
Component process of ENG.1 - Development process
The purpose of the Software requirements analysis process is to establish the requirements of the software
components of the system. As a result of successful implementation of the process:
 the requirements allocated to software components of the system and their interfaces will be defined to match
the customer's stated needs;
analyzed, correct, and testable software requirements will be developed;

 the impact of software requirements on the operating environment will be understood;
 a software release strategy will be developed that defines the priority for implementing software requirements;
 the software requirements will be approved and updated as needed;
 consistency will be established between system requirements and design and software requirements;
 the software requirements will be communicated to all affected parties.
5.1.2.4 ENG.1.3 Software design process
Component process of ENG.1 - Development process
The purpose of the Software design process is to define a design for the software that implements the requirements
and can be tested against them. As a result of successful implementation of the process:
 an architectural design will be developed that describes the major software components that will implement the
software requirements;
 internal and external interfaces of each software component will be defined;
© ISO/IEC
 a detailed design will be developed that describes software units that can be built and tested;
 consistency will be established between software requirements and software designs.
5.1.2.5 ENG.1.4 Software construction process
Component process of ENG.1 - Development process
The purpose of the Software construction process is to produce executable software units and to verify that they
properly reflect the software design. As a result of successful implementation of the process:
 verification criteria will be defined for all software units against their requirements;
 software units defined by the design will be produced;
 consistency will be established between
...