ISO/IEC/IEEE 24774:2021

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2021-05
Systems and software engineering —
Life cycle management —
Specification for process description
Ingénierie du logiciel et des systèmes — Gestion du cycle de vie —
Spécification pour la description des processus
Reference number
©
ISO/IEC 2021
©
IEEE 2021
© ISO/IEC 2021
© IEEE 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2021 – All rights reserved
ii © IEEE 2021 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 4
5 Specification of a process description and its elements . 4
5.1 Elements of process description . . 4
5.2 Process and related concepts . 4
5.3 Process description – required elements . 6
5.3.1 General. 6
5.3.2 Process name . 7
5.3.3 Process purpose . 7
5.3.4 Process outcomes . 8
5.4 Process description – optional elements. 9
5.4.1 General. 9
5.4.2 Process activities . 9
5.4.3 Process tasks . 9
5.4.4 Notes.10
5.4.5 Process inputs .10
5.4.6 Process outputs .10
5.4.7 Process controls and constraints .11
6 Process views and viewpoints .12
6.1 The process view concept .12
6.2 Process viewpoint .12
6.3 Contents of a process view .12
7 Claims of conformance to a process .13
Annex A (informative) Example process descriptions .14
Annex B (Informative) Process description traceability between elements .21
Annex C (informative) Example process view description .24
Bibliography .27
IEEE Notices and Abstract .29
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved iii

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 rules given in 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 https:// 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 24774 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards
Development Organization cooperation agreement between ISO and IEEE.
This first edition cancels and replaces ISO/IEC TR 24774:2010, which has been technically revised.
The main changes compared to ISO/IEC TR 24774:2010 are as follows:
— process definition and examples have been updated to reflect SC 7 latest standards;
— the former ISO/IEC Technical Report has been jointly revised with IEEE as an International Standard.
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.
© ISO/IEC 2021 – All rights reserved
iv © IEEE 2021 – All rights reserved

Introduction
For an organization to function effectively, the organization has to determine and manage numerous
interrelated activities and tasks to achieve its goals. An activity or a set of activities using resources
and managed in order to enable the achievement of outcomes through the transformation of inputs
into outputs can be considered a process. Often the output from one process forms the input to
other processes. When processes are explicitly described and performed in a systematic manner, the
likelihood of consistent quality in the results is improved. Thus, process descriptions and process
models (frameworks of related processes) enable consistent performance and delivery of expected
results.
A number of international, national and industry standards describe processes and process reference
models. The process descriptions vary in format, content and level of prescription. The purpose of this
document is to encourage uniformity in the description of processes. Uniform description of processes
facilitates adoption, adaptation and improvement of standardized processes, as well as process
assessment. The combination of processes and the development of process views from different
reference models eases the development of new models and facilitates comparison of processes.
In order for users of standards to select the appropriate forms of process description and apply them
in a consistent fashion, it is desirable to develop a common characterization of all of these forms of
process description. This document presents requirements for the description of processes in terms of
their format, content and level of prescription. The requirements of this document can be applied to any
process model developed for any purpose.
This document is intended for use by all parties that define process models, for example systems and
software engineers, sector or special interest groups, professional standards groups, researchers, and
process assessors.
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC/IEEE 24774:2021(E)
Systems and software engineering — Life cycle
management — Specification for process description
1 Scope
This document provides an explanation of considerations involved in defining a process. This document
gives requirements and recommendations for the description of processes by identifying elements and
rules for their formulation.
This document also describes the use of process views.
This document explains how conformance to a process can be defined, when the process is described in
accordance with this document.
This document does not describe how processes are composed or otherwise aggregated into
larger frameworks or life cycle models. Nor does the document cover how to assess or evaluate the
performance of a process, or the output (products) of a process.
NOTE Two prominent International Standards in process description for software and system engineering
are ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288. These two standards have very similar process models. The
information items associated with their process definitions are given in ISO/IEC/IEEE 15289. Other International
Standards provide further characterization of a single life cycle process by elaborating the process elements and
levying specific requirements on the execution of the process.
This document is applicable when processes are described for various process definitions in any party,
organization or standard relating to systems and software engineering processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
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:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org
— IEEE Standards Dictionary Online: available at http:// dictionary .ieee .org
NOTE 1 For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
Engineering Vocabulary) database and is publicly accessible at computer .org/ sevocab.
3.1
activity
set of cohesive tasks (3.20) of a process (3.8)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.3]
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved 1

