Use Case methodology: a progress report

Abstract

In this poster paper, we describe our experiences with the Use Case methodology in a funded consortium research project. In our project, more than 50 documented Use Cases evolved during five phases where their maturity continuously increased. They were firstly used in the application phase of the project, afterwards recorded more detailed, migrated and continuously updated in a repository for the further utilization, and outlined in the Smart Grid Architecture Model. The report addresses the methodology used, the organizational support as well as the synergies that warrant the effort spend on the Use Case methodology. We thereby describe our initial course of action as well as our experiences made during two years of deploying the methodology.

Introduction

The Federal Ministry for Economic Affairs and Energy initiated the funding programme “Schaufenster intelligente Energie – Digitale Agenda für die Energiewende” (SINTEG) to show how digitalization can boost the energy transition and to generate practical indicators for the future development of our legal framework. Over four years, a total of more than 300 million euros private invest and 200 million funding will be invested into the digitalization of the energy sector, across five SINTEG model regions.

EWE, a regional utility supplying the north west part of Germany being located in Oldenburg and the leader of the SINTEG project enera, has invited partners to discuss with them already in the phase between the initial announcement of SINTEG and the start of the application phase about topics which could become part of the project. Since the SINTEG announcement already obliges the use of the Smart Grid Architecture Model (SGAM) (firstly described in (CEN-CENELEC-ETSI Smart Grid Coordination Group, 2012)) and IEC 62559 (International Electrotechnical Commission, 2015) for the documentation, it was decided to use the Use Case methodology (Santodomingo et al., 2014; Trefke et al., 2013; Neureiter et al., 2014; Gottschalk et al., 2017) already in this phase of the project. Therefore, a course of action was concepted that will be explained in the following chapter. The experiences made with this concept are described afterwards and finally, we will describe our lessons learned and summarize the results at the end of this work.

Course of action

The course of action, that bases on (Santodomingo et al., 2014; Trefke et al., 2013; Neureiter et al., 2014; Gottschalk et al., 2017) and will be described in the following, can be divided into three parts: First, we adress the methodology and how it was used within the project context. Second, the organizational support plays an imported role and is described supplementary. Third, the expected synergies that motivate the strong position of the Use Case methodology within the project are explained.

Methodological approach

The Use Cases in the project enera evolved during five phases within two years. These phases are depicted in Fig. 1 and will be explained in the following paragraphs.

Fig. 1

Evolving phases of the Use Cases within the project

In the first phase, during the application for the funding programme, the so-called “SGAM Light” was queried on every Use Case. The SGAM Light is a project specific template based on MS Word and contains a subset of fields from the standardized Use Case template (International Electrotechnical Commission, 2015) for the Use Case description as well as fields needed to capture information needed to describe the intended Use Case realization in the funding application. The information queried in this template is listed in Table 1.

Table 1 Information queried in SGAM Light template

Between the grant and the official start of enera, the second phase proceeded on eliciting the Use Cases. Therefore, the template for the Use Case methodology provided by the International Electrotechnical Commission (IEC) in the international standard IEC 62559–2 (International Electrotechnical Commission, 2015) was used. Again, the template was filled with MS Word in this phase. Additionally, we prepared an actor list based on the market role model of the Federal Association of the German Energy and Water Industries (BDEW) (BDEW Bundesverband der Energie- und Wasserwirtschaft e.V, 2016) beforehand as an actor glossary to reach consistency in the notation of actors. This actor list raised no claim to completeness and was intended to be complemented by new actors once they were needed.

At the funded beginning of the project enera, the third phase for the Use Cases started. During this phase, the Use Cases were imported from the MS Word template to the webbased Use Case Management Repository (UCMR) from OFFIS.¹ Meanwhile, the actors and information exchanged within the Use Cases were subject to a consistency check, where the information exchanged was mapped manually to a high level data object catalogue and the consistency of actors was supported by the merge-function of the UCMR.

In the following fourth phase, the Use Cases were updated and refined within the UCMR. The background was a review of the Use Cases after their import, an introduction on the UCMR for the Use Case Owner (role definition see Table 2) and also an adaption of new knowledge on the Use Cases that resulted from the conceptual phase of the project.

Table 2 Definition of the role Use Case Owner in enera

Finally, the information from the Use Cases is used to document the project with the Smart Grid Architecture Model (SGAM) (CEN-CENELEC-ETSI Smart Grid Coordination Group, 2012). This phase is just proceeding about one year after the start of enera. Therefore, the Use Cases were classified into eight so called scopes that will get a separate SGAM model each. Table 3 shows where the information for the SGAM layers can be extracted from the Use Cases as described in (Clausen et al., 2018).

