ISO/IEC/IEEE 41062:2024

International
Standard
ISO/IEC/IEEE 41062
Second edition
Software engineering — Life cycle
2024-10
processes — Software acquisition
Ingénierie du logiciel — Processus du cycle de vie — Acquisition
des logiciels
Reference number
© IEEE 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Website: www.ieee.org
Published in Switzerland
© IEEE 2024 – All rights reserved
ii
Contents Page
Foreword .vi
Introduction .viii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .4
4 Software acquisition process . 4
4.1 General .4
4.2 Purpose .5
4.3 Outcomes .5
4.4 Structure of the software acquisition process .5
4.4.1 Software acquisition sub-processes .5
4.4.2 Defining the acquisition process .6
4.4.3 Tailoring the acquisition process.7
5 Software acquisition alternatives . 8
5.1 General .8
5.2 Custom-developed software .8
5.2.1 General .8
5.2.2 Advantages of custom-developed software .9
5.2.3 Disadvantages of custom-developed software .9
5.3 Off-the-shelf (OTS) software .9
5.3.1 General .9
5.3.2 Advantages of OTS software . . .10
5.3.3 Disadvantages of OTS software .10
5.4 Software as a service (SaaS) .11
5.4.1 General .11
5.4.2 Advantages of software as a service (SaaS).11
5.4.3 Disadvantages of SaaS .11
5.5 Free and open-source software (FOSS) . 12
5.5.1 General . 12

5.5.2 Advantages of FOSS. 12
5.5.3 Disadvantages of FOSS . 13
5.6 Services . 13
6 Planning and RFP sub-process. 14
6.1 Purpose .14
6.2 Outcomes . 15
6.3 Planning the software acquisition strategy . 15
6.3.1 Develop an acquisition strategy . 15
6.3.2 Perform feasibility study .16
6.3.3 Assess and manage risk .16
6.3.4 Agile development considerations .16
6.3.5 Initiate a planning process .18
6.3.6 Develop an acquisition plan . . .19
6.3.7 Form an acquisition team .19
6.3.8 Obtain assistance with acquisition .19
6.4 Defining the acquisition and content requirements .21
6.4.1 General .21
6.4.2 Types of requirements in an RFP . 22
6.4.3 Business requirements . 22
6.4.4 Software/System requirements . 23
6.4.5 Statement of work (SOW) .24
6.4.6 Performing verification and validation of requirements .24

© IEEE 2024 – All rights reserved
iii
6.5 Identifying potential suppliers .24
6.5.1 General .24
6.5.2 Advertising the acquisition .24
6.5.3 Pre-qualification . . 25
6.5.4 Streamlined pre-qualification . 26
6.5.5 No pre-qualification . 26
6.6 Preparing contract requirements .27
6.6.1 General .27
6.6.2 Request for information (RFI) .27
6.6.3 Request for quote (RFQ) .27
6.6.4 Request for proposals (RFP) . . 28
6.6.5 Contractual requirements . 30
7 Evaluation, selection, and contracting sub-process.33
7.1 Purpose . 33
7.2 Outcomes . 35
7.3 Evaluating proposals . 35
7.3.1 Planning for proposal evaluation . 35
7.3.2 Evaluation criteria . 35
7.3.3 Establishing proposal evaluation procedures . 35
7.3.4 Alternative evaluation techniques . 38
7.3.5 Information to aid proposal evaluation . 39
7.4 Selecting the supplier . 40
7.4.1 General . 40
7.4.2 Evaluation of information not in the proposal . 40
7.4.3 Additional requested information .41
7.5 Negotiating the contract .42
7.5.1 General .42
7.5.2 Additional negotiation considerations .42
7.5.3 Informal letter of understanding (LOU) .43
7.6 Assessing and managing risk . 44
7.7 Performing verification and validation (V&V) . 44
8 Implementation and acceptance sub-process .44
8.1 Purpose . 44
8.2 Outcomes . 46
8.2.1 Outcomes of evaluating supplier performance . 46
8.2.2 Outcomes of software acceptance . 46
8.3 Implementing software or services . 46
8.4 Evaluating and accepting software and services .47
8.4.1 Developing plans to evaluate and accept software and services .47
8.4.2 Defining acceptance criteria and procedures . 48
8.4.3 Accepting the software and services . 49
8.4.4 Evaluating the process and identifying improvement opportunities . 50
8.4.5 Applying non-performance remedies . 50
9 Acquisition of operations, maintenance and support sub-process .51
9.1 Purpose .51
9.2 Outcomes . 53
9.3 Service transitions . 53
9.4 Operations . 54
9.4.1 General . 54
9.4.2 Service validation and testing . 54
9.4.3 Change evaluation and management . 54
9.4.4 Service asset and configuration management . 54
9.4.5 Continuous evaluation and improvement . 55
9.4.6 Capacity management . 55
9.4.7 Monitoring and security management . 55
9.5 Maintenance . 55
9.5.1 General . 55