3.2
base practice
activity (3.1) that, when consistently performed, contributes to achieving a specific process purpose
(3.12)
[SOURCE: ISO/IEC 33001:2015, 3.3.2]
3.3
information item
separately identifiable body of information that is produced, stored, and delivered for human use
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.12, modified — The preferred term "information product" has
been removed; notes 1 and 2 to entry have been removed.]
3.4
life cycle
evolution of a system (3.18), product (3.16), service, project or other human-made entity from conception
through retirement
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.26]
3.5
life cycle model
framework of processes (3.8) and activities (3.1) concerned with the life cycle (3.4), which can be
organized into stages (3.17), acting as a common reference for communication and understanding
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.27]
3.6
output
product (3.16), result, or service generated by a process (3.8)
3.7
procedure
information item (3.3) that presents an ordered series of steps to perform a process (3.8), activity (3.1),
or task (3.20)
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.19, modified — Notes 1 and 2 to entry have been removed.]
3.8
process
set of interrelated or interacting activities (3.1) that transforms inputs into outputs (3.6)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.33]
3.9
process improvement
actions taken to improve the quality of the organization's processes (3.8) aligned with the business
needs and the needs of other concerned parties
[SOURCE: ISO/IEC 33001:2015, 3.1.7]
3.10
process maturity
extent to which an organizational unit consistently implements processes (3.8) within a defined scope
that contribute to the achievement of its business needs (current or projected)
Note 1 to entry: This term is “organizational process maturity” with the same definition in ISO/IEC 33001.
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.23, modified — Note 1 to entry has been added.]
© ISO/IEC 2021 – All rights reserved
2 © IEEE 2021 – All rights reserved

3.11
process outcome
observable result of the successful achievement of the process purpose (3.12)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.34]
3.12
process purpose
high-level objective of performing the process (3.8) and the likely outcomes of effective implementation
of the process
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.35, modified — Note 1 to entry has been removed.]
3.13
process reference model
model comprising definitions of processes (3.8) in a domain of application described in terms of process
purpose (3.12) and outcomes, together with an architecture describing the relationships between the
processes
[SOURCE: ISO/IEC 33001:2015, 3.3.16]
3.14
process tailoring
making, altering, or adapting a process (3.8) description for a particular end
EXAMPLE A project tailors its defined process from the organization's set of standard processes to meet the
objectives, constraints, and environment of the project.
3.15
process view
description of how a specified purpose and set of outcomes can be achieved by employing the activities
(3.1) and tasks (3.20) of existing processes (3.8)
[SOURCE: ISO/IEC/IEEE 15026-1:2019, 3.2.2, modified — "may" has been changed to "can"; note 1 to
entry has been removed.]
3.16
product
result of a process (3.8)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.36, modified — Note 1 to entry has been removed.]
3.17
stage
period within the life cycle (3.4) of an entity that relates to the state of its description or realization
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.58, modified — Notes 1 and 2 to entry have been removed.]
3.18
system
combination of interacting elements organized to achieve one or more stated purposes
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46, modified — Notes 1, 2 and 3 to entry have been removed.]
3.19
tailoring
process (3.8) by which individual requirements in specifications, standards, and related documents
are evaluated and made applicable to a specific project by selection, and in some exceptional cases,
modification of existing or addition of new requirements
[SOURCE: ISO/IEC/IEEE 26513:2017, 3.38]
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved 3

