SIST-TP IEC/PAS 62559:2009
IntelliGrid Methodology for Developing Requirements for Energy Systems
IntelliGrid Methodology for Developing Requirements for Energy Systems
This Publicly Available Specification (PAS) defines a methodology for power system domain experts to determine and describe their user requirements for automation systems, based on their utility business needs. This methodology was originally developed as part of the IntelliGrid Architecture developed by the Electrical Power Research Institute (EPRI), as a means to implement the "IntelliGrid vision" of the automated, self-healing, and efficient power system of the future. The IntelliGrid methodology is a subset of the science of systems engineering. Systems engineering methodology separates the concepts of "user requirements" from "technical specifications": user requirements define "what" is needed without reference to any specific designs or technologies, while technical specifications define "how" to implement the automation systems in order to meet the user requirements.
Metodologija IntelliGrid za razvojne zahteve energetskega sistema
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-junij-2009
Metodologija IntelliGrid za razvojne zahteve energetskega sistema
IntelliGrid Methodology for Developing Requirements for Energy Systems
Ta slovenski standard je istoveten z: IEC/PAS 62559
ICS:
29.020 Elektrotehnika na splošno Electrical engineering in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
Edition 1.0 2008-01
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
IntelliGrid Methodology for Developing Requirements for Energy Systems
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XF
ICS 29.020 ISBN 2-8318-9525-1
– 2 – PAS 62559 © IEC:2008(E)
CONTENTS
FOREWORD .9
EPRI DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES .11
1. SCOPE AND OBJECTIVES .12
1.1 Scope of the Specification .12
1.2 Overview of the Methodology .12
1.2.1 Concept of System Engineering .12
1.2.2 IntelliGrid System Engineering Methodology.12
1.2.3 Overview of Phased Approach .14
1.2.4 Phase 1: IntelliGrid Methodology for Executives .15
1.2.5 Phase 2: IntelliGrid Methodology for Domain Experts: Modeling User
Requirements with Use Cases.15
1.2.6 Phase 3: IntelliGrid Methodology for Project Engineers: Developing Detailed
User Requirements .17
1.3 Objectives of this Specification .17
1.4 Audience of this Specification .18
2. NORMATIVE REFERENCES.19
3. DEFINITIONS AND ABBREVIATIONS .21
4. GLOSSARY OF TERMS . 21
4.1 Referenced Sources of Glossary Terms. 21
4.2 Terms and Definitions . 22
5. INTRODUCTION TO THE INTELLIGRID ARCHITECTURE . 23
5.1 History and Rationale. 23
5.2 Basic Concepts . 24
5.3 The Pyramid. 25
5.4 Business Needs and Functional Requirements. 26
5.5 Development Phases. 27
5.6 Development Streams. 29
5.7 Scope Addressed in this Specification. 30
6. PHASE 1: EXECUTIVES DETERMINE BUSINESS NEEDS AND PLAN PROJECTS . 32
6.1.1 Determine Business and Regulatory Drivers. 32
6.1.2 Choose Projects. 32
6.1.3 Identify Candidate Technologies. 32
6.1.4 Define a High-Level Business Case . 32
PAS 62559 © IEC:2008(E) – 3 –
6.1.5 Refine Process for Your Organization .32
6.1.6 Identify Stakeholders .32
6.1.7 Establish a Project Team .33
6.1.8 Select Teams .33
7. PHASE 2: STAKEHOLDERS DEFINE USER REQUIREMENTS WITH USE CASES.35
7.1 Use Case Methodology.36
7.1.1 Use Case Introduction . 37
7.1.2 Use Case Selection.37
7.2 Use Case Workshops to Develop Requirements .37
7.2.1 Use Case Workshop Goals.37
7.2.2 Use Case Workshop Membership .38
7.2.3 Use Case Workshop Planning.38
7.2.4 Use Case Workshop Agendas.38
7.2.5 Developing Requirements and Business Value.39
7.2.6 Writing Good Requirements.40
7.3 Use Case Analysis.42
7.3.1 Global Actor List.42
7.3.2 Activity Diagrams .42
7.3.3 Interface Diagrams.44
7.3.4 Message Sequence Diagrams.44
7.3.5 Use Case Interaction Diagrams.45
7.3.6 Refining Requirements .45
7.3.7 Identify Security Risks.45
7.3.8 Distill Requirements .46
7.3.9 Evaluate Requirements vs. Business Case.46
7.3.10 Publish Requirements.46
8. PHASES 3-5: TECHNOLOGY SELECTION AND DEPLOYMENT .47
8.1 Design an Architecture.48
8.1.1 Resolve List of Actors .48
8.1.2 Identify Messages Exchanged.49
8.1.3 Define Interfaces.49
8.1.4 Define Security Domains .49
8.1.5 Define Security and Network Management Policies.49
8.1.6 Break Down Actors into Components.50
8.1.7 Assess Candidate Technologies.50
8.1.8 Map Candidate Technologies to Interfaces .50
8.1.9 Define Integration Interfaces.51
8.1.10 Test Architecture against Use Cases.51
– 4 – PAS 62559 © IEC:2008(E)
8.2 Select Technologies.51
8.2.1 Build Technology Capability Scales.51
8.2.2 Request Proposals.51
8.2.3 Evaluate Requirements and Proposals.53
8.2.4 Perform Gap Analysis . 53
8.2.5 Trade-Off Requirements .53
8.2.6 Identify Missing Standards and Technologies .53
8.2.7 Create Technology Roadmap.53
8.2.8 Submit Proposals to Standards Bodies and Industry Groups .54
8.2.9 Complete Final Business Case.54
A. ANNEX A: HOW TO DEVELOP USE CASES .55
A.1 What is a Use Case? .55
A.2 Purpose of the IntelliGrid PAS Use Case Template .55
A.3 IntelliGrid PAS Use Case Template: Setting the Stage.55
A.3.1 Domain Expert(s) Responsible for Use Case .55
A.3.2 Name of Function.56
A.3.3 Scope and Objectives of Function .56
A.3.4 Narrative of Function.56
A.3.5 Actors: People, Systems, Applications, Databases, the Power System, and
Other Stakeholders .56
A.3.6 Legal Issues: Contracts, Regulations, Safety Rules, and Other Constraints .56
A.3.7 Preconditions and Assumptions.56
A.4 IntelliGrid PAS Use Case Template: A Picture is Worth a Thousand Words .56
A.5 IntelliGrid PAS Use Case Template: Step-by-Step Interactions within Function.57
A.5.1 Steps Describe the Detailed Interactions.57
A.5.2 Contents of Steps.57
A.6 IntelliGrid PAS Use Case Template: Characteristics of Steps.58
A.6.1 Characteristics of Steps Capture Constraints and Details of User Requirements .58
A.6.2 Configuration Issues .58
A.6.3 IntelliGrid Quality of Service (QoS) Issues .62
A.6.4 IntelliGrid Security Issues .64
A.6.5 IntelliGrid Data Management Issues.67
A.6.6 IntelliGrid Constraints and Other Issues .71
B. ANNEX B: USE CASE TEMPLATE.72
B.1 Description of the User Requirements of a Function.72
B.1.1 General .72
B.1.2 Domain Expert(s) .72
B.1.3 Name of Function.72
PAS 62559 © IEC:2008(E) – 5 –
B.1.4 Scope and Objectives of Function .72
B.1.5 Narrative of Function.73
B.1.6 Actors: People, Systems, Applications, Databases, the Power System, and
Other Stakeholders .73
B.1.7 Legal Issues: Contracts, Regulations, Policies, and Constraints .73
B.1.8 Preconditions and Assumptions.73
B.2 Drawing or Diagram of Function .75
B.3 Step by Step Analysis of Function .76
B.3.1 Steps – Normal Sequence .76
B.3.2 Steps – Alternative, Error Management, and/or Maintenance/Backup
Sequences .77
C. ANNEX C: EXAMPLE OF TRANSMISSION SYNCHRO-PHASOR USE CASE .79
C.1 Description of the User Requirements of a Function.79
C.1.1 General .79
C.1.2 Domain Expert(s) .79
C.1.3 Name of Function.79
C.1.4 Scope and Objectives of Function .79
C.1.5 Narrative of Function.79
C.1.6 Actors: People, Systems, Applications, Databases, the Power System, and
Other Stakeholders .82
C.1.7 Legal Issues: Contracts, Regulations, Policies, and Constraints .83
C.2 Drawing or Diagram of Function .84
Step by Step Analysis of Function .85
C.2.1 Preconditions and Assumptions.85
C.2.2 Steps – Normal Sequence .86
C.2.3 Steps – Alternative, Error Management, and/or Maintenance/Backup
Sequences .89
EXAMPLE OF DISTRIBUTION AUTOMATION USE CASE .91
C.3 Description of the User Requirements of a Function.91
C.3.1 General .91
C.3.2 Domain Expert(s) .91
C.3.3 Name of Function.91
C.3.4 Scope and Objectives of Function .91
C.3.5 Narrative of Function.92
C.3.6 Actors: People, Systems, Applications, Databases, the Power System, and
Other Stakeholders .97
C.3.7 Legal Issues: Contracts, Regulations, Policies, and Constraints .100
C.3.8 Preconditions and Assumptions.101
C.4 Drawing or Diagram of Function .104
– 6 – PAS 62559 © IEC:2008(E)
C.5 Step by Step Analysis of Function .104
C.5.1 Steps – Normal Sequence .104
C.5.2 Steps – Alternative, Error Management, and/or Maintenance/Backup
Sequences . 112
D. EXAMPLE OF CONSUMER USE CASE . 114
D.1 Description of the User Requirements of a Function. 114
D.1.1 General . 114
D.1.2 Domain Expert(s) . 114
D.1.3 Name of Function. 114
D.1.4 Scope and Objectives of Function . 114
D.1.5 Narrative of Function. 115
D.1.6 Actors: People, Systems, Applications, Databases, the Power System, and
Other Stakeholders . 116
D.1.7 Legal Issues: Contracts, Regulations, Policies, and Constraints . 118
D.1.8 Preconditions and Assumptions. 118
D.2 Step by Step Analysis of Function . 120
D.2.1 Steps – Normal Sequence . 120
D.2.2 Steps – Alternative, Error Management, and/or Maintenance/Backup
Sequences . 125
PAS 62559 © IEC:2008(E) – 7 –
Figures
Figure 1: IntelliGrid Methodology for Project Definition .13
Figure 2: IntelliGrid Applications . 24
Figure 3: The IntelliGrid Architecture Pyramid. 26
Figure 4: Phases of the IntelliGrid Development Process . 28
Figure 5: Streams of the IntelliGrid Development Process. 29
Figure 6: Potential Stakeholders and Requirements Team Structure . 33
Figure 7: The Use Case Workshop Requirements Development Process. 36
Figure 8: Example of an Activity Diagram. 43
Figure 9: Interface Diagram Example . 44
Figure 10: Message Sequence Diagram Example .45
Figure 11: Requirements and Systems Architecture Process . 47
Figure 12: Technology Selection, Business Case, and Deployment Process. 48
Figure 13: Overview of the Technology Selection Process . 51
Figure 14: Example of a Technology Capability Measurement Scale . 52
Figure 15: Illustrative Diagram of a Function Described in a Use Case . 57
– 8 – PAS 62559 © IEC:2008(E)
Tables
Table 1: Checklist of IntelliGrid Configuration Issues .59
Table 2: Checklist of IntelliGrid Quality of Service Issues .63
Table 3: Checklist of IntelliGrid Security Issues.65
Table 4: Checklist of IntelliGrid Data Management Issues.67
PAS 62559 © IEC:2008(E) – 9 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
IntelliGrid Methodology for Developing Requirements for Energy Systems
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 provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment
declared to be in conformity with an IEC Publication.
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.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance with this
SM
document may involve the use of a service mark concerning EPRI .
Electric Power Research Institute and EPRI are registered service marks of the Electric Power Research Institute, Inc.
EPRI. ELECTRIFY THE WORLD and EPRI. SHAPING THE FUTURE OF ELECTRICITY are service marks of the Electric
Power Research Institute, Inc.
IEC takes no position concerning the evidence, validity and scope of this service mark right.
The holder of these service mark rights has assured the IEC that it is willing to negotiate licences under reasonable and
non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder
of these service mark rights are registered with IEC. Information may be obtained from:
EPRI, 3420 Hillview Avenue, Palo Alto, California 94303 USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other
than those identified above. IEC shall not be held responsible for identifying any or all such patent rights.
A PAS is a technical specification not fulfilling the requirements for a standard but made available
to the public .
IEC-PAS 62559 has been processed by technical committee 8: Systems aspects for electrical energy
supply.
The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document
Draft PAS Report on voting
8/1233/NP 8/1237/RVN
– 10 – PAS 62559 © IEC:2008(E)
Following publication of this PAS, the technical committee or subcommittee concerned will
transform it into an International Standard.
This PAS shall remain valid for an initial maximum period of 3 years starting from the
publication date. The validity may be extended for a single 3-year period, following which it
shall be revised to become another type of normative document, or shall be withdrawn.
PAS 62559 © IEC:2008(E) – 11 –
EPRI DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES
THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION(S) NAMED BELOW AS AN
ACCOUNT OF WORK SPONSORED OR COSPONSORED BY THE ELECTRIC POWER RESEARCH
INSTITUTE, INC. (EPRI). NEITHER EPRI, ANY MEMBER OF EPRI, ANY COSPONSOR, THE
ORGANIZATION(S) BELOW, NOR ANY PERSON ACTING ON BEHALF OF ANY OF THEM:
(A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER, EXPRESS OR IMPLIED, (I)
WITH RESPECT TO THE USE OF ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR
SIMILAR ITEM DISCLOSED IN THIS DOCUMENT, INCLUDING MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE, OR (II) THAT SUCH USE DOES NOT INFRINGE ON OR
INTERFERE WITH PRIVATELY OWNED RIGHTS, INCLUDING ANY PARTY'S INTELLECTUAL
PROPERTY, OR (III) THAT THIS DOCUMENT IS SUITABLE TO ANY PARTICULAR USER'S
CIRCUMSTANCE; OR
(B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER
(INCLUDING ANY CONSEQUENTIAL DAMAGES, EVEN IF EPRI OR ANY EPRI REPRESENTATIVE
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES) RESULTING FROM YOUR
SELECTION OR USE OF THIS DOCUMENT OR ANY INFORMATION, APPARATUS, METHOD,
PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT.
– 12 – PAS 62559 © IEC:2008(E)
IntelliGrid Methodology for Developing Requirements for Energy Systems
1. Scope and Objectives
This section describes the scope, purpose and objectives of this specification and the architect-
ure on which it was based.
1.1 Scope of the Specification
This Publicly Available Specification (PAS) defines a methodology for power system domain
experts to determine and describe their user requirements for automation systems, based on
their utility business needs. This methodology was originally developed as part of the IntelliGrid
Architecture developed by the Electrical Power Research Institute (EPRI), as a means to
implement the “IntelliGrid vision” of the automated, self-healing, and efficient power system of
the future.
1.2 Overview of the Methodology
1.2.1 Concept of System Engineering
The IntelliGrid methodology is a subset of the science of systems engineering. Systems eng-
ineering methodology separates the concepts of “user requirements” from “technical spec-
ifications”: user requirements define “what” is needed without reference to any specific designs
or technologies, while technical specifications define “how” to implement the automation
systems in order to meet the user requirements.
1.2.2 IntelliGrid System Engineering Methodology
The overall IntelliGrid systems engineering methodology is illustrated in Figure 1 and consists of
the following types of people and project steps:
x Executives or other utility managers review business cases which describe and
justify a perceived business need. They then approve specific projects.
x Domain experts and project engineers are tasked to develop a project team to
undertake the project. As one of the first undertakings of the project team, all power
system experts and other stakeholders (users) that could impact or be impacted by the
project should be identified and represented (full time, part time, or as applicable) on the
project team.
x Domain experts review the existing IntelliGrid Use Cases for applicability and ideas.
These Use Cases can be found at
http://intelligrid.info/IntelliGrid_Architecture/Use_Cases/IECSA_use_cases_overview.htm
x Domain experts develop a list of Use Cases (functional descriptions), covering not only
the specific business need but other user needs and future possibilities that could impact
or might be impacted by the project.
x Domain experts, with possible assistance by project engineers who understand the Use
Case process, draft the key Use Cases, capturing all of the necessary user require-
ments.
x Domain experts review and update these Use Cases to ensure their needs are
captured correctly and to assess possible misunderstandings, overlaps, holes, and other
inconsistencies
PAS 62559 © IEC:2008(E) – 13 –
x Project engineers assess and coordinate the Use Cases from which they develop a
comprehensive and detailed user requirements document. This detailed user require-
ments document contains only user requirements.
x Information specialists apply the appropriate standards and technologies, based on
the user requirements document. The strategic vision of the IntelliGrid Architecture
should be used to determine the key standards and technologies.
x Design engineers develop the Technical Specifications, which combine the user
requirements from the domain experts, the strategic standards and technologies from the
information specialists, and the tactical approach to system development recommended
by the IntelliGrid Architecture.
Figure 1: IntelliGrid Methodology for Project Definition
The user requirements as elicited by the Use Case process and ultimately described in the
detailed user requirements document cover:
x Functions from the user perspective, including functional description of processes, user
choices, types of input data, types of results, and possibly display appearance
– 14 – PAS 62559 © IEC:2008(E)
x Configuration issues, such as access to field data, electrically noisy substation
environment, control centre LAN, or cross-organizational interactions
x Performance requirements, such as availability, response times, latency, precision,
frequency of updated results, and other user parameters
x Security requirements, such as confidentiality, access restrictions, detection of failures
and/or intrusions, failure management, and other safety, security, and failure issues
x Data management requirements, such as sizes, numbers of devices, amounts of data,
expected growth over time, data access methods, data maintenance, and other data
management considerations.
x Constraints, such as contractual, legal, regulatory, safety rules, or other issues that
could impact the requirements
While a complete systems engineering methodology covers both the identification of user
requirements and the development of technical specifications, this PAS addresses only the
methodology for determining and documenting the user requirements.
1.2.3 Overview of Phased Approach
Although the IntelliGrid methodology covers the entire process for developing systems, this PAS
focuses only on the development of User Requirements, and therefore concentrates on the first 3
phases, although it also addresses the remaining phases as they are applicable to User
Requirements.
The IntelliGrid Architecture describes the overall methodology for undertaking projects consisting
of the following phases, as illustrated in Figure 2.
x Phase 1: Executives use Business Cases to approve projects in order to meet Business
Needs. Although this step in the process involves executive decisions based on cost-
justification and other non-technical factors, from the IntelliGrid Architecture point of
view, the key requirement for these executives in making decisions to approve projects is
that they should require all IntelliGrid Strategic Vision issues to be addressed in the
Business Cases. Specifically, the Business Cases should explicitly state whether or why
not the Strategic Vision issues will be part of the project, including Use Case modeling,
use of abstract data models, security issues, network and system management, data
management, and integration/interoperability.
x Phase 2: Domain Expert Stakeholders describe their User Requirements through the
formal Use Case process. Use Cases permit these experts to express their requirements
in a formalized manner that can then be coordinated and solidified into more detailed
functional and performance requirements in the next phase.
x Phase 3: Project Engineers develop the more detailed functional and performance
requirements from the Use Cases that were developed by the domain experts.
x Phase 4: Project Engineers and IT Specialists assess applicability to the project of the
standards, technologies, and best practices identified in the appropriate IntelliGrid
Environments.
x Phase 5: Design Engineers develop Technical Specifications based on Strategic Vision,
Tactical Approach, & Standards
PAS 62559 © IEC:2008(E) – 15 –
1.2.4 Phase 1: IntelliGrid Methodology for Executives
1.2.4.1 Step 1: IntelliGrid Recommendations for Executives
As described in the IntelliGrid Architecture report and web site, the following are the general
IntelliGrid recommendations for utility executives:
x Adopt the IntelliGrid Architecture as the strategic vision for the utility information
infrastructure
x Ensure that the different users of the IntelliGrid Architecture understand how to
utilize the relevant parts of IntelliGrid Architecture products, including the power system
functional descriptions and IntelliGrid Architecture Strategic Vision.
x Develop a plan for implementing the IntelliGrid Architecture methods and
standards-based technologies, based on the utility’s specific business needs, the
timeframe appropriate for meeting those needs, and the financial constraints.
x Provide feedback to EPRI and Standards Organizations so that the IntelliGrid
Architecture can evolve to meet future needs and recommend standards that are created
in the future.
x Ensure all Business Cases explicitly state how or why not the Strategic Vision
issues will be part of the project, including Use Case modeling for functions, abstract
data models, security issues, network and system management, data management, and
integration/ interoperability.
1.2.4.2 Step 2: Executives and Business Needs
When specific business needs are identified, executives have long used Business Cases as the
method for assessing and determining which business needs can and should be met. Business
Cases typically describe the business need, provide financial and organizational assessments of
potential ways for meeting the business need, and recommend a specific solution with a
justification for that recommendation.
As the first phase in the IntelliGrid methodology, executives (or other utility decision-makers) are
expected to review the Business Cases and approve those that meet certain justification criteria
(often financial payback criteria).
1.2.4.3 Step 3: Establishing a Project Team
Once the executives have approved a project to meet a business need, the first step is to
develop a project team. This project team should include representatives from all of the main
stakeholders, in order to ensure more useful functional requirements and to help ensure “buy-in”
by these ultimate users of the function. Not all stakeholders need to be full-time members of the
project team, but should always be included in any discussions that are relevant to their areas of
expertise.
1.2.5 Phase 2: IntelliGrid Methodology for Domain Experts: Modeling User Requirements with
Use Cases
1.2.5.1 Step 1: Identification of All Potential Stakeholders
One of the very first tasks of the project team should be to identify ALL potential stakeholders,
even if some eventually do not directly participate in the project. Often they may have
– 16 – PAS 62559 © IEC:2008(E)
requirements that may appear peripheral to the main project but could easily be met if designed
in from the beginning.
Once identified, all of these stakeholders should have the project explained (briefly) to them, and
then asked if they have any user requirements that could impact (or be impacted by) the project.
They should be encouraged to think “out of the box”, to brainstorm future scenarios, and to
envision new capabilities, rather than just restating existing functions. Thinking “out of the box”
and generating “idealized designs” about what a stakeholder really needs can make profound
changes in how businesses operate and how projects are implemented. This process can be
difficult because understanding what might be possible under different conditions and
technologies is very different from stating what is currently done.
Some of the new user requirements could just piggyback on the project without significant
technical or financial impact while others might involve changing the overall user requirements to
accommodate the new needs. Other requirements might lead to simple accommodations for
future expansion of the systems being implemented so that they could handle these new, but
possibly not yet justified, requirements in the future. Some brainstorming discussions might
cause other stakeholders to rethink their own needs in a new way.
Although not all new user requirements would be implemented immediately, this brainstorming
could lead new ways of thinking and eventually new projects to address those needs.
1.2.5.2 Step 2: Reviewing IntelliGrid Architecture Use Cases
The wheel should not be re-invented too many times. The IntelliGrid Architecture project
identified over 400 functions: these could serve as a checklist or initiate new discussions on new
types of functions. A few are described in more detail, using the IntelliGrid Architecture Use
Case template (from which the IntelliGrid PAS Use Case template was derived). These can be
reviewed also as illustrations on how Use Cases can be developed clearly and effectively to
describe functions.
1.2.5.3 Step 3: Brainstorming List of Functions (Use Cases) with Stakeholders
A list of functions should be developed by the stakeholders that will capture all user
requirements associated with the project area, even if some are “peripheral” to the main purpose
of the project. This list of functions will ultimately be described by a set of interconnected Use
Cases.
However, applying brainstorming to the Use Case process involves not only discarding old
mindsets that inhibit creative thinking, but also learning how to use the Use Case process most
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...