© IEEE 2024 – All rights reserved
iv
9.5.2 Covered maintenance. 56
9.5.3 Maintenance quality. 56
9.6 Support . 56
9.6.1 General . 56
9.6.2 Customer support .57
10 Quality assurance for software acquisition .57
10.1 Objectives of quality assurance in software acquisition .57
10.2 Implementing quality assurance in software acquisition .57
Annex A (informative) Software acquisition considerations
............................................................................................................59
Annex B (Normative) Acquisition of software with safety-critical and information security-
critical requirements .75
Annex C (normative) Rights in technical data and software usage .79
Bibliography .80
IEEE notices and abstract .82

© IEEE 2024 – All rights reserved
v
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.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards
through a consensus development process, approved by the American National Standards Institute, which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE
administers the process and establishes rules to promote fairness in the consensus development process,
the IEEE does not independently evaluate, test, or verify the accuracy of any of the information contained in
its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 41062:2019), which has been
technically revised.
The main changes are as follows:
— the eight steps of software acquisition were replaced by four sub-processes of software acquisition;
— discussion of the various forms of requirements and their implications was expanded;
— additional attention was given to acquisitions of services;
— alternatives to traditional methods were described for identifying prospective suppliers, structuring
requests for proposals (RFPs), evaluating proposals, and negotiating contracts;
— numerous insights and tips are provided to aid in avoiding common acquisition difficulties;

© IEEE 2024 – All rights reserved
vi
— the acquisition of operations, maintenance and support services in conjunction with acquiring software
products was added.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© IEEE 2024 – All rights reserved
vii
Introduction
This document describes the management and execution of software acquisition activities and is intended for:
— individuals or organizations that acquire software or software services from external suppliers for
operational use, including software implementation, support, and operations services;
— individuals or organizations that acquire software from external suppliers for resale to other individuals
or organizations;
— individuals or organizations that influence how software and software services is acquired from
suppliers or implemented, operated, and maintained by suppliers;
— suppliers interested in providing high-quality software to acquirers.
This document is designed to help organizations and individuals:
— incorporate quality considerations during the definition, evaluation, selection, implementation,
acceptance, operation, and support of supplier software for operational use;
— specify how the external supply of software and software services should be specified, selected,
monitored, and accepted on behalf of end users.
This document is intended to satisfy the following objectives:
— enable acquirers to more effectively acquire software that economically meets their needs;
— enable external suppliers to more effectively and economically deliver software that meets acquirers’ needs;
— enable acquirers and suppliers to establish fair, understandable, suitable, and sufficient agreements for
the acquisition of software;
— promote consistency within and among organizations in acquiring software from external suppliers;
— provide guidance and useful practices for enhancing the quality of acquired software and the software
acquisition process;
— provide guidance and useful practices for evaluating and qualifying supplier capabilities to meet the
acquirer’s business and technical requirements;
— provide guidance and useful practices for evaluating, qualifying, and contracting for proposed supplier
software;
— provide guidance and useful practices for evaluating and determining acceptability of software
implemented by external suppliers;
— provide guidance and useful practices for specifying, evaluating, and controlling the acceptability of
ongoing software services provided by external suppliers.
This document can be helpful if the software acquirer and supplier are both part of the same organization.
While many of the concepts and techniques for acquiring software from external suppliers can also be
relevant for internal software development, this document is not intended to address techniques of software
development, testing, or operation.
Each organization or individual using this document can identify the specific set of activities to include
within the organization’s acquisition process, given its legal and regulatory environment, procurement
guidelines, and life cycle processes.