3.20
task
required, recommended, or permissible action, intended to contribute to the achievement of one or
more outcomes of a process (3.8)
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.66]
3.21
view
representation of a whole system (3.18) from the perspective of a related set of concerns
Note 1 to entry: For further details, refer to ISO/IEC/IEEE 42020:2019, 3.24.
3.22
viewpoint
specification of the conventions for constructing and using a view (3.21)
Note 1 to entry: A viewpoint is a pattern or template from which to develop individual views by establishing the
purposes and audiences for a view, and the techniques for its creation and analysis.
Note 2 to entry: For a detailed explanation of view and viewpoint and how they can be defined and used, see
ISO/IEC/IEEE 42010.
Note 3 to entry: For further details, refer to ISO/IEC/IEEE 42020:2019, 3.25.
4 Conformance
Full conformance to this document can be claimed if process descriptions defined using the
requirements of this document clearly cover the required elements (5.2). Any of the optional elements
(5.3) may also be included either as requirements, recommendations, examples or suggestions.
5 Specification of a process description and its elements
5.1 Elements of process description
This document characterizes the following elements of process description:
— name;
— purpose;
— outcomes;
— activities;
— tasks;
— inputs;
— outputs;
— controls and constraints.
5.2 Process and related concepts
As defined in 3.7, a process is a set of interrelated or interacting activities that transforms inputs into
outputs. Figure 1 shows a typical representation of this transformation.
© ISO/IEC 2021 – All rights reserved
4 © IEEE 2021 – All rights reserved

Figure 1 — Basic process
There is no fixed dividing line between what constitutes a process and what is considered as a sub-
process or an activity within a process. Typically, processes are achieved through the performance of
activities comprising groups of related tasks. A significant activity of interest with numerous tasks can
also be described as a process if it were useful to treat the activity of interest in detail. The limits of a
process generally are determined by the production of a major output and outcomes, rather than the
intermediate outputs produced by activities within the process. Additionally, if processes are highly
automated and require little human control or intervention, it can be appropriate to combine several
processes into one process description.
NOTE 1 Often a set of processes are developed; and some processes are decomposed into more than one level.
However, decomposition of processes into more than three levels is likely to be confusing and hard for humans to
use.
Procedures differ from process descriptions in that procedures are written in steps to be followed in
order. Procedures can be written as instructions to the persons performing the procedure. Procedures
can also be written to assist an evaluator or auditor to understand the procedure, especially its controls
or outputs.
NOTE 2 ISO/IEC/IEEE 82079-1 provides detailed requirements for writing instructions.
Required activities are stated in process descriptions using either the imperative (as a command), or as
a 'shall' statement.
NOTE 3 Annex A shows different examples of the expression of mandatory/required process elements as used
in sample process descriptions.
Complete processes generally involve several types of generic activities (Table 1).
Table 1 — Model of generic activities within a process
Generic activity Example activities in the design Example activities/task in the
definition process implementation process
Strategize and plan (Plan) Prepare for software system design Prepare for implementation
definition
Perform (Do) Establish designs related to each soft- Perform implementation
ware system element.
NOTE  Adapted from ISO/IEC/IEEE 24748-3:2020, Table 1.
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved 5

Table 1 (continued)
Generic activity Example activities in the design Example activities/task in the
definition process implementation process
Evaluate and decide (Check) Assess alternatives for obtaining soft- Evaluate software unit and affiliated
ware system elements data or other information according
to the implementation strategy and
criteria.
Manage outcomes and outputs (Act): Manage the design. Manage results of implementation
Preserve and present artefacts and
information items
NOTE  Adapted from ISO/IEC/IEEE 24748-3:2020, Table 1.
Generally, several software or systems engineering processes are performed concurrently during a life
cycle stage. However, concurrent activities (e.g. installation and quality assurance inspections) are not
necessarily part of the same process, since their purpose, resources, methods, outputs, and outcomes
are different.
Process descriptions may be used either to describe generic processes (for example “project
management process”) or to describe a particular instance of a generic type (for example “project
management process for project A”). For specific process descriptions, generic process descriptions
may be instantiated with respect to roles or responsibilities, resources, required inputs and outputs,
constraints and controls, and time. Annex A provides examples of process descriptions used to develop
a process model. Annex B provides a technique for demonstration of process traceability between
elements, using an example process from Annex A.
Processes are often combined to form a process model (framework of related processes).
ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, for example, provide life cycle process reference models
for systems and software in which outcomes are defined and activities grouped for generic life cycle
process description. Based on ISO/IEC/IEEE 15288:2015, Annex A and ISO/IEC/IEEE 12207:2017,
Annex A, organizations or projects can apply process tailoring to suit the nature of the effort.
NOTE 4 ISO/PAS 19450 specifies concepts, semantics, and syntax of Object-Process Methodology as a
modelling paradigm and language for producing conceptual models at various extents of detail.
Various schemas for characterizing and evaluating process maturity, capability or quality are in use.
These schemas typically distinguish between levels of process performance and involve process
improvement. Process levels can involve following the process repeatedly to successfully achieve its
outcome or produce specified output, and automating and improving the process. The choice of details
in the process description can be used to characterize the process description at a certain level of
process maturity, capability or quality.
NOTE 5 ISO/IEC 33020 defines a process measurement framework for the assessment of process capability.
5.3 Process description – required elements
5.3.1 General
A process description can include the elements as shown in Figure 2. The minimum required elements
for a process description shall be the name, purpose, and outcomes. Optional elements, such as outputs,
activities, and tasks, may be included in process descriptions.
The goals and objectives of performing a process shall be described by using the elements of name,
purpose, and outcomes. These elements are used to describe intended results without the necessity
of performing structural decomposition of the process. Processes defined using name, purpose, and
outcomes provide a common starting point for process implementation and process assessment.
NOTE ISO/IEC/IEEE 15288:2015, Figure D.1 and ISO/IEC/IEEE 12207:2017, Figure D.1 show a process
construct. ISO/IEC/IEEE 24748-1:2018, Annex A also describes process elements.
© ISO/IEC 2021 – All rights reserved
6 © IEEE 2021 – All rights reserved

