ISO/IEC/IEEE 32430:2021

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2021-10
Software engineering — Trial use
standard for software non-functional
sizing measurements
Ingénierie du logiciel — Norme expérimentale pour la quantification
des caractéristiques non fonctionnelles des logiciels
Reference number
© IEEE 2019
© IEEE 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Website: www.ieee.org
Published in Switzerland
ii
© IEEE 2019 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of ISO/IEC documents should be noted. This document was drafted in accordance
with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the
information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
ISO/IEC/IEEE 32430 was prepared by the Systems and Software Engineering Standards Committee of
the IEEE Computer Society (as IEEE Std 2430-2019) and drafted in accordance with its editorial rules. It
was adopted, under the “fast-track procedure” defined in the Partner Standards Development
Organization cooperation agreement between ISO and IEEE, by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 7, Software and systems engineering.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© IEEE 2019 – All rights reserved iii

IEEE Std 2430™-2019
IEEE Trial-Use Standard for Software
Non-Functional Sizing Measurements
Developed by the
Software & Systems Engineering Standards Committee (C/S2ESC)
of the
IEEE Computer Society
Approved 13 June 2019
IEEE-SA Standards Board
Abstract: A method for the sizing of nonfunctional software requirements is defined in this
standard. It complements ISO/IEC 20926:2009, which defines a method for the sizing of functional
user requirements. Non-functional categories for data operations, interface design, technical
environment, and architecture software are included in this standard.Steps to determine and
calculate the non-functional size are also included. Handling requirements involving both functional
and non-functional requirements are explained in this standard, which also covers how to apply
non-functional sizing estimates in terms of cost, project duration and quality, and considerations of
software performance in terms of productivity and quality. The combination of functional and non-
functional size should correspond to the total size necessary to produce the software. The functional
size and non-functional size are orthogonal, and both are needed when sizing the software. The
complementarity of the functional and the non-functional sizes, to avoid overlaps or gaps between
the two size methods, are described in this standard. Calculating the implementation work effort
and duration of the non-functional requirements is outside the scope of this standard.
Keywords: IEEE 2430™, IFPUG, non-functional size measurements, non-functional requirements,
SNAP
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 16 October 2019. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers,
Incorporated.
W3C is trademarks or registered trademarks of the W3C®, (registered in numerous countries) World Wide Web Consortium. Marks of W3C
are registered and held by its host institutions: Massachusetts Institute of Technology (MIT), European Research Consortium for Information
and Mathematics (ERCIM), and Keio University, Japan.
PDF: ISBN 978-1-5044-5987-7 STD23763
Print: ISBN 978-1-5044-5988-4 STDPD23763
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit https:// 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.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices
and disclaimers, or a reference to this page, appear in all standards and may be found under the heading
“Important Notices and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on
request from IEEE or viewed at https://standards .ieee.or g/ ipr/ disclaimers.html .
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use,
are developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a consensus
development process, approved by the American National Standards Institute (“ANSI”), which brings
together volunteers representing varied viewpoints and interests to achieve the final product. IEEE Standards
are documents developed through scientific, academic, and industry-based technical working groups.
Volunteers in IEEE working groups are not necessarily members of the Institute and participate without
compensation from IEEE. While IEEE administers the process and establishes rules to promote fairness in the
consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of any of
the information or the soundness of any judgments contained in its standards.
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure
against interference with or from other devices or networks. Implementers and users 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.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other document
relating to the standard, including, but not limited to, the warranties of: merchantability; fitness for a particular
purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In
addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort. IEEE standards
documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments received
from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or
her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate,
seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

