IEC 62559-2:2015

IEC 62559-2 ®
Edition 1.0 2015-04
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Use case methodology –
Part 2: Definition of the templates for use cases, actor list and requirements list

Méthodologie des cas d'utilisation –
Partie 2: Définition du formulaire type de modèle de cas d'utilisation, de la liste
d'acteurs et de la liste d'exigences

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 15
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 60 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Catalogue IEC - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
Application autonome pour consulter tous les renseignements
Le premier dictionnaire en ligne de termes électroniques et
bibliographiques sur les Normes internationales,
électriques. Il contient plus de 30 000 termes et définitions en
Spécifications techniques, Rapports techniques et autres
anglais et en français, ainsi que les termes équivalents dans
documents de l'IEC. Disponible pour PC, Mac OS, tablettes
15 langues additionnelles. Egalement appelé Vocabulaire
Android et iPad.
Electrotechnique International (IEV) en ligne.

Recherche de publications IEC - www.iec.ch/searchpub
Glossaire IEC - std.iec.ch/glossary
Plus de 60 000 entrées terminologiques électrotechniques, en
La recherche avancée permet de trouver des publications IEC
en utilisant différents critères (numéro de référence, texte, anglais et en français, extraites des articles Termes et
comité d’études,…). Elle donne aussi des informations sur les Définitions des publications IEC parues depuis 2002. Plus
projets et les publications remplacées ou retirées. certaines entrées antérieures extraites des publications des

CE 37, 77, 86 et CISPR de l'IEC.
IEC Just Published - webstore.iec.ch/justpublished

Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications IEC. Just
Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur cette
Disponible en ligne et aussi une fois par mois par email. publication ou si vous avez des questions contactez-nous:
csc@iec.ch.
IEC 62559-2 ®
Edition 1.0 2015-04
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Use case methodology –
Part 2: Definition of the templates for use cases, actor list and requirements list

Méthodologie des cas d'utilisation –

Partie 2: Définition du formulaire type de modèle de cas d'utilisation, de la liste

d'acteurs et de la liste d'exigences

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 29.020 ISBN 978-2-8322-2656-8

– 2 – IEC 62559-2:2015 © IEC 2015
CONTENTS
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviations . 8
4 Definition of a use case template . 12
4.1 Overview . 12
4.1.1 General . 12
4.1.2 Short template version and use case overview table . 13
4.1.3 Actor list and requirements list . 14
4.1.4 Use case repository . 14
4.2 Use case template . 14
5 Explanation of fields of the use case template . 17
6 Definition of an actor list . 29
7 Definition of a list for requirements . 30
Annex A (informative) Examples of actors . 34
Annex B (informative) Example of a use case based on the suggested template (short
and extended version) . 36
B.1 Short version of the use case "Locate and isolate fault and restore system
(FLISR Fault location, isolation, system restoration)" . 36
B.2 Use case overview table of the use case "Locate and isolate fault and restore
system (FLISR Fault location, isolation, system restoration)" . 41
B.3 Detailed version of the use case " Locate and isolate fault and restore system
(FLISR Fault location, isolation, system restauration)" . 41
Bibliography . 56

Figure 1 – IEC 62559 standard series . 5
Figure 2 – Overview of the use case template. 13

Table A.1 – Example of an actor list . 34

INTERNATIONAL ELECTROTECHNICAL COMMISSION
_____________
USE CASE METHODOLOGY –
Part 2: Definition of the templates for use cases,
actor list and requirements list

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62559-2 has been prepared by IEC technical committee 8: Systems
aspects for electrical energy supply.
This first edition cancels and replaces IEC PAS 62559:2008 which had been published together
with EPRI. Main content of the former PAS will be transferred to the new IEC 62559-4.
IEC 62559-1 to IEC 62559-3 are now more related to the application of the use case
methodology in standardisation. In this document, a revised and updated template is provided.

– 4 – IEC 62559-2:2015 © IEC 2015
The text of this standard is based on the following documents:
FDIS Report on voting
8/1389/FDIS 8/1395/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 62559 series, published under the general title Use case
methodology, can be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until the
stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to
the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