Table 3 Disposition of Use Case information in the SGAM (Clausen et al., 2018)

Organizational support

Top management attention was necessary in order to support the rollout of the SGAM Use Case methodology over the entire enera project. Twelve so called SGAM coaches where initially trained to support the Use Case Owners by modelling their Use Cases, whereby the role of the Use Case Owner was defined by the enera project management team (see Table 2). Moreover, the permanent coaches (some persons changed over time) established a SGAM governance team for adoption and harmonization of the framework for enera.

Communication was key over the time into both directions, to the Use Case Owners as well as to the enera management team. It was necessary to explain the entire framework, to take care of good modelling practice and to stress the benefits that are sketched in Fig. 2. Basing on and complementing literature (Clausen et al., 2018; Gottschalk & Uslar, 2015; Heussen et al., 2015; Uslar et al., 2016; van Amelsvoort & Uslar, 2016a; van Amelsvoort & Uslar, 2016b), the identified benefits to enera are:

• Consistent overview of all use cases and corresponding interconnections

• Supporting views for the project management

• Standardized actors and data model

• An end-to-end view for data privacy analysis

• An end-to-end view for data security analysis

Fig. 2

Added values of the Use Case methodology to the sponsor and the project

Furthermore, there are the following benefits to the ministry:

• Possibility to compare project description over all projects in the SINTEG consortium

• Reusability of project results in various scopes

• Backpropagation of framework adoptions into the IEC standardization processes

The benefit of supporting views for the project management was even lifted by the decision to plan and track the milestones and their interdependencies via the Use Cases. This anchors the importance of the Use Cases and their use over the whole project time with little extra effort.

Expected synergies

Already before the application for the funding programme of the project, the Use Cases had been defined and informations on them were collected for the application phase.

The second phase of recording the Use Cases was already performed before the official start of the project. The expected benefit was to get a technical overview including system components and essential data interfaces, especially to get an initial overview of systems that are going to be connected to the Smart Data and Service Platform (SDSP), which does play a vital and central role in the project enera.

The third phase aimed at providing access to the Use Cases to all project members in their latest version within the UCMR. Furthermore, the technical possibilities of the UCMR like described in (Gottschalk & Uslar, 2015) proposed to get information exchanges overarching several or even all Use Cases. One idea was filtering the Use Cases down to those including personal data, for example.

The continuous refinement and refreshing of the Use Cases in the fourth phase was planned to track the current state of the Use Cases. Furthermore, this aimed at tracking the current state of the project in the required SGAM documentation so this could be used as an actual state of the technical system landscape implemented.

Besides the interfaces to the SDSP, the technical system landscape also delivers input for the security analysis (Clausen et al., 2018; Uslar et al., 2016): the structure analysis and inventarisation can be conducted by using the technical system landscape and do not need to be gathered separately. Afterwards, the main findings can be transferred to the cross-cutting issue security in the SGAM.

Building upon the first use and establishment of the Use Case methodology and a Use Case Management Repository in the project DISCERN (Santodomingo et al., 2014; Trefke et al., 2013), enera extends the central role of Use Cases within the project and can be considered as the first user of the IEC 62559 use case methodology for project coordination purposes, and the project will provide very valuable feedback to the authors of IEC 62559 to improve the applicability of the use case methodology for more than only standardization purposes.

Experiences

In this section, we describe our experiences with the Use Case methodology. Therefore, we reuse the structure of the previous section and describe our experiences from the methodological, organizational and synergetical point of view.

Within the project enera, we identified 70 Use Cases in total, among them almost 50 that were judged to be technically important and therefore classified for a detailed description.

Methodological

The approach, to start with the “SGAM Light” version for the use case collection has been proven as very beneficial for the overall project. The additional workload for the project partners during the funding application was minimized, however the information collected during this phase already allows detecting first dependencies between the various tasks. This helps to motivate the project partner to continue with the 2nd phase of Use Cases recording.

For the Use Case elicitation, the information from the SGAM Light could easily be added manually as preparation.

As the showcase project enera bases on the three intensively connected core areas of network, market and data, the Use Cases strongly differ in their focus and content. Furthermore, the Use Cases differ in their granularity, too, as some Use Cases describe innovative, emerging technologies that are concepted during the project while other technologies are already prototyped, have a higher technology readiness level and will be rolled out. Thus, in the recording phase, some Use Cases could only be described with their principal idea while others could be described in technical detail.

