ISO/IEC/IEEE 41062:2019

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2019-02
Software engineering —
Recommended practice for software
acquisition
Ingénierie du logiciel — Pratique recommandée pour l'acquisition des
logiciels
Reference number
©
IEEE 2016
© IEEE 2016
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 either ISO or IEEE at
the respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© IEEE 2016 – All rights reserved
ii
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 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 ISO documents should be noted (see www.iso.org/directives).
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.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
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.
ISO/IEC/IEEE 41062 was prepared by the Software & Systems Engineering Standards Committee of
the IEEE Computer Society (as IEEE Std 1062‐2015) and drafted in accordance with its editorial
rules. It was adopted, under the “fast‐track procedure” defined in the Partner Standards
Development Organization cooperation agreement between ISO and IEEE, by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems
engineering.
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.
© IEEE 2016 – All rights reserved
iii
IEEE Std 1062™-2015
(Revision of
IEEE Std 1062-1993)
IEEE Recommended Practice for
Software Acquisition
Sponsor
Software & Systems Engineering Standards (C/S2ESC) Committee
of the
IEEE Computer Society
Approved 5 December 2015
IEEE-SA Standards Board
Abstract: A set of useful quality considerations that can be selected and applied during one or
more steps in a software acquisition process is described in this recommended practice. The
recommended practices can be applied to software that runs on any computer system regardless
of the size, complexity, or criticality of the software. The software supply chain may include
integration of off-the-shelf (OTS), custom, or free and open source software (FOSS). Each
organization or individual using this recommended practice will need to identify the specific quality
and activities that need to be included within its acquisition process.
Keywords: acquirer, custom developed, end user, FOSS, IEEE 1062™, off-the-shelf, OTS,
SaaS, software acquisition process, software as a service, supplier
•
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 26 February 2016. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics
Engineers, Incorporated.
PDF: ISBN 978-1-5044-0085-5 STD20506
Print: ISBN 978-1-5044-0086-2 STDPD20506
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
iv
© IEEE 2016 – All rights reserved

Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These
notices and disclaimers, or a reference to this page, appear in all standards and may be found under the
heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Standards
Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a
consensus development process, approved by the American National Standards Institute (“ANSI”), which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and participate without compensation from IEEE.
While IEEE administers the process and establishes rules to promote fairness in the consensus development
process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the
soundness of any judgments contained in its standards.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness
of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort.
IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related
to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved
and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his
or her own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given
IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event
that an IEEE standard is translated, only the English version published by IEEE should be considered the
approved IEEE standard.
v
© IEEE 2016 – All rights reserved

Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that his or her views should be considered the personal views of that individual rather than the
formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and
Standards Coordinating Committees are not able to provide an instant response to comments or questions
except in those cases where the matter has previously been addressed. For the same reason, IEEE does not
respond to interpretation requests. Any person who would like to participate in revisions to an IEEE
standard is welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, IEEE does not waive any rights in copyright to the
documents.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual,
non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance
Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission
to photocopy portions of any individual standard for educational classroom use can also be obtained
through the Copyright Clearance Center.

vi
© IEEE 2016 – All rights reserved

Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten
years old and has not undergone a revision process, it is reasonable to conclude that its contents, although
still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to
determine that they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at
http://ieeexplore.ieee.org/xpl/standards.jsp or contact IEEE at the address listed previously. For more
information about the IEEE SA or IEEE’s standards development process, visit the IEEE-SA Website at
http://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL:
http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to
the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant
has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without
compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of
any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely
their own responsibility. Further information may be obtained from the IEEE Standards Association.

vii
© IEEE 2016 – All rights reserved