INTRODUCTION
For complex systems, the use case methodology supports a common understanding of
functionalities, actors and processes across different technical committees or even different
organizations. Developed as software engineering tool, the methodology can be used to
support the development of standards as it facilitates the analysis of requirements in relation to
new or existing standards. Further arguments for the use case methodology and background
information are available in IEC 62559-1.
Figure 1 provides an overview of the intended first parts of the IEC 62559, mainly describing
the relation between IEC 62559-2 and IEC 62559-3.
IEC 62559 − Use case methodology
Background: IEC 62559−1
Textual
use case
description
IEC 62559−2
Template
Word
UML use case
processing
IEC 62559−future
file / template
extension
UML profile definition
Web-
browser
2 possible routes
On-line Textual
editing Import / UML modelling tool
Export
XML
IEC 62559-3
Use case
repository
(Database)
Processes described in IEC 62559−1
IEC
Figure 1 – IEC 62559 standard series
IEC 62559-1 – Concept and processes in standardization
IEC 62559-1 is the basis for a common use case repository in order to gather use cases within
IEC on a common collaborative platform. This repository will also be used to organize a
harmonization of use cases in order to provide broadly accepted generic use cases as basis for
the further standardization work. It describes processes and provides basics for the use case
methodology like terms or use case types.
IEC 62559-2 – Definition of the templates for use cases, actor list and requirements list
IEC 62559-2 defines the structure of a use case template, an actor list and a list for
requirements. The document is mainly based on the previous IEC PAS 62559 specification and
shall be read together with IEC 62559-1.

– 6 – IEC 62559-2:2015 © IEC 2015
IEC 62559-3 – Definition of use case template artefacts into an XML serialized format
Based on IEC 62559-2, IEC 62559-3 defines the required core concepts and their serialization
into an XML format of a use case template, an actor list and a list for detailed requirements.
The XML format is used to transfer the content of the template to other engineering systems
(e.g. UML modelling tools). These documents are developed using the energy system and
Smart Grids as examples, but they are general enough to be transferred to other domains and
systems. It is intended to develop a UML profile definition based on this part in the future.
Motivation
The International Standard IEC 62559 "Use case methodology" is needed to fulfill the SG3
decision 7 made by the SMB at its February 2010 meeting (SMB/4204/DL, Decision 137/10)
requesting the urgent delivery of a generic use case repository for all Smart Grid applications.
Nevertheless, the use case methodology described in this document is intended for a broader
application within standardization exceeding Smart Grid systems.
More and more complex systems such as Smart Grids or Smart Cities are raising the question
of managing system level requirements, which have to be fed by many domains of expertise (in
standardization related to different Technical Committees (TCs)), and which have to be broken
down further and shared by many TCs in charge of specifying standards to support these
system level functions.
One way to handle this transversality efficiently is to set some common methods and terms.
The use case methodology is the current state of art and supports further engineering
activities.
The use case methodology offers a unique way for sharing ideas and requirements of new use
cases or business cases between many experts/TC's with different backgrounds: e.g. domain
experts with knowledge about energy systems or business processes on one hand and system-
/IT-experts defining exchanged information and communication on the other hand. In the
requirement development process, domain experts are providing general ideas and functional
requirements. The main goal is for system experts to detail down these use cases to a level
they can be used to specify interfaces, dedicated functionality, data and service model
exchange. However, safety- or EMC-experts (as examples) may also make use of the
described use cases, their terminology and identified requirements.
However, the starting point is to set up a frame for consistency within IEC helping IEC
members to provide use cases in a consistent manner – this standard shall serve as basis for
use case repositories in order to gather, administrate, maintain, and evaluate use cases.
Within IEC, a use case repository shall be used as common collaborative platform for use case
elaboration and to organize a harmonization of use cases in order to provide broadly accepted
generic use cases as basis for further standardization work.
But the use case template defined in this document may serve not only for the development of
standards, but also – as it was the original purpose of the previous IEC PAS 62559:2008 (refer
to IEC 62559-4) – as a helpful means for the realization of projects within the area of complex
systems. Also other applications, which need the benefits of a structured requirements
development and formalized description of functionality, may make use of the suggested
template.
The use case methodology has to be seen as a process which starts with the definition of
business ideas, goals and requirements, detailing these in use case descriptions. This
information can be used as a basis to identify/link reference architectures describing the types
of components used, and going further down to an analysis for the further standardization
process.
Further developments regarding the use case template are expected. These developments are
mainly related to information, which is required in the use case description for further analysis,
and which can be mapped to other information (e.g. to a reference architecture, IT security
methods, standards and data models). Partly this is considered in the suggested template of
this standard. Further relations will be described separately as they are still under development
and they might be considered for the further development of the IEC use case repository.