For the template-based work, some fields of the Use Case template in MS Word were write-protected. This protection was sometimes avoided by copying the template into a new document. Fortunately, this had no serious effect on meeting the template, but some fields needed small rework to meet the specifications on the template for the import into the UCMR.

The prepared actor list was not used as strongly as originally intended. So here, a consolidation workshop of the coaches was needed after recording the Use Cases to harmonize the actors. Furthermore, there was a second consolidation workshop to standardize the information objects used. For this, each information object from the Use Cases was profiled on one page and besides the annotation of some general attributes, similar information objects were noted on the profile.

After recording the Use Cases in MS Word, they were prepared for the import into the UCMR and imported, too. This was performed by only one expert so the knowledge of (sometimes rare) import problems and their detection and solution could be used effectively. Though we used a template for the recording and had a write protection on the template file, various Use Cases needed adjustments due to syntactical reasons. But the chosen procedure proved beneficial for this task.

In the next phase, the Use Case Owners were involved again. While the Use Case recording was performed before the official start of the project, the first Use Case update was placed after the first half-year of the project. Yet, some Use Cases were still in their conceptional phase after the first half-year of the project, so their update needed to be postponed past the conceptional phase. In the meantime, several personnel changes occured between the preparation and the start of the project. This had effects on the Use Cases, too, as the contact persons for the Use Case Owners as well as some SGAM Coaches changed. So the methodology and process for the Use Cases needed to be explained and trained again to the new contact persons.

Another point is the availability of the Use Cases in the UCMR for the project staff. The 50 different Use Cases classified for a detailed description means round about 40 different Use Case Owners that need an account and introduction for the UCMR to maintain their Use Case. This number is increased even more by the colleagues that work on the Use Cases for the described synergies.

One risk in the fact that about 40–50 people have concurrent write access in the UCMR lies in the right management of the UCMR. Some contents of the Use Cases are managed centrally above all Use Cases (e.g. the actors), so each Use Case Owner needs write access on this content. But a modification in this central managed contents means a modification of e.g. actor definition in all Use Cases that use this content. This risk was adressed strongly while handing over the accounts, so the users were aware of this circumstance and until now, no problems occured on this point.

The last phase of exporting the information from the Use Cases to a visualization is just proceeding right now and has yet only been prepared methodologically. At this stage, we can say that the informations on the technical SGAM layers component, communication and information can be extracted automatically from the UCMR, while the organizational layers function and business need to be extracted manually. Table 3 shows where the information for the SGAM can be extracted from the IEC 62559 template like described in (Clausen et al., 2018). Except for the actors, the UCMR provides no field for the SGAM zone and domain of a content, so this always needs to be added manually. Yet, the UCMR provides still an extra function for an SGAM export that delivers an OpenDocument Spreadsheet filled with the available information. This Spreadsheet can be complemented easily by hand and then smoothly fits for the import in the 3D visualization tool for SGAM.²

Organizational dimensions

The management support could be motivated and helped to establish the role of the Use Cases within the project. The resources for the Use Case recording before the official start of the project could be provided, too. Yet by the start of the project, many Use Case Owners changed because of organizational changes. Furthermore, some Use Cases changed contentwise over time, so that the ownership switched to another company involved in the project, Use Cases were discarded or newly defined. This needed to be tracked and in the beginning, the report of changes on Use Cases to the SGAM coaches was not always present. But due to the continuous organizational support by the management team and the reuse of the Use Cases for the explained benefits and synergies, the role of the Use Cases within the project could be supported and by now, changes on Use Cases are reported by the stakeholders to the coaches without extra trigger.

Synergies

As expected, the information collected during the SGAM Light query could easily be used for the application on the funding programme for the project as well as for the further specification of the Use Cases.

The description of the Use Cases with the template did give input to the expected generic high-level system architecture overview of the Smart Data and Service Platform (SDSP), yet still there were some extra workshops with the Use Case Owners needed from the requirements management team of the SDSP to extract, refine and harmonize the informations needed.

Among the technical overview including system components and essential data interfaces the template does include an initial overview of systems that are going to be connected to the SDSP. The initial systems have been split up into five non-technical categories to support the work of the editors and give them some help. The categories have been Market, Enterprise, Operational IT, Station and Field bus level.

