BS ISO/IEC/IEEE 41062:2019

BSI Standards Publication

Software engineering — Recommended

practice for software acquisition
BS ISO/IEC/IEEE 41062:2019 BRITISH STANDARD

National foreword
This British Standard is the UK implementation of ISO/IEC/
IEEE 41062:2019.
The UK participation in its preparation was entrusted to Technical
Committee IST/15, Software and systems engineering.
A list of organizations represented on this committee can be obtained on
request to its secretary.
This publication does not purport to include all the necessary provisions
of a contract. Users are responsible for its correct application.
© The British Standards Institution 2019
Published by BSI Standards Limited 2019
ISBN 978 0 580 99869 0
ICS 35.080
Compliance with a British Standard cannot confer immunity from
legal obligations.
This British Standard was published under the authority of the
Standards Policy and Strategy Committee on 28 February 2019.

Amendments/corrigenda issued since publication

Date Text affected
 BS ISO/IEC/IEEE 41062:2019
I N TERNATIONAL ISO/IEC/
S TANDARD IEEE
41062
First edition

2 0 1 9 -0 2

Software engineering —
Recommended practice for software
acquisition
Ingénierie du logiciel — Pratique recommandée pour l'acquisition des
logiciels

Reference number

I SO /I E C/I E EE 41 0 62 : 2 0 1 9 (E )

© IEEE 2 01 6
BS ISO/IEC/IEEE 41062:2019
ISO/IEC/IEEE 41062:2019(E)

COPYRIGHT PROTECTED DOCUMENT

© I E EE 2 0 1 6
All rights reserved. Unless otherwise specified, or required in the context o f its implementation, no part o f 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 o f the requester.

ISO copyright o ffice Institute o f 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: [email protected] Email: [email protected]
Website: www. iso .o rg Web site: www. ieee. org

Published in Switzerland

ii © I E EE 2 0 1 6 – All rights reserved

 BS ISO/IEC/IEEE 41062:2019
ISO/IEC/IEEE 41062:201 9 (E)

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members o f ISO or IEC participate in the development o f International Standards through technical
committees established by the respective organization to deal with particular fields o f technical
activity. ISO and IEC technical committees collaborate in fields o f mutual interest. Other
international organizations, governmental and non‐governmental, in liaison with ISO and IEC, also
take part in the work. In the field o f 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 di fferent approval criteria needed for
the di fferent types o f ISO documents should be noted (see www.iso.org/directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees o f 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 o f 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 veri fy the
accuracy o f any o f the information contained in its standards.
Attention is drawn to the possibility that some o f the elements o f this document may be the subject
o f patent rights. ISO and IEC shall not be held responsible for identi fying any or all such patent
rights. Details o f any patent rights identified during the development o f the document will be in the
Introduction and/or on the ISO list o f patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience o f users and does
not constitute an endorsement.
For an explanation o f the voluntary nature o f standards, the meaning o f ISO specific terms and
expressions related to con formity 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 So ftware & Systems Engineering Standards Committee o f
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” de fined in the Partner Standards
Development Organization cooperation agreement between ISO and IEEE, by Joint Technical
Committee ISO/IEC JTC 1, Information techn ology, 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 o f these bodies can be found at www.iso.org/members.html.

© IEEE 201 6 – All rights reserved iii

BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 62 ™ -2 0 1 5

(Revisi on of
I EEE Std 1 062-1 993)

I E E E Recom m en d ed P racti ce for

S oftware Acq u i s i ti on

Spon sor

S oftware & S ys tem s E n g i n eeri n g S tan d ard s (C /S 2 E S C ) C om m i ttee

of th e

I E E E C om p u ter S oci ety

Approved 5 Decem ber 201 5

I E E E -S A S tan d ard s B oard

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

Abstract: A set of u sefu l q u al i ty con si d erati on s th at can be sel ected an d appl i ed d u ri n g on e or

m ore steps i n a software acq u isi ti on process i s d escri bed i n th i s recom men d ed practi ce. Th e
recom m en d ed practi ces can be appl i ed to software th at ru n s on an y com pu ter system reg ard l ess
of th e si ze, com pl exi ty, or cri ti cal i ty of th e software. Th e software su ppl y ch ai n m ay i n cl u d e
i n teg rati on of off-th e-sh el f (OTS), cu stom , or free an d open sou rce software (FOSS ). Each
org an i zati on or i n d i vi d u al u si n g th i s recom m en d ed practi ce wi l l n eed to i d en ti fy th e speci fi c q u al i ty
an d acti vi ti es th at n eed to be i n cl u d ed wi th i n i ts acq u isi ti on process.

Keyword s: acq u i rer, cu stom d evel oped , en d u ser, FOS S, I EE E 1 062 ™ , off-th e-sh el f, OTS ,
SaaS , software acq u i si ti on process, software as a servi ce, su ppl i er

Th e I n sti tu te of El ectri cal an d El ectron i cs En g i n eers, I nc.

3 Park Aven u e, N ew York, N Y 1 001 6-5997, U SA

Copyri g h t © 201 6 by Th e I n sti tu te of Electri cal an d El ectron i cs En g i n eers, I n c.

Al l ri g hts reserved . Pu bl i sh ed 26 Febru ary 201 6. Pri n ted i n th e U n ited States of Am eri ca.

I EEE i s a reg i stered trad em ark i n th e U . S. Paten t & Trad em ark Offi ce, own ed by Th e I n sti tu te of El ectri cal an d El ectron i cs
En g i n eers, I n corporated .

PDF: I SBN 978-1 -5044 -0085-5 STD2 0506

Pri n t: I SB N 978-1 -5044 -0086-2 STDPD2 0506

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
Copyri gh t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I m portan t N oti ces an d D i s cl ai m ers C on ce rn i n g I E E E S tan d ard s D ocu m en ts

IEEE documents are made available for use subj ect 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. ”

N oti ce an d D i s cl ai m er of Li abi l i ty C on cern i n g th e U se of I E E E S tan d ard s

D ocu m en ts

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 (“ANS I”), 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 j udgments 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 subj ect 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 j udgment 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 LIAB LE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUB STITUTE GOODS OR SERVICES ; LOS S OF USE, DATA, OR PROFITS ;
OR BUS INESS INTERRUPTION) HOWEVER CAUS ED AND ON ANY THEORY OF LIAB ILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWIS E) ARISING IN ANY WAY OUT OF THE PUB LICATION, US E OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVIS ED OF THE POSS IBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.

Tran s l ati on s

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
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

Offi ci al 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.

Commen ts 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 j oin 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 08 85 4 USA

Laws and regu l ati ons

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.

Copyrig hts

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.

Ph otocopi es

Subj ect 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 01 923 USA; +1 978 75 0 8400. Permission
to photocopy portions of any individual standard for educational classroom use can also be obtained
through the Copyright Clearance Center.

vi
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

U pd ati n g of I E E E S tan d ard s d ocu m en ts

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 subj ected 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. j sp 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.

E rrata

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.

Paten ts

Attention is called to the possibility that implementation of this standard may require use of subj ect 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
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

Parti ci pants

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 Banerj ee 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
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

When the IEEE-SA Standards Board approved this recommended practice on 5 December 201 5 , 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
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I n trod u cti on

This introduction is not part of IEEE Std 1 062-201 5 , 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 obj ectives:

 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 j udging the quality of supplier software for referral to end users

x
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

Contents

1 . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1
1 . 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1
1 . 2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2

2. Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2

3 . Definitions and terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3

3 . 1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3
3 . 2 Use of should, may, and can . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3

4. Software acquisition alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3

4. 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3
4. 2 Custom-developed software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4
4. 3 Off-the-shelf (OTS) software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4
4. 4 Software as a service (SaaS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 5

5 . Software acquisition process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8

5 . 1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8
5 . 2 Eight steps in acquiring quality software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 0
5 . 8 Step 6: Managing for supplier performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
5 . 9 Step 7: Accepting the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3
5 . 1 0 Step 8: Evaluating the process and identifying improvement opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4

6. Quality assurance for software acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6

6. 1 Obj ectives of quality assurance in software acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6
6. 2 Implementing quality assurance in software acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6

Annex A (informative) Checklists for quality software acquisition processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 8

A. 1 Checklist 1 : Organizational strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 0
A. 9 Checklist 9: Monitor supplier progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1
A. 1 0 Checklist 1 0: Software evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2
A. 1 1 Checklist 1 1 : Software testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5
A. 1 2 Checklist 1 2: Software acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6

Annex B (informative) Software safety assurance and software information security assurance . . . . . . . . . . . . . . . . 5 7
B. 1 Software safety assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7
B. 2 Software information security assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8

Annex C (informative) Rights in technical data and software usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

xi
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

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
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E Recom m en d ed P racti ce for

S oftware Acq u i s i ti on

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 . O vervi ew

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 S cope

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 (FOS S). 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.

1
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

1 . 2 Pu rpose

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 obj ectives:

 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 j udging 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 obj ectives

b) Selecting suppliers most capable of meeting the acquisition obj ectives

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. N ormati ve 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 1 228™, IEEE Standard for Software Safety Plans.

ISO/IEC/IEEE Std 1 2207, Systems and software engineering—S oftware life cycle processes.

IS O/IEC/IEEE Std 1 5 28 8, Systems and software engineering—S ystem life cycle processes.

ISO/IEC/IEEE Std 1 5 289, Content of life-cycle information products.

ISO/IEC/IEEE Std 24765 , Systems and Software Engineering—Vocabulary.

1
IEEE publications are available from the Institute of Electrical and Electronics Engineers, Inc. , 445 Hoes Lane, Piscataway, NJ

088 54, USA (http: //standards.ieee. org/).

2
The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.

2
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

3. D efi n i ti on s an d term s

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
3
defined in this clause.

3. 1 D efi n i ti on s

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 1 5 289: 201 1 ] .

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 1 5 289: 201 1 ] .

software-intensive system : A system for which software is a maj or technical challenge and is perhaps the
maj or factor that affects system schedule, cost, and risk [IEEE Std 1 3 62-1 998 (Reaff 2007)] and
[ISO/IEC/IEEE 24765 : 201 0] .

NOTE —In the most general case, a software-intensive system is comprised of hardware, software, people, and manual
4
procedures.

3 . 2 U s e of s h ou l d , m ay, an d 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. S oftware acq u i s i ti on al tern ati ves

4. 1 I n trod u cti on

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 proj ect 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 .

3
The International Standard ISO/IEC/IEEE 24765: Systems and Software Engineering—Vocabulary is available at

www.computer.org/sevocab.
4
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.

3
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

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 (FOS S) products acquired in “as is” condition, and other non-
developmental items (NDI).

4
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

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 (NIS T Special Publication 8 00-1 45 [B1 2] ) to software (aka renting access to
products, services, infrastructure, etc. ) and is frequently referred to as software as a service (S aaS).

5
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

4.4.1 Advantages of SaaS

The advantages of SaaS are as follows:

 Rapid access to products and services via Service Level Agreement (SLA) and ready to use
solutions, more so than custom-developed or OTS .

 No need to provide internal computing assets to support “building or buying” the equivalent
products or services, thus reducing costs and time in prep for using solution, as compared to both
custom-developed and OTS .

 Typically is cheaper than custom-developed option and can be cheaper than the OTS option.

 No need to take permanent ownership of the software solution, thus reducing impacts associated
with such ownership (e. g. , sustainment, hardware to host solution), as in the custom-developed and
OTS options.

4.4.2 Disadvantages of SaaS

The disadvantages of SaaS 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.

 The location of where the data is stored is not controlled by the acquirer; therefore the data
(personal data, sensitive data, etc. ) could be subj ect to the rules and regulations of the locality of
the supplier.

 In the event the supplier is no longer a case of e. g. , bankruptcy of supplier, potentially the
acquirer’ s data could be lost.

 The user interface to the solution may be 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.

 Protection of data, being transmitted in both directions due to dependency on supplier’ s

capabilities. This may require internal protections or legal agreements if this protection should ever
fail or be compromised.

 Problem reporting and problem correction of a solution, if it does not work as desired: Supplier
may not agree with nature of the problem or may not be able to fix in a timely manner. Similar to
OTS and more problematic than custom-developed.

 Assured access to solution due to dependency on external assets. Again, backup/alternative paths
to supplier’ s assets may be required or legal recourse in case of loss of access. This is typically a
bigger risk than for custom-developed or OTS options.

 Recovery from loss of access to or other failures of the solution may be dependent on the supplier’ s
abilities and sometimes out of the control of the acquirer.

 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.

6
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

Table 1 —Software acquisition options

Advantages Disadvantages
Custom- 1. The solution should match the need exactly, no 1. Typically costs more than the other options.
developed more or no less. 2. Typically takes more time than the other options.
software 2. The acquirer can require that flexibility and
maintainability be supported by the solution and
by the supplier of the solution.
3. The acquirer can monitor and influence the
course of development and test in case changes
are needed.
4. 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. ).
5. 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.
6. Changes after acceptance are typically still under
control of the acquirer via an
operations/maintenance agreement with a
possibly different operations/maintenance
supplier.
Off-the- 1. Cost is less than custom-developed option but 1. The terms of the generally non-negotiable license
shelf (OTS) similar to the SaaS option. agreement constrain how the solution may be used
software 2. Time to initial operations is less than the custom- by the acquirer, possibly to the acquirer’ s
developed option but greater than the SaaS detriment. The solution typically includes
option. features that attempt to enforce specific agreement
3. Since the acquirer takes possession of the terms, adding cost and complexity to the solution.
solution, the control over data and access is 2. The solution may not satisfy all of the acquirer’ s
greater than the SaaS option and about the same needs (sometimes called “gaps”) and it may also
as the custom-developed option. 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 need to
identify and deactivate or prevent the extraneous
code from activating itself.
3. 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.
4. Typically, there will be a need to obtain support
from the supplier for installation, activation and
maintenance.
5. 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.
6. 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.
7. It is possible for the vendor to go out of business
resulting in a possible loss of data.