a
Element of a process description that can be used with any other element.
Figure 2 — Process description elements
To enable uniform description, 5.3.2 to 5.3.4 contain additional requirements for the process elements.
5.3.2 Process name
The name of a process description shall be stated as a short noun phrase that presents a descriptive
heading for the process. The name identifies the principal concern of the process and distinguishes
the process from other processes in the model. Because of the latter criterion, it may sometimes be
necessary to tailor the name of a process. For example, one may have a "software architecture process"
which is later refined as a "software detailed design process" or "data architecture process" or
"interface architecture process." Process names should end in the word process.
Wordy noun-verb or verb-noun phrases can get confused with process activities and often represent an
attempt to summarize the purpose or process so that the name can stand for the purpose. A descriptive
noun phrase - the name of the process - is more useful. The intent is to give a name, not a summary.
NOTE Although the term "process name" is preferred and used throughout this document, “process title” is
an acceptable alternative.
5.3.3 Process purpose
The purpose element of the process shall be stated as one or more related high-level goals for
performing the process. In cases where processes seem to overlap, the purpose element should be used
to characterize the scope or bounds of the process.
Whenever possible, the purpose element should be succinctly captured in a single sentence.
Summarizing the activities or outcomes of the process in the purpose statement should be avoided.
Use of the conjunction “and” to connect multiple clauses should be avoided as it would indicate that
the description is being written as an aggregation of marginally related outcomes rather than as a
statement of a single purpose. The purpose element shall begin with the words, “The purpose of the xxx
process is. “. The phrase, “in order to” may be useful in recording the objective of the process.
Further explanations of the purpose of a process can be placed in informative text or notes.
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved 7

5.3.4 Process outcomes
Process outcomes are measurable, tangible, technical or business results that are achieved by a
process. For example, the results are used by other processes. Outcomes are observable and assessable.
Outcomes are distinguished from outputs and are not stated as the production of a document, record,
or other information item.
An outcome shall be phrased as a declarative sentence using a verb in the present tense. For example, if
the preceding sentence is phrased as an outcome, the preceding sentence states, “Outcomes are phrased
as declarative sentences using verbs in the present tense.”
Outcomes shall be expressed in terms of a positive, observable objective, e.g. the provision of a service,
a significant change of state, the successful maintenance of a desired state (e.g. safety), or the meeting
of specified objectives (such as requirements, goals).
An outcome shall express a single result. Hence, the use of the word “and” or “and/or” to conjoin clauses
shall be avoided; such constructions are better expressed as multiple outcomes.
Outcomes of generic processes shall be written in a manner that is meaningful for any scope of
applicability, e.g. for organizations of any relevant domain or size.
As a test of completeness, the set of outcomes shall be sufficient to achieve the stated purpose of the
process.
As a test of relevancy, each outcome shall be phrased so that it is necessary to the achievement of the
purpose of the process.
Outcomes shall avoid requiring any specific method, technique or tool.
Outcomes shall avoid requiring any specific process measures or management methods.
Outcomes shall avoid presuming any particular sequence of execution; and the process user shall not be
expected to presume any sequence.
Outcome statements should be no longer than two lines of text, about 20 words.
A process should have from three to seven outcomes, but may have only one or two outcomes.
Outcomes should be differentiated from benefits, which are positive achievements from the execution
of a process, often spread broadly across the business and not necessarily related to the technical or
business intent of executing a process. Benefits are not usually assessable, or at least not assessable
using process assessment approaches. A benefit may provide the motivation to execute a process, but
it may not be the primary reason to do so. Benefits may be described in an informative Note to the
purpose statement.
The list of outcomes associated with a process should be prefaced by the text, “As a result of successful
implementation of this process.”
There is no need for a one-to-one correspondence between outcomes and activities; in particular, it is
not necessary to specify an activity for every outcome of a process or an outcome for every activity.
The execution of the activities, considered as a group, shall produce the set of outcomes, considered as
a group.
Outcomes should be meaningful and understandable when considered individually. They may be based
on terminology and concepts that are further explained by other material included in the process
description.
© ISO/IEC 2021 – All rights reserved
8 © IEEE 2021 – All rights reserved