Participants
At the time this IEEE recommended practice was completed, the RP of the Software Acquisition Working
Group had the following membership:
Marcus Hervey, Chair
Paul Bishop, Vice Chair
Philip Bernick, Secretary
Angela Anuszewski Leslie Holloway Zvikomborero Murahwi
Taohong Chang Thomas Howard Lori Naiberg-Olson
Milton Concepcion Kathleen Kaplan Annette Reilly
Steve Cropper Ronald Kohl Alberto Sampaio
Suellen Eslinger Dana Kusumo Rob Schaaf
Michael George Mario Lozano Mike Smith
Guy Goodwin Linda Martinez Joan Williamson
Jay Griesser Winifred Menezes Sharon Young
The following members of the individual balloting committee voted on this recommended practice.
Balloters may have voted for approval, disapproval, or abstention.
Johann Amsenga Mark Henley Bartien Sayogo
Bakul Banerjee Richard Hilliard Robert Schaaf
Pieter Botman Werner Hoelzl Hans Schaefer
Susan Burgess Bernard Homes Maud Schlich
Juan Carreon Noriyuki Ikeuchi Carl Singer
Sue Carroll Atsushi Ito Michael Smith
Suresh Channarasappa Mark Jaeger Kendall Southwick
Keith Chow Cheryl Jones Luca Spotorno
S Claassen Adri Jovin Thomas Starai
Raul Colcher Piotr Karocki Eugene Stoudenmire
Paul Croll Yuri Khersonsky Walter Struppler
Geoffrey Darnton Thomas Kurihara Marcy Stutzman
Ronald Dean Dewitt Latimer Michael Swearingen
Sourav Dutta Claire Lohr Thomas Tullia
Andrew Fieldsend Edward Mccall John Vergis
Eva Freund James W. Moore David Walden
David Fuschi Michael Newman Michael Waterman
Gregg Giesler Olileanya Ogbonna Stephen Webb
Randall Groves Robert Peterson Jian Yu
Louis Gullo Annette Reilly Oren Yuen
John Harauz Robert Robinson Daidi Zhong
Randy Saunders
viii
© IEEE 2016 – All rights reserved

When the IEEE-SA Standards Board approved this recommended practice on 5 December 2015, it had the
following membership:
John D. Kulick, Chair
Jon Walter Rosdahl, Vice Chair
Richard H. Hulett, Past Chair
Konstantinos Karachalios, Secretary
Masayuki Ariyoshi Joseph L. Koepfinger* Stephen J. Shellhammer
Ted Burse David J. Law Adrian P. Stephens
Stephen Dukes Hung Ling Yatin Trivedi
Jean-Philippe Faure Andrew Myles Phillip Winston
J. Travis Griffith T. W. Olsen Don Wright
Gary Hoffman Glenn Parsons Yu Yuan
Michael Janezic Ronald C. Petersen Daidi Zhong
Annette D. Reilly
*Member Emeritus
ix
© IEEE 2016 – All rights reserved

Introduction
This introduction is not part of IEEE Std 1062-2015, IEEE Recommended Practice for Software Acquisition.
This introduction provides some background on the rationale used to develop this recommended practice.
This information is meant to aid in the understanding and usage of this recommended practice.
This recommended practice describes the management and execution of software acquisition activities. It is
intended for the following:
 Individuals or organizations that acquire software from suppliers
 Individuals or organizations that acquire software from a developer for resale to other individuals
or organizations
 Individuals or organizations that influence how software is acquired from suppliers
 Suppliers interested in providing high-quality software to acquirers
This recommended practice is designed to help organizations and individuals
 Incorporate quality considerations during the definition, evaluation, selection, and acceptance of
supplier software for operational use
 Determine how supplier software should be evaluated, tested, and accepted for delivery to end
users
This recommended practice is intended to satisfy the following objectives:
 Promote consistency within organizations in acquiring third-party software from software suppliers
 Provide useful practices on including quality considerations during software acquisition planning
 Provide useful practices on evaluating and qualifying supplier capabilities to meet user software
requirements
 Provide useful practices on evaluating and qualifying supplier software
 Assist individuals or organizations judging the quality of supplier software for referral to end users

x
© IEEE 2016 – All rights reserved

