Use Case methodology: a progress report

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.

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.

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

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.

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).

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.