Translations
The IEEE consensus development process involves the review of documents in English only. In the event that
an IEEE standard is translated, only the English version published by IEEE should be considered the approved
IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations
Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall
not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or
educational courses, an individual presenting information on IEEE standards shall make it clear that his or her
views should be considered the personal views of that individual rather than the formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless
of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards
Coordinating Committees are not able to provide an instant response to comments or questions except in
those cases where the matter has previously been addressed. For the same reason, IEEE does not respond to
interpretation requests. Any person who would like to participate in revisions to an IEEE standard is welcome
to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under US 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.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy
portions of any individual standard for company or organizational internal use or individual, non-commercial
use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer
Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions
of any individual standard for educational classroom use can also be obtained through the Copyright Clearance
Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. A current IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10 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 IEEE Xplore at https://ieeexplore .ieee .or g/ 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.or g.
Errata
Errata, if any, for IEEE standards can be accessed via https://standards .ieee.or g/ standard/index .html. Search
for standard number and year of approval to access the web page of the published standard. Errata links are
located under the Additional Resources Details section. Errata are also available in IEEE Xplore: https://
ieeexplore.ieee .or g/ browse/ standards/ collection/ieee/ . Users are encouraged to periodically check for errata.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-
SA Website at https://standards .ieee.or g/ 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.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

Trial-use standards
Publication of this trial-use standard for comment and criticism has been approved by the Institute of Electrical
and Electronics Engineers, Inc. Trial-use standards are effective for 36 months from the date of publication.
Comments for revision will be accepted for 24 months after publication. Suggestions for revision should be
directed to the Secretary, IEEE-SA Standards Board, 445 Hoes Lane, Piscataway, NJ 08855, and should be
received no later than 16 October 2021.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

Participants
At the time this IEEE trial-use standard was completed, the P2430 Working Group had the following
membership:
Talmon Ben-Cnaan, Chair
Bill Curtis Robert Schaaf Charley Tichenor
Victoria (Vicky) Hailey Roopali Thapar Altaz Valani
Annette Reilly Kiran Yeole
The following members of the individual balloting committee voted on this trial-use standard. Balloters may
have voted for approval, disapproval, or abstention.
Robert Aiello Werner Hoelzl Carl Singer
Talmon Ben-Cnaan Noriyuki Ikeuchi Kendall Southwick
Atsushi Ito Friedrich Stallinger
Juris Borzovs
Pieter Botman Srinivasa Rao Thomas Starai
Demetrio Bucaneg Jr. Kanneganti Walter Struppler
Paul Cardinal Piotr Karocki Marcy Stutzman
Lawrence Catchpole David Leciston Sachin Thakur
Jan de Liefde Johnny Marques Roopali Thapar
Yaacov Fenster LaMont McAliley Charley Tichenor
Andrew Fieldsend Rajesh Murthy John Vergis
David Fuschi Nick S.A. Nikjoo Scott Willy
Julian Gomez Mark Paulk Steven Woodward
Randall Groves Annette Reilly Jian Yu
Victoria (Vicky) Hailey Saurabh Saxena Oren Yuen
Mark Henley Robert Schaaf Janusz Zalewski
Stephen Schwarm
When the IEEE-SA Standards Board approved this trial-use standard on 13 June 2019, it had the following
membership:
Gary Hoffman, Chair
Ted Burse, Vice Chair
Jean-Philippe Faure, Past Chair
Konstantinos Karachalios, Secretary
Masayuki Ariyoshi John D. Kulick Annette D. Reilly
Stephen D. Dukes David J. Law Dorothy Stanley
J.Travis Griffith Joseph Levy Sha Wei
Guido Hiertz Howard Li Phil Wennblom
Christel Hunter Xiaohui Liu Philip Winston
Thomas Koshy Kevin Lu Howard Wolfman
Joseph L. Koepfinger* Daleep Mohla Feng Wu
Thomas Koshy Andrew Myles Jingyi Zhou
*Member Emeritus
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

