ISO/IEC 23531:2020

Systems and software engineering - Capabilities of issue management tools

This document defines the capabilities of issue management tools and is used to select the most appropriate one from many issue management tools. The evaluation and selection of the issue management tools is performed in accordance with ISO/IEC 20741 which defines the general evaluation selection process and evaluation characteristics. Issue management is based on the tasks described in several activities in their processes (e.g. project assessment and control, decision management, and system/software requirements definition) of ISO/IEC/IEEE 12207. This document is independent of development methodology or approaches (e.g. Waterfall or Agile) or lifecycle processes (e.g. implementation or operation).

Ingénierie du logiciel et des systèmes — Capacités des outils de gestion des écarts

General Information

• Status: Published
• Publication Date: 20-Dec-2020
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 4 - Tools and environment
• Current Stage: 9020 - International Standard under periodical review
• Start Date: 15-Oct-2025
• Completion Date: 15-Oct-2025

Relations

• Consolidated By: ISO 15630-3:2025 - Steel for the reinforcement and prestressing of concrete - Test methods - Part 3: Prestressing steel
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 23531:2020 - Systems and software engineering - Capabilities of issue management tools - defines a structured, vendor-neutral framework for the capabilities of issue management tools. It provides an object model, use cases and a categorized capability catalog to help organizations evaluate and select issue management tools across development and operations lifecycles. The standard is independent of development methodology (e.g., Waterfall or Agile) and maps to lifecycle activities in ISO/IEC/IEEE 12207.

Key Topics

• Scope and purpose: Establishes what an issue management tool should support to manage issues, defects, incidents, work items and related relationships across the lifecycle (Scope, Clause 1).
• Object model and UML use cases: Defines an object model for issue management entities and use cases for work management, defect management and incident/IT service scenarios (Clause 4).
• Capability categories: Groups capabilities into Common, Work Management, Defect Management and IT Service Management (Clauses 4–6).
• Entities and relationships: Clarifies data entities that tools must create, update, refer to and archive (e.g., issue-ID, timestamps, artifact links) without including the artifacts themselves (Clause 4.3).
• Evaluation guidance: Designed to be used with ISO/IEC 20741, the guideline for evaluation and selection of software engineering tools (Annex A).
• Normative independence: No prescriptive methodology - applicable to development, testing and operations.

Practical applications and who uses it

ISO/IEC 23531:2020 is practical for organizations that must compare, procure or integrate issue management tools:

• Project managers and program leads use it to define selection criteria for tool procurement and deployment.
• Tool evaluators and QA/Testing teams apply the capability categories to compare defect tracking and test-issue workflows.
• Configuration and release engineers map issue entities and links to configuration management and build tools for traceability.
• IT service and operations teams assess incident and service-request handling capabilities.
• Vendors and integrators use the object model to design interoperable features and APIs.

Typical uses:

• Creating a requirements checklist for vendor comparisons
• Mapping tool features to lifecycle activities in ISO/IEC/IEEE 12207
• Ensuring traceability between issues and related artifacts (requirements, code, test results)
• Integrating issue tracking with CI/CD, CM and ITSM ecosystems

Related standards

• ISO/IEC 20741 - Guideline for the evaluation and selection of software engineering tools (integration for selection process)
• ISO/IEC/IEEE 12207 - Systems and software lifecycle processes (source of related tasks and activities)
• ISO/IEC 19505-2 (UML) - Notation used for model diagrams in the standard