7
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

Advantages Disadvantages
Software 1. Rapid access to products and services via 1. The terms of the generally non-negotiable license
as a Service Level Agreement (SLA) and ready-to- agreement constrain how the solution may be used
service use solutions, more so than custom-developed or by the acquirer, possibly to the acquirer’ s
(SaaS) OTS. detriment. The solution typically includes
2. No need to provide internal computing assets to features that attempt to enforce specific agreement
support ‘ building or buying’ the equivalent terms, adding cost and complexity to the solution.
products or services, thus reducing costs and 2. The solution may not satisfy all of the acquirer’ s
time in preparation for using solution, as needs (sometimes called gaps) and it may also
compared to both custom-developed and OTS. provide features/capabilities that are not required,
3. Typically is cheaper than custom-developed not desired or even tolerable to the acquirer. The
option and can be cheaper than the OTS option. acquirer may also need to identify and deactivate
4. No need to take permanent ownership of the or prevent the extraneous code from activating
software solution, thus reducing impacts itself.
associated with such ownership (e. g., 3. Sometimes the user interface to the solution is
sustainment, hardware to host solution), as in the different from the way an acquirer is currently
custom-developed and OTS options. offering a user interface to their current users.
This can sometime/often be solved via product
tailoring.
4. Typically, there will be a need to obtain support
from the supplier for installation, activation, and
maintenance.
5. Problem reporting and problem correction of a
solution, if it does not work as desired.
6. Recovery from loss of access to or other failures
of the solution may be dependent on the supplier’ s
abilities and sometimes out of the control of the
acquirer.
7. 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.
8. It is possible for the vendor to go out of business
resulting in a possible loss of data.

5. Software acquisition process

5.1 Purpose
The purpose of the acquisition process is to obtain a product or service in accordance with the acquirer’ s
requirements.

5.1 .1 Outcomes
As a result of the successful implementation of the acquisition process:

a) A request for supply is prepared.

b) One or more 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.

8
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.1 .2 Activities and tasks

Software can be acquired as a stand-alone product, as a service, or embedded in a system consisting of a
single processor or a large, complex system with many hardware items. This clause describes the activities
in the software acquisition process and is applicable to the acquisition of developed software, non-
developmental software (COTS , reuse, or FOS S), and software services.

5.1 .3 Principal acquisition roles

There are three principal roles involved: acquirer, supplier, and end user. These roles may be performed by
a single individual in a small business or by multiple people representing organizations in a large corporate
or government environment. The acquirer develops the method to satisfy the identified need and the
supplier provides the required product or service to the end user.

5.2 Eight steps in acquiring quality software

The software acquisition process can be described by eight steps. The activities in each step support the
acquisition of high-quality software products, services or systems that meet the acquirer’ s requirements and
expectations, including on-time and on-budget delivery.

The software acquisition process should be tailored or streamlined to the maximum extent possible taking
risk into consideration. The process should be consistent with technical maturity, validated requirements,
and expected level of effort and funding. The tailoring process is presented in Annex A of ISO/IEC/IEEE
1 2207.

Figure 1 illustrates the eight-step process described in this clause and Table 2 summarizes the process steps,
along with their inputs and outputs.

9
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I EEE Std 1 062-201 5

I EEE Recomm end ed Practi ce for Software Acq u i si ti on

I d en ti fi ed N eed

Step 1 . Pl an n i n g th e software
acq u i si ti on strateg y (5. 3)

Acq u isi ti on Strateg y an d Acq u i si ti on Pl an d ocu m en ted

Step 2 . D efi n i n g th e acq u i si ti on

an d software req u i rem en ts
(5. 4)

Software system req u i rem en ts d ocu m en ted

Step 3 . I d en ti fyi n g poten ti al

su ppl i ers (5. 5)

N o poten ti al su ppl i ers

Poten ti al su ppl i ers i d en ti fi ed

Step 4. Prepari n g con tract

req u i rem en ts (5. 6)

N o con tract

RFP pu bl ish ed

Step 5. Eval u ati n g proposal s

an d sel ecti n g th e su ppl ier
(5. 7)

Con tract n eg oti ated

Step 6 . M an ag i n g for su ppl i er

perform an ce (5. 8)

Software or servi ce d el i vered

Step 7 . Accepti n g th e software

(5. 9)

Software or servi ce accepted

Step 8 . Eval u ati n g th e

process an d i d en ti fyi n g
i mprovem en t opportu n i ti es
(5. 1 0)

Figure 1 —Eight steps in acquiring software

10
Copyrig h t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

Table 2 —Eight steps in acquiring software

Steps in software Activities and Tasks Outcomes
acquisition process
Step 1 . Planning the 1. Initiate a planning process. 1. High level specification of functional and non-

software acquisition 2. Develop an acquisition strategy. functional requirements to confirm need for a
3. Develop an acquisition plan. system and guide acquisition planning is produced.
strategy (5. 3 )
4. Include contracting practices. 2. Acquisition plan is specified and deliberated on.
5. Obtain acquisition services from 3. Acquisition plan is approved.
other organizations.
6. Tailor the process.

Step 2. Defining the 1. Define the software being acquired. 1. The software to be acquired is defined in detail.

acquisition and software 2. Establish supplier evaluation criteria. 2. The Statement of Work (SOW) is defined and
3. Establish acquirer and supplier approved.
requirements (5. 4)
obligations. 3. Software requirements are specified and approved.
4. Develop plans to evaluate and accept 4. A detailed RFP which includes acquirer and
software and services. supplier obligations is produced and approved.
5. Develop contingency plans. 5. Evaluation and acceptance criteria for the software
to be acquired are produced.
6. Contingency plan is drawn up and approved.

Step 3 . Identifying 1. Gather software supplier’ s 1. Potential supplier information is gathered and a

potential suppliers (5. 5 ) information. detailed RFI report produced for each supplier
2. Review software supplier’ s visited.
information. 2. Review report based on potential supplier’ s
3. Survey uses of the supplier’ s information is produced.
software. 3. A limited number of supplier candidates are
shortlisted based on the acquisition organization’s
policy.

Step 4. Preparing contract 1. Determine the required quality of the 1. The desired level of quality of work is determined.

requirements (5. 6) work. 2. Payment terms are determined.

2. Determine how payment is to be 3. Remedies for non-performance are determined.
made. 4. Contract for engaging a supplier is produced and
3. Determine nonperformance approved.
remedies. 5. Legal review opinion including caveats and
4. Prepare contract provisions. limitations documented.
5. Review contract provisions with
legal counsel.

Step 5 . Evaluating 1. Evaluate supplier proposals. 1. An evaluation report on proposals submitted is

proposals and selecting the 2. Visit supplier facilities. produced.

3. Select a qualified supplier. 2. A qualified and preferred supplier is selected.
supplier (5. 7)
4. Negotiate the contract. 3. A contract between acquirer and supplier is
negotiated and signed.

Step 6. Managing for 1. Manage the contract during 1. Performance measures or assessment results are

supplier performance (5. 8) execution. available.

2. Monitor the supplier’ s progress. 2. Adequacy of roles and accountabilities is assessed.
3. Agreement obj ectives are achieved.
4. Accountability in carrying out proj ect activities and
tasks.
5. Issues (including problems) in proj ect execution
are managed.

Step 7. Accepting the 1. Review and update the acceptance 1. An acceptance testing report on delivered software

software (5. 9) criteria. solution is produced.

2. Conduct a review and test of the 2. Decision to accept, rej ect or make changes to the
software. delivered software solution is made.
3. Manage the testing process.
4. Document the test results.

Step 8. Evaluating the 1. Evaluate contracting practices. 1. Contracting practices evaluated and reviewed.

process and identifying 2. Evaluate software product quality. 2. Acquired software product is evaluated.
3. Evaluate supplier performance. 3. Supplier performance is evaluated.
improvement opportunities
4. A detailed evaluation report is produced.
(5 . 1 0)

11
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5. 3 S tep 1 : P l an n i n g th e s oftware acq u i s i ti on s trateg y

5. 3. 1 Pu rpos e

a) The purpose of planning the software acquisition is to define the acquisition strategy. Planning for
software acquisition begins when an organization has established a need for a software system and
has made the decision to acquire the software rather than to develop it in-house. This includes the
activities performed to define an acquisition strategy for the software to be acquired. The
acquisition strategy includes a description of what is to be acquired, the length of time estimated for
implementation, and an estimate of the cost of the implementation. The acquisition strategy also
includes a concept for how the software will be operated and maintained; whether by the acquirer,
the supplier, or by a third party.

b) Planning includes the definition of the acquisition plan to be used by the acquirer. The acquisition
plan describes the activities that the acquisition organization should perform to acquire the
software.

5. 3. 2 Ou tcom es

The outcomes of Step 1 are as follows:

 High level specification of functional and non-functional requirements to confirm need for a system
and guide acquisition planning is produced.

 Acquisition plan is specified and deliberated on.

 Acquisition plan is approved.

5. 3. 3 Acti vi ti es an d tas ks

5. 3. 3. 1 I n i ti ate a pl an n i n g proces s

Before initiating planning, the acquirer should ascertain if any established acquisition processes policies
exist (preferred supplier lists, etc. ) for the planning organization.

Initiate a planning process by

a) Developing a scope for the planning process

b) Forming a planning group and reviewing the organization’ s obj ectives

c) Identifying the qualities a software product should possess to achieve the organization’ s obj ectives

5. 3. 3 . 2 D evel op an acq u i s i ti on strateg y

The qualities and basic characteristics software should possess to achieve the organization’ s obj ectives
should be determined in order to detail a strategy for acquiring the software. These characteristics can
include high-level descriptions of functionality, as well as other characteristics such as the required time
frame, estimated cost, etc. Constraints in the planned software environment can limit choices to software
that is compatible with the environment and available infrastructure.

12
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

This strategy should include the following:

a) Developing lists of capabilities (those of the acquiring organization and those of potential
suppliers) that would be helpful in identifying who could provide the needed software.

b) Identifying responsibilities that are associated with either the supplier or the acquirer.

c) Determining the extent of the supplier’ s organizational involvement in providing a high-quality

product (consider the strategic areas shown in Annex A, Checklist 1 ).

d) Identify the potential options for acquisition and the risk, cost, and benefits for each. ISO/IEC/IEEE
Std 1 2207 lists potential options.

e) Custom-developed versus OTS versus SaaS : It is important that the acquirer become aware of
which of these three options are viable at this point in the planning process. If experienced vendors
exist, the OTS or SaaS options become important as the acquirer starts to identify such acquisition
options and the necessary trade space to compare one of those options against the other.

f) The strategy should be flexible enough to leave room for negotiations between acquirer and
supplier. Suppliers may propose unanticipated solutions to the proj ect or may wish to negotiate
agreement types, responsibilities, terms and conditions, etc. The strategy should not favor any
particular supplier in order to provide a fair level of competition to all potential suppliers.

5. 3. 3. 3 D evel op an acq u i s i ti on pl an

An acquisition plan should document the acquisition of software for a particular proj ect and should contain
the following:

a) Requirements to determine the scope of the system to be acquired

b) A description of how the software will be used

c) A risk assessment and associated planned risk management actions

5. 3 . 3. 4 I n cl u d e con tracti n g practi ces

When establishing an acquisition process, the following should be documented as appropriate in the
proj ect’ s acquisition plan:

a) Selection of contracting method(s) or agreements

b) Preparation of contracting exhibits describing the work required, deliverables, support, training,
and acceptance requirements

c) Consideration of what support, training, and other activities will be provided by the supplier and
what will be provided by acquirer’ s organizations

d) Assignment of negotiation and contract administration responsibilities

e) Milestones that will be used to monitor the proj ect’ s progress and acceptance

f) The primary responsibilities of the acquirer’ s organization

g) The primary responsibilities of the supplier, including the processes that will be imposed on the
supplier

h) The method to be used to address contract changes, including but not limited to triggers for
renegotiation

13
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.3.3.5 Obtain acquisition services from other organizations

If some of the above acquisition tasks are not performed within the acquirer’ s organization, help should be
obtained from other organizations that can provide consultation and assistance in software contracting and
negotiating.

5.3.3.6 Tailor the process

The process may be tailored to perform these tasks at a level appropriate for the complexity of the software
to be acquired. For example, procurement of an off-the-shelf product may not require extensive
requirements documentation, but may require a support or training agreement. Likewise, a large
development proj ect with many requirements will likely require all of the topics listed above to be
addressed.

The processes that both the acquirer and supplier are required to implement may be tailored as appropriate.
The amount of tailoring permissible for the supplier should be included in contract documents.

Reference to internal policies and practices may be used for additional guidance on implementing a process
for acquiring high-quality software. A reference list of information currently available within the
organization should be maintained.

After completing the acquisition process, lessons learned should be collected and reviewed to identify
potential process improvements to meet the changing needs and obj ectives of the organization.

5.4 Step 2: Defining the acquisition and software requirements

5.4.1 Purpose
The purpose of defining the software requirement is to specify detailed functional and non-functional
requirements for the software to be procured and use these to produce the request for proposal (RFP) and
statement of work (SOW).

5.4.2 Outcomes
The outcomes of Step 2 are as follows:



The software to be acquired is defined in detail.


The SOW is defined and approved.


Software requirements are specified and approved.


A detailed RFP that includes acquirer and supplier obligations is produced and approved.


Evaluation and acceptance criteria for the software to be acquired are produced.
Contingency plan is drawn up and approved.

14
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.4.3 Activities and tasks

