ISO/IEC/IEEE 24765:2017

INTERNATIONAL ISO/IEC/
STANDARD IEEE
Second edition
2017-09
Systems and software engineering —
Vocabulary
Ingénierie des systèmes et du logiciel — Vocabulaire
Reference number
©
ISO/IEC 2017
©
IEEE 2017
© ISO/IEC 2017, Published in Switzerland
© IEEE 2017
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from ISO, IEC or IEEE at
the respective address below.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
Ch. de Blandonnet 8 • CP 401 3 Park Avenue, New York
CH-1214 Vernier, Geneva, Switzerland NY 10016-5997, USA
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org stds.ipr@ieee.org
www.iso.org www.ieee.org
© ISO/IEC 2017 – All rights reserved
ii © IEEE 2017 – All rights reserved

Contents Page
Foreword . v
Introduction .vi
1 Scope .1
1.1 General .1
1.2 Relationship of the print and internet-accessible versions .1
1.3 Vocabulary structure .1
1.4 PMI Glossary provisions .2
2 Normative references .2
3 Terms, definitions, and abbreviated terms .2
Annex A (informative)  List of References . 513
Bibliography . 514

iii
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

List of Figures
Figure 1 — Activity group . 10
Figure 2 — Bathtub curve . 42
Figure 3 — Block diagram . 47
Figure 4 —Box Diagram . 50
Figure 5 —Bubble chart . 52
Figure 6 —Call graph . 56
Figure 7 —Case construct . 59
Figure 8 — Category . 60
Figure 9 — Data flow diagram .1 16
Figure 10 — Data structure diagram . 119
Figure 11 — Directed graph .1 40
Figure 12 — Documentation tree .1 44
Figure 13 — Flowchart .1 85
Figure 14 — If-then-else construct . 212
Figure 15 — Input-process-output chart . 225
Figure 16 — Modification request.2 78
Figure 17 — Structure chart .4 40
Figure 18 — UNTIL construct .4 87
Figure 19 — Waterfall model .5 06
Figure 20 — Website .5 07
Figure 21 — WHILE construct .5 08

iv
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – 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. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
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.
The procedures used to develop this document and those intended for its further maintenance are described in the
ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of document
should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2
(see www.iso.org/directives).
Attention is called to the possibility that implementation of this standard may require the use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity
of any patent rights in connection therewith. ISO/IEEE is not responsible for identifying essential patents or patent
claims for which a license may be required, for conducting inquiries into the legal validity or scope of patents or
patent claims or determining whether any licensing terms or conditions provided in connection with submission of
a Letter of Assurance or a Patent Statement and Licensing Declaration Form, 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 ISO or the IEEE Standards Association. Any trade name used in this document is
information given for the convenience of users and does not constitute an endorsement.
Use of IEEE Standards documents is wholly voluntary. IEEE documents are made available for use subject to
for more
important notices and legal disclaimers (see http://standards.ieee.org/IPR/disclaimers.html
information).
For an explanation on 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 the following URL www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology, SC 7, Software and
systems engineering, in cooperation with the IEEE Computer Society Systems and Software Engineering Standards
Committee, under the Partner Standards Development Organization cooperation agreement between ISO and IEEE.
Certain material contained in ISO/IEC/IEEE 24765 is reproduced, with permission, from A Guide to the Project
Management Body of Knowledge (PMBOK®) Guide — Fifth Edition, copyright 2013, Project Management Institute.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 24765:2010), and has been editorially
revised. Revisions in terms and definitions published in this second edition have been previously approved through
the vocabulary maintenance procedures of ISO/IEC JTC 1/SC7, in cooperation with the IEEE Computer Society.
These revisions have been made available through the online vocabulary database used for this standard,
maintained by the ISO/IEC JTC 1/SC7/SWG 22 Vocabulary Validation Team in cooperation with the IEEE Computer
Society at www.computer.org/sevocab

v
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