Using ISO/IEC 23531:2020 helps organizations make objective, standards-based decisions when selecting and integrating issue management tools that support consistent issue, defect and incident handling across the software lifecycle.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 23531
First edition
2020-12
Systems and software engineering —
Capabilities of issue management tools
Ingénierie du logiciel et des systèmes — Capacités des outils de
gestion des écarts
Reference number
©
ISO/IEC 2020
© ISO/IEC 2020
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 at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions . 1
4 Object model for issue management tools . 2
4.1 Overview of issue management . 2
4.2 Use case of issue management . 3
4.2.1 Use case. 3
4.2.2 Use case scenarios . 4
4.3 Object model of issue management entity . 9
4.3.1 General. 9
4.3.2 Common entities . 9
4.3.3 Work Management entities .10
4.3.4 Defect Management entities .10
4.3.5 IT Service Management entities .11
4.4 Categories of capability of issue management tool .12
5 Category of issue management entity .13
5.1 Overview .13
5.2 Common entities .13
5.3 Work Management entities .13
5.4 Defect Management entities .13
5.5 IT Service Management entities .13
5.6 Summary of issue management entities .14
6 Capabilities of issue management tools .19
6.1 Overview .19
6.2 Common capabilities .20
6.3 Work management capabilities .23
6.4 Defect management capabilities .24
6.5 IT service management capabilities .25
6.6 Summary of capabilities .27
Annex A (informative) How to use this document with ISO/IEC 20741 .32
Annex B (informative) Overview of the approach for this document .33
Bibliography .36
© ISO/IEC 2020 – 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 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 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 http:// 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.
This document was prepared 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.
iv © ISO/IEC 2020 – All rights reserved

Introduction
Issue management tools have become increasingly important in project management and been applied
to a wide range of lifecycle processes, from development process to operation process. Information
managed by these tools has been expanded further than ever before, such as work items and claims as
well as defects. These tools need to cooperate with many other tools such as configuration management
tools, build tools, etc.
There are many issue management tools on the market but with no clear definition of their category
and their capabilities. Therefore, it is becoming difficult for project managers to choose the right tool.
This document provides a framework of category of issue management tools and a list of their
capabilities. The capabilities are gathered from existing tools (see Annex B). This document is prepared
as one of the capability series to select the appropriate tool in combination with ISO/IEC 20741
"Guideline for the evaluation and selection of software engineering tools" (see Annex A).
© ISO/IEC 2020 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 23531:2020(E)
Systems and software engineering — Capabilities of issue
management tools
1 Scope
This document defines the capabilities of issue management tools and is used to select the most
appropriate one from many issue management tools. The evaluation and selection of the issue
management tools is performed in accordance with ISO/IEC 20741 which defines the general evaluation
selection process and evaluation characteristics. Issue management is based on the tasks described
in several activities in their processes (e.g. project assessment and control, decision management, and
system/software requirements definition) of ISO/IEC/IEEE 12207.
This document is independent of development methodology or approaches (e.g. Waterfall or Agile) or
lifecycle processes (e.g. implementation or operation).
2 Normative reference
There is no normative reference in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC 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/
3.1
defect
imperfection or deficiency in a work product where that work product does not meet its requirements
or specifications and needs to be either repaired or replaced
[SOURCE: IEEE 1044:2009, 2]
3.2
incident
anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of
a project, product, service (3.5), or system
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.21]
3.3
issue
observation that deviates from expectations
EXAMPLE Potential defect (3.1), improvement or point needing clarification.
[SOURCE: ISO/IEC 20246:2017, 3.9]
© ISO/IEC 2020 – All rights reserved 1

3.4
problem
cause of one or more actual or potential incidents (3.4)
[SOURCE: ISO/IEC 20000-10:2018, 3.2.10]
3.5
service
means of delivering value for the user by facilitating results the user wants to achieve
[SOURCE: ISO/IEC TS 25011:2017, 3.3.1, modified — Notes 1 and 2 to entry have been removed.]
4 Object model for issue management tools
4.1 Overview of issue management
The overall structure of object model of issue management consists of the following elements:
a) issue management use case; defined in 4.2, a use case for describing issue management as an
integrated activity, building on the activities and tasks described in ISO/IEC/IEEE 12207 in
generic way,
b) issue management entity; defined in 4.3 and Clause 5, a set that represents identifiable information
which appears in issue management tasks and described as a class in the object model, and
c) issue management tool; defined Clause 6, a tool that supports creating, referring, updating and
deleting an issue management entity.
Figure 1 — Object model of issue management
The issue management entity comprises multiple entities. A set of entities is created when an issue
occurs, and referred, updated through its life to keep track the status, and archived after closing the
issue. There are two type of entities. One is the information of the issue itself such as issue-ID, date,
2 © ISO/IEC 2020 – All rights reserved