The editors did get access to an additional list of all non-technical information/data-objects defined at that time and to a list of all actors/roles.

It is easy to create a simplified version on behalf of this building blocks. This includes primarily a simplified assembly of systems, information objects and actors. In this step, a textual description was not foreseen. The non-complex handling of data acquisition on behalf of the use of templates with graphical elements did work out very well. The procedure could be valuated in a positive way, although at a later stage it is of course necessary to collect more information and add it to the Use Case documentation.

Due to the previously described collection and assembly of Use Case information even before the start of the project containing a first connection to the architecture of the SDSP, it was the case that at the beginning of the project an overview of the responsible contact persons and a high level IT-system architecture already did exist.

The continuously refinement and evolution of the Use Cases lead to a deeper understanding of the technical system landscape. The final analysis of the overall picture of the Use Cases does create a good first overview of the system landscape, covering applications, devices and IT-systems. This overview results in a practical starting point for the operational work of the requirements engineering, making use of the SGAM Use Cases subsequently.

The project enera has the obligation to create an information security management concept (resp. ISMS) within a separate work package. Among generic requirements like the handling of legal restrictions and handling of certification issues a major part of that work is the so called structure analysis. The German federal agency for information security (BSI) claims in its model for basic IT-security to define an area of application as well as a subsequent way of recording of objects belonging to that area.

The structure analysis consists of the observation of business processes, the technical network structure, IT-systems up to the spatial conditions. The information on processes and IT-systems can be extracted out of SGAM in principal. To enhance the necessary further information, an import of the SGAM Use Cases to the ARIS tool (Software AG) did get implemented. After designing an adequate methodical mapping, the mandatory information for the structure analysis could be reused. Additionally all other needed types of objects had been defined and consequently added straight to the imported SGAM Use Cases (see Fig. 3).

Fig. 3

Security concept and SGAM for ISMS

The further refinement and documentation of the needed level of defense is done within ARIS, a direct information channel back to the SGAM Use Cases in UCMR was not envisioned.

However, it will be checked if information, which was required to be added in ARIS might be suitable to be collected already during the Use Case description, as this would not impose to much additional effort for the Use Case writer, but could help to ease the ARIS workflow. If such kind of information is identified, a proposal to enhance IEC 62559 accordingly will be created.

Besides the project own usage of the Use Cases, they also where used to give input for the accompanying research of the project. Therefore, an export of all Use Cases with their name, short description and long description was provided in their current state to give a more detailed and actual overview. The work of the accompanying research aims in this case at developing overall key performance indicators overarching for all five projects of the funding programme SINTEG.

Lessons learned

During the initial phase of the project, three different approaches of completing a Use Case had been tried by the SGAM Coaches. The first was based on the complete SGAM stack and a hands-on workshop during a physical meeting. The second was also based on the complete SGAM stack, but instead of a physical meeting the Use Case owners mainly had been instructed by phone and then worked by their own. The third was to make use of the SGAM Light approach with a reduced methodology and less usage of text.

The third approach worked with quite every Use Case owner, but there is huge need to get more into details afterwards. The first approach worked also with quite every Use Case owner, but it is the most time consuming way. The second approach worked also well with Use Case owners having any kind of experience in creating structured concepts or similar kind of documents. If that is not the case, approach one or three would work better.

Summary

In the project enera, we used the Use Case methodology to describe all solutions that are deployed in the project to meet the challenges of the energy transition in Germany. This resulted in more than 50 documented Use Cases that needed to be recorded, reviewed, harmonized and tracked over time.

In total, after two years applying the Use Case methodology in the project context, we can say that the Use Case methodology

• is a method to specify informations and requirements within a project in a structured way,

• can be used to get overarching information from the whole project that can be used for the project management and implementations within the project,

• is usable even in a large project over time by using a Use Case Management Repository as a document management system,

• should be monitored continuously in the first elicitation phase of the Use Cases to handle the complexity and

• needs continuous attention to create added values like cost benefit and security analysis.

The sheer number of Use Cases leaded to a complexity that demands strongly for continuous audit and harmonization of the described Use Cases. But with these efforts, the Use Case methodology qualifies to get a structured overview of a project and creates synergies for overarching analyses like partly described or demonstrated in (Clausen et al., 2018; Gottschalk & Uslar, 2015; Heussen et al., 2015; Uslar et al., 2016; van Amelsvoort & Uslar, 2016a; van Amelsvoort & Uslar, 2016b) and outlined in this work, that outperform the invested efforts.