– 8 – IEC 62559-2:2015 © IEC 2015
USE CASE METHODOLOGY –
Part 2: Definition of the templates for use cases,
actor list and requirements list

1 Scope
This part of IEC 62559 “Use case methodology” defines the structure of a use case template,
template lists for actors and requirements, as well as their relation to each other. In this
document, a standardized template for the description of use cases is defined for various
purposes like the use in standardization organizations for standards development or within
development projects for system development.
This document was developed for general application in various domains and systems. The
energy system/smart grid is used as example in this document as it was one of the first usage
areas for this use case template, but this general template can be applied in other usage areas
different from energy systems as well (e.g. smart home or electro-mobility).
The motivation, background information on use cases, recommendations for the handling of
use cases and the processes for the description of use cases inside standardization and in
relation to a central use case repository is described in IEC 62559-1.
2 Normative references
Void.
3 Terms, definitions and abbreviations
For the purposes of this document, the terms and definitions given in IEC 62559-1and the
following apply.
3.1
use case
specification of a set of actions performed by a system, which yields an observable result that
is, typically, of value for one or more actors or other stakeholders of the system
[SOURCE: ISO/IEC 19505-2:2012, 16.3.6]
3.2
actor
entity that communicates and interacts
Note 1 to entry: These actors can include people, software applications, systems, databases, and even the power
system itself.
[SOURCE: Based on IEC PAS 62559:2008]
3.3
role
role played by an actor in interaction with the system under discussion
Note 1 to entry: Alternative: A role represents the external intended behavior of a party. A party cannot share a
role.
EXAMPLES A legally defined market participant (e.g. grid operator, customer), a generic role which represents a
bundle of possible roles (e.g. flexibility operator) or an artificially defined body needed for generic process and use
case descriptions.
Note 2 to entry: Legally or generically defined external actors may be named and identified by their roles.
[SOURCE: SG-CG/M490/E:2012-12, definition 3.17]
3.4
use case template
a form which allows the structured description of a use case in predefined fields
[SOURCE: SG-CG/M490/E:2012-12, definition 3.2]
3.5
repository
here used for a place where information like use cases can be stored, usually as a database
(refer to use case repository)
[SOURCE: based on SG-CG/M490/E:2012-12, definition 3.12]
3.6
use case repository
UCR
database, based on a given use case template, for editing, maintenance and administration of
use cases, actors and requirements including their interrelations
Note 1 to entry: The UCR is designed as collaborative platform for standardization bodies, inter alia equipped with
export functionalities as UML model or text template.
[SOURCE: based on SG-CG/M490/E:2012-12, definition 3.13]
3.7
system
set of interrelated elements considered in a defined context as a whole and separated from
their environment
Note 1 to entry: A system is generally defined with the view of achieving a given objective, for example by
performing a definite function.
[SOURCE: IEC 60050-351:2013, 351-42-08]
3.8
area
major usage area for use cases supporting of grouping, filtering and administration of use
cases within a common use cases database
EXAMPLE Energy Systems/Smart Grid, Smart Home.
Note 1 to entry: Might be used in combination with domain which further divides an area.
3.9
domain
area of knowledge or activity characterized by a set of concepts and terminology understood by
the practitioners in that area
EXAMPLE Taken from Smart Grid/energy system area: Generation, transmission, distribution, customer.
Note 1 to entry: Major area of similar technologies and organisational background, for the energy system some
domains are suggested in this document as examples thoughout this document.
[SOURCE: ISO/IEC 19501:2005: Unified Modeling Language Specification]

– 10 – IEC 62559-2:2015 © IEC 2015
3.10
group/grouping
group of actors in order to organize an actor list
EXAMPLE Smart metering actors like meter operator (role), smart meter gateway (devices).
Note 1 to entry: Might be used in combination with domain and area.
3.11
zones
automation levels, classified in combination with a reference architecture
EXAMPLE SGAM.
3.12
smart grid architecture model
SGAM
suggested reference architecture for the smart grid area
[SOURCE: SG-CG/M490/C:2012-12]
3.13
semantic model
structured description of the semantics of a set of information, e.g. using some information
modeling language like UML
Note 1 to entry: Many different semantic models are expressions of the same semantics. Even with one language,
like UML, there are lots of ways to represent the structure of the same kind of information.
Note 2 to entry: Semantic modeling only represents information content – it does not include formatting/encoding
(syntactical) specifications. There are typically many formatting/encoding options for a given semantic model.
[SOURCE: based on SGAC Semantic Framework, draft version]
3.14
canonical data model
CDM
semantic model chosen as the single unifying model that will govern the semantic definition of
a collection of data specifications, such as the specifications for message payload content for a
collection of interfaces
[SOURCE: based on SGAC Semantic Framework, draft version]
3.15
namespace
(standardized) space of names qualifying pieces of information, including information about
their name detailed semantic, and usually their attached model (e.g. canonical data model)
3.16
name of information
unique ID which identifies the selected information to be exchanged in the context of the use
case and its step-by-step analysis and which should be related to the namespace
3.17
by-default namespace
namespace where “name of information” is by default originated from