etc. Another is the relationship information between the issue and the related artifacts such as
requirements specification, source code, etc. The artifacts themselves are not included in this issue
management entity.
The issue management tool takes issue management entities as the input and produces issue
management entities as the output. The issue management tool effectively supports the management
tasks by producing issue management entities automatically.
The object model diagrams, Figure 1 to Figure 10, are described using Unified Modeling Language
(UML) 2 (ISO/IEC 19505-2).
4.2 Use case of issue management
4.2.1 Use case
Issue management is a task that is performed through the development and operation of a system. It is
not defined as a process or an activity, but it is described as a task in multiple processes and activities
in ISO/IEC/IEEE 12207. Therefore, these different use cases have different information related to the
issue, and it is not proper to describe them all in one use case.
In this subclause, three use cases for each of the different life cycle processes are identified as follows:
a) work management in development process: the response to various issues in system development
process such as requirement analysis, design definition and implementation;
b) defect management in testing process: the response to obstacles in the test process of the system;
c) incident management under operation process: the response to challenges centred on failure of the
system in the operation process.
Figure 2 — Use case diagram of issue management
© ISO/IEC 2020 – All rights reserved 3

4.2.2 Use case scenarios
4.2.2.1 Use case scenario of work management in system development process
In system development process, various issues occur and need to be properly managed. For example, in
the requirement analysis process, a number of questions are raised against the initial analysis results,
and those questions need to be tracked until it is resolved. In case of design review, once the design
is complete, a review task is scheduled, and the results are tracked. The details of the review task are
defined in ISO/IEC 20246. Work product reviews, and the capabilities of the review tool are defined
in ISO/IEC 23396. After the review, the unresolved issues by the review will be taken over as general
issues during the system development process. In this way, issues arise for different processes, different
actors, different work products and considerations, but in most cases the form of use case scenario
is the same. Figure 3 shows the work management use cases that are commonly handled during the
system development process.
a) The project manager instructs work and assigns it to the assigned customer or developer.
b) The assigned customer or developer performs the assigned work and report the results.
c) The project manager approves the result and the work content is completed.
Figure 3 — Activity diagram of work management
Table 1 notes that input, output, and actors are different from the use cases in work management in
system development process.
4 © ISO/IEC 2020 – All rights reserved

Table 1 — Explanation for the use cases in work management in system development process
Process Name of actor Input Output
Requirement analysis Customer Research items Result of research
(to customer)
Requirement analysis Developer Research items Result of research
(to developer) (system analyst)
Design definition Developer Requirement Design
(designer)
Implementation Developer Design Source code
(programmer)
4.2.2.2 Use case scenario of defect management in testing process
Issue management can be used for managing defects which are found during dynamic testing. The
actors are the technical manager responsible for defects, developer, tester, and system shown in
Figure 4. These actors work in the following scenario.
a) The tester tests the system. In the event of a defect, the tester will create a defect work item.
b) The technical manager responsible for defects approves the defect work item and assigns the
correction of the defect to the developer.
c) The developer identifies the cause of the defect assigned by the technical manager responsible for
defects and corrects the system.
d) The developer retests with the corrected test system and reports the result to the technical
manager responsible for defects.
e) The technical manager responsible for defects confirms the modified system, approves that the
issue has been resolved, and closes it.
© ISO/IEC 2020 – All rights reserved 5

Figure 4 — Activity diagram of defect management in testing process
6 © ISO/IEC 2020 – All rights reserved

4.2.2.3 Use case scenario of incident management in a system under operation
Issue management can be used for user concerns during operations. The actors are the user, operation
manager, technical manager responsible for defects, developer, tester, and system in Figure 5. These
actors work in the following scenario.
a) If the user finds an incident using the system, the user notifies the operation manager of the incident
contents.
b) The operation manager receives a notification from the user and creates an incident report.
c) The technical manager responsible for defects approves the incident report and assigns the work to
solve that issue to the developer.
d) The developer identifies the cause of the issue assigned by the technical manager and corrects the
system under test environment.
e) The tester retests the modified system of the test environment and reports the result to the
technical manager.
f) The technical manager checks the modified system and if it is confirmed to be fixed then approves
it and requests the developer to release it.
g) With the approval of the technical manager, the developer releases the modified system to the
operation environment.
h) The technical manager confirms that the issue has been resolved in the operation environment and
reports to the user that the incident has been resolved.
i) The user confirms that the incident has been resolved in the operation environment and contacts
the operation manager.
j) The operation manager closes the incident report.
© ISO/IEC 2020 – All rights reserved 7