5.4 Process description – optional elements
5.4.1 General
In many areas of application, a description needs to allow for a range of approaches to achieving outcomes
and in these cases a typical set of activities may be described. Alternatively, where conformance to a set
of tasks is required or recommended, the activities and tasks may also be described.
5.4.2 Process activities
Rather than describing the results of executing a process, activities describe a set of actions that can be
required, recommended, or permissible or typically undertaken to achieve or execute the process.
NOTE 1 ISO/IEC 33001 describes “typical activities” as “base practices” to be considered in a process
assessment.
NOTE 2 ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288 treat the activities and tasks in their process
descriptions as required for “full conformance to tasks”. They also allow the alternative of “full conformance to
outcomes.”
Activities are constructs for grouping together related tasks. The activities provide a means to look
at related tasks within the process to improve understanding and communication of the process. If an
activity is cohesive enough and sufficiently elaborated, it may be helpful to consider the activity as a
lower-level process with its own purpose and set of outcomes.
The set of lower-level processes and activities associated with a process shall be complete. In other
words, the set of lower-level processes and activities shall, when considered as a group, address the
achievement of all process outcomes and the satisfaction of the purpose of the process. Alternatively
stated, any action falling within the purpose and scope of a process necessarily falls within the scope of
one or more of the activities of the process.
Ideally, the definition of the activities of a process achieves a goal of “cohesion” in the same sense as that
term applies to software design. The tasks within a single activity should be strongly related to each
other and weakly related to those of other activities or processes.
Placing timing, scheduling, ordering or sequencing requirements on process activities should be
avoided because these limit application of the standards in alternative life cycle models. However, if
timing or sequencing constraints are necessary, they shall be explicitly stated. Synchronous process
description is sometime mandatory and considered as “state of the art “in some domains. In the absence
of any explicit statements, the reader shall not be expected to assume any timing or sequencing. Thus,
activities are not to be regarded as the “steps” in performing a procedure. Instead, they are to be
regarded as continuing or recurring responsibilities, but with a scope smaller than that of the entire
process. Specifying a set of activities can result in requiring the achievement of capabilities beyond
those associated with a minimal process maturity, capability or quality. The set of activities defined for
a process may thus go beyond the minimal achievement of process purpose. In other words, the set of
activities for a process should be sufficient to address all of the process outcomes, but may go beyond
the minimum set necessary for this. For example, the set of activities may include those associated with
planning, monitoring and controlling process performance.
Some processes, such as design and implementation, have multiple methods and techniques to achieve
acceptable results. It can be preferable to require compliance only to outcomes rather than to specific
activities or tasks, and to avoid specifying detailed methods unless they are indeed required for
conformance.
5.4.3 Process tasks
Tasks are written to define specific requirements or provide recommendations on the execution of a
conforming process.
© ISO/IEC 2021 – All rights reserved
© IEEE 2021 – All rights reserved 9