Introduction
This introduction is not part of IEEE Std 2430-2019, IEEE Trial-Use Standard for Software Non-Functional Sizing
Measurements.
Having both software functional size and non-functional size provides significant information for the
management of software product development. The functional size is quantifiable and represents a good
measure of the functional project/application size. Providing a quantifiable measure for the non-functional
requirements (NFR) allows organizations to build historical data repositories that can be referenced to assist in
decision making for the technical and/or quality aspects of applications.
Non-functional sizing assists organization in multiple ways (see Annex A). It provides insight into projects
and applications to assist in effort and cost estimating and in the analysis of quality and productivity. Used
in conjunction with function-point analysis, non-functional sizing provides information that can identify
additional software size, which may impact quality and productivity in a positive or negative way. Having this
information enables software professionals to:
— Better plan, schedule, and estimate projects.
— Identify areas of process improvement.
— Assist in determining future technical strategies.
— Quantify the impacts of the current technical strategies.
— Improve quality: Analyzing non-functional size may assist in identifying implicit requirement and may
assist in analyzing the components of the solution to meet the NFR by looking at the sizing attributes.
By learning the methodology as described in this standard and by performing the non-functional sizing
together with functional sizing, the added time and effort to size the NFR is small.
Acknowledgments
The author thanks the International Electrotechnical Commission (IEC) for permission to reproduce
information from its international standards. All such extracts are copyright of IEC Geneva, Switzerland. All
rights reserved. Further information on the IEC is available from www .iec .ch. IEC has no responsibility for the
placement and context in which the extracts and contents are reproduced by the author, nor is IEC in any way
responsible for the other content or accuracy therein.
Portions of the Software Non-functional Assessment Process (SNAP), Assessment Practices Manual, Release
2.4, reprinted with permission from IFPUG, ©2017.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

Contents
1. Overview . 10
1.1 Scope . 10
1.2 Purpose . 10
1.3 Word usage . 11
2. Normative references . 11
3. Definitions, acronyms, and abbreviations . 12
3.1 Definitions . 12
3.2 Abbreviations . 16
4. Introductory Information . 17
4.1 Non-Functional Software Size Measurement (NFSSM) introduction . 17
4.2 Software-intensive system and software product . 18
4.3 Software domains . 18
4.4 The relations between non-functional requirements (NFR) definition and functional user
requirements (FUR) . 18
4.5 Key features of the NFSSM . 20
4.6 Future evolution of NFR . 21
4.7 Objectives and benefits . 22
5. Non-functional size: Categories and sub-categories . 23
5.1 Category 1: Data operations . 23
5.2 Category 2: Interface design . 32
5.3 Category 3: Technical environment . 41
5.4 Category 4: Architecture . 47
5.5 Sizing code data . 52
6. The sizing process . 55
6.1 The timing of the non-functional sizing . 56
6.2 Non-functional sizing and FSM . 56
6.3 Steps to determine the non-functional size . 57
6.4 Calculating the Non-functional size . 63
7. Complementarity of the functional and the non-functional sizes. 66
7.1 Requirements involving functional and non-functional requirements . 67
8. Use of non-functional software sizing . 77
8.1 Functional size and non-functional size . 77
8.2 Project management . 77
8.3 Performance management . 81
Annex A (informative) NFSSM strengths . 84
Annex B (informative) Bibliography . 85
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