Figure 5 — Activity diagram of IT service management
8 © ISO/IEC 2020 – All rights reserved

4.3 Object model of issue management entity
4.3.1 General
Figure 6 shows a detailed view of the issue management entity shown in Figure 1. As explained in the
use case in 4.2, there are three use cases that differ depending on the life cycle process, and information
specific to each use case and common information are handled. In Figure 6, information commonly
used in all use cases is represented as a namespace called Common, and information handled in each
use case is represented as namespaces called Work Management, Defect Management, and IT Service
Management. Furthermore, Common is imported and used in each use case.
Detailed attributes of each entity are described in Clause 5.
Figure 6 — Four name space of issue management entity
4.3.2 Common entities
As shown in Figure 7, entities common to each issue management use case scenario can be defined with
five classes. Issue records the issue and manages it. Status maintains the state the instance of Issue has.
Target System is the subject or the source of Issue. Trigger represents the activities or circumstances
in which the issue is found. Report collectively represents states of multiple instances of Issue. Status
usually has a hierarchical structure depending on the organizations and responsibilities to be approved.
© ISO/IEC 2020 – All rights reserved 9

Figure 7 — Class diagram of Common entities
4.3.3 Work Management entities
Work Management includes several entities as shown in Figure 8. These are defined as the subclasses
of four classes which are imported from Common. Issue which is imported from Common is inherited
to Work Item which is found as a result of consideration in the development process. Target System
which is imported from Common is inherited to Artifact which is created for the target system. Artifact
is inherited to and detailed as Requirement, Design Document, Program and Research Result. Trigger
which is imported from Common is inherited to Work Plan. Report which is imported from Common is
inherited to Unfinished Work Item List and To-do List.
Figure 8 — Class diagram of Work Management entities
4.3.4 Defect Management entities
Defect Management includes several entities as shown in Figure 9. These are defined as the subclasses
of four classes which are imported from Common. Issue which is imported from Common is inherited
to Defect. Target System which is imported from Common is inherited to Artifact which is created for
the target system. Artifact is inherited to and detailed as Requirement, Design Document and Program.
Report which is imported from Common is inherited to Defect Status List which shows the status of
10 © ISO/IEC 2020 – All rights reserved

the issues. Trigger which is imported from Common is inherited to Testing to discover defects. Testing
consists of the sub classes which are Test Plan, Test Environment, Test Program, Test Data and Test Result.
Figure 9 — Class diagram of Defect Management entities
4.3.5 IT Service Management entities
IT Service Management includes several entities as shown in Figure 10. These are defined as the
subclasses of four classes which are imported from Common. Status which is imported from Common
is inherited to Internal Approved Status. Issue which is imported from Common is inherited to Incident.
Target System which is imported from Common is inherited to System Under Operation. Trigger which
is imported from Common is inherited to Evidence. Evidence is inherited to and detailed as Claim,
Screen Capture, Screen Operation, and Input Data.
© ISO/IEC 2020 – All rights reserved 11

Figure 10 — Class diagram of IT Service Management entities
4.4 Categories of capability of issue management tool
A category of issue management tool capability is determined by the type of use case scenario. The
capability which processes common entities described in 4.3.2 that are commonly handled by the three
use cases is defined as common capabilities. Each capability to process each of the three sets of entities
described in 4.3.3, 4.3.4, and 4.3.5 is defined as work management capabilities, defect management
capabilities, and IT service management capabilities, respectively (see Figure 11). Work management
capability is to handle information on the tasks of development process. Defect management capability is
to handle information about defects that occurred in testing process. IT service management capability
is to handle information about incidents to which the user faces on the operation of IT services.
Figure 11 — Category of issue management tool capabilities
12 © ISO/IEC 2020 – All rights reserved