5.4.3.1 Define the software being acquired

The obj ective is to develop the requirements for the software, including functional, performance, and non-
functional requirements and to obtain from the supplier(s) realistic assessments of the size, scope, and cost
of the effort required for the software.

Functional requirements specify what the software should do. Performance requirements specify the
performance attributes for the software, such as computational load, algorithm timing, precision, or
accuracy. Non-functional requirements specify the quality attributes required for the software, such as
dependability, reliability, availability, or maintainability.

The needed software, deliverables, and software support should be described as completely as possible in
the RFP so that the supplier can understand and address the scope of work in the proposal. The example
questions in Annex A, Checklist 2 may be used as a starting point.

IEEE Std 83 0™ [B5 ] should be used to document the requirements.

Depending upon the type of software being acquired, a request for quote or other acquisition document may
be used in place of the RFP.

5.4.3.2 Establish supplier evaluation criteria

The obj ective is to confirm that the supplier most suited to do the work is selected.

Evaluation criteria should be developed to use in reviewing supplier proposals, identifying nonresponsive
suppliers, and selecting a qualified supplier. The supplier’ s management qualifications, technical approach,
quality assurance program, and proposed cost should be considered. The questions in Annex A, Checklist
3 , may be used.

A provision should be included in the RFP requiring inspections of supplier facilities to investigate and
evaluate various factors, including financial position, technical capability, experience, and quality practices.

5.4.3.3 Establish acquirer and supplier obligations

The obj ective is to establish and clearly state the obligations of both the acquirer and the supplier. Annex
A, Checklist 4, may be used.

5.4.3.4 Develop plans to evaluate and accept software and services

Quality and maintenance plans should be developed to use in evaluating and accepting the software and
services provided by the supplier. Annex A, Checklist 5 , may be used.

5.4.3.5 Develop contingency plans

Contingency plans should be developed to use in the event the supplier fails to satisfy contract
requirements and the contract is then terminated. The complexity of the proj ect and the risk in achieving
the contract requirement should be considered.

15
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5. 5 S tep 3 : I d en ti fyi n g poten ti al s u ppl i ers

5. 5. 1 Pu rpos e

The purpose is to identify potential suppliers of the required software through a request for information
(RFI) followed by site visits to those potential suppliers.

Contact potential suppliers and schedule the itinerary for facilities visiting. Facilities visiting participants
should be selected and meeting agenda should be prepared in advance. A comparison chart to record
observations made during the supplier facility visit should be created. Annex A, Checklist 3 , may be used.
The purpose of the visiting is to verify the RFI responses matched with suppliers’ operation practices, to
validate products demonstration, and to review document and quality system. A presentation of the RFI
response should be conducted by suppliers for critical points clarification and a management or executive
level meeting will be helpful for mutual understanding of further cooperation possibility.

Identify a group of suppliers whose offers are likely to be acceptable to receive an RFP for further
evaluation. Also, evaluate if a non-disclosure agreement (NDA) is required for the RFP to secure both
acquirer’ s and supplier’ s confidential information.

It is important that the acquirer establishes “valid supplier” criteria and that these are shared with the
supplier community. This can reduce the possibility of protests against any final supplier selection.

Custom-developed vs OTS vs SaaS can be summarized as follows:

a) Custom-developed: If custom built software is an option, then determining the past performance of
a potential supplier in the domain (e. g. , communications, spacecraft, IT) is important.

b) OTS /S aaS: If OTS or SaaS is an option, determining the satisfaction of the user community of the
product/service is important. This can sometimes be accomplished by interacting with
product/service user groups for a given product/service.

5. 5. 2 Ou tcom es

The outcomes of Step 3 are as follows:

 Potential supplier information is gathered and a detailed RFI report produced for each supplier
visited.

 Review report based on potential supplier’ s information is produced.

 A limited number of supplier candidates (e. g. , 3) are shortlisted based on the acquisition
organization’ s policy.

5. 5. 3 Acti vi ti es an d tas ks

5. 5. 3 . 1 G ath er s oftware s u ppl i er’ s i n form ati on

Prepare an RFI/market survey and/or user survey form to collect software suppliers’ information. Collect
any information to assist further evaluation and mitigate the acquisition risk.

The RFI should consist of general company and domain specific information.

16
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

a) General company information includes company size, founder/executives, location(s), subsidiaries,

product roadmap, service cost, financial information (capital and/or statements), and quality
process/system. Annex A, Checklist 3 may be helpful.

b) Domain specific information such as domain specific technology/knowledge, expertise,

development resources, patent list, and test equipment is required for further evaluation.
Information from Annex A, Checklist 2 may be helpful.

The RFI and user survey needs to be managed to determine who should receive it. The supplier list may be
obtained from technical alliance membership lists, exhibition and/or trade publications, consultants,
supplier-chain management (refer to ISO/IEC/IEEE 1 2207). The user list can be obtained from suppliers’
website, consultant, or other stakeholders’ recommendation.

A task owner should be assigned to distribute the RFI and/or user survey form to appropriate suppliers or
users. She/he should also be responsible for collecting the RFI and user survey response. The RFI and user
survey form should define the deadline for response submission.

5.5.3.2 Review software supplier’s information

Review the general company information and filter out those are not appropriate for the software to be
acquired. The criteria, especially security and/or financial, should be defined according to organization’ s
acquisition strategy, information from Annex A, Checklist 3 may be helpful.

Review domain specific information and user survey responses. The acquirer’ s proj ect team should define
criteria for the technical related thresholds such as quality process maturity level, person-years of expertise
team experience, domain knowledge scope, patent(s) protection coverage, etc.

If a supplier has been contracted with before, review the suppliers’ performance and commitment
fulfillment.

The suppliers identified with capability insufficiency and/or bad user experience should be eliminated from
the potential suppliers list. Suppliers without the capability to handle a large effort on their own may be
awarded a portion of a proj ect, as an encouragement to small businesses or to apply specific expertise.

5.5.3.3 Survey users of the supplier’s software

One indicator of the quality and effectiveness of a software product is the number of satisfied companies
currently using the software. Users can provide information on volume throughput planning and system
degradation, and important insights on correcting software failures. The nature, quality, speed, and
reliability of maintenance may be determined by exploring other users’ experiences. The following should
be considered:

a) Establishing functional and performance requirements.

b) Evaluating software product against the functional and performance requirements of item a).

c) Evaluating the adequacy of the development process including the activities of quality assurance,
configuration management, verification and validation, reliability measurement, documentation,
and maintenance.

When preparing to contact users about a product, the questions suggested in Annex A, Checklist 6, may be
used. This checklist can be easily modified to fit the acquirer’ s needs.

17
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.6 Step 4: Preparing contract requirements

5.6.1 Purpose
The purpose is to prepare a detailed contract for the engagement of the chosen supplier.

5.6.2 Outcomes
The outcomes of Step 4 are as follows:

 The desired level of quality of work is determined.

 Payment terms are determined.

 Remedies for non-performance are determined.

 Contract for engaging a supplier is produced and approved.

 Legal review opinion including caveats and limitations documented.

5.6.3 Activities and tasks

5.6.3.1 Determine the required quality of the work

The obj ective is to prepare a contract that describes the expected quality level of the finished work. The
following should be included:

a) Describe in the contract’ s statement of work the relationship between the supplier and acquirer, and
who has responsibility for each task. The list of supplier and acquirer obligations developed from
Annex A, Checklist 4, may be used (see 5 . 5 . 3 ).

b) Describe in the contract what will be delivered, and what constitutes satisfactory and timely
performance by the supplier (see Annex A, Checklist 7. ).

c) Specify who is authorized to make changes in the contract and to answer supplier questions.

d) Consider providing in the contract means to monitor the supplier’ s progress. To do this, divide the
development effort into logical work steps. The more undefined the software is, the closer the steps
should be at the outset. The acquirer’ s approval should be required for each step before the
development is allowed to continue to the next step. Identify performance as well as functional
specifications.

e) Specify what measures will be used to determine the acceptability of the product or service. Service
contracts often include service level agreements (SLA) that define an acceptable level of service.
Agreements for developed software can require acceptance testing in the acquirer’ s environment.

f) Specify the measures of reliability and quality by which the supplier’ s work will be evaluated. The
list of quality obj ectives developed from Annex A, Checklist 5 , may be used.

g) Specify the criteria for software evaluation. The list of criteria developed from Annex A, Checklist
1 0, may be used.

5.6.3.2 Determine how payment is to be made

The obj ective is to create a contract that ties supplier payments to contract deliverables (see Annex A,
Checklist 8).

18
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5. 6. 3. 3 Determ i n e n on perform an ce rem ed i es

An obj ective of this step is to prepare a contract that provides the acquirer the right to terminate the contract
if the supplier cannot perform according to the contract’ s terms. The satisfactory performance and
acceptance testing criteria developed from Annex A, Checklist 7, can be used to identify work that does not
meet contract requirements.

Include a provision requiring the supplier to deliver, at contract termination, all agreed deliverables.

Complex proj ects where there is significant risk in achieving the contract requirements should include a
provision that requires the supplier to deposit with an escrow agent source code, documentation and other
material deemed appropriate by the acquirer.

5. 6. 3. 4 Prepare con tract provi si on s

Contract provisions should be developed according to the acquirer’ s needs. Consideration should be given
to the following when preparing the contract:

 Review the obj ectives previously described in 5 . 5 . 1 . Select those provisions that represent the
acquirer’ s business practices that influence or contribute to obtaining a high-quality product.

 Identify the contracting method most appropriate for acquiring software products or services from
suppliers.

 Incorporate in the agreement the acquirer selected provisions. Review existing agreements and
consider including favorable contract provisions used successfully in the past.

 Incorporate in the agreement appropriate contract exhibits describing the work required,
deliverables, support, and training (see Annex A, Checklist 2) and the acceptance requirements (see
Annex A, Checklist 7, Checklist 1 0, and Checklist 1 2).

5. 6. 3. 5 Revi ew con tract provi si on s wi th l eg al cou n sel

During the review of the contract provisions, modify existing provisions in the agreement as required.
When these modifications affect any of the intellectual property or other legal provisions, then these
modified provisions should be reviewed with the organization’ s legal counsel.

 SaaS : When renting access to a software product, typically a Service Level Agreement is involved
as part of the contracting effort.

 OTS : When buying an OTS product, not only are contracts involved, but purchase agreements and
license agreements typically are also required. It is important that the consequences of these
various contractual devices are well understood.

 Custom-developed: In custom-developed systems, a documents needing legal counsel review (i. e. ,

SOW, data rights, purchase agreements, license agreements, IP) are required. For government
acquisition, regulations such as the Federal Acquisition Regulation (FAR) are important to
understand and incorporate.

19
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.7 Step 5: Evaluating proposals and selecting the supplier

5.7.1 Purpose
The purpose is to confirm that a skilled and responsible supplier is selected. The supplier qualification and
selection process is established as a part of the software acquisition process.

a) Evaluate supplier proposals.

b) Visit supplier facilities.

c) Select a qualified supplier.

d) Negotiate the contract.

5.7.2 Outcomes
The outcomes of Step 5 are as follows:

 An evaluation report on proposals submitted is produced.

 A qualified and preferred supplier is selected.

 A contract between acquirer and supplier is negotiated and signed.

5.7.3 Activities and tasks

5.7.3.1 Evaluate supplier proposals

Use the evaluation criteria established in the acquirer’ s proposal evaluation standards to review supplier’ s
responsiveness to the software requirements, deliverables, and software support requirements described in
the RFP. Consider the supplier’ s management qualifications, technical approach, quality assurance
program, and proposed cost estimate.

If the supplier proposes the use of existing software products, the list of questions in Annex A, Checklist
1 0, may be helpful.

Consider any results observed during supplier demonstrations at the supplier’ s site or the acquirer’ s site,
and supplier facility visits.

Determine for whom the supplier has produced work. Solicit comments from the supplier’ s prior
customers. The questions in Annex A, Checklist 6, may be used as a guide.

Costs should be compared to other supplier’ s prices and schedules. Caution should be exercised when the
supplier’ s proposed costs are much higher or lower than the average of all costs received.

Suppliers that are not completely responsive to the requirements in the RFP should be eliminated from
further consideration.

20
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.7.3.2 Visit supplier facilities

During the proposal evaluation period, visit supplier facilities to investigate and evaluate various factors,
including financial position, technical capability, experience, and quality practices. See Annex A, Checklist
3, for ideas on evaluating supplier capabilities.

Determine whether supplier’ s staff has experience with the problem domain for the software to be acquired,
the required languages, and with the software and hardware to be used during development. Review
resumes of personnel who would be assigned to the project and conduct interviews, if needed.

Determine whether any changes are under consideration that might impact the progress of the development
project, i.e., changes in organization, moving of supplier offices, or change in ownership.

5.7.3.3 Select a qualified supplier

Summarize the results achieved from supplier evaluations, demonstrations, and visits to supplier facilities
and compare the results against the proposal evaluation standards. Select a qualified supplier from the best
two or three candidates and begin negotiations.

5.7.3.4 Negotiate the contract

Negotiate the contract to develop, produce, and/or deliver the software with the supplier representative who
has final negotiating authority. Negotiations should be based upon the existence of adequate written
specifications; a definition of the obligations and responsibilities of the supplier and acquirer; the time
frames in which the work is to be accomplished; and a balance of the responsibilities, risks, and benefits to
both parties.

During the negotiating process, identify any problems and misunderstandings, examine potential
uncertainties, allocate the risks, and protect both parties. Consideration should be given to the following
when negotiating the contract:

a) Provide a means of avoiding disputes and of resolving disputes that may arise
b) Provide for investing only a minimum amount of funds before the quality of the supplier’ s work or
product is demonstrated
c) Provide for a maximum total price, payment amounts, or total value of the contract