3.18
scenario
a possible sequence of interactions
[SOURCE: SG-CG/M490/E:2012-12, definition 3.10]
3.19
activity step
elementary step within a scenario representing the finest-grained description level of
interactions in the use case
[SOURCE: SG-CG/M490/E:2012-12, definition 3.11]
3.20
conceptual description
cluster of use cases which can be described in an overall description providing an introduction
and summarizing the main ideas and the relations between different high level use cases of the
cluster
EXAMPLE Flexibility concept in the Smart Grid area, smart charging in the electro-mobility/Smart Grid area.
3.21
cluster
group of use cases with a similar background or belonging to one system or one conceptual
description
[SOURCE: SG-CG/M490/E:2012-12, definition 3.3]
3.22
high level use case
use case which describes a general requirement, idea or concept independently from a specific
technical realization like an architectural solution
[SOURCE: SG-CG/M490/E:2012-12, definition 3.4]
3.23
primary use case
use case which describes in detail the functionality of (a part of) a business process
Note 1 to entry: Primary use cases can be related to a primary goal or function which can be mapped to one
architectural solution.
[SOURCE: SG-CG/M490/E:2012-12, definition 3.5]
3.24
secondary use case
elementary use case which may be used by several other primary use cases
EXAMPLE Communication functions.
[SOURCE: SG-CG/M490/E:2012-12, definition 3.6]
3.25
generic use case
use case which is broadly accepted for standardization, usually collecting and harmonizing
different individual use cases without being based on a project or technology-specific solution
[SOURCE: SG-CG/M490/E:2012-12, definition 3.7]

– 12 – IEC 62559-2:2015 © IEC 2015
3.26
specialized use case
use case which is using specific technological solutions/implementations
EXAMPLE Use case with a specific interface protocol.
[SOURCE: SG-CG/M490/E:2012-12, definition 3.8]
3.27
individual use case
use case which is used specific for a project or within a company/organization
[SOURCE: SG-CG/M490/E:2012-12, definition 3.9]
3.28
identification number
ID
string of characters representing the value of the identifier
EXAMPLE Each use case and each requirement have an ID.
[SOURCE: IEC 62507-1:2010, definition 3.5]
3.29
identifier
attribute associated with an object to unambiguously identify it in a specified domain
[SOURCE: IEC 62507-1:2010, definition 3.8]
3.30
requirement ID
R-ID
ID for the requirements in template section 4 in order to identify requirements in the general
requirements list
3.31
unified modeling language
UML
graphical modeling language for the specification, construction, and documentation of parts of
software and other systems.
Note 1 to entry: It has a very broad scope that covers a large and diverse set of application domains.
Note 2 to entry: This note only applies to the French language.
[SOURCE: Based on UML Infrastructure Specification, v2.4.1]
4 Definition of a use case template
4.1 Overview
4.1.1 General
Figure 2 provides an overview of the use case template and its internal relations as well as the
relation to the actor list and the requirements list, which are common for all use cases.

Short version
Use case template
of the template
General information
Template section 1 and 3.2
Existing data models
(if available)
Function
Template section 1.4: Narrative
Generic actor list
(Use case repository)
Actors
Template section 3.1
Step-by-step analysis
Template section 4
Actors
Information exchanged
Requirements list
Requirements
(Use case repository)
Summarizing information
Information exchanged
Template section 5: summary of the step-by-step table
Requirements
Template section 6: summary of the step-by-step table
Common terms and definitions
Template section 7
Custom information
Template section 8: for future extension, in case