5 Category of issue management entity
5.1 Overview
Entities handled in issue management are defined in this clause. Common entities and the three specific
entities are defined as subclauses.
5.2 Common entities
In issue management, every use case is managed by five entities Issue, Status, Target System, Trigger,
and Report.
a) Issue
The occurred issue is recorded and managed as one instance of Issue. Normally, the identifier, the
name, the description of the content, the occurrence date and time, name of a person whom an issue
is assigned to, the priority, the related file, the comment of the participant, and the resolution time
limit are recorded. In addition, influence degree, progress rate, etc. may be recorded in some cases.
b) Status
The status of the issue is recorded and managed as one instance of Status. Normally, an assignment
identifier, a state identifier, a state name, a responsibility to approve, an approver, and an approval
date and time are recorded.
c) Target System
Information related to the object in which the issue occurred is recorded and managed as one
instance of Target System. Normally, objects are different depending on categories, and there is no
information handled in common.
d) Trigger
Information on the cause of the issue is recorded and managed as an instance of Trigger. Normally,
objects are different depending on categories, and there is no information handled in common.
e) Report
A set of issues corresponding to an arbitrary condition is recorded and managed as one instance
of Report together with the result of the statistical processing and calculation of the set of issues.
Normally, conditions to be specified, calculation and statistical processing are different from the
purpose of use. And there is no information handled in common.
5.3 Work Management entities
Information of Common entities and specific to work management is recorded and managed as one
instance of Work Management entities. See Table 2 for the attributes which are held by each entity.
5.4 Defect Management entities
Information of Common entities and specific to defect management is recorded and managed as one
instance of Defect Management entities. See Table 2 for the attributes which are held by each entity.
5.5 IT Service Management entities
Information of Common entities and specific to IT service management is recorded and managed as one
instance of IT Service Management entities. See Table 2 for the attributes which are held by each entity.
© ISO/IEC 2020 – All rights reserved 13

5.6 Summary of issue management entities
Issue management entities are summarized and the relation between attributes of entity and
ISO/IEC/IEEE 15289:2019 is shown as Table 2.
14 © ISO/IEC 2020 – All rights reserved

© ISO/IEC 2020 – All rights reserved 15
Table 2 — Summary of entities
Catego-
Com-
ry Relation to
Catego- mon
specific Explanation of entity Attribute name Explanation of attribute ISO/IEC/
ry entity
entity IEEE 15289:2019
name
name
Common Issue - Record and manage the occurred issue as one instance. Identifier A value that uniquely identifies an assignment
Name Name of the issue
Description A text explaining the contents of the issue
Occurred time Date and time when the issue occurred 10.21 c), 10.37 c)
Assigned to Name of person whom the issue is assigned to 10.21 h), 10.37 h)
Priority Priority of the issue
Related files Files related to the issue
Comment from related Comment from persons who have related with
persons the issue.
Response Response for the issue 10.21 f), 10.37 f)
Deadline for resolution Deadline to resolution of the issue 10.21 h), 10.37 h)
Impact Degree of impact from the issue 10.21 f), 10.37 f)
Occurred project Name of the project in which the issue occurred.
Related project Name of the project which is related to the issue.
Related users Identifier or name of the user who is related to
the issue.
Estimated time for Estimated time which is required to resolve the
resolution issue.
Progress Degree of progress by end of resolution.
Start date Date on which the assignee had started resolving
the issue
Expected date for Expected date on which the assignee finish 10.21 h), 10.37 h)
resolution resolving the issue.
Identifier of related Identifier of the other issues related to the issue.
issues Issues which is similar to the issue or is required
to be resolved before resolution of the issue, is
specified.
Related keyword Keyword related to the issue
Sensitivity Data to limit the users who can access the
issues from the viewpoint of confidentiality. For
instance, users, responsibilities and sets of these
elements which can access an issue can be set.
NOTE  The column of "Relation to ISO/IEC/IEEE 15289:2019" shows clauses and subclauses which describe the entity or the attribute in ISO/IEC/IEEE 15289:2019.

16 © ISO/IEC 2020 – All rights reserved
Table 2 (continued)
Catego-
Com-
ry Relation to
Catego- mon
specific Explanation of entity Attribute name Explanation of attribute ISO/IEC/
ry entity
entity IEEE 15289:2019
name
name
Status - Record and manage the status and the responsibility of the approval Identifier Identifier to be identified the related issue
as one instance together with the identifier of the issue. Generally,
Name of status Name of status of the issue 10.21 k), 10.37 k)
multiple people approval is required to approve one state.
Approvable responsi- Responsibility being able to approve for
...