Confirm the right of using intellectual property of acquired software and the remedy process if intellectual
property infringement occurs on the acquired software to protect acquirer’ s product delivery.

The acquirer should negotiate necessary maintenance supplements with the supplier to extend the
acquisition software lifecycle though the sustainability is not included in the acquisition process.

Define the process of invoking and escalating urgent/critical events (delivery schedule slipped,
critical/quality issue, payment delay, response time, etc.) to the supplier management for prioritization and
resolution.

The review comments from business, finance, legal, procurement, and technical stakeholders should be
consolidated for negotiation reference.

Compare contract against related or previous contracts for organization acquisition policy/strategy
consistency.

21
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

The acquirer should adj ust the contract consideration in accordance with custom-developed/OTS /SaaS
acquisition model.

If negotiations with the selected supplier fail to produce a contract that will assure delivery of a quality
product on time and properly supported, consider opening negotiations with an alternate supplier.

5.8 Step 6: Managing for supplier performance

5.8.1 Purpose
The purpose of managing for supplier performance is to determine the status of the work and process
execution to help assure that performance is consistent with the agreement and milestones are met.

5.8.2 Outcomes
The outcomes of Step 6 are as follows:

 Performance measures or assessment results are available.

 Adequacy of roles and accountabilities is assessed.

 Agreement obj ectives are achieved.

 Accountability in carrying out proj ect activities and tasks.

 Issues (including problems) in proj ect execution are managed.

5.8.3 Activities and tasks

The acquirer and supplier should cooperate within the agreed terms of the contract. The acquirer should
manage delivery of the software product through reviews and audits as specified in the agreement. The
frequency of reviews depends on the size, risk, and previous performance of the effort (ISO/IEC/IEEE
1 2207). Consideration should be given to the following when managing a contract:

a) The acquirer should provide any required work product (e. g. , equipment, software, machine time,
and reference materials) to the supplier within the specified time frames so that the supplier is not
delayed. When provided, the work products should be complete and accurate to provide a basis for
the supplier’ s work. Any discrepancies should be dealt with immediately.

b) Management should create an environment within the organization that supports the supplier’ s
efforts. Internal disagreements should be resolved in-house by management and not left for the
supplier to encounter.

c) An individual should be appointed to deal with the supplier on all aspects of the contract. If
possible, the same person who previously worked with the supplier should be kept on the proj ect
throughout the contract. All discovered problems should be resolved. The individual appointed to
deal with the supplier will be responsible for confirming that all discovered problems (e. g. , during
the reviews) “are identified, analyzed, managed, and controlled to resolution” (ISO/IEC/IEEE
1 2207).

d) An open line of communication should be maintained with the supplier. A representative of the
acquirer should be closely involved in the development and provide continuous feedback to the
acquirer. Undocumented informal communication can lead to additional costs; therefore any
changes in the scope of work should be handled by amending the contract.

22
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

e) Depending on the type of contract, performance information can be used for award fees
determination. Consideration should be given to the following when monitoring supplier progress:

1) The representative of the acquirer closely involved in all the development should participate
in the planning of each iteration, at development reviews at the end of each iteration (or other
segment of work), and manage the delivery of contract products yet to be delivered.

2) Use measures (e. g. , of reliability) specified in the contract to evaluate the supplier’ s work.

f) Regular and continuous feedback to the supplier on supplier performance (see Annex A, Checklist
7) in terms of overall progress and on handling problems, should be provided.

g) The acquirer should maintain a process for risk management in order to manage the risk of contract
default.

5.9 Step 7: Accepting the software

5.9.1 Purpose
The purpose of software acceptance is to manage the acceptance of the software product by the acquirer by
following an acceptance testing process that has been agreed to by both the acquirer and supplier.
Acceptance begins when the acquirer receives the completed product. The acquirer determines whether the
product meets all functional, performance, and non-functional requirements. This process may include
tests conducted in the supplier’ s development environment and tests conducted in the acquirer’ s operational
environment. When the acquirer has determined that the software product meets the requirements of the
contract, the software product is accepted, including any documentation or other support provided from the
supplier. Before accepting the software, the processes in 5 . 9. 2 through 5 . 9. 4 should be completed.

5.9.2 Outcomes
The outcomes of Step 7 are as follows:

 An acceptance testing report on delivered software solution is produced.

 Decision to accept, rej ect or make changes to the delivered software solution is made.

5.9.3 Activities and tasks

5.9.3.1 Review and update the acceptance criteria

The obj ective is to confirm that all acceptance criteria have been satisfied. Review and update the
acceptance criteria for the software product. When the software is ready to be accepted, Annex A,
Checklist 1 2, may be used. All remedies should be reviewed in case the supplier fails to perform. When
accepting software, final payment should not be made to the supplier until it has been certified that all the
software deliverables meet contract specifications and that all acceptance criteria have been satisfied. If
nonperformance is encountered, exercise the contract provisions to withhold or reduce payments to the
supplier. To minimize losses and time delays, if the contract is terminated, exercise the acquirer’ s
contingency plans.

23
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

5.9.3.2 Conduct a review and test of the software

The obj ective is to review and test to confirm that the software meets contract specifications. Software
testing is beyond the scope of this document, ISO/IEC/IEEE 291 1 9 parts 1 to 4, and IEEE Std 1 01 2™ [B6]
provide requirements and guidance. Consideration should be given to the following when reviewing and
testing the software:

a) Acceptance criteria provided as a part of supplier performance standards should be kept meaningful
and current.

b) Evaluations and tests should be conducted to detect the differences between existing and required
conditions and to evaluate the features of the software (e. g. , conformance to specifications,
standards, performance, portability, or functionality).

c) Consideration should be given to conducting a system-level test, particularly when the software is
to be used in another system. Once it has been determined the test is needed, then it should be
included in the acceptance criteria.

d) Final acceptance criteria should include testing results to verify conformance to standards,
performance, and quality of the software in a user environment.

e) The quality, conformance to standards and maintenance plans developed for the proj ect should be
used in evaluating and accepting the software and services provided by the supplier.

5.9.3.3 Manage the testing process

The acquirer should confirm that an appropriate amount of effort and cost is applied to ensure high-quality
software. Consideration should be given to the following during software testing:

a) When evaluating a software product, the list of questions in Annex A, Checklist 1 0, may be helpful
in considering significant factors that would have some impact on the quality of the product. This
list is also useful when preparing requirements for a fully developed software effort (see 5 . 5 . 1 ).
This list may be tailored by adding other factors and questions that are important to the acquirer’ s
organization.

b) When testing a software product, the acquirer should have a role in the testing process. Annex A,
Checklist 1 1 , may be used in defining that role.

5.9.4 Document the test results

The acquirer should update and review the test results against the software specifications. The review
should include: conformance to specifications, standards, performance, portability and functionality. Test
results should be used as the acceptance or rej ection of the software.

5.1 0 Step 8: Evaluating the process and identifying improvement opportunities

5.1 0.1 Purpose

The purpose of the acquisition evaluation is

 To assess how well the software solution meets the identified need and software requirements

 To assess how well the software acquisition process was handled and suggest improvements
otherwise.

24
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

An analysis should be conducted on the software acquisition contract to evaluate contracting practices,
evaluate product quality, notably quality in use, as for example, user satisfaction with the product, and
evaluate supplier performance. The evaluation should result in usable information for future acquisitions.

5.1 0.2 Outcomes

The outcomes of Step 8 are as follows:

 Contracting processes are evaluated and reviewed.

 Acquired software product is evaluated.

 Supplier performance is evaluated.

 A detailed evaluation report is produced.

5.1 0.3 Activities and tasks

5.1 0.3.1 Evaluate contracting practices

Consideration should be given to the following when evaluating contracting practices:

a) Identify practices that are ineffective or inefficient and need to be changed.

b) Identify and retain practices that produced good results.

c) Identify additional practices that need to be developed and implemented.

5.1 0.3.2 Evaluate software product quality

The obj ective is to determine the quality of the deployed product. Before starting to evaluate product
quality, the acquirer should define the criteria for the evaluation starting with the criteria defined in Step 1
(5 . 3 ) and written in the contract agreement. Emphasis should be placed on quality in use and user
satisfaction in particular. Acquirers are advised to follow models like IS O/IEC 25 000 series for product
quality.

Consideration should be given to the following when assessing product quality:

a) Evaluate user satisfaction with the software.

b) Record the actual amount of software maintenance work that is needed after the software is put into
use.

c) Record data about other software product qualities that in the minimum should be the specified in
the contract agreement. A product quality model and measures are defined in the ISO/IEC 25 000
families of standards, particularly the quality in use model. A product evaluation process for
acquires is described in ISO/IEC 1 45 98 -4 that can be used with the IS O/IEC 25 000 families.

d) Follow the organization defined measurement process.

5.1 0.3.3 Evaluate supplier performance

When evaluating supplier performance, retain performance data (from Step 7) on the individual supplier for
future reference. Also, record the maturity level, or capability levels of the supplier. This information could
be obtained, for example, from a software process evaluation of the possible suppliers during contracting.

25
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

6. Qu al i ty as s u ran ce for s oftware acq u i s i ti on

6. 1 Obj ecti ves of q u al i ty as s u ran ce i n s oftware acq u i s i ti on

The acquisition of software should aim to achieve the desired or intended acquirer goals and obj ectives.
Quality assurance (QA) in the acquisition of software facilitates the achievement of the goal(s) through of
the following (specific obj ectives):

 Reducing risk in the software acquisition processes and activities.

 Ensuring the acquired software solution conforms to requirements and are acceptable to the
acquirer and end user.

 Enabling acquirer selection teams to identify contractors whose methodologies and processes in
architecting and delivering software solutions are compliant with known standards and are most
likely to produce the desired results.

6. 2 I m pl em en ti n g q u al i ty as s u ran ce i n s oftware acq u i s i ti on

It is recommended that QA activities be performed in every step of the software acquisition process. The
quality assurance approach will depend on the software acquisition option that is chosen or implemented.
A detailed quality assurance plan reflective of the software acquisition option is necessary to detail specific
quality assurance activities during the software acquisition process. These activities help ensure the
acquisition processes and methods are monitored and evaluated to avoid mistakes or defects. Such activities
may simply involve checking activities/processes/results of a given stage /process against known ISO/IEC
and IEEE standards.

Table 3 includes recommended quality assurance activities for each step in the software acquisition
process.

26
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

Tabl e 3 —Recom m en d ed q u al i ty assu ran ce acti vi ti es

Steps in software Recommended quality Applicable

acquisition process assurance activities standards/guidelines
Step 1 . Planning the software 1. Check completeness and PMBOK

acquisition strategy (5. 3 ) compliance of the defined ISO/IEC/IEEE 1 2207

strategy/approach ISO/IEC 1 63 26 [B1 3 ]
2. Compile quality assurance plan.

Step 2. Defining the acquisition and 1. Check that requirements ISO/IEC 291 48

software requirements (5. 4) specifications are unambiguous

and comply with standards.

Step 3 . Identifying potential suppliers 1. Check compliance of potential ISO/IEC 291 1 0 [B1 7]

(5. 5 ) supplier’ s processes against known ISO/IEC 1 5 5 04-2 [B1 1 ]

standards to determine level of ISO/IEC 1 5 5 04-5 [B1 2]
likelihood to succeed. IEEE Std 1 01 2 [B6]
2. Evaluate capability of potential
supplier in terms of software
development service delivery
record.

Step 4. Preparing contract 1. Check completeness of contract ISO/IEC/IEEE 1 2207

requirements (5. 6) specification and seek legal advice.

Step 5 . Evaluating proposals and 1. Check solution against

selecting the supplier (5 . 7) requirements.

Step 6. Managing for supplier 1. Evaluate software/solution design ISO/IEC/IEEE 1 2207

performance (5 . 8) and trace to requirements. ISO/IEC/IEEE 1 2207

2. Evaluate database design and trace IEEE Std 1 01 2 [B6]
to requirements.

Step 7. Accepting the software (5. 9) 1. Assemble user acceptance test ISO/IEC 25051 [B1 5 ]
cases to support verification of ISO/IEC/IEEE 291 1 9 [B1 0]
requirements. IEEE Std 1 01 2 [B6]
2. Evaluate results of acceptance tests IEEE Std 73 0 [B4]
conducted using the acceptance test
cases.
3. Check completeness of user
manuals.

Step 8. Evaluating the process and 1. Monitor performance against ISO/IEC/IEEE 1 2207

identifying improvement opportunities requirements. ISO/IEC/IEEE 1 5 288

2. Monitor and observe quality in use ISO/IEC 25050 [B1 3 ]
(5 . 1 0)

27
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I EEE Std 1 062-201 5

I EEE Recomm end ed Practi ce for Software Acq u i si ti on

Annex A

(i n formati ve)

Checkl i sts for qu ali ty software acqu i si ti on processes

Checklists in this annex are provided to assist organizations in establishing an organization’ s own software
acquisition process. These checklists are intended to help organizations think about relevant issues to
specific organization and software acquisition efforts. The checklists are not applicable to every acquisition
and should be tailored to a specific software acquisition effort.

Tabl e A. 1 —C h eckl i sts su pporti n g th e ei g h t steps i n acq u i ri n g software

Steps in software acquisition process Checklists

Step 1 . Planning the software acquisition strategy (5 . 3 ) A. 1 Organizational strategy

Step 2. Defining the acquisition and software requirements. (5. 4) A. 2 Define the software
A. 3 Supplier selection evaluation
A. 4 Supplier and acquirer obligations
A. 5 Quality and maintenance plans
Step 3 . Identifying potential suppliers (5. 5 ) A. 1 Organizational strategy
A. 3 Supplier selection evaluation
A. 6 User survey