© IEEE 2024 – All rights reserved
viii
International Standard ISO/IEC/IEEE 41062:2024(en)
Software engineering — Life cycle processes — Software
acquisition
1 Scope
This document describes a set of useful activities, tasks, methods, and practices that acquirers of software
and related services from unrelated (external) suppliers can apply to help ensure an efficient and effective
acquisition of software or software services. These practices can be applied in competitive and in sole
source procurements, regardless of the type, size, complexity, and cost of the acquisition. The document can
be applied to software that runs on any computer system regardless of its size, complexity, or criticality. The
software supply chain can include integration of off-the-shelf (OTS), custom, software as a service (SaaS), or
open-source software. Software services can include software development and sustainment (maintenance),
integration, verification (testing) and operation. Security and safety are included as attributes to be
considered during the acquisition. However, specific requirements for acquisition of information assurance
(security), safety, and cloud services are not included.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments or corrigenda) applies.
ISO/IEC/IEEE 12207, Systems and software engineering — Software life cycle processes
ISO/IEC/IEEE 15289, Systems and software engineering — Content of life-cycle information items
(documentation)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www. iso. org/o bp
— IEC Electropedia: available at https:// www.e lectropedia. org/
— IEEE Standards Dictionary Online: available at: http:// dictionary.i eee. org
NOTE Definitions for other systems and software engineering terms typically can be found in ISO/IEC/IEEE 24765,
available at www .computer .org/ sevocab.
3.1.1
acquirer
stakeholder that acquires or procures a product or service from a supplier (3.1.19)
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or internal/
organizational sponsor.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.1]

© IEEE 2024 – All rights reserved
3.1.2
acquisition
process of obtaining a system, product or service
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.2]
3.1.3
agile development
software development approach based on iterative development, frequent inspection and adaptation, and
incremental deliveries in which requirements and solutions evolve through collaboration in cross-functional
teams and through continuous stakeholder feedback
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — "software" has been added at the beginning of the
definition.]
3.1.4
business objective
strategy designed by senior management to help ensure an organization's continued existence and enhance
its profitability, market share, and other factors influencing the organization's success
Note 1 to entry: Capability, performance level or process outcome (3.1.13) to be achieved to solve a problem, take
advantage of an opportunity, or meet a challenge and thereby provide benefit or value.
Note 2 to entry: Identifying business objective(s) is an integral part of the business or mission analysis process
described in ISO/IEC/IEEE 12207:2017, 6.4.1.
Note 3 to entry: Business objectives are not the same as business requirements (3.1.5); business objectives are
accomplished by satisfying business requirements.
[SOURCE: ISO/IEC TR 29110-5-1-4:2018, 3.5, modified — "help" has been added; notes to entry has been added.]
3.1.5
business requirement
requirement that describes in business terms what needs to be delivered or accomplished
Note 1 to entry: The business requirement is a means to achieve business objectives (3.1.4) and thereby provide value.
Note 2 to entry: A product, system, or item of software is not and does not determine the business requirements;
rather, a product, system or item of software can be used to satisfy the business requirements.
Note 3 to entry: The term “business” here is used broadly and generically, without implying a commercial venture,
and can pertain to both personal and work, for-profit and not-for-profit, and production and administrative situations.
[SOURCE: ISO 29481-1:2016, 3.4, modified — Notes to entry have been added.]
3.1.6
COTS
commercial off-the-shelf
product available for purchase and use without the need to conduct development activities
[SOURCE: ISO/IEC/IEEE 90003:2018, 3.4]
3.1.7
defect
fault or deviation from the intended level of performance of a system or software
[SOURCE: ISO/IEC 23643:2020, 3.4]
3.1.8
functional requirement
requirement that specifies a function that a system or system component performs
[SOURCE: IEEE Std 730-2014, 3.2]

© IEEE 2024 – All rights reserved
3.1.9
hazard
source or situation with a potential for harm in terms of human injury or ill health (both short and long
term), damage to property, damage to the environment, or a combination of these
[SOURCE: IEEE 7000:2021]
3.1.10
IT asset management
ITAM
coordinated activity of an organization to realize value from IT assets
[SOURCE: ISO/IEC 19770-1:2017, 3.3, modified — "IT" has been added in the term and the definition; the
abbreviated term "ITAM" has been added.]
3.1.11
non-functional requirement
any requirement for a software-intensive system or for a software product, including how it should be
developed and maintained, and how it should perform in operation, except any functional user requirement
for the software
1)
[SOURCE: ISO/IEC/IEEE 32430:— , 3.1.25, modified — The abbreviated term "NFR" has been removed.]
3.1.12
off-the-shelf
OTS
product or system already developed and available
3.1.13
process outcome
observable result of the successful achievement of the process purpose (3.1.14)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.34]
3.1.14
process purpose
high-level objective of performing the process and the likely outcomes of effective implementation of the process
Note 1 to entry: The purpose of implementing the process is to provide benefits to the stakeholders.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.35]
3.1.15
product requirement
requirement that describes how a product, system, or item of software will satisfy a business requirement
(3.1.5) and thereby provide value
3.1.16
safety
expectation that a system does not, under defined conditions, lead to a state in which human life, health,
property, or the environment is endangered
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.48]
3.1.17
software acquisition
process that begins with the decision to obtain a software product or service with the outcome of acceptance
of the software
1) Under preparation. Stage at the time of publication: ISO/IEC/IEEE PRF 32430:2024.