Contents
1. Overview . 11
1.1 Scope . 11
1.2 Purpose . 12
2. Normative references . 12
3. Definitions and terms . 13
3.1 Definitions . 13
3.2 Use of should, may, and can . 13
4. Software acquisition alternatives . 13
4.1 Introduction . 13
4.2 Custom-developed software . 14
4.3 Off-the-shelf (OTS) software. 14
4.4 Software as a service (SaaS) . 15
5. Software acquisition process . 18
5.1 Purpose . 18
5.2 Eight steps in acquiring quality software . 19
5.3 Step 1: Planning the software acquisition strategy . 22
5.4 Step 2: Defining the acquisition and software requirements . 24
5.5 Step 3: Identifying potential suppliers . 26
5.6 Step 4: Preparing contract requirements . 28
5.7 Step 5: Evaluating proposals and selecting the supplier . 30
5.8 Step 6: Managing for supplier performance . 32
5.9 Step 7: Accepting the software . 33
5.10 Step 8: Evaluating the process and identifying improvement opportunities . 34
6. Quality assurance for software acquisition . 36
6.1 Objectives of quality assurance in software acquisition . 36
6.2 Implementing quality assurance in software acquisition . 36
Annex A (informative) Checklists for quality software acquisition processes . 38
A.1 Checklist 1: Organizational strategy . 39
A.2 Checklist 2: Define the software . 40
A.3 Checklist 3: Supplier selection evaluation . 42
A.4 Checklist 4: Supplier and acquirer obligations . 44
A.5 Checklist 5: Quality and maintenance plans . 45
A.6 Checklist 6: User survey . 46
A.7 Checklist 7: Supplier performance standards . 49
A.8 Checklist 8: Contract payments . 50
A.9 Checklist 9: Monitor supplier progress . 51
A.10 Checklist 10: Software evaluation . 52
A.11 Checklist 11: Software testing . 55
A.12 Checklist 12: Software acceptance . 56
Annex B (informative) Software safety assurance and software information security assurance . 57
B.1 Software safety assurance . 57
B.2 Software information security assurance . 58
Annex C (informative) Rights in technical data and software usage . 61

xi
© IEEE 2016 – All rights reserved

Annex D (informative) Acquisition plan guidelines . 62
D.1 (AP Section1) Introduction . 62
D.2 (AP Section 2) References . 63
D.3 (AP Section 3) Definitions . 63
D.4 (AP Section 4) Software acquisition overview . 63
D.5 (AP Section 5) Software acquisition process . 64
D.6 (AP Section 6) Software acquisition reporting requirements . 64
D.7 (AP Section 7) Software acquisition management requirements . 64
D.8 (AP Section 8) Software acquisition documentation requirements. 65
Annex E (informative) Bibliography . 66
xii
© IEEE 2016 – All rights reserved

IEEE Recommended Practice for
Software Acquisition
IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, security, health,
or environmental protection, or ensure against interference with or from other devices or networks.
Implementers of IEEE Standards documents are responsible for determining and complying with all
appropriate safety, security, environmental, health, and interference protection practices and all
applicable laws and regulations.
This IEEE document is made available for use subject to important notices and legal disclaimers.
These notices and disclaimers appear in all publications containing this document and may
be found under the heading “Important Notice” or “Important Notices and Disclaimers
Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
This recommended practice is divided into six clauses. Clause 1 provides the scope of this recommended
practice. Clause 2 lists references to other standards that are essential in applying this recommended
practice. Clause 3 provides definitions that are either not found in other standards, or have been modified
for use with this recommended practice. Clause 4 describes the options for acquiring software. Clause 5
describes the eight steps in a software acquisition process and the related quality practices that apply to
acquiring software. Clause 6 describes how quality assurance can be applied to software acquisition.
This recommended practice also contains five annexes. Annex A provides a set of checklists that
individuals or organizations may elect to adapt to their specific needs, Annex B provides software
acquisition guidelines with respect to Software Safety Assurance and Software Information Security
Assurance, Annex C provides guidelines with respect to rights in technical data software usage, Annex D
provides acquisition plan guidelines, and Annex E is the bibliography.
1.1 Scope
This recommended practice describes a set of useful quality considerations that can be selected and applied
during one or more steps in a software acquisition process. The recommended practices can be applied to
software that runs on any computer system regardless of the size, complexity, or criticality of the software.
The software supply chain may include integration of commercial-off-the-shelf (COTS), custom, or free
and open source software (FOSS). Each organization or individual using this recommended practice will
need to identify the specific quality and activities that need to be included within the organization’s
acquisition process. Security will be included as a quality attribute considered during the acquisition.

© IEEE 2016 – All rights reserved