Introduction
The systems and software engineering disciplines are continuing to mature while information technology
advances. New terms are being generated and new meanings are being adopted for existing terms. This
document was prepared to collect and standardize terminology. Its purpose is to identify terms currently in use
in the field and standard definitions for these terms. It is intended to serve as a useful reference for those in
the Information Technology field, and to encourage the use of systems and software engineering standards
prepared by ISO/IEC JTC 1 and liaison organizations IEEE Computer Society and Project Management Institute
(PMI). It provides definitions that are rigorous, uncomplicated, and understandable by all concerned.
While it is useful to find the meaning of a term, no word stands in isolation. This document makes it possible to
search for related concepts and to view how a term is used in definitions of other terms.
Every effort has been made to use definitions from established systems and software engineering standards of
ISO JTC 1/SC 7 and its liaison organizations IEEE Computer Society and the PMI. When existing standards
were found to be incomplete, unclear or inconsistent with other entries in the vocabulary, however, new, revised,
or composite definitions have been developed. Some definitions have been recast in a system, rather than software,
context.
The vocabulary is offered in both print and internet­accessible versions for ease of reference and to encourage use
of the source standards for the vocabulary. The online vocabulary database used for this standard is maintained by
the ISO/IEC JTC 1/SC7/SWG 22 Vocabulary Validation Team in cooperation with the IEEE Computer Society at
www.computer.org/sevocab
vi
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 24765:2017(E)

Systems and software engineering — Vocabulary
1 Scope
1.1 General
Consistent with ISO vocabulary standards, each technical committee is responsible for standard terminology in its
area of specialization. This document provides a common vocabulary applicable to all systems and software
engineering work falling within the scope of ISO/IEC JTC 1/SC 7, Software and systems engineering, and the IEEE
Computer Society Systems and Software Engineering Standards Committee (IEEE­CS S2ESC).
The scope of each concept defined has been chosen to provide a definition that is suitable for general application.
In those circumstances where a restricted application is concerned, a more specific definition might be needed.
Terms have been excluded if they were:
— considered to be parochial to one group or organization;
— company proprietary or trademarked;
— multi­word terms whose meaning could be inferred from the definitions of the component words; and
— terms whose meaning in the information technology (IT) field could be directly inferred from their common
English dictionary meaning.
1.2 Relationship of the print and internet-accessible versions
The primary tool for maintaining this vocabulary is a database that is modified in a controlled fashion. Hosted by
the IEEE Computer Society, the SEVOCAB (systems and software engineering vocabulary) database is publicly
accessible at www.computer.org/sevocab ISO/IEC/IEEE 24765 is issued periodically as a formal, published
document reflecting a "snapshot" of the database.

The copyright notice provided with the database permits users to copy definitions from the database as long as the
source of the definition is cited. Permitting public use of the definitions in the database is intended to encourage the
use of other ISO/IEC JTC 1 and IEEE systems and software engineering standards.
1.3 Vocabulary structure
Entries in the vocabulary are arranged alphabetically. Blanks precede all other characters in alphabetizing. Hyphens
and slashes (­ and /) follow all other characters in alphabetizing.
Preferred terms are shown in bold. Synonyms or admitted terms (terms with the same meaning as the preferred
term), are listed under the preferred term in plain text, and can be located by searching.
Terms, definitions, and notes use spelling preferred in the US. The use of capital letters has been minimized and
generally limited to proper names and acronyms. In some cases, the source standard uses another correct spelling
(such as behaviour rather than behavior, on­line rather than online). Technical terms in English often change form
from two words to a hyphenated word to a single word as they become more familiar, e.g., real time to real­time to
realtime. Hence, other correct spellings and capitalization of the terms, according to a national standard, an
authoritative general dictionary or accepted style guide, can be used with the definitions.
An entry can consist of a single word, such as "software"; a phrase or compound term, such as "test case"; or an
abbreviated term, such as "CDR". Phrases are given in their natural order (test plan) rather than in reversed order
(plan, test). Abbreviated terms can be listed separately as well as in parentheses following the source term. Terms
that are verbs are shown without the infinitive marker "to".
© ISO/IEC 2017 – All rights reserve
© IEEE 2017 – All rights reserved