IEC
Figure 2 – Overview of the use case template
Some fields require inputs which are/should be predefined for easier harmonization and
analysis of use cases (it is recommended to use standardized lists). These recommended
answers are described in the explanation of the use case template. In a tool-supported
repository, the selection of predefined answers can support the author.
Existing use case descriptions are mainly based on a similar template design and can be
migrated into the defined version of this standard, if required. In this case, an individual
mapping table for the fields is required.
In the following, the template is defined being first provided as empty version in 4.2 below. The
template and its fields are explained in Clause 5.
4.1.2 Short template version and use case overview table
Only the following fields are mandatory covering the minimum short version of a use case
which is mainly used for a first version of a new use case:
– name of use case,
– author,
– date,
– narrative,
– 14 – IEC 62559-2:2015 © IEC 2015
– actors.
The short version is the basis for the complete use case and can simply be extended with the
addition of further information, i.e. without rewriting the use case. Being self-explaining, the
short version is seen as an easy starting point for domain experts without going into every
detail of the use case methodology and its complete use case template.
Use cases can be displayed in a brief overview table (single row per use case). It can be used
to scope the full list of possible use cases as tabular summary. Then, for instance, the most
important use cases can be identified and expanded using either the short or long template.
Name of use Short description Actors General
case remarks
First use case
Next use case
…
For examples, refer to Annex B. Further versions may be defined on individual demand, but it
is recommend to use the provided fields and their definitions described in this document in
order to be compatible with other use cases descriptions, tools, and repositories.
4.1.3 Actor list and requirements list
Following the explanation of the template, an actor list and a requirements list are pre-defining
answers for the respective fields in order to harmonize information in various use cases from
different sources. In standardization, the lists are virtually made available in the IEC use case
repository. A process for validating new information is described in IEC 62559-1.
4.1.4 Use case repository
The template may be used in a word processing software, but using a repository provides
several advantages: maintenance, overview of/interrelation between use cases, common basis
for working groups or communities, support of the use case experts providing already relevant
information like actors, requirements, etc. In addition to that, a repository can provide selection
boxes with predefined answers, allow an easier start using the short version, easier migration
to new versions of the template/consistent use of different versions (e.g. short and more
detailed), mapping of information, design of special reports/views, etc.
In general, all information related to the use case can be integrated into the existing template
and its defined fields. Nevertheless, section 8 of the template provides options for future
individual extension. It is strongly recommended to use existing fields in order to be
interoperable with general use case tools like the UCR.
For the official IEC template (and repository) fields of template section 8 can be used for future
adaptations until a new version of this standard is issued. IEC 62559-1 provides a process for
the request and validation of new fields. New fields for the use inside the IEC shall be
announced to the responsible committee and shall be acknowledged according to the
procedure described in IEC 62559-1, prior to use.
4.2 Use case template
The following overview provides the empty template. The template is explained in Clause 5.

1 Description of the use case
1.1 Name of use case
Use case identification
ID Area/ Domain(s)/ Name of use case
Zone(s)
1.2 Version management
Version management
Version Date Name of Changes Approval
No. author(s)  status
1.3 Scope and objectives of use case
Scope and objectives of use case
Scope
Objective(s)
Related business
case(s)
1.4 Narrative of use case
Narrative of use case
Short description
Complete description
1.5 Key performance indicators (KPI)
Key performance indicators
ID Name Description Reference to mentioned use
case objectives
1.6 Use case conditions
Use case conditions
Assumptions
Prerequisites
1.7 Further information to the use case for classification/mapping
Classification information
Relation to other use cases
Level of depth
Prioritisation
Generic, regional or national relation

Nature of the use case
– 16 – IEC 62559-2:2015 © IEC 2015
Further keywords for classification

1.8 General remarks
General remarks
2 Diagrams of use case
Diagram(s) of use case
3 Technical details
3.1 Actors
Actors
Grouping Group description
Actor name Actor type Actor description Further information

specific to this use
case
3.2 References
References
No. References Reference Status Impact on use Originator/ Link
type case organisation
4 Step by step analysis of use case
4.1 Overview of scenarios
Scenario conditions
No.
Scenario Scenario Primary Triggering Pre-condition Post-
name description actor event condition

4.2 Steps – Scenarios
Scenario
Scenario
No. 1 – …
name:
Step Event Name of Description Service Information Information Information Require-
No. process/ of process/ producer receiver exchanged ment,
activity activity (actor) (actor) (IDs) R-IDs