Step 4. Preparing contract requirements (5. 6) A. 2 Define the software

A. 4 Supplier and acquirer obligations
A. 5 Quality and maintenance plans
A. 7 Supplier performance standards
A. 8 Contract payments
A. 1 0 Software evaluation

Step 5 . Evaluating proposals and selecting the supplier (5 . 7) A. 7 Supplier performance standards
A. 9 Monitor supplier progress

Step 6. Managing for supplier performance (5. 8) A. 7 Supplier performance standards

A. 9 Monitor supplier progress

Step 7. Accepting the software (5 . 9) A. 1 0 Software evaluation

A. 1 1 Software testing
A. 1 2 Software acceptance

28
Copyrig h t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.1 Checklist 1 : Organizational strategy

a) Who is the preferred party to provide software support? Supplier ❐ ❐
Acquirer

b) Is maintenance documentation necessary? Yes ❐ No ❐

c) Should user training be provided by the supplier? Yes ❐ No ❐

d) Will acquirer’ s personnel need training? Yes ❐ No ❐

e) When software conversion or modi fi cation is planned:

1) Will supplier manuals sufficiently describe the supplier’ s software? Yes ❐ No ❐

2) Will speci fi cations be necessary to describe the conversion or Yes ❐ No ❐
modi fi cation requirements and the implementation details of the
conversion or modi fi cation?

3) Who will provide these speci fications? Supplier ❐ Acquirer ❐

4) Who should approve these speci fi cations? Yes ❐ No ❐
f) Should source code be provided by the supplier so that modi fi cations Yes ❐ No ❐
can be made?
g) Who will own the IP (Intellectual property) for the software product

h) Are supplier publications suitable for end users? Yes ❐ No ❐

1) Will unique publications be necessary? Yes ❐ No ❐

2) Will unique publications require formal acceptance? Yes ❐ No ❐

3) Are there copyright or royalty issues? Yes ❐ No ❐

i) Will the software be evaluated and certi fi ed? Yes ❐ No ❐

1) Is a survey of the supplier’ s existing customers sufficient? Yes ❐ No ❐

2) Are reviews and audits desirable? Yes ❐ No ❐

3) Is a testing period preferable to demonstrate that the software and Yes ❐ No ❐
its associated documentation are usable in the intended environment?
4) Where will the testing be performed? ____________________________________________

5) Who will perform the testing? __________________________________________________

6) When will the software be ready for acceptance? ___________________________________

j) Will supplier support be necessary during initial installations of the
software by end users? Yes ❐ No ❐
k) Will subsequent releases of the software be made? Yes ❐ No ❐

1) If so, how many? __________________________________________________

2) Will there be compatibility with each other? Yes ❐ No ❐
l) Will the acquired software require rework whenever operating system
changes occur? Yes ❐ No ❐
1) If so, how will the rework be accomplished? _______________________________________

29
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.2 Checklist 2: Define the software

a) When is the software required? ____________________________________________________
b) What is the budget for the software? ________________________________________________
c) What are the key functions the software should perform ______________________________________
d) What are the key organizational capabilities needed to produce the software? ________________
e) What are the key responsibilities of the acquirer? _______________________________________
f) What are the key responsibilities of the supplier? _______________________________________
g) What are some options for the software solution, and what are the risks and benefits of each potential
solution? _______________________________________________________________________
h) Rate the importance of the following aspects of the software being acquired

1) Functional specification Important ❐ Not Important ❐

2) Capability specification including performance, Important ❐ Not Important ❐
physical characteristics, and environmental conditions
under which the software is to perform.
3) Interfaces external to the system and software Important ❐ Not Important ❐
4) Qualification requirements Important ❐ Not Important ❐
5) Safety specifications including those related to Important ❐ Not Important ❐
methods of operation and maintenance, environmental
influences, and personnel inj ury.
6) Security specifications including those related to Important ❐ Not Important ❐
compromise of sensitive information
7) Human-factors engineering (ergonomics) specifications Important ❐ Not Important ❐
including those related to manual operations,
human-equipment interactions, constraints on
personnel, and areas needing concentrated human
attention, that are sensitive to human errors and
training
8) Data definitions and database requirements Important ❐ Not Important ❐
9) Installation and acceptance requirements of the Important ❐ Not Important ❐
delivered software product at the operation and
maintenance site(s).
1 0) User documentation requirements. Important ❐ Not Important ❐
11) User operation and execution requirements. Important ❐ Not Important ❐

1 2) User maintenance requirements. Important ❐ Not Important ❐

1 3) Any known constraints or parameters Important ❐ Not Important ❐

i) Rate the importance of the deliverables to be included with the software being defined and who is
responsible for the format of each deliverable

1) Software architecture Important ❐ Not Important ❐

Acquirer format ❐ Supplier format ❐
2) Software design documentation Important ❐ Not Important ❐
(including database design, if relevant) Acquirer format ❐ Supplier format ❐

30
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

3) Software description Important ❐ Not Important ❐

Acquirer format ❐ Supplier format ❐
4) Source code listings Important ❐ Not Important ❐
Acquirer format ❐ Supplier format ❐
5) User documentation Important ❐Not Important ❐
(ISO/IEC/IEEE 2651 4 should be used to create Acquirer format ❐Supplier format ❐
user documentation)

6) Support documentation Important ❐ Not Important ❐

Acquirer format ❐ Supplier format ❐
7) Sales and promotional material Important ❐ Not Important ❐
Acquirer format ❐ Supplier format ❐
8) List of current users (existing software product) Important ❐ Not Important ❐
Acquirer format ❐ Supplier format ❐
9) Off-the-shelf product documentation Important ❐ Not Important ❐
Acquirer format ❐ Supplier format ❐
1 0) Software release documentation Important ❐ Not Important ❐
Acquirer format ❐ Supplier format ❐
11) Software test documentation Important ❐ Not Important ❐
Acquirer format ❐ Supplier format ❐

j) Rate the importance of the software support to be provided with the software being defined

1) User training Important ❐ Not Important ❐

2) Internal training Important ❐ Not Important ❐

3) Installation support Important ❐ Not Important ❐

4) Post-installation support Important ❐ Not Important ❐

5) Correction of errors Important ❐ Not Important ❐

6) Modifications, when requested Important ❐ Not Important ❐

7) Software warranty Important ❐ Not Important ❐

8) Documentation warranty Important ❐ Not Important ❐

9) New releases of the software Important ❐ Not Important ❐

1 0) Free and open source software (FOSS) products used Important ❐ Not Important ❐

31
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.3 Checklist 3: Supplier selection evaluation

Financial soundness
a) Can a current financial statement be obtained for examination? Yes No ❐ ❐
b) Is an independent financial rating available? Yes No ❐ ❐
c) Has the company or any of its principals ever been involved
in bankruptcy or computer-related litigation? Yes No ❐ ❐
d) How long has the company been in business? _________________________________________
e) What is the company’ s history? ____________________________________________________

Experience and capabilities

a) List by job function the number of people in the company. _______________________________
b) List the names of sales and technical representatives
and contact persons for support. ___________________________________________________
c) Can they be interviewed? Yes No ❐ ❐
d) List the supplier’ s software products that are sold and the number of
installations of each. ____________________________________________________________
3) Is a list of users available? Yes No ❐ ❐
Development and control processes
a) Are software development practices and standards used? Yes No ❐ ❐
b) Are software development practices and standards adequate? Yes No ❐ ❐
c) Are the currently used practices written down? Yes No ❐ ❐
d) Are documentation guidelines available? Yes No ❐ ❐
e) How is testing accomplished? _____________________________________________________
f) Are the security procedures adequate? Yes No ❐ ❐
g) Does the supplier have any software related certifications
or maturity/capability level ratings? Yes No ❐ ❐
List the certifications and/reference models and ratings achieved _________________________

Technical assistance
a) What assistance is provided at the installation time?
b) Can staff training be conducted on site? Yes No ❐ ❐
c) To what extent can the software and documentation be modified
to meet user requirements? ________________________________________________________
d) Who will make changes to the software and documentation? _____________________________
e) Will modification invalidate the warranty? Yes No ❐ ❐
f) Are any enhancements (software and documentation) planned or in process? Yes No ❐ ❐
g) Will future enhancements be made available? Yes No ❐ ❐
Quality practices
a) Are the development and control processes followed? Yes ❐ No ❐
b) Are requirements, design, and code reviews used? Yes ❐ No ❐
c) If requirements, design, and code reviews are used, are they effective? Yes ❐ No ❐
d) Is a total quality program in place? Yes ❐ No ❐
e) If a total quality program is in place, is it documented? Yes ❐ No ❐
f) Does the quality program assure the product meets specifications? Yes ❐ No ❐
g) Is a corrective action process established to handle error corrections
and technical questions? Yes ❐ No ❐
h) Is a configuration management process established? Yes ❐ No ❐

32
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

Maintenance service
a) Is there a guarantee in writing about the level and quality of maintenance
services provided? Yes No ❐ ❐
b) Will ongoing updates and error conditions with appropriate
documentation be supplied? Yes No ❐ ❐
c) Who will implement the updates and error corrections? _________________________________
d) How and where will the updates and error corrections be implemented? ____________________
e) What turnaround time can be expected for error corrections? _____________________________

Product usage

a) Can a demonstration of the software be made at a user site? Yes No ❐ ❐

b) Are there restrictions on the purposes for which the product may be used? Yes No ❐ ❐
c) What is the delay between order placement and delivery of the product? ____________________
d) Can documentation be obtained for examination now? Yes No ❐ ❐
e) How many versions or releases of the software are there? ________________________________

Product warran ty

a) Is there a warranty period? Yes No ❐ ❐

b) What are the warranty conditions? __________________________________________________
c) Does successful execution of an agreed-upon acceptance test initiate the
warranty period? Yes No ❐ ❐
d) Does a warranty period provide for a specified level of software
product performance for a given period at the premises where it is installed? Yes No ❐ ❐
e) How long is the warranty period? ___________________________________________________

Costs
a) What pricing arrangements are available? ____________________________________________
b) What are the license terms and renewal provisions? ____________________________________
c) What is included in the acquisition price or license fee? _________________________________
d) What costs, if any, are associated with a warranty period? _______________________________
e) What is the cost of maintenance after the warranty period? ______________________________
f) What is the cost of modifications? __________________________________________________
g) What is the cost of enhancements? _________________________________________________
h) Are updates and error corrections provided at no cost? Yes No ❐ ❐
Contracts

a) Is a standard contract used? Yes No ❐ ❐

b) Can a contract be obtained now for examination? Yes No ❐ ❐
c) Are contract terms negotiable? Yes No ❐ ❐
d) Are there royalty issues? Yes No ❐ ❐
e) What obj ections, if any, are there to attaching a copy of these checklist
questions with responses to a contract? _____________________________________________

Oth er legal/regulatory issues

a) Who owns the intellectual property of the software designs? _____________________________
b) Is the software under any form of export control? Yes No ❐ ❐

33
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.4 Checklist 4: Supplier and acquirer obligations

a) Definition of software development framework

1) Were development steps to be accomplished by the supplier identified? Yes ❐ No ❐

2) Was a product (deliverable) included at the end of each step that demonstrates
that the step has been satisfactorily completed, e.g., surveys, feasibility studies,
development plans, architecture and detail designs, test data and test plans, the
actual programs, user documentation, support publications, and
integration/acceptance test results? Yes ❐ No ❐
3) Were milestones that should be satisfied before the development is allowed to
continue to the next step identified? Yes ❐ No ❐
4) Were the acquirer obligations included in the same milestone chart as
the supplier obligations? Yes ❐ No ❐
b) Definition of the relationships between the supplier and acquirer

1) Were the relationships between the supplier and acquirer identified? Yes❐ No ❐
2) Were responsibilities for each task identified? Yes ❐ No ❐

c) Who is responsible for the following?

1) Publication and expense of user documentation Supplier ❐ Acquirer❐ N/A ❐

2) Publicity releases Supplier ❐ Acquirer ❐ N/A ❐

3) Software distribution to end users Supplier ❐ Acquirer ❐ N/A ❐

4) Notices and reports, if specified Supplier ❐ Acquirer ❐ N/A ❐

5) New software that replaces old software Supplier ❐ Acquirer ❐ N/A ❐

6) Appointment of a representative for

Supplier____________________________________________________
Acquirer____________________________________________________

34
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.5 Checklist 5: Quality and maintenance plans

Identify the contents of a quality plan .
a) What are the quality obj ectives?
1 ) Documentation is usable. Yes ❐ No ❐
2) Warranty is adequate. Yes ❐ No ❐
3) Software possesses functional capabilities that are required. Yes ❐ No ❐
4) Software is verified to properly perform its functional capabilities. Yes ❐ No ❐
b) What are the evaluations and tests planned to satisfy the quality obj ectives?
1 ) Demonstration Yes ❐ No ❐
2) User survey Yes ❐ No ❐
3 ) Inspection Yes ❐ No ❐
4) Test Yes ❐ No ❐
5) Documentation review Yes ❐ No ❐
c) Who is responsible for conducting the evaluations and tests?
1 ) Supplier Yes ❐ No ❐
2) Acquirer Yes ❐ No ❐
3 ) Third party Yes ❐ No ❐
d) For which of the following items is test documentation required?
1 ) Test plans Yes ❐ No ❐
2) Test procedure Yes ❐ No ❐
3 ) Test data Yes ❐ No ❐
4) Test results Yes ❐ No ❐
Iden tify what a main tenan ce plan should con tain.
a) What are the maintenance obj ectives?
1 ) Support documentation is usable. Yes ❐ No ❐
2) Technical support is available. Yes ❐ No ❐
b) What is included in the technical support?
1 ) Error corrections Yes ❐ No ❐
2) Modifications Yes ❐ No ❐
3) New releases of software Yes ❐ No ❐
4) Updating of user documentation Yes ❐ No ❐
5) Installation assistance Yes ❐ No ❐
6) Training Yes ❐ No ❐
c) The responsibility of providing technical support on a timely basis.
1 ) Who provides technical support during the Supplier ❐ Acquirer ❐ Third- party ❐
warranty period?
2) Who provides technical support after the Supplier ❐ Acquirer ❐ Third- party ❐
warranty period?
3 ) Who pays for the cost of the technical support? Supplier ❐ Acquirer ❐ Third- party ❐
d) What acquirer responsibilities are obtained or satisfied by other organizations?
1 ) Internal organization(s) Yes ❐ No ❐
2) Third party Yes ❐ No ❐