After each term, numbered definitions are listed in order of preference, or from the most general to the more specific
usages. The different definitions can show the use of a term as a noun, verb and adjective.
This document includes references to the active source standards for each definition, so that the use of the term
can be further explored. The sources of most of the definitions are ISO JTC 1/SC 7 or IEEE Computer Society
standards and the PMI Glossary, Fifth Edition. Sources are listed in the Bibliography. Additional sources for
definitions drawn from outside the scope of systems and software engineering are in Annex A, List of References.
In some cases, the same definition can also be found in other active or withdrawn standards. No source is shown if
the original source standard has been withdrawn or archived and the definition has been retained in this
vocabulary.
Notes (comments), Examples, and Figures taken from the source standards have been included to clarify selected
definitions.
Cross­references are used to show a term's relationship to other terms in the dictionary: cf. refers to related terms
that are not synonyms.
1.4 PMI Glossary provisions
The Project Management Institute (PMI) Glossary definitions have been included without alteration in
accordance with the copyright agreement. Some of these terms and definitions are not worded according to
terms and other
ISO/IEC or IEEE styles. Many of these definitions include explanatory material. For other
definitions that have ISO/IEC and IEEE standards as their source, explanatory matter is shown in the Notes
and Examples.
2 Normative references
There are no normative references in this document.
NOTE The definitions in this document are drawn from normative standards and informative guidance
documents, including ISO/IEC Technical Reports (TR). Where terms have multiple definitions, users should consult
the source standards for further information on appropriate usage within a specific context.
3 Terms, definitions, and abbreviated terms
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following addresses:

— IEC Electropedia: available at http://www.electropedia.org
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEEE Standards Dictionary Online: available at http://dictionary.ieee.org
3.1
1GL
1. first­generation language
cf. machine language
3.2
2GL
1. second­generation language
cf. assembly language
3.3
3D
1. three­dimensional [ISO/IEC/IEEE 23026:2015 Systems and software engineering — Engineering and
management of websites for systems, software, and services information
3.4
3GL
1. third­generation language
cf. high order language
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.5
4GL
1. fourth­generation language
3.6
5GL
1. fifth­generation language
3.7
language
1. definitions of concepts and rules for the specification of an ODP system from the viewpoint
[ISO/IEC 10746­3:2009 Information technology — Open Distributed Processing — Reference Model: Architecture,
4.2.1.1]
Note 1 to entry: Thus, engineering language: definitions of concepts and rules for the specification of an ODP system from the
engineering viewpoint.
3.8
domain
1. set of objects, each of which is related by a characterizing relationship to a controlling object [ISO/IEC 10746­
2:2009 Information technology — Open Distributed Processing — Reference Model: Foundations, 10.3]
3.9
federation
1. community of domains [ISO/IEC 10746-3:2009 Information technology — Open Distributed Processing —
Reference Model: Architecture, 5.1.2]
3.10
group
1. set of objects with a particular characterizing relationship [ISO/IEC 10746-2:2009 Information technology —
Open Distributed Processing — Reference Model: Foundations, 10.1]
3.11
interceptor
1. engineering object in a channel, placed at a boundary between domains [ISO/IEC 10746-3:2009 Information
technology — Open Distributed Processing — Reference Model: Architecture, 8.1.11]
Note 1 to entry: An interceptor performs checks to enforce or monitor policies on permitted interactions between basic
engineering objects in different domains; performs transformations to mask differences in interpretation of data by basic
engineering objects in different domains. An inter­subnetwork relay is an example of an interceptor
3.12
pattern
1. abstract specification of a composition of objects that results in any instance of the composition having a given
property, named by [ISO/IEC 10746-2:2009 Information technology — Open Distributed Processing — Reference
Model: Foundations, 9.8]
3.13
A-0 context diagram
1. the only context diagram that is required for a valid IDEF0 model, the A­0 diagram contains one box, which
represents the top­level function being modeled, the inputs, controls, outputs, and mechanisms attached to this box,
the full model name, the model name abbreviation, the model's purpose statement, and the model's viewpoint
statement [IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for
IDEF0]
3.14
A-profile
1. Application profile [ISO/IEC 10746-1:1998 Information technology — Open Distributed Processing — Reference
model: Overview]
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.15
ABC
1. activity­based costing
3.16
abend
1. abnormal end
3.17
abnormal end (abend)
1. termination of a process prior to completion
cf. abort, exception
3.18
abort
1. to terminate a process prior to completion
cf. abend, exception
3.19
absolute address
explicit address
specific address
1. address that is permanently assigned to a device or storage location and that identifies the device or location
without the need for translation or calculation
cf. relative address, relocatable address, symbolic address, absolute assembler, absolute code, absolute instruction
3.20
absolute assembler
1. assembler that produces absolute code
cf. relocating assembler
3.21
absolute code
specific code
1. code in which all addresses are absolute addresses
cf. relocatable code
3.22
absolute instruction
1. computer instruction in which all addresses are absolute addresses
cf. direct instruction, effective instruction, immediate instruction, indirect instruction
3.23
absolute loader
1. loader that reads absolute machine code into main memory, beginning at the initial address assigned to the
code by the assembler or compiler, and performs no address adjustments on the code
cf. relocating loader
3.24
abstract class
1. class that cannot be instantiated independently [IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual
Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.1]
Note 1 to entry: That is, instantiation must be accomplished via a subclass. A class for which every instance must also be an
instance of a subclass in the cluster (a total cluster) is called an abstract class with respect to that cluster.
3.25
abstract data type
1. data type for which only the properties of the data and the operations to be performed on the data are specified,
without concern for how the data will be represented or how the operations will be implemented
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.26
abstract design
1. generic form that needs specialization (further design work) to produce concrete designs2. design aimed at
producing designs
3.27
abstraction
1. view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of
the information [ISO/IEC 19506:2012 Information technology — Object Management Group Architecture-Driven
Modernization (ADM) — Knowledge Discovery Meta-Model (KDM), 4] 2. process of formulating a view 3. process of
suppressing irrelevant detail to establish a simplified model, or the result of that process [ISO/IEC 10746-2:2009
Information technology — Open Distributed Processing — Reference Model: Foundations, 6.3]
cf. data abstraction
3.28
AC
1. actual cost [A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fifth Edition]
3.29
acceptability
1. exposure to loss (financial or otherwise) that an organization is willing to tolerate from a risk
Note 1 to entry: Risk acceptability can apply to an individual risk or to a collection of risks, such as the totality of risks confronting
a project or enterprise. Acceptability can differ for different categories of risk and can depend on the cost of treatment or other
factors.
3.30
acceptability criteria
1. documented set of characteristics of a program's work products that if satisfied, forms a sufficient basis for
judging each product's content to be acceptable to support a successful review or audit [IEEE 15288.2:2014 IEEE
Standard for Technical Reviews and Audits on Defense Programs, 3.1]
3.31
acceptable
1. meeting stakeholder expectations that can be shown to be reasonable or merited
3.32
acceptance criteria
1. criteria that a system or component must satisfy in order to be accepted by a user, customer, or other
authorized entity 2. a set of conditions that is required to be met before deliverables are accepted [A Guide to the
Project Management Body of Knowledge (PMBOK® Guide) — Fifth Edition]
cf. requirement, test criteria
3.33
acceptance test
1. test of a system or functional unit usually performed by the purchaser on his premises after installation with the
participation of the vendor to ensure that the contractual requirements are met [ISO/IEC 2382:2015, Information
technology -— Vocabulary]
cf. acceptance testing, validation test
3.34
acceptance testing
1. testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to
determine whether to accept the system 2. formal testing conducted to enable a user, customer, or other
authorized entity to determine whether to accept a system or component [IEEE 1012-2012 IEEE Standard for
System and Software Verification and Validation, 3.1]
cf. acceptance test, validation test
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.35
accepted deliverables
1. products, results, or capabilities produced by a project and validated by the project customer or sponsors as
meeting their specified acceptance criteria [A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
— Fifth Edition]
3.36
access
1. to obtain the use of a resource [ISO/IEC 2382:2015, Information technology — Vocabulary]
3.37
access facility
1. set of service primitives that allow a stub objects to negotiate the abstract and transfer syntax to be used for the
operation data to be transmitted over the channel [ISO/IEC 14752:2000 Information technology — Open Distributed
Processing — Protocol support for computational interactions, 3.3.1]
3.38
access method
1. technique to obtain the use of data, the use of storage in order to read or write data, or the use of an input­output
channel to transfer data [ISO/IEC 2382:2015, Information technology — Vocabulary]
3.39
access routine
1. routine that provides access to a data structure that is hidden, usually because it is a global variable or used in an
abstract data type.
3.40
access transparency
1. distribution transparency which masks differences in data representation and invocation mechanisms to enable
interworking between objects [ISO/IEC 10746-3:2009 Information technology — Open Distributed Processing —
Reference Model: Architecture, 4.4.1.1]
3.41
accessibility
1. extent to which products, systems, services, environments and facilities can be used by people from a population
with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use
[ISO/IEC 25064:2013 Systems and software engineering — Software product Quality Requirements and Evaluation
(SQuaRE) — Common Industry Format (CIF) for usability: User needs report, 4.1] 2. degree to which a product or
system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in
a specified context of use [ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality
Requirements and Evaluation (SQuaRE) — System and software quality models, 4.2.4.6] 3. usability of a product,
service, environment or facility by people with the widest range of capabilities [ISO/IEC 25062:2006 Software
engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF)
for usability test reports, 4.1; ISO/IEC 26514:2008 Systems and software engineering — requirements for designers
and developers of user documentation, 4.1]
Note 1 to entry: Although "accessibility" typically addresses users who have disabilities, the concept is not limited to disability
issues. The range of capabilities includes disabilities associated with age. Accessibility for people with disabilities can be specified
or measured either as the extent to which a product or system can be used by users with specified disabilities to achieve specified
goals with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use, or by the presence of product
properties that support accessibility. Context of use includes direct use or use supported by assistive technologies.
[SOURCE: ISO 9241­171:2008]
3.42
accessibility testing
1. type of usability testing used to measure the degree to which a test item can be operated by users with the widest
possible range of characteristics and capabilities [ISO/IEC/IEEE 29119-1:2013 Software and systems engineering —
Software testing — Part 1: Concepts and definitions, 4.1]
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.43
accident
1. unplanned event or series of events that results in death, injury, illness, environmental damage, or damage to or
loss of equipment or property [IEEE 1228-1994 (R2002) IEEE Standard for Software Safety Plans, 3.1.1]
3.44
accountability
1. degree to which the actions of an entity can be traced uniquely to the entity [ISO/IEC 25010:2011 Systems and
software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software
quality models, 4.2.6.4]
3.45
accuracy
1. qualitative assessment of correctness, or freedom from error 2. quantitative measure of the magnitude of error
3. Within the quality management system, accuracy is an assessment of correctness [A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) — Fifth Edition]
cf. precision
3.46
accuracy of measurement
1. the closeness of the agreement between the result of a measurement and the true value of the measurand [ISO/IEC
TR 14143-3:2003 Information technology — Software measurement — Functional size measurement — Part 3:
Verification of functional size measurement methods, 3.1]
Note 1 to entry: Accuracy is a qualitative concept. The term precision is not a synonym for "accuracy". A true value is a value
consistent with the definition of a given particular quantity and this is a value that would be obtained by a perfect measurement.
In contexts where perfect measurement is not practically feasible, a conventional true value is a value attributed to a particular
quantity and accepted, sometimes by convention, as having an uncertainty appropriate for a given purpose. 'Conventional true
value', in the same reference, is sometimes called assigned value, best estimate of the value, conventional value or reference
value. The accuracy can be expressed in terms of the Mean magnitude of relative error.
[SOURCE: ISO/IEC Guide 99:2007 International vocabulary of metrology — Basic and general concepts and
associated terms]
3.47
ACIA
1. asynchronous communication interface adapter
3.48
ACID
1. Atomicity Consistency Isolation Durability [ISO/IEC 10746-1:1998 Information technology — Open Distributed
Processing — Reference model: Overview]
3.49
ACQ
1. acquirer [ISO/IEC TR 29110-5-6-2:2014 Systems and software engineering — Lifecycle profiles for Very Small
Entities (VSEs) — Part 5-6-2: Systems engineering — Management and engineering guide: Generic profile group: Basic
profile, 4.2]
3.50
acquire project team
1. the process of confirming human resource availability and obtaining the team necessary to complete project
activities [A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fifth Edition]
3.51
acquirer
owner
purchaser
1. stakeholder that acquires or procures a product or service from a supplier [ISO/IEC 12207:2008 Systems and
software engineering — Software life cycle processes, 4.1; ISO/IEC TS 24748-1:2016 Systems and software engineering
— Life cycle management — Part 1: Guide for life cycle management, 2.1; ISO/IEC/IEEE 15288:2015 Systems and
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

software engineering — System life cycle processes, 4.1.1] 2. person or organization that acquires or procures a
system, software product, or software service (which can be part of a system) from a supplier [ISO/IEC TR
12182:2015 Systems and software engineering — Framework for categorization of IT systems and software, and guide
for applying it, 3.13] 3. individual or organization that acquires or procures a system, software product or software
service from a supplier [ISO/IEC 25040:2011 Systems and software engineering — Systems and software Quality
Requirements and Evaluation (SQuaRE) — Evaluation process, 4.1]
Note 1 to entry: The acquirer can be internal or external to the supplier organization. Acquisition of a software product can
involve, but does not necessarily require, a legal contract or a financial transaction between the acquirer and supplier.
3.52
acquisition
1. process of obtaining a system, product, or service [ISO/IEC TS 24748-1:2016 Systems and software engineering —
Life cycle management — Part 1: Guide for life cycle management, 3.2; ISO/IEC/IEEE 15288:2015 Systems and
software engineering — System life cycle processes, 4.1.2] 2. obtaining human and material resources necessary to
perform project activities. Acquisition implies a cost of resources, and is not necessarily financial [A Guide to the
Project Management Body of Knowledge (PMBOK® Guide) — Fifth Edition]
3.53
acquisition strategy
1. specific approach to acquiring products and services that is based on considerations of supply sources, acquisition
methods, requirements specification types, contract or agreement types, and related acquisition risks
3.54
action
1. element of a step that a user performs during a procedure [ISO/IEC 26514:2008 Systems and software engineering
— requirements for designers and developers of user documentation, 4.2] 2. description of an operation to be taken
in the formulation of a solution [ISO 5806:1984 Information processing — Specification of single-hit decision tables,
3.7] 3. something which happens [ISO/IEC 10746-2:2009 Information technology — Open Distributed Processing —
Reference Model: Foundations, 8.3] 4. user behavior that a system accepts as a request for a particular operation
[ISO/IEC TR 25060:2010 Systems and software engineering — Systems and software product Quality Requirements
and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability: General framework for usability-related
information, 2.2] 5. process of transformation that operates upon data or other types of inputs to create data,
produce outputs, or change the state or condition of the subject software [IEEE 1175.3-2004 IEEE Standard for CASE
Tool Interconnections - Reference Model for Specifying Software Behavior] 6. statement of causal and affective
relationships in a behavior model linking particular stimulus interactions to particular response interactions and
changes within a unit under a certain set of conditions on a unit's lifeline [IEEE 1175.4-2008 IEEE Standard for CASE
Tool Interconnections - Reference Model for Specifying System Behavior, 3.1]
3.55
action entry
1. indication of the relevance of an action to a particular rule [ISO 5806:1984 Information processing — Specification
of single-hit decision tables, 3.9]
3.56
action of interest
1. action in a transaction which leads to a state change of significance to the transaction [ISO/IEC 10746-3:2009
Information technology — Open Distributed Processing — Reference Model: Architecture, 13.7.1.2]
3.57
action signature
1. specification of an action that comprises the name for the action, the number, names and types of its parameters,
and an indication of the causality of the object that instantiates the action template [ISO/IEC 10746-2:2009
Information technology — Open Distributed Processing — Reference Model: Foundations, 9.14]
3.58
action stub
1. list of all the actions to be taken in the solution of a problem [ISO 5806:1984 Information processing — Specification
of single-hit decision tables, 3.11]
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.59
activation
1. one occurrence of a function's transformation of some subset of its inputs into some subset of its outputs [IEEE
1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.3]
3.60
activation constraint
1. function's requirement for the presence of a non­empty object set in a particular arrow role as a precondition for
some activation of the function [IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax
and Semantics for IDEF0, 2.1.4]
3.61
active area
1. (on­screen documentation) area that responds to user input
EXAMPLE: a window, icon or text field
3.62
active enterprise object
1. enterprise object that is able to fill an action role [ISO/IEC 15414:2015 Information technology — Open distributed
processing — Reference model — Enterprise language, 6.3.1]
3.63
active interconnection
1. physical interaction mechanism allowing the action of one thing to cause a change or to stimulate an action in
another thing [IEEE 1175.2-2006 IEEE Recommended Practice for CASE Tool Interconnection — Characterization of
Interconnections, 3.1]
3.64
active redundancy
1. in fault tolerance, the use of redundant elements operating simultaneously to prevent, or permit recovery from,
failures
cf. standby redundancy
3.65
active text
1. text displayed on the screen that responds to user input
3.66
active white space
1. area around textual or graphical elements, not including margins, which breaks up text, separates topic and
subtopic groupings, indicates hierarchical and topical relationships, highlights information, or makes text easier to
read
3.67
activity
1. set of cohesive tasks of a process [ISO/IEC 12207:2008 Systems and software engineering — Software life cycle
processes; ISO/IEC TS 24748-1:2016 Systems and software engineering — Life cycle management — Part 1: Guide for
life cycle management, 2.3; ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes,
4.1.3] 2. a distinct, scheduled portion of work performed during the course of a project [A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) — Fifth Edition] 3. order submitted to the system under test (SUT)
by a user or an emulated user demanding the execution of a data processing operation according to a defined
algorithm to produce specific output data from specific input data and (if requested) stored data [ISO/IEC
14756:1999 Information technology — Measurement and rating of performance of computer-based software systems,
4.1] 4. defined body of work to be performed, including its required input information and output information 5.
set of cohesive tasks of a process, which transforms inputs into outputs [IEEE 730-2014 IEEE Standard for Software
Quality Assurance Processes, 3.2] 6. element of work performed during the implementation of a process 7. set of
actions that consume time and resources and whose performance is necessary to achieve, or contribute to, the
realization of one or more outcomes [ISO/IEC TR 24766:2009 Information technology — Systems and software
engineering — Guide for requirements engineering tool capabilities, 3.1] 8. single­headed directed acyclic graph of
actions, where occurrence of each action in the graph is made possible by the occurrence of all immediately
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

preceding actions (i.e., by all adjacent actions which are closer to the head) [ISO/IEC 10746-2:2009 Information
technology — Open Distributed Processing — Reference Model: Foundations, 8.6]
Note 1 to entry: An activity normally has an expected duration, cost, and resource requirements. Activities are often subdivided
into tasks.
3.68
activity attributes
1. multiple attributes associated with each schedule activity that can be included within the activity list. Activity
attributes include activity codes, predecessor activities, successor activities, logical relationships, leads and lags,
resource requirements, imposed dates, constraints, and assumptions [A Guide to the Project Management Body of
Knowledge (PMBOK® Guide) — Fifth Edition]
3.69
activity code
1. one or more numerical or text values that identify chara
...