• TwitterFacebookLinkedInYoutube

Deliverable 1.1 Stakeholder Requirements Analysis

Please, note that this deliverable is currently under external review.

Executive Summary

The WHY Project follows the ambitious approach to improve the representation of household electricity demand in Energy System Models by applying a Causal Model to simulate the behaviour of residential consumers which will lead to the consumption of electricity. The first step into the development of the models and tools required to reach that goal is the involvement of stakeholders and the analysis of their requirements. Obtaining the stakeholder requirements is crucial both from a technical perspective (regarding the technical specifications of the WHY Toolkit like temporal and spatial resolutions, etc.) and non-technical perspective (regarding topics like the presentation of results or the general requirements for the toolkit). 

The goal of this report is the definition of the WHY Model Architecture for the WHY Toolkit from the analysis of the stakeholder requirements. The process was divided into four main phases, all of which are described in detail in this Deliverable. 

The first phase consists of the identification of the stakeholders who should provide the requirements for the WHY Toolkit. A preliminary research of potential stakeholders has been conducted during the proposal phase of the WHY Project which provided the foundation for the stakeholder identification process during the project. All project partners were involved in that process and had to look for stakeholders who would potentially benefit from the use of the WHY Toolkit or the use of Energy System Models in general. Furthermore potential stakeholders for later consultation on project results or methods were also identified during that phase of the project. The stakeholder identification phase resulted in a total of 85 stakeholders from 13 EU-member countries and multiple  different sectors and with different fields of expertise relevant to the WHY Project. Of these 85 stakeholders 63 stakeholders were identified as relevant for the requirements analysis. Due to the wide range of different stakeholders it was necessary to cluster these stakeholders according to their background and specific skill set. For that purpose three different clusters were defined:

  • Modelling experts with an academia background and policy consultants:
    Members of the academic community with focus on modelling or policy consultancy. A total of 14 stakeholders were assigned to this cluster.
  • Energy System Model users:
    Members of the energy industry, with some experience in Energy System Modelling and a solid understanding of energy systems as well as in energy policies and regulations. A total of 16 stakeholders were assigned to this cluster. 
  • Result users:
    Policy and decision makers who will very likely have limited knowledge in Energy System Models but substantial knowledge in energy related policies and regulations.  A total of 33 stakeholders were assigned to this cluster. 

The clustering of the stakeholders initiated the second phase of the stakeholder involvement process, the development of the methods to obtain the requirements from the stakeholders. Since the knowledge and expertise of the cluster was very heterogeneous,  the WHY Consortium concluded that methods applied to obtain the requirements needed to be tailored to the specific cluster. For that purpose three different approaches were chosen:

  • Focus Groups: For the academia cluster the method of creating focus groups and holding workshops was selected. During the preparation of the Focus Groups a lack in participation of stakeholders and limited time lead to a change in the method. The stakeholders had to provide their inputs via a survey and discuss the results during an online workshop. Since the inputs provided by the different stakeholders of the academia cluster were very homogenous, the workshop was canceled as discussions were not necessary.
  • Surveys: The stakeholders assigned to the cluster of Energy System Model users were asked to participate in a survey. The questions of the survey required a fundamental understanding of modelling and Energy System Models in general but it was assumed that the members of this cluster would have the required expertise to provide the answers without the need for feedback from the WHY Consortium.
  • Interviews: For the cluster of result users the method of participation in interviews was deemed to be the best option. Interviews provided the big advantage of interaction with the stakeholders and to obtain more detailed answers. 

Regardless of the initial assignment of the stakeholder involvement action, the stakeholders  were always offered the possibility of participating in another type of involvement action, an option that was very willingly used, as will be described later on. 

After defining the best approach to integrate the stakeholders into the WHY Project, the stakeholder involvement phase started, which lasted for 6 weeks. During that time a total number of 27 stakeholders from 11 different EU-member states participated in the stakeholder involvement actions. Of these 27 stakeholders 19 stakeholders were male (70%) and 8 stakeholders were female (30%). 

As mentioned before, the stakeholders were offered the possibility to participate in the type of stakeholder involvement action of their choosing, regardless of our initial assignment. This led to a very dominant shift in the distribution of participation. Only 3 stakeholders participated in the focus groups, 5 in the survey and a total of 19 in the interviews. While this was unexpected it did lead to positive results, as the answers from the interviews provided the most tangible results. Also the interviews provided the best opportunities to get to know the stakeholders and networks for potential exchanges of ideas during the course of the project. One of the main findings of the Deliverable D1.1 aside from the actual requirements is that Interviews should be the preferred type of actions to obtain requirements and build new networks.