© IEEE 2024 – All rights reserved
3.1.18
software requirement
software capability needed by a user to solve a problem or to achieve an objective
Note 1 to entry: A software requirement is a form of product requirement (3.1.15).
3.1.19
supplier
organization or an individual that enters into an agreement with the acquirer (3.1.1) for the supply of a
product or service
Note 1 to entry: Other terms commonly used for supplier are contractor, producer, seller, or vendor.
Note 2 to entry: The acquirer and the supplier sometimes are part of the same organization.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.60]
3.1.20
technical requirement
requirement relating to the technology and environment for the development, maintenance, support and
execution of the software
3.2 Abbreviated terms
FOSS free and open-source software
LOU letter of understanding
MOU memo of understanding
NDA non-disclosure agreement
QA quality assurance
RFI request for information
RFQ request for quote
RFP request for proposal
RPP request for prototype proposals
SaaS software as a service
SLA service level agreement
SOI system of interest
SOW statement of work
T&M time and materials
V&V verification and validation
4 Software acquisition process
4.1 General
The acquirer shall perform software acquisition as specified in the process outcomes, activities, and tasks
of the acquisition process required in ISO/IEC/IEEE 12207, with additional requirements as specified in

© IEEE 2024 – All rights reserved
Clauses 6 through 10 and Annexes B and C. Information items (output) shall conform to the required content
of ISO/IEC/IEEE 15289.
For convenience in this document, requirements quoted from these normative standards are shown in boxes.
Quoted requirements include the acquisition process purpose, outcomes, activities and tasks.
4.2 Purpose
The purpose of the Acquisition process is to obtain a product or service in accordance with the acquirer’s
requirements
[ISO/IEC/IEEE 12207:2017, 6.1.1.1]
This document applies primarily to the software acquisition process, for the acquisition of software products
and services from external suppliers.
4.3 Outcomes
The following outcomes shall apply to the acquisition of software and software-related services:
a) A request for supply is prepared.
b) One or more suitable suppliers are selected.
c) An agreement is established between the acquirer and supplier.
d) A product or service complying with the agreement is accepted.
e) Acquirer obligations defined in the agreement are satisfied.
[ISO/IEC/IEEE 12207:2017, 6.1.1.2]
Operation and maintenance of the supplied software or consumption of the supplied services consistent
with the contract are examples of delivered software and services. Some or all of such activities can be
performed by the acquirer, by the supplier of the acquired software and services, or by a subsequently and
separately engaged third-party supplier.
4.4 Structure of the software acquisition process
4.4.1 Software acquisition sub-processes
The software acquisition process consists of four major sub-processes within which relevant activities may
be performed in a more flexible, less sequential manner:
a) planning and request for proposals (RFP);
b) evaluation, selection, and contracting;
c) implementation and acceptance;
d) acquisition of operations, maintenance, and support.
NOTE 1 The acquisition of operations, maintenance, and support sub-process pertain only to essentially an
additional acquisition of such services in conjunction with acquisition of an executable software product to which
such services pertain. Operations, maintenance, and support services that are obtained in their own right separately
from acquiring the executable software product(s) to which the services pertain are treated like any acquisition of
software services and are not addressed in the associated operations, maintenance, and support sub-process.
Each sub-process includes its purpose, outcomes, and activities and tasks in addition to activities for
security, risk management, process improvement, and verification and validation (V&V).
Figure 1 illustrates the four sub-processes of the software acquisition process, along with supporting life
cycle processes.
© IEEE 2024 – All rights reserved
Key
activity
optional activity
QA activity
relationship
Figure 1 — Software acquisition sub-processes
Table 1 illustrates the alignment of the four sub-processes described in this clause to ISO/IEC/IEEE 12207.
Table 1 — Alignment with the acquisition activities in ISO/IEC/IEEE 12207
ISO/IEC/IEEE 12207 acquisition activities Sub-processes in this document
a)  Prepare for the acquisition Planning and RFP
b)  Advertise the acquisition and select the supplier
Evaluation, selection and contracting
c)  Establish and maintain an agreement
d)  Monitor the agreement
Implementation and acceptance
e)  Accept the product or service
a)  Prepare for the acquisition
b)  Advertise the acquisition an
...