35
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.6 Checklist 6: User survey

Operation

a) Is the system easy to use? Yes ❐ No ❐

b) What is the level of technical knowledge required to use and maintain
the system? _______________________________________________________________
c) Have there been any serious operator complaints? Yes ❐ No ❐
d) Was adequate operator and support training given? Yes ❐ No ❐
e) How long did it take the acquirer’ s operator to become familiar with
the system? ________________________________________________________________

Reliability

a) How long has the system been in use? __________________________________________

b) During this time, how many updates, error corrections, and enhancements
have there been? ____________________________________________________________
c) Was the documentation supplied? Yes ❐ No ❐
d) How many errors have been encountered during this time? __________________________
e) What parts of the system are particularly error-prone? ______________________________
f) What other parts of the system have become unusable and for how
long? _____________________________________________________________________
g) What errors can be made that will bring the system down? __________________________
h) In the event of an error, are there any recovery procedures? Yes ❐ No ❐
i) How long does it take for recovery? ____________________________________________
j) Is a diagnostic package available on site to verify that the system Yes ❐ No ❐
functions properly?
k) Are supplier backup facilities available? Yes ❐ No ❐

Mainten ance service

a) How reliable and accessible is the supplier? ______________________________________

b) Are supplier person personnel competent in solving problems? Yes ❐ No ❐
c) What is the average turnaround time between an error report call
and the supplier’ s response? ___________________________________________________
d) Are backup procedures adequate? Yes ❐ No ❐
e) How long does backup take? __________________________________________________

Performan ce

a) What are the daily transaction volumes? _________________________________________

b) How long does daily processing take? ___________________________________________
c) What size are the acquirer’ s files? ___________________ ___________________________
d) How many users can be on the system before response time becomes
sluggish, and how serious is the degradation? _____________________________________
e) How have multiple-user degradation problems been solved? _________________________
f) Is the acquirer’ s print capacity adequate? Yes ❐ No ❐
g) Are there any terminal lockouts when the printer is running? Yes ❐ No ❐
h) What is the envisioned response time? __________________________________________

36
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

Flexibility
a) What software product modifications have been done? _____________________________
b) Who did the modifications? __________________________________________________
c) Are changes done on site? Yes ❐ No ❐
d) If the changes are not done on site, where are they done? ___________________________
e) How long did changes in each area take? ________________________________________
f) What fully developed software has been added? ___________________________________
g) Who added the software? _____________________________________________________
h) How long did it take? _______________________________________________________
i) Were there any interface problems? Yes ❐ No ❐
j ) How has the system been expanded or upgraded? ________________________________
k) How successful was the conversion? __________________________________________
l) How much time was involved? _______________________________________________
m) How much cost was involved? _______________________________________________
n) How many personnel were involved? __________________________________________

Installation
a) Was the system installed as planned? Yes ❐ No ❐
b) How long did installation take? ________________________________________________
c) How much did installation cost? _______________________________________________
d) Was supplier installation training adequate? Yes ❐ No ❐
e) Was supplier installation support competent and complete? Yes ❐ No ❐
f) Was the system cut over smoothly? Yes ❐ No ❐
g) What anomalies, if any, marred the installation? __________________________________
h) What environmental changes were required to install the system? ____________________

Costs
a) What unanticipated charges were incurred during installation
and training? _______________________________________________________________
b) What unanticipated charges were incurred after installation
and training? _______________________________________________________________
c) Is the acquirer’ s service agreement cost-effective? Yes ❐ No ❐
d) What have new product enhancements from the supplier cost? _______________________
e) What charges, if any, have been incurred to update or correct software? ________________
f) How much does customized software work cost? __________________________________
g) Does customized software work also include updated documentation? Yes ❐ No ❐
h) In what areas is the system to be
most cost-effective? _________________________________________________________
i) In what areas is the system to be
least cost-effective? __________________________________________________________

37
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

Security

a) Are user and file security levels adequate? Yes ❐ No ❐

b) Can unauthorized transactions or programs be run? Yes ❐ No ❐
c) Are accounting audit controls satisfactory? Yes ❐ No ❐
d) Do accounting audit controls satisfy the acquirer’ s accountant? Yes ❐ No ❐

Docum entation

a) Is the documentation accurate? Yes ❐ No ❐

b) Is the documentation adequate? Yes ❐ No ❐
c) Is the documentation kept up to date? Yes ❐ No ❐

Miscellan eous

a) Why was the system purchased? _______________________________________________

b) Would the system be bought today if you were in the market for a system? Yes ❐ No ❐
c) What changes would you make? _______________________________________________
d) What changes do you think realistically could have been
implemented? ______________________________________________________________
e) What did you learn from other users of the system? ________________________________

38
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.7 Checklist 7: Supplier performance standards

Describe what constitutes satisfactory performance by the supplier. Satisfactory performance should be
quantified in terms of all known requirements and constraints.

Performan ce criteria

a) Approach to meet software functional requirements is defined. Yes ❐ No ❐

b) Approach to meet software quality requirements is defined. Yes ❐ No ❐
c) Growth potential or expansion requirements of the system are defined. Yes ❐ No ❐
d) Test and acceptance criteria that are to be met are defined. Yes ❐ No ❐
e) Programming language and design practices to be followed are defined. Yes ❐ No ❐
f) Documentation standards to be followed are defined. Yes ❐ No ❐
g) Ease of modification, including the correction of vulnerabilities, is addressed. Yes ❐ No ❐
h) Maximum computer resources allowed, such as memory size and number of
users, are defined. Yes ❐ No ❐
i) Throughput requirements are defined. Yes ❐ No ❐
Evaluation and test

a) Software possesses all the functional capabilities required. Yes ❐ No ❐

b) Software was tested for security vulnerabilities. Yes ❐ No ❐
c) Software performs each functional capability as verified by the following method(s):
⎯ Documentation evaluation Yes ❐ No ❐

⎯ Demonstration Yes ❐ No ❐

⎯ User survey Yes ❐ No ❐

⎯ Test Yes ❐ No ❐

⎯ Some formal method Yes ❐ No ❐

⎯ Results of the performed reviews Yes ❐ No ❐

d) Software errors and vulnerabilities revealed are documented. Yes ❐ No ❐
e) Software performs all system-level capabilities as verified by a system test. Yes ❐ No ❐

Correction of discrepan cies

a) Supplier documents all identified discrepancies. Yes ❐ No ❐

b) Supplier documents all identified vulnerabilities. Yes ❐ No ❐
c) Supplier establishes discrepancy correction and reporting. Yes ❐ No ❐
d) Supplier indicates warranty provisions for providing prompt and appropriate corrections. Yes ❐ No ❐
A cceptan ce criteria

a) All discrepancies are corrected. Yes ❐ No ❐

b) All detected vulnerabilities are corrected. Yes ❐ No ❐
c) Prompt and appropriate corrections are provided. Yes ❐ No ❐
d) Satisfactory compliance to contract specifications is demonstrated by evaluations
and tests. Yes ❐ No ❐
e) Satisfactory compliance to contract specifications is demonstrated by field tests. Yes ❐ No ❐
f) All deliverable items are provided. Yes ❐ No ❐
g) Corrective procedures are established for correction of errors found after delivery. Yes ❐ No ❐
h) Satisfactory training is provided. Yes ❐ No ❐
i) Satisfactory assistance during initial installation(s) is provided. Yes ❐ No ❐

39
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.8 Checklist 8: Contract payments

Rate the payment provisions that help ensure the maximum chance for success and reward the supplier for
achieving satisfactory progress.

a) Provide for investing only a minimum amount of funds before

the quality of the suppliers work is demonstrated. Important ❐ Not Important ❐
b) Provide separate due dates and costs for each
deliverable. Important ❐ Not Important ❐
c) Identify allowable printing expenses associated with
publishing user documentation. Important ❐ Not Important ❐
d) Identify allowable travel and per diem expenses. Important ❐ Not Important ❐

e) Stagger the frequency and amount of supplier payments

to coincide with maj or milestones, test results, or
achievements. Important ❐ Not Important ❐
f) Identify the amount and method of determining incentive
payments associated with significant results, achievements,
costs, or schedules. Important ❐ Not Important ❐
g) Consider the complexity of the proj ect and the risk in
achieving the contract requirements. Important ❐ Not Important ❐
h) Include a dollar amount limit on royalty payments. Consider
the amount of a fully paid license fee when setting the limit
on royalties. Important ❐ Not Important ❐
i) Confirm that payments are limited to those copies of the
software products and deliverables actually provided by the
supplier and are not tied to forecasted quantity or dollar
volumes. Important ❐ Not Important ❐
j ) Withhold payment for incomplete or unacceptable work. Important ❐ Not Important ❐

k) Reduce payment if certain requirements are not met. Important ❐ Not Important ❐

l) Reduce payment to the supplier by the amount of any

deliverables (e.g., documentation) specified in the contract
but not produced. Important ❐ Not Important ❐
m) Withhold as a final payment some reasonable percentage of
the entire contract dollar value to help ensure that the supplier
follows through on all deliverable items and corrects all
discrepancies. Important ❐ Not Important ❐

40
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.9 Checklist 9: Monitor supplier progress

Rate the actions that would confirm adequate visibility of supplier progress.

a) Use the specified time frames that are established in the

contract to determine whether the suppliers development is
on schedule. Important ❐ Not Important ❐
b) Review all work at the end of each completed development
step to determine if it conforms with contract specifications. Important ❐ Not Important ❐
c) Decide if the suppliers approach is technically
feasible. Important ❐ Not Important ❐
d) Render timely management decisions on all alternatives
presented by the supplier. Important ❐ Not Important ❐
e) Once a step is approved, freeze that work step until
development is complete to stabilize the base for
succeeding work steps. Important ❐ Not Important ❐
f) Apply acceptance testing to completed steps as well as at the
end of the development effort. Important ❐ Not Important ❐
g) Use the measures of reliability and quality specified in the
contract during step 5 (see 4.2) of the acquisition process to
evaluate the supplier’ s work. Important ❐ Not Important ❐
h) Assess the suppliers performance in terms of the
satisfactory performance criteria as specified in the
contract during step 5 (see 4.2). Important ❐ Not Important ❐
i) Provide some means for regular and continuous feedback to
the supplier on supplier performance in terms of overall
progress on handling problems. Important ❐ Not Important ❐
j ) Delivering is being done as specified in the
contract (e.g., at the end of each iteration)? Important ❐ Not Important ❐

41
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.1 0 Checklist 1 0: Software evaluation

Functionality
a) Does the basic function of the software meet the acquirer’ s needs? Yes ❐ No ❐
b) Are its overall capabilities consistent with the requirements of the acquirer’ s Yes ❐ No ❐
application?

c) Can the software be run under the acquirer’ s operating system? Yes ❐ No ❐
Performance
a) Is the performance adequate for the acquirer’ s needs? Yes ❐ No ❐
b) Are believable performance figures available? Yes ❐ No ❐

c) How many users can be on the system before it begins to slow down? _________________________

d) What verifiable evidence is available showing that the supplier has tested
performance issues in a suitable environment? ______________________________________________

Reliability
a) Does the product have a clean, modular design? Yes ❐ No ❐
b) Has it been in actual use long enough to make sure that most of its bugs
have been cleaned up? Yes ❐ No ❐
c) Are there errors that a user can make that will bring the system down? Yes ❐ No ❐

d) What are the recovery capabilities? _____________________________________________________

Availability
a) Was the software available for actual use when it was needed? Yes ❐ No ❐
b) Can another user prevent you from using the system? Yes ❐ No ❐

c) How much time is needed to correct errors that bring the system down? ________________________

d) Are recovery capabilities automated? Yes ❐ No ❐

e) How long does recovery take? _________________________________________________________

f) How effectively did the supplier test the product in the acquirer’ s
operational environment? _______________________________________________________________

g) Are software errors caused by problems in performance rather than

function? Yes ❐ No ❐
Ease of modification
a) Are the software’ s input, output, and processing capabilities flexible
enough to accommodate the changing requirements of the acquirer’ s
business? Yes ❐ No ❐
b) Can the software be adapted to new applications? Yes ❐ No ❐

42
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

Serviceability

a) Is the software available in source code form? Yes ❐ No ❐

b) If the supplier will be doing maintenance, how reliable and accessible
is the company? ______________________________________________________________________

c) What level and quality of maintenance will the supplier provide? _____________________________

d) Is this guaranteed in writing? Yes ❐ No ❐

e) Are sets of test data available with adequate documentation about how to
use them and about what results to expect? Yes ❐ No ❐
f) What are the opinions of past and present users? __________________________________________

Ease of installation
a) How difficult will it be to install the software? ____________________________________________

b) What type of training and orientation will be needed? ______________________________________

c) Will data tables need to be converted? Yes ❐ No ❐

d) Can the supplier provide procedures for the installation and conversion process? Yes ❐ No ❐

e) How much assistance will the supplier furnish during the process? ____________________________

Ease of use

a) Will the software be easy to use? Yes ❐ No ❐