After finishing the stakeholder involvement process, the inputs of the stakeholders were analysed. The most relevant results for the definition of the stakeholder requirements were obtained from the interviews, the results of the survey provided no new insights as they were in line with the results of the interviews. The results of the focus groups also provided no new insights. 

To create a better understanding of the different stakeholders, 5 different personas following the Persona Method (Pérez-Montoro and Codina, 2017) were created:

  • Elena: A modeller that designs and develops energy system models and supports decision making by public authorities and private businesses.
  • Max: An industry expert who works for a company in the energy industry (DSO, TSO, energy supplier, etc.).
  • Polad: A policy advisor who provides energy policy advice and could be an employee of a consulting agency or work directly as part of a team for policy makers. 
  • Markel: An official representative or policy maker who could be working for the European Commission and is responsible for drafting and negotiating new legislations or regulations.
  • Alex and Andrea: A working couple who while tackling everyday life also feel the need to provide a sustainable future for their kids. 

Following the Volere Requirements Specification Template (Robertson James and Robertson Suzanne, 2012) a set of Toolkit Use Cases (TUCs) was developed. Each TUC describes a specific situation in which the WHY Toolkit would be used by one of the personas created and described above.

  • TUC 1.1: Assessment of a policy intervention
  • TUC 1.2: Assessment of a new business model / technology
  • TUC 1.3: Run a full energy system model simulation for teaching purposes
  • TUC 2: Assessment of a counterfactual scenario
  • TUC 3: Generate more precise load forecasts
  • TUC 4: Improve the  understanding of one’s energy consumption, possibly leading  to more informed decision making and the optimization of the energy use
  • TUC 5: Optimise policy interventions to fulfil a policy objective

The definition of the requirements also follows the Volere method. Requirements are separated into functional requirements (defining what the toolkit should or should not do) and non-functional requirements (defining how the toolkit should do it). The input from the stakeholders resulted in a total number of 22 functional and 7 non-functional requirements, which are described in detail in this deliverable. Furthermore a large number of requirements were defined during the proposal phase. While those are not necessarily stakeholder requirements, they must not be neglected, as they could stand in contradiction to stakeholder requirements or be supported by them. 37 functional and 20 non-functional requirements were identified that way. A ranking of these requirements and a definition of which ones will be considered will be made later in the project and was not subject to this deliverable. 

The final work of the deliverable, aside from the Stakeholder Requirement Analysis, was the definition of the WHY Model Architecture. The architecture is described by Code-Elements, acollection of models and modules designated to perform a certain task within the WHY Model Architecture, which are linked by Interfaces. Interfaces are described by their corresponding data format and the data they will contain. Lastly the architecture contains Components, which are the key parts that make up the Code-Elements and are either Models, Data or Algorithms performing different tasks in the project. 

The WHY Model Architecture presented in this Deliverable is a preliminary version that will be developed further in the course of the projects when the different elements will be developed. This preliminary version was developed to provide first insights into the inner workings of the WHY Toolkit. Figure 1 shows a simplified version of the architecture with only the Code-Elements considered. Between each of the Code-Elements is an Interface which provides the required data in the necessary format. The Components setting up the different Code-Elements are mentioned in the list below. A detailed description can be found in the corresponding section of the Deliverable.

Causal Model:

  • Environment Data:
    • Climate Data projections
    • Exogenous Data projections
    • Legal and interventions
    • Grid Data
    • Geographic Data
  • Behavioural Models:
    • Data on energy use classes
    • Energy behaviour classifier Model
    • Investment decision Model
    • Energy needs model
    • Thermal needs model
  • Transport needs model

Non-controllable Renewable Energy:

  • Energy Generation Model

Building Scaling:

  • Investment Effects Model
  • Technology Data


  • Upscale Algorithm


  • Sustainability Assessment Model 
  • Intervention Optimizer

LPG Tr-Version:

  • Transport Data
  • Transport needs model

LPG El-Version:

  • Energy Generator Models
  • Non-Controllable Appliance Models
  • Multi Agent System Model

LPG Th-Version

  • Building Data and Model
    • Thermal Model
    • Electrical Data

House Infrastructure Simulation:

  • Stationary Energy Storage Models: Batteries
  • Movable Energy Storage Models: EV
  • Power2Gas Models
  • Transport Energy Models
  • Controllable Appliances Models
  • Energy Management System Model


  • Energy System Model