A task is expressed in the form of a requirement, recommendation, permissible or typically undertaken
action, intended to support the achievement of the outcomes of a process.
Unlike the process/activity relationship, the set of tasks within an activity is not required to “cover” the
activity. (If it were, then the writers of process models would have to write a task regarding every item
conceivable within the scope of an activity.) If we think in terms of Venn diagrams, then the total areas
of all of the lower-level processes and activities equal the area of the process. The tasks, however, are
points within the processes.
When providing additional tasks, informative mappings or other information explaining the role of
the additional tasks may be helpful. Examples include conformance requirements and achievement of
higher levels of capability (on any scale).
Placing timing or sequencing requirements on tasks should be avoided because this limits application
of the standards in alternative life cycle models. However, if timing or sequencing constraints are
necessary, they should be explicitly stated. In the absence of any explicit statements, the user is not
expected to assume any timing or sequencing requirements for the tasks.
5.4.4 Notes
Notes are used to describe the intent or mechanics of a process or process element. Notes provide
insight regarding related processes frequently performed at the same stage in the project life cycle,
potential implementation methods, constraints, or areas of applicability.
Process descriptions may also contain brief examples (longer specialized forms are typically
procedures, instructions, or process views).
5.4.5 Process inputs
Process inputs are those items transformed by the process to outputs. Human or automated resources
that perform the process are not considered as inputs. Inputs can come from other processes being
executed in a project, the organizational processes and resources, suppliers, or other external sources.
Specifying required or typical process inputs is helpful but optional, unless a closed-loop life cycle
model is used (where every output is an input to another process).
NOTE Process descriptions rarely specify required process inputs, because it is difficult to check
conformance, i.e., to prove that the organization considered and did not ignore specified inputs.
The widespread use of iterative or recursive life cycle models mean that outputs are being frequently
modified or improved, resulting in changes to the inputs of other concurrent or subsequent processes.
Major inputs and outputs of systems and software engineering processes, such as the requirements,
design, and information items, are thus repeatedly changed.
5.4.6 Process outputs
Depending on the method of evaluating process compliance or conformance, specifying process outputs
in the process description is optional, as long as it can be demonstrated that the process outcomes have
been achieved. Some process outputs are essential to build the end product or service deliverable. Other
process outputs are intermediate work products, produced only for customer validation or inspection
by auditors. Outputs frequently become organizational assets for use in other products and processes.
Process outputs are of two main types: artefacts and information items. Artefacts include prototypes,
models, system components and elements, as well as finished products and services. A work product is
an artefact associated with the execution of a process. There are four generic work product categories:
services (e.g. operation); software (e.g. computer program, documents, information, contents);
hardware (e.g. computer, device); and processed materials.
© ISO/IEC 2021 – All rights reserved
10 © IEEE 2021 – All rights reserved

The description of an information item consists of a name and a set of characteristics.
— Information item name: The name associated with the information item characteristics. This
name is provided as an identifier of the type of information item that the practice or process may
produce. Organizations may call these information items by different names. The name of the
information item in the organization is not significant. Similarly, organizations may have several
equivalent information items which contain the characteristics defined in one information item
type. The formats for the information items can vary.
— Information item characteristics: The potential characteristics associated with the information
item type. Characteristics may relate to the purpose and use of an information item, and its contents,
format and quality.
The use of generic types to classify information items simplifies the application of consistent structure,
content and format of similar information items, and supports the usability of process models.
The set of generic types used in ISO/IEC/IEEE 15289 to describe the information items implied in
ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288 is given in Table 2.
Table 2 — Generic information item types
Information
Information item characteristics
item name
Description A representation of a proposed or actual object or concept. It may include a textual, pictorial,
graphical or mathematical representation. It may be in a standardised form for human inter-
pretation. It may establish order, structure, grouping or classification.
Plan A proposed scheme or systematic course of action for achieving a declared purpose. It defines
when, how, and by whom specific processes or activities are to be performed. predicts how to
successfully accomplish objectives in terms of specific actions, undertaken at defined times
and employing defined resources. It may apply to technical, project or enterprise actions.
Policy A statement of an organization's high-level intention and approach to achieve objectives for,
and ensuring effective control of, a service, process, or management system.
Procedure A declared way of formally conducting a customary course of action. It defines an established
and approved way or mode of conducting business in an organization. It may detail a permis-
sible or recommended method in order to achieve technical or managerial goals or outcomes,
including the tools needed.
Record A permanent, readable (either human or machine-readable) form of data, information or knowl-
edge. Accessible and maintained evidence of the existence or occurrence of facts, events or
transactions. It m
...