b) Is it designed for straightforward operation with a well-documented operating Yes ❐ No ❐
procedure?

c) Are the reports and screen displays it produces reliable, informative, and
easy to interpret? Yes ❐ No ❐
d) Are help screens provided? Yes ❐ No ❐

e) Will the users be enthusiastic about this product? Yes ❐ No ❐

A dequacy of docum entation

a) Is the user documentation complete and up to date? Yes ❐ No ❐

b) Is the user documentation easy to read and understand? Yes ❐ No ❐

Cost to acquire and use

a) What was the total cost of acquiring and using the software product? ____________________________

b) Are direct costs included for the price of the software? Yes ❐ No ❐
c) Are direct costs included for the price of the documentation? Yes ❐ No ❐

d) What is included in the indirect costs?

⎯ Modifying the software ❐

43
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

⎯ Training personnel ❐
⎯ Converting tables ❐
⎯ Installing the software ❐
⎯ Checking out the software ❐
⎯ Operating the software ❐
⎯ Maintaining the software after installation ❐
⎯ Travel expenses ❐

44
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.1 1 Checklist 1 1 : Software testing

Rate the actions needed to maintain adequate control over the software test.

a) Observe or participate in the software test. Important ❐ Not Important ❐

b) Adequately analyze the test results. Important ❐ Not Important ❐

c) Document all errors revealed by the test. Important ❐ Not Important ❐

d) Require the supplier to correct all designated discrepancies

or discrepancy severity categories as a condition for final payment.
(Should be included in the contract.) Important ❐ Not Important ❐
e) Follow up on all designated discrepancies or discrepancy
severity categories to make sure they are
corrected before the software is accepted. Important ❐ Not Important ❐
f) Assure that personnel responsible for the acquirer’ s
acceptance testing of the software have adequate
technical expertise. Important ❐ Not Important ❐
g) Assign qualified personnel with systems, data
processing, and performance evaluation expertise to
test the software. Important ❐ Not Important ❐
h) If personnel with the expertise to adequately evaluate
the software are not available, arrange for an
independent evaluation by outside sources. Important ❐ Not Important ❐

45
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

A.1 2 Checklist 1 2: Software acceptance

a) Rate actions for a certification process.

1) Identify certification steps that are consistent with satisfying the

quality and maintenance objectives documented in the quality
and maintenance plans. Important ❐ Not Important ❐
2) Make sure the acceptance criteria developed from Checklist 7
are consistent with achieving high-quality software as planned
for in the Quality and Maintenance Plans. Important ❐ Not Important ❐
3) Make sure the evaluations and tests are sufficient to
satisfactorily demonstrate that all acceptance criteria can be
achieved, and that the software conforms to contract
specifications Important ❐ Not Important ❐
4) Identify an individual or organization who is responsible for
determining final acceptance of the software from the supplier. Important ❐ Not Important ❐
5) Document the steps involved in certifying the software.
Make sure the checklist for recording the results and
determining final acceptance is current. Important ❐ Not Important ❐
b) Rate actions needed in case the supplier fails to perform.

1) Make sure final payment is not made until

Certification that the software meets contract specifications
And all acceptance criteria have been satisfied Important ❐ Not Important ❐
2) Utilize the contract provisions for withholding or reducing
payments to the supplier if nonperformance occurs Important ❐ Not Important ❐
3) If the contract is terminated, notify the sponsor and
complete a contingency plan. Important ❐ Not Important ❐

46
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I EEE Std 1 062-201 5

I EEE Recomm end ed Practi ce for Software Acq u i si ti on

Annex B
(i n formati ve)

Software safety assurance and software information security assurance

The acquisition of software for systems with safety or information security requirements deserves special
consideration. Failure of software that is acquired for safety systems may have the potential to result in a
risk of inj ury or death, whereas failure of software acquired for information security systems may have the
potential to result in risks to individual privacy, business or organizational confidential information, or
operational stability.

Software for these systems should focus on reducing the exposure to software safety or software
information security risks and requirements typically focus on minimizing unacceptable system behavior
rather than identifying software system functionality.

B.1 Software safety assurance

Software safety risks may enable hazards that could result in mishaps or accidents, and could lead to a risk
of loss of life or other serious harm. The goal of software safety assurance is to help minimize such hazards
for the reduction of mishaps and accidents.

Safety considerations in the acquisition of software include the identification and management of hazards
and their associated risks during system development and system sustainment.

A Software Safety Plan, as specified in IEEE Std 1 228, should be used by the acquirer and supplier to
document the software safety approach for managing hazards throughout the acquisition lifecycle.

Safety requirements to be met by the software should be specified to help avoid or control system hazards.
Software safety requirements are derived from the system and subsystem safety requirements and should be
clearly specified in the Software Requirements Document (SRD).

Hazards should be identified through a systematic analysis process to include the software, system
interfaces and the intended use in the operational environment. A Hazard Tracking System is also
recommended, where both the acquirer and supplier have access, with appropriate controls on data
management. The plan should specify the tracking system used to help ensure that hazards, hazard owners,
and their status can be tracked throughout the software life cycle, through retirement.

47
Copyrig h t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I E E E S td 1 0 6 2 -2 0 1 5

I E E E Re co m m e n d e d P ra cti ce fo r S o ftwa re Acq u i s i ti o n

Tabl e B . 1 —Recom m en d ed s oftware s afety as s u ran ce acti vi ti es

Steps in software Recommended software safety assurance

acquisition process activities
Step 1 . Planning the software 1. Perform a preliminary hazard analysis to identify associated risks with each
acquisition strategy (5.3) acquisition alternative.
2. Develop a preliminary hazard list.
3. Confirm the acquisition strategy/plan includes software safety risks.
Step 2. Defining the acquisition and 1. Develop software safety requirements to be included in the statement of work.
software requirements. (5.4) 2. Identify any safety controls mandated by government regulation.
Step 3. Identifying potential suppliers 1. Conduct market research.
(5.5) 2. Consider prequalifying software suppliers and creating a qualified supplier
list.
Step 4. Preparing contract 1. Perform analysis to determine software safety evaluation criteria
requirements (5.6) 2. Identify any reliance on FOSS.
3. Develop evaluation plan describing how to evaluate software products and
services against the software safety criteria.
4. Suggest supplier provide a software safety plan as a part of their management
approach.
Step 5. Evaluating proposals and 1. Confirm RFP responses include objective evidence of a supplier’s ability to
selecting the supplier (5.7) perform and manage for software safety.
2. Confirm software safety contract requirements cascade down to subcontracted
suppliers.
3. Confirm software safety subject matter experts support the source selection to
evaluate proposals.
4. Confirm negotiated software safety agreements are incorporated into the final
contract.
Step 6. Managing for supplier 1. Confirm software safety deliverables are identified in the work breakdown
performance (5.8) structure.
2. Confirm change and configuration control of software safety requirements and
configuration items are managed.
3. Perform software safety test planning.
4. Acceptance criteria should be explicit, measurable, and included in the
assurance case or in the terms and conditions.
5. Consider using independent auditing.
Step 7. Accepting the software (5.9) 1. Perform software safety testing.
2. Consider using independent software testing.

B . 2 S oftware i n form ati on s ecu ri ty as s u ran ce

Software information security assurance is the practice of assuring information and managing risks related
to the use, processing, storage, and transmission of information or data and the systems and processes used
for those purposes. While focused dominantly on information in digital form, the full range of information
assurance encompasses not only digital but also analog or physical form. Information assurance as a field
has grown from the practice of information security, which in turn grew out of practices and procedures of
computer security.

The terms privacy, information security, computer security, and information assurance are frequently used
interchangeably. These fields are interrelated often and share the common goals of protecting the
confidentiality, integrity, and availability of information; however, there are some subtle differences
between them.

These differences lie primarily in the approach to the subject, the methodologies used, and the areas of
concentration. Information security is concerned with the confidentiality, integrity, and availability of data
regardless of the form the data may take: electronic, print, or other forms. Computer security can focus on
ensuring the availability and correct operation of a computer system without concern for the information

48
C o p yri g h t © 2 0 1 6 I E E E . Al l ri g h ts re s e rve d .

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

stored or processed by the computer. Information assurance focuses on the reasons for assurance that
information is protected, and is thus reasoning about information security.

Software information security risks are vulnerabilities that can lead to software security incidents including
network intrusion or data loss. The goal of successful implementation of software information security is
to help minimize such hazards for the reduction of mishaps.

Procurement of information security-critical software should consider potential failures that could result in
a risk of loss of life, serious harm, or that could have widespread negative social impact.

Information security considerations in the acquisition of software include ensuring the identification and
management of hazards and their associated risks during system development and system sustainment.

Security requirements should cover both overt functional security and emergent systems characteristics and
properties. Abuse cases describe the system under attack.

Processes to produce secure software include at least two testing strategies for testing security functionality
with standard functional testing techniques, and risk-based security testing based on attack patterns and
threat models.

Vulnerabilities that can be exploited by malicious code should be reduced. Any international activities and
any plans for, or known, foreign cooperative development or sales of the system should be summarized.

An evaluation plan should be developed, describing how to evaluate software products and services
(including software-intensive systems) against the software information security criteria.

B.2. 1 Pri vacy

Privacy is the ability of an individual or group to seclude themselves or information about themselves and
thereby reveal themselves selectively. The boundaries and content of what is considered private differ
among cultures and individuals but share basic common themes. Privacy is sometimes related to
anonymity, the wish to remain unnoticed or unidentified in the public realm. When something is private to
a person, it usually means there is something within them that is considered inherently special or personally
sensitive. Therefore, the degree to which private information is exposed depends on how the public will
receive this information, which differs between places and over time. Privacy partially intersects security,
including for instance the concepts of appropriate use, as well as protection, of information. Privacy may
also take the form of bodily integrity.

B . 2 . 2 I n form ati on s ecu ri ty

Information security means protecting information and information systems from unauthorized access, use,
disclosure, disruption, modification, perusal, inspection, recording, or destruction.

B . 2 . 3 Th reat an d th reat protecti on

A threat is something that is a source of danger; it can be a cause of pain or inj ury or loss; e. g. ,
“earthquakes are a constant threat in Japan. ”

Threat protection is the process of keeping (something or someone) safe; the state of being safe.

49
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

Tabl e B. 2—Recom men ded software i n form ati on secu ri ty assu ran ce acti vi ti es

Steps in software Recommended software information

acquisition process security assurance activities
Step 1 . Planning the software 1. Perform a preliminary threat analysis to identify associated risks with each

acquisition strategy (5. 3 ) acquisition alternative.

2. Develop a preliminary threat list.
3. Confirm the acquisition strategy/plan includes software information security
risks.

Step 2. Defining the acquisition and 1. Develop software information security requirements to be included in the

software requirements. (5. 4) statement of work.

2. Identify any information security controls mandated by government
regulation.

Step 3 . Identifying potential suppliers 1. Conduct market research.

(5. 5 ) 2. Consider prequalifying software suppliers and creating a qualified supplier

list.

Step 4. Preparing contract 1. Perform analysis to determine software information security evaluation

requirements (5. 6) criteria.

2. Identify any reliance on FOSS.
3. Develop evaluation plan describing how to evaluate software products and
services against the software information security criteria.
4. Suggest supplier provide a software information security plan as a part of
their management approach.

Step 5 . Evaluating proposals and 1. Confirm RFP responses include obj ective evidence of a supplier’ s ability to

selecting the supplier (5. 7) perform and manage for software information security.
2. Confirm software information security contract requirements cascade down
to subcontracted suppliers.
3. Confirm software information security subj ect matter experts support the
source selection to evaluate proposals.
4. Confirm negotiated software information security agreements are
incorporated into the final contract.

Step 6. Managing for supplier 1. Confirm software information security deliverables are identified in the work

performance (5 . 8) breakdown structure.

2. Confirm change and configuration change control of software information
security requirements and configuration items are managed.
3. Perform software information security test planning.
4. Acceptance criteria should be explicit, measurable, and included in the
assurance case or in the terms and conditions.
5. Consider using independent auditing.

Step 7. Accepting the software (5 . 9) 1. Perform software information security testing.

2. Consider using independent software testing.

50
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

I EEE Std 1 062-201 5

I EEE Recomm end ed Practi ce for Software Acq u i si ti on

Annex C

(i n formati ve)

Ri ghts i n techni cal d ata and software u sage

A topic that is of increasing interest in the acquisition of software is that of intellectual property rights.
Innovation in the development of software and software-intensive systems is time-consuming and
expensive. To recoup the expense of conceiving, designing, developing, and maintaining software, industry
relies on the ownership of intellectual property rights. The price of software acquired or developed under
contract should consider the appropriate or necessary division of the intellectual property rights between
the acquirer and the supplier.

The acquirer does not automatically “own” all of the rights to software it has paid a supplier to develop;
instead, the acquirer obtains the limited right to use the software and/or to provide or disclose the software
to a third party for use in accordance with the terms and conditions of a software license. Unauthorized
use, distribution, or disclosure of the software or unauthorized use of protected rights in the software may
lead to possible claims and damages, if they fall outside the rights defined in the license.

As part of the software acquisition process the licensing agreement should be carefully reviewed to help
ensure the acquirer obtains sufficient intellectual property rights to use and maintain the software for its
entire life cycle, including distribution, use and maintenance rights for third parties. Careful review of the
software license is necessary whether the acquirer plans to rely on the supplier to perform maintenance,
perform maintenance by the acquirer, or contract the maintenance to a third party.

Intellectual property rights can be a complicated topic, and software acquisition requires close co-
ordination among the technical, contracts, and legal staff to help ensure a successful acquisition of all the
rights necessary to use and maintain the software, not only by the acquirer but also for third parties.

51
Copyrig h t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I EEE Std 1 062-201 5