5 Information exchanged
Information exchanged
Information Name of Description of information Requirement, R-IDs
exchanged, ID information exchanged

6 Requirements (optional)
Requirements (optional)
Categories ID Category name Category description
for
requirements
Requirement Requirement Requirement description
R-ID name
7 Common terms and definitions
Common terms and definitions
Term Definition
8 Custom information (optional)
Custom information (optional)
Key Value Refers to
section
5 Explanation of fields of the use case template
In Clause 5, each table of the use case template is presented with descriptions of the content
of the table cells. Some additional information about this content is presented where helpful.
Different sections of the template are marked with grey background in order to differentiate
from clauses of this document.
Template section: 1 Description of the use case
Template section: 1.1 Name of use case
Use case identification
ID Area/ Domain(s)/ Name of use case
Zone(s)
ID: The identification number (ID) of a use case is unique within a repository or project and
serves for organization/administration of use cases.
Area /Domain(s)/Zone(s): Use cases can be used in various areas (e.g. energy system). Within
these areas, different domains are used to define/determine a more specific subgrouping.
Zones might describe additionally zones within an automation system or a reference
architecture. Experts in a particular field can suggest their set of domains (and zones) in order
to provide a common understanding how to group use cases within an complex area. These
predefined domains (and zones) can be chosen by the author of a use case (preselection). The
author can select one or more domains and zones, comma separated, as it is usual that use
cases are crossing different domains and zones.
EXAMPLE For the energy system according to the smart grid architecture model (SGAM), the following domains
and zones are suggested:
Area: Energy systems
Domains:
– Generation
– Transmission system
– 18 – IEC 62559-2:2015 © IEC 2015
– Distribution system
– Distributed Energy Resources (DER)
– Customers
Zones:
– Market
– Enterprise
– Operation
– Station
– Field
– Process
Transferring the SGAM example to other areas the domains have to be adopted accordingly, it
is assumed that the zones might be valid for other areas as well.
Name of use case: A short name, which should be unique within the area/domain and which
refers to the activity of the use case itself using “Verb + description”, should be used.
EXAMPLE Determine energy balance on substation level.

Template Section: 1.2 Version management
This section 1.2 is related to a version management and information about authors.
Version management
Version Date Name of Changes Approval
No. author(s)  status
Version No.: Sequential number to identify the version of the document.
Date: Date, when the version was created.
Name of author(s): This field is used to document who has provided the current version. It can
be a person, organisation or e.g. standardization committee like TC or WG.
Changes: When changing the use case, general changes shall be documented shortly in the
column “Changes”, multiple changes are separated with paragraphs.
Approval status: will be used within the standardization organizations. The procedures for
validation of use cases or actors will be defined in part 1 of this standard.
EXAMPLE Similar to working draft, committee draft (CD) for comments, committee draft for vote (CDV), for voting
(similar FDIS), final
Template section: 1.3 Scope and objectives of use case
Here the background or motivation of this use case is described.
Scope and objectives of use case
Scope
Objective(s)
Related business
case(s)
Scope: The scope defines the limits of the use case.

Objectives: List of objectives of the use case
Related business case(s): Provides a description or reference with some rationale for the
suggested use case. Usually the business case is related to several use cases. Therefore an
external reference or link to a business case/business requirements might be more efficient
and can be added here. Alternatively it may be described in this field. Refer also to template
section 3.2.
Template section: 1.4 Narrative of use case
Narrative of use case
Short description
Complete description
Short description: Short text intended to summarize the main idea as service for the reader
who is searching for a use case or looking for an overview.
Recommendation: This short description should have not more than 150 words.
Complete description: Provides a complete narrative of the use case from a user’s point of
view, describing what occurs when, why, with what expectation, and under what conditions.
This narrative should be written in plain text so that non-domain experts can understand it.
The length of the complete description can range from a few sentences to a few pages,
depending on the complexity and/or newness of the use case. This description often helps the
domain expert to reflect about the requirements for the use case before getting into the details
in the next sections of the use case template.
The description may include drawings for explanation (for UML diagrams refer to section 2).
Template section: 1.5 Key performance indicators (KPI)
Key performance indicators
ID Name Description Reference to mentioned
use case objectives
ID: Unique identifier for the Key Performance Indicator (KPI).
Name: Short name that describes the KPI.
EXAMPLE Increased Hosting Capacity DER.
Description: The description specifies the KPI and may include specific targets in relation to
one of the objectives of the use cas
...