ISO/IEC 23531:2020
(Main)Systems and software engineering — Capabilities of issue management tools
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
Buy Standard
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 23531:2020(E)
©
ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC 23531:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© 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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 3 ----------------------
ISO/IEC 23531:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members 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
---------------------- Page: 4 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 5 ----------------------
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
---------------------- Page: 6 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 7 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 8 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 9 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 10 ----------------------
ISO/IEC 23531:2020(E)
Figure 4 — Activity diagram of defect management in testing process
6 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 12 ----------------------
ISO/IEC 23531:2020(E)
Figure 5 — Activity diagram of IT service management
8 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 14 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 15 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 16 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 17 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 18 ----------------------
ISO/IEC 23531:2020(E)
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
---------------------- Page: 19 ----------------------
ISO/IEC 23531:2020(E)
© 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
...
FINAL
INTERNATIONAL ISO/IEC
DRAFT
STANDARD FDIS
23531
ISO/IEC JTC 1/SC 7
Systems and software engineering —
Secretariat: BIS
Capabilities of issue management tools
Voting begins on:
20201002
Voting terminates on:
20201127
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
ISO/IEC FDIS 23531:2020(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC FDIS 23531:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
CH1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 3 ----------------------
ISO/IEC FDIS 23531:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members 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 nongovernmental, 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
---------------------- Page: 4 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 5 ----------------------
FINAL DRAFT INTERNATIONAL STANDARD ISO/IEC FDIS 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
---------------------- Page: 6 ----------------------
ISO/IEC FDIS 23531:2020(E)
3.4
problem
cause of one or more actual or potential incidents (3.4)
[SOURCE: ISO/IEC 2000010: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
---------------------- Page: 7 ----------------------
ISO/IEC FDIS 23531:2020(E)
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 195052).
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
---------------------- Page: 8 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 9 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 10 ----------------------
ISO/IEC FDIS 23531:2020(E)
Figure 4 — Activity diagram of defect management in testing process
6 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 12 ----------------------
ISO/IEC FDIS 23531:2020(E)
Figure 5 — Activity diagram of IT service management
8 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 14 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 15 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 16 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 17 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 18 ----------------------
ISO/IEC FDIS 23531:2020(E)
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
---------------------- Page: 19 ----------------------
ISO/IEC FDIS 23531:2020(E)
© ISO/IEC 2020 – All rights reserved 15
Table 2 — Summary of entities
Catego-
C
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.