IEEE Trial-Use Standard for Software
Non-Functional Sizing Measurements
1. Overview
1.1 Scope
This standard defines a method for the sizing of non-functional software requirements. It complements ISO/
IEC 20926:2009, which defines a method for the sizing of functional user requirements (FUR).
This standard also describes the complementarity of functional and non-functional sizes, so that sizing both
functional and non-functional requirements (NFR) do not overlap. It also describes how non-functional size,
together with functional size, should be used for measuring the performance of software projects, setting
benchmarks, and estimating the cost and duration of software projects.
In general, there are many types of non-functional software requirements. Moreover, non-functional aspects
evolve over time and may include additional aspects in the as technology advances. This standard does not
intend to define the type of NFR for a given context. Users may choose ISO 25010:2011 or any other standard
for the definition of NFR. It is assumed that users will size the NFR based on the definitions they use.
This standard covers a subset of non-functional types. It is expected that, with time, the state of the art can
improve and that potential future versions of this standard can define an extended coverage. The ultimate
goal is a version that, together with ISO/IEC 20926:2009, covers every aspect that may be required of any
prospective piece of software, including aspects such as process and project directives that are hard or
impossible to trace to the software's algorithm or data. The combination of functional and non-functional size
would then correspond to the total size necessary to bring the software into existence.
Calculating the effort and duration of the implementation of the NFR is outside the scope of this standard.
1.2 Purpose
The purpose of this standard is to define the method of sizing of NFR and describe how to use this size,
alongside with the functional size.
Information on references can be found in Clause 2.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2430-2019
IEEE Trial-Use Standard for Software Non-Functional Sizing Measurements
1.3 Word usage
The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard
2,3
and from which no deviation is permitted (shall equals is required to).
The word should indicates that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily
required (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals
is permitted to).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can
equals is able to).
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments or corrigenda) applies.
4,5
ISO/IEC 14143-1:2007, Information Technology—Software measurement—Functional size measurement.
ISO/IEC 20926:2009, Software and systems engineering—Software measurement—IFPUG functional size
measurement method 2009.
ISO/IEC 25010:2011, Systems and software engineering—Systems and software Quality Requirements and
Evaluation (SQuaRE)—System and software quality models.
ISO/IEC TR 14143-5:2004 Information technology—Software measurement—Functional size
measurement—Part 5: Determination of functional domains for use with functional size measurement.
6,7
ISO/IEC/IEEE 24765:2017, Systems and software engineering—Vocabulary.
The use of the word must is deprecated and shall not be used when stating mandatory requirements, must is used only to describe
unavoidable situations.
The use of will is deprecated and shall not be used when stating mandatory requirements, will is only used in statements of fact.
ISO publications are available from the International Organization for Standardization (https://www .iso .org/ ) and the American
National Standards Institute (https://www .ansi .org/ ).
IEC publications are available from the International Electrotechnical Commission (https://www .iec.ch/ ). IEC publications are also
available in the United States from the American National Standards Institute (http://www .ansi .org).
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
IEEE publications are available from The Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854, USA
(https://standards .ieee.or g/ ).
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2430-2019
IEEE Trial-Use Standard for Software Non-Functional Sizing Measurements
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. For terms not defined in this
clause, consult ISO/IEC/IEEE 24765:2017 or the IEEE Standards Dictionary Online.
adaptive maintenance: Modification of a software product, performed after delivery, to keep a software
product usable in a changed or changing environment.
NOTE 1 —Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which
a software product must operate. These changes are those that must be made to keep pace with the changing environment.
For example, the operating system might be upgraded, and some changes may be made to accommodate the new operating
system.
NOTE 2 —From ISO/IEC 14764:2006 ed 2.0, Copyright © 2006 IEC Geneva, Switzerland. www .iec.ch. [B8].
application: A cohesive collection of automated procedures and data supporting a business objective;
it consists of one or more components, modules, or subsystems. Examples: accounts payable, accounts
receivable, payroll, procurement, shop production, assembly line control, air search radar, target tracking,
weapons firing, flight line scheduling, and passenger reservations.
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
boundary (application boundary): A conceptual interface between the software under study and its users.
The boundary (also referred to as application boundary) defines what is external to the application; it indicates
the border between the software being measured and the user; it acts as a “membrane” through which data
processed by transactions pass into and out of the application; it is dependent on the user’s external business
view of the application; it is independent of non-functional and/or implementation considerations. The
boundary is identical when assessing the functional size and the non-functional size
NOTE —From ISO/IEC 14143-1:2007 ed 2.0, Copyright © 2007 IEC Geneva, Switzerland. www .iec.ch.
code data: A type of data entities, used for software sizing (in addition to Business Data and Reference Data).
According to ISO/IEC 20926:2009 [IFPUG function point analysis (FPA)], “code data” usually exists to satisfy
non-functional requirements (NFR) from the user (for quality requirements, physical implementation and/or a
technical reason). Code data provides a list of valid values that a descriptive attribute may have. Typically, the
attributes of the code data are Code, Description and/or other “standard” attributes describing the code; e.g.,
standard abbreviation, effective date, termination date, audit trail data, etc. The different categories of data are
outlined below to assist in identification.
corrective maintenance: Reactive modification of a software product performed after delivery to correct
discovered problems [B8].
NOTE 1—The modification repairs the software product to satisfy requirements.
NOTE 2 —From ISO/IEC 14764:2006 ed 2.0, Copyright © 2006 IEC Geneva, Switzerland. www .iec.ch.
IEEE Standards Dictionary Online is available at: http://dictionary .ieee.or g.
Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this
standard.
The numbers in brackets correspond to those of the bibliography in Annex B.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2430-2019
IEEE Trial-Use Standard for Software Non-Functional Sizing Measurements
data element type (DET): A unique, non-repeated attribute, which can be in Business Data, Reference Data,
or code data. The number of different types of Data Elements of all tables is the number of DETs. Instances of
control information are also counted as a DET, such as the “Enter” key to facilitate an external input (EI).
database view: The result set of a stored query on the data, which the database users can query just as they
would in a persistent database collection object. This pre-established query command is kept in the database
dictionary. Unlike ordinary base tables in a relational database, it is a virtual table computed or collated
dynamically from data in the database, when access to that view is requested. Changes applied to the data in a
relevant underlying table are reflected in the data shown in subsequent invocations of the view.
elementary process (EP): The smallest unit of activity that is meaningful to the user(s).
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
external input (EI): An elementary process (EP) that processes data or control information sent from outside
the boundary.
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
external inquiry (EQ): An elementary process (EP) that sends data or control information outside the
boundary.
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
external interface file (EIF): user recognizable group of logically related data or control information, which
is referenced by the application being measured, but which is maintained within the boundary of another
application.
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
external output (EO): An elementary process (EP) that sends data or control information outside the boundary
and includes additional processing logic beyond that of an External Inquiry.
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
family of platforms: Software Platforms that are serving the same purpose. for example, operating systems;
browsers. See also: platforms.
file type referenced (FTR): A data function read and/or maintained by a transactional function. A file type
referenced includes: An internal logical file read or maintained by a transactional function, or an external
interface file read by a transactional function. Code data is grouped into one additional FTR.
function points (FPs): A unit of measurement to express the amount of functionality an information system
(as a product) provides to a user. In this standard, function points (FPs).
NOTE —From ISO/IEC 20926:2009 ed 2.0, Copyright © 2009 IEC Geneva, Switzerland. www .iec.ch.
functional sizing measurements (FSM): The process of measuring functional size.
NOTE —From ISO/IEC 14143-1:2007 ed 2.0, Copyright © 2007 IEC Geneva, Switzerland. www .iec.ch.
Authorized licensed use limited to: IEEE Standards Board BoG CAG SASB RAC. Downloaded on October 28,2019 at 15:50:29 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2430-2019
IEEE Trial-Use Standard for Software Non-Functional Sizing Measurements
functional user requirements (FUR): A sub-set of the user requirements. Requirements that describe what
the software shall do, in terms of tasks and services.
NOTE 1—FUR relate to, but are not limited to:
— Data transfer (for example: input customer data; send control signal)
— Data transformation (for example: calculate bank interest; derive average temperature)
— Data storage (for example: store customer order; record ambient temperature over time)
— Data retrieval (for example: list current employees; retrieve latest aircraft position)
NOTE 2—Examples of user requirements that are not FUR include, but are not limited to:
— Quality constraints (for example: usability, reliability, efficiency and portability)
— Organizational constraints (for example: locations for operation, target hardware and compliance to
standards)
— Environmental constraints (for example: interoperability, security, privacy and safety)
— Implementation constraints (for example: development language, delivery schedule)
NOTE 3—From ISO/IEC 14143-1:2007 ed 2.0, Copyright © 2007 IEC Geneva, Switzerland. www .iec.ch.
internal logical file (ILF): User recognizable group of logically related data or control information maintained
within the boundary of the application being measured.
logical file: A logical group of data as seen by the user. A logical file is made up of one or more data entities.
A data function represents functionality provided to the user to meet internal and external data storage
requirements. A data function is either an internal logical file or an external interface file. Grouping of d
...