IEEE Std 1062-2015
IEEE Recommended Practice for Software Acquisition
1.2 Purpose
This recommended practice is designed to help organizations and individuals incorporate quality, including
security considerations during the definition, evaluation, selection, and acceptance of supplier software for
operational use. It will also help determine how supplier software should be evaluated, tested, and accepted
for delivery to end users. This recommended practice is intended to satisfy the following objectives:
 Promote consistency within organizations in acquiring software from software suppliers.
 Provide useful practices on including quality, security, safety and data rights considerations during
acquisition planning.
 Provide useful practices on evaluating and qualifying supplier capabilities to meet user
requirements.
 Provide useful practices on evaluating and qualifying supplier software.
 Assist individuals or organizations judging the quality of supplier software for referral to end users.
 Assist suppliers in understanding how the software will be evaluated, tested, and accepted for
delivery to end users.
Success in acquiring high-quality software products and services from software suppliers can be achieved
by doing the following things:
a) Identifying quality characteristics necessary to achieve the acquirer’s objectives
b) Selecting suppliers most capable of meeting the acquisition objectives
c) Including quality considerations in the planning, evaluation, and acceptance activities
d) Developing an organizational strategy for acquiring software
e) Establishing a software acquisition process using the eight steps stated in 5.2 as a starting point
f) Putting the defined process into practice
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments or corrigenda) applies.
1, 2
IEEE Std 1228™, IEEE Standard for Software Safety Plans.
ISO/IEC/IEEE Std 12207, Systems and software engineering—Software life cycle processes.
ISO/IEC/IEEE Std 15288, Systems and software engineering—System life cycle processes.
ISO/IEC/IEEE Std 15289, Content of life-cycle information products.
ISO/IEC/IEEE Std 24765, Systems and Software Engineering—Vocabulary.
IEEE publications are available from the Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ
08854, USA (http://standards.ieee.org/).
The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.

© IEEE 2016 – All rights reserved

IEEE Std 1062-2015
IEEE Recommended Practice for Software Acquisition
3. Definitions and terms
For the purposes of this document, the following terms and definitions apply. The International Standard
ISO/IEC/IEEE 24765: Systems and Software Engineering—Vocabulary should be referenced for terms not
defined in this clause.
3.1 Definitions
acquisition: Process of obtaining a system, product, or service.
commercial-off-the-shelf (COTS): A product available for purchase and use without the need to conduct
development activities [ISO/IEC/IEEE 15289:2011].
modified-off-the-shelf (MOTS): Software product that is already developed and available, usable either
“as is” or with modification, and provided by the supplier, acquirer, or a third party.
off-the-shelf (OTS): Product or system already developed and available [ISO/IEC/IEEE 15289:2011].
software-intensive system: A system for which software is a major technical challenge and is perhaps the
major factor that affects system schedule, cost, and risk [IEEE Std 1362-1998 (Reaff 2007)] and
[ISO/IEC/IEEE 24765:2010].
NOTE—In the most general case, a software-intensive system is comprised of hardware, software, people, and manual
procedures.
3.2 Use of should, may, and can
In this document, the word should is used to indicate a recommendation. The word may is used to indicate a
permissible action. The word can is used for statements of possibility and capability.
4. Software acquisition alternatives
4.1 Introduction
Software can be acquired in three different ways or a combination of the three. It is acknowledged that any
combination of these three alternatives will make the overall software project more complex and likely to
be different from each other. This document does not attempt to address the combinations of these three
basics software acquisition options. The software acquisition alternatives include contracting custom-
developed software, obtaining the right to use off-the-shelf (OTS) software and renting software as a
service (SaaS). The advantages and disadvantages of each option are summarized in Table 1.
The International Standard ISO/IEC/IEEE 24765: Systems and Software Engineering—Vocabulary is available at
www.computer.org/sevocab.
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.

© IEEE 2016 – All rights reserved

IEEE Std 1062-2015
IEEE Recommended Practice for Software Acquisition
4.2 Custom-developed software
Reaching an agreement, often a formal contract for the custom development is an acquisition approach
where the solution to an acquirer’s need is provided via hiring a supplier (outsourcing) or using an internal
team to custom develop a software solution that is built to a specification or set of requirements. Following
software development standards and known methods, the acquirer oversees the development, test activities,
and products performed by the supplier. At acceptance, the acquirer takes ownership of the solution and
possibly some of the supporting tools/methods in order to support ops/maintenance of the solution. This
option includes software built from scratch and/or integrated from other existing components (e.g., reuse,
modified FOSS).
4.2.1 Advantages of custom-developed software
The advantages of custom-developed software are as follows:
 The solution should match the need exactly, no more or no less.
 The acquirer can require that flexibility and maintainability be supported by the solution and by the
supplier of the solution.
 The acquirer can monitor and influence the course of development/test in case changes are deemed
appropriate.
 The acquirer can control and influence the related topics to the executable software solution (e.g.,
size, performance, information protection, authorization security, capacity) and the software
development environment (language, tools, etc.).
 If a problem is reported, the acquirer can determine if the problem legitimately violates the
specifications and if it does, the supplier should be responsible for fixing that problem, typically at
no additional cost to the acquirer.
 Changes after acceptance are typically still under control of the acquirer via an ops/maintenance
agreement with a possibly different ops/maintenance supplier.
4.2.2 Disadvantages of custom-developed software
The disadvantages of custom-developed software are as follows:
 Typically costs more than the other options.
 Typically takes more time (sometimes much more) than the other options.
4.3 Off-the-shelf (OTS) software
This is an acquisition approach where the solution to an acquirer’s need is provided via purchasing and
taking possession of an already built solution from a software supplier. The acquirer agrees to the seller’s
license agreement to use the “executable” version of the solution but typically does not have access to the
source code or other information about the solution or the processes used to produce that product. In
addition, the acquirer typically takes possession of the software solution and installs in on assets owned by
the acquirer. In addition, the solution is typically acquired in “as is” condition, unless the supplier offers
built-in tailoring of the product (and this more common than not). This option includes commercial off-the-
shelf (COTS), free and open source software (FOSS) products acquired in “as is” condition, and other non-
developmental items (NDI).
© IEEE 2016 – All rights reserved

IEEE Std 1062-2015
IEEE Recommended Practice for Software Acquisition
4.3.1 Advantages of OTS
The advantages of OTS are as follows:
 Cost is less than the custom-developed option but similar to the SaaS option.
 Time to initial operations is less than the custom-developed option and can be greater than the SaaS
option.
 Since the acquirer takes possession of the solution, the control over data and access is greater than
the SaaS option and about the same as the custom-developed option.
4.3.2 Disadvantages of OTS
The disadvantages of OTS are as follows:
 The terms of the generally non-negotiable license agreement constrain how the solution may be
used by the acquirer, possibly to the acquirer’s detriment. The solution typically includes features
that attempt to enforce specific agreement terms, adding cost and complexity to the solution.
 The solution may not satisfy all of the acquirer’s needs (sometimes called gaps) and it may also
provide features/capabilities that are not required, not desired or even tolerable to the acquirer. The
acquirer may need additional solutions, or modifications to the acquired solution, to fill these gaps.
In addition, the acquirer may also need to identify and deactivate or prevent the extraneous code
from activating itself.
 Sometimes, the User Interface to the solution is different from the way an acquirer is currently
offering a User Interface to their current users. This can sometimes/often be solved via product
tailoring.
 Typically, there will be a need to obtain support from the supplier for installation, activation, and
maintenance.
 Problem reporting can be an issue, depending on the supplier’s capability to accept and react to
problem reports. In addition, the supplier may not even agree that because an acquirer alleges a
problem exists that a legitimate problem actually does exist.
 Product changes, both fixes and upgrades, are controlled mostly by the supplier and determined by
marketplace needs. Such changes may not be consistent with the acquirer’s ongoing needs or
timeframe.
 It is possible for the vendor to go out of business resulting in a possible loss of data.
4.4 Software as a service (SaaS)
Software as a service (SaaS) is an acquisition approach where the solution to an acquirer’s need is provided
via an agreement with a supplier for access to a software product for a fixed amount of time and to use that
software product remotely, via connection (wired, wireless, etc.) to the supplier’s assets. Inputs to the
remote software product are transmitted to the supplier and outcomes/results/products from using the
software product are transmitted back to the acquirer. This acquisition option is part of the Cloud
Computing approach (NIST Special Publication 800-145 [B12]) to software (aka renting access to
products, services, infrastructure, etc.) and is frequently referred to as software as a service (SaaS).

© IEEE 2016 – All rights reserved

IEEE Std 1062-20
...