I EEE Recomm end ed Practi ce for Software Acq u i si ti on

An n ex D

(i n formati ve)

Acq u i s i ti on pl an g u i d el i n es

The purpose of this annex is to provide a template to guide the preparation of an acquisition plan (AP)
based on this recommended practice. (See 5 . 3 . )

The AP should contain the content as described in D. 1 through D. 8. The user of this annex may adopt any
format and numbering system for the AP. The AP section numbers listed in this annex are provided to
assist in the readability of this annex and are not mandatory for the user.

1. I n trodu ction
2. References
3. Defin i ti ons
4. Software acq u i si ti on overview
4. 1 . Defin i ti on of Acq u i ri n g Organi zation
4. 2. Sched u l e
4. 3. Resource su m m ary
4. 4. Responsi bi l i ti es
4. 5. Tools, techn i q u es, an d meth od s
5. Software acq u i si ti on process
5. 1 . Pl an n i n g th e software acq u i si ti on strategy
5. 2. Defin i n g th e software req u i remen ts
5. 3. I d enti fyin g potenti al su ppl i ers
5. 4. Preparin g contract req u i rem en ts
5. 5. Eval u ati n g proposals an d sel ectin g th e su ppl i er
5. 6. M anagi n g for su ppl i er performan ce
5. 7. Acceptin g th e software
5. 8. Eval u ati n g th e software
6. Software acq u i si ti on reportin g req u i rements
7. Software acq u i si ti on manag ement requ i rem ents
7. 1 . Anomal y resol u ti on an d reportin g
7. 2. Deviati on pol i cy
7. 3. Control proced u res
7. 4. Stan d ards, practices, an d con venti ons
7. 5. Performan ce trackin g
7. 6. Qu al i ty con trol of pl an
8. Software acq u i si ti on d ocu men tati on req u i rem en ts

F i g u re D . 1 —E xam pl e acq u i s i ti on pl an ou tl i n e

D. 1 (AP S ecti on 1 ) I n trod u cti on

The AP should describe the acquirer’ s needs that are to be fulfilled via the acquisition of software.

It should include the following:

a) A short description of the need motivating the acquisition

b) A description of the proj ect stakeholders, including identification of end users

c) Information regarding priority concerns (need-by dates, should not exceed costs, required industry
certifications, etc. )

52
Copyrig h t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

D.2 (AP Section 2) References

The AP should identify the documents placing constraints on the acquisition, documents referenced by the
AP, and any supporting documents supplementing or implementing the AP, including other plans or task
descriptions that elaborate details of this plan.

D.3 (AP Section 3) Definitions

The AP should define or reference all terms that are required to understand the AP. All abbreviations and
notations used in the AP should be described.

D.4 (AP Section 4) Software acquisition overview

The AP should describe organization, schedule, resources, responsibilities, tools, techniques, and methods
necessary to perform the software acquisition process.

D.4.1 (AP Section 4.1 ) Definition of acquiring organization

The AP should define the organization of the acquirer. The AP should describe the lines of communication
with the acquisition effort, the authority for resolving issues raised in the acquisition, and the authority for
approving acquisition products.

D.4.2 (AP Section 4.2) Schedule

The AP should define the proj ect’ s milestones, including any dependencies between the milestones. It
should be written at such a level that it allows the supplier flexibility in organizing work while still meeting
the needs of the acquirer. The acquirer may also specify penalties, etc. the supplier will incur if the
milestones are not met.

D.4.3 (AP Section 4.3) Resource summary

The AP should summarize the acquisition resources, including staffing, facilities, tools, finances, and
special procedural requirements (e. g. , security, access rights, and documentation control). Estimates of cost
and other resource requirements should be provided.

D.4.4 (AP Section 4.4) Responsibilities

The AP should summarize the primary responsibilities of the acquirer’ s and supplier organization,
including any processes that will be imposed on the supplier. If the responsibilities are negotiable, then the
acquirer may note that fact in this section.

D.4.5 (AP Section 4.5) Tools, techniques, and methods

The AP should describe the special documents, tools, techniques, methods, and operating and test
environment to be used in the acquisition process. Acquisition, training, support, and qualification
information for each tool, technology, and methodology should be included. The AP should document the
metrics to be used by the acquisition process and should describe how these metrics support the acquisition
process.

53
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

D.5 (AP Section 5) Software acquisition process

The AP should identify actions to be performed for each of the software acquisition steps described in
Clause 5 of this recommended practice, and should document those actions. The AP should contain an
overview of the acquisition steps. (See 5.3 through 5.1 0.)

D.5.1 (AP Sections 5.3 through 5.1 0) Software acquisition process

The AP should include 5.3 through 5.1 0 of this recommended practice for software acquisition steps as
shown in the AP outline (see Figure C.1 ).

The AP should address the following topics for each software acquisition step:

 Step input. What is needed to perform the step.

 Step output. What results when the step is performed.
 Step process. The details of what a step is expected to do.
 Step controls. What is to be performed to control the results of the step.
NOTE—The user of this template should examine 5.3 through 5.1 0 of this recommended practice for process details.

D.6 (AP Section 6) Software acquisition reporting requirements

The AP should describe how information will be collected and provided for each reporting period,
including work packages completed, work packages in-work, and work packages started. Also, risks should
be identified, along with mitigation approaches.

D.7 (AP Section 7) Software acquisition management requirements

The AP should describe the anomaly resolution and reporting; deviation policy; control procedures;
standards, practices, and conventions; performance tracking; and quality control of the plan.

D.7.1 (AP Section 7.1 ) Anomaly resolution and reporting

The AP should describe the method of reporting and resolving anomalies, including the criteria for
reporting an anomaly, the anomaly distribution list, and authority for resolving anomalies.

D.7.2 (AP Section 7.2) Deviation policy

The AP should describe the procedures and forms used to deviate from the Plan. The AP should identify
the authorities responsible for approving deviations.

D.7.3 (AP Section 7.3) Control procedures

The AP should identify control procedures applied during the acquisition effort. These procedures should
describe how software products and acquisition results should be configured, protected, and stored.

54
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

BS ISO/IEC/IEEE 41062:2019 ISO/IEC/IEEE 41062:2019(E)

IEEE Std 1 062-201 5

IEEE Recommended Practice for Software Acquisition

D.7.4 (AP Section 7.4) Standards, practices, and conventions

The AP should identify the standards, practices, and conventions that govern the performance of
acquisition actions including internal organizational standards, practices, and policies.

D.7.5 (AP Section 7.5) Performance tracking

The AP should describe the procedures for tracking performance through all software acquisition steps for
each work item.

D.7.6 (AP Section 7.6) Quality control of the Plan

The AP should describe how the Plan is reviewed, updated, and approved to confirm correctness and
currency.

D.8 (AP Section 8) Software acquisition documentation requirements

The AP should describe the procedures to be followed in recording and presenting the outputs of each
acquisition step. (See 5.2.)

55
Copyright © 201 6 IEEE. All rights reserved.

© IEEE 2016 – All rights reserved

ISO/IEC/IEEE 41062:2019(E) BS ISO/IEC/IEEE 41062:2019

I EEE Std 1 062-201 5

I EEE Recomm end ed Practi ce for Software Acq u i si ti on

Annex E
(i n formati ve)

Bibliography

Bibliographical references are resources that provide additional or helpful material but do not need to be
understood or used to implement this standard. Reference to these resources is made for informational use
only.

[B1 ] ANS I/PMI 99/001 /2008 , A Guide to the Proj ect Management Body of Knowledge (PMB OK
Guide)—Fourth Edition.

[B2] DACS Acquisition Process Improvement, Software Acquisition Gold Practice—Acquisition Process
Improvement.

[B3 ] GAO-04-3 93 , Stronger Management Practices Are Needed to Improve DOD’ s Software-Intensive
Weapon Acquisitions, March 2004.

[B4] IEEE Std 73 0, IEEE Standard for Software Quality Assurance Processes.

[B5 ] IEEE Std 83 0, IEEE Recommended Practice for Software Requirements Specifications.

[B6] IEEE Std 1 01 2, IEEE Standard for Software Verification and Validation.

[B7] IS O/IEC/IEEE 265 1 2, Systems and software engineering—Requirements for acquirers and suppliers
of user documentation.

[B8 ] IS O/IEC/IEEE 20000, Information Technology—S ervice Management.

[B9] ISO/IEC/IEEE 265 1 4, Systems and Software Engineering—Requirements for designers and
developers of user documentation.

[B1 0] ISO/IEC/IEEE 291 1 9, Systems and software engineering—S oftware testing (multiple parts).

[B1 1 ] ISO/IEC 1 5 5 04-2, Information technology—Process assessment—Part 2: Performing an assessment.

[B1 2] ISO/IEC 1 5 5 04-5 , Information technology—Process assessment—Part 5 : An exemplar software life

cycle process assessment model.

[B1 3 ] ISO/IEC 1 63 26, Systems and software engineering—Life cycle processes—Proj ect management.

[B1 4] IS O/IEC 25 05 0, Software Engineering—Software product Quality Requirements and Evaluation

(S QuaRE)—Guide to SQuaRE.

[B1 5 ] ISO/IEC 25 05 1 , Software engineering—S ystems and software Quality Requirements and Evaluation
(S QuaRE)—Requirements for Quality of Ready to Use Software Product (RUS P) and Instructions for
Testing.

[B1 6] IS O/IEC 27000, Information Technology—S ecurity Techniques—Information Security

Management Systems—Overview and Vocabulary.

[B1 7] ISO/IEC 291 1 0, Systems and Software Engineering—Lifecycle Profiles for Very Small Entities
(VSEs).

[B1 8 ] NIST Special Publication 800-1 45 , NIST Definition to Cloud Computing.

[B1 9] Pelgrin, Will, and Jim Routh, Application Security Procurement Language, SANS , February 201 0.

56
Copyrig h t © 201 6 I EEE. Al l ri g h ts reserved.

© IEEE 2016 – All rights reserved

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

British Standards Institution (BSI)

BSI is the national body responsible for preparing British Standards and other
standards-related publications, information and services.
BSI is incorporated by Royal Charter. British Standards and other standardization
products are published by BSI Standards Limited.

About us Reproducing extracts

We bring together business, industry, government, consumers, innovators For permission to reproduce content from BSI publications contact the BSI
and others to shape their combined experience and expertise into standards Copyright & Licensing team.
-based solutions.
The knowledge embodied in our standards has been carefully assembled in Subscriptions
a dependable format and ref ned through our open consultation process. Our range of subscription services are designed to make using standards
Organizations of all sizes and across all sectors choose standards to help easier for you. For further information on our subscription products go to
them achieve their goals. bsigroup.com/subscriptions.
With British Standards Online (BSOL) you’ll have instant access to over 55,000
Information on standards British and adopted European and international standards from your desktop.
We can provide you with the knowledge that your organization needs It’s available 24/7 and is refreshed daily so you’ll always be up to date.
to succeed. Find out more about British Standards by visiting our website at You can keep in touch with standards developments and receive substantial
bsigroup.com/standards or contacting our Customer Services team or discounts on the purchase price of standards, both in single copy and subscription
Knowledge Centre. format, by becoming a BSI Subscribing Member.

Buying standards PLUS is an updating service exclusive to BSI Subscribing Members. You will
automatically receive the latest hard copy of your standards when they’re
You can buy and download PDF versions of BSI publications, including British revised or replaced.
and adopted European and international standards, through our website at
bsigroup.com/shop, where hard copies can also be purchased. To f nd out more about becoming a BSI Subscribing Member and the bene f ts
of membership, please visit bsigroup.com/shop.
If you need international and foreign standards from other Standards Development
Organizations, hard copies can be ordered from our Customer Services team. With a Multi-User Network Licence (MUNL) you are able to host standards
publications on your intranet. Licences can cover as few or as many users as you
Copyright in BSI publications wish. With updates supplied as soon as they’re available, you can be sure your
documentation is current. For further information, email [email protected].
All the content in BSI publications, including British Standards, is the property
of and copyrighted by BSI or some person or entity that owns copyright in the
information used (such as the international standardization bodies) and has
Revisions
formally licensed such information to BSI for commercial publication and use. Our British Standards and other publications are updated by amendment or revision.

Save for the provisions below, you may not transfer, share or disseminate any We continually improve the quality of our products and services to benef t your
portion of the standard to any other person. You may not adapt, distribute, business. If you f nd an inaccuracy or ambiguity within a British Standard or other
commercially exploit, or publicly display the standard or any portion thereof in any BSI publication please inform the Knowledge Centre.
manner whatsoever without BSI’s prior written consent.
Useful Contacts
Storing and using standards Customer Services
Standards purchased in soft copy format: Tel: +44 345 086 9001
• A British Standard purchased in soft copy format is licensed to a sole named Email (orders): orders@bsigroup. com
user for personal or internal company use only. Email (enquiries): cservices@bsigroup. com
• The standard may be stored on more than 1 device provided that it is accessible Subscriptions
by the sole named user only and that only 1 copy is accessed at any one time. Tel: +44 345 086 9001
• A single paper copy may be printed for personal or internal company use only. Email: subscriptions@bsigroup. com
• Standards purchased in hard copy format:
Knowledge Centre
• A British Standard purchased in hard copy format is for personal or internal Tel: +44 20 8996 7004
company use only.
Email: knowledgecentre@bsigroup. com
• It may not be further reproduced – in any format – to create an additional copy.
This includes scanning of the document. Copyright & Licensing
If you need more than 1 copy of the document, or if you wish to share the Tel: +44 20 8996 7070
document on an internal network, you can save money by choosing a subscription Email: copyright@bsigroup. com
product (see ‘Subscriptions’).
BSI Group Headquarters
389 Chiswick High Road London W4 4AL UK

This page deliberately left blank