5.2.2. The Responsibility Model

The responsibility model maps the relationship between agents and their role in requirements satisfaction and restrictions. Building a responsibility model means analyzing different requirements and expectations, and assigning agents responsible for launching, performing, or receiving their results.

The responsibility model denotes relations where an agent can be the service provider or service consumer for modeling services. A provider or consumer relation was detailed only in the Petri Nets model since it does not belong to the current goal-oriented method.

Figure 15 shows the responsibility diagram for our case study and describes both the new requirements and expectations assigned to the end user and SM agents, respectively.

**Figure 15.** Agent user.

5.2.3. The Operation's Diagram

The operation's diagram describes agents' behavior for meeting requirements. For instance, the SM agent must fulfill the requirement "Receive information of energy consumed and produced" and the expectation "Inform the user about Energy consumed and produced". In further maintenance, any change in the communication with the user would lead to an investigation, reprogramming, or modification of this agent.

Figure 16 shows a definition for the object Smart Meter ("SM") and Figure 17 shows its behavior carrying out operations that affect the "Consumption report" and cause the activation of the "Register consumption" operation. It is verified that this operation has an entry called the "Measurement data received" event and the corresponding output is represented by the "Consumption report" object. The "Recorded record" event represents the end of the operation.

#### 5.2.4. The Operation's Diagram

The operation's Diagram describes agents' behavior for meeting requirements. For instance, the SM agent must fulfill the requirement "Receive information of energy consumed and produced" and the expectation "Inform the user about Energy consumed and produced", respectively. In further maintenance, any change in the communication with the user would lead to an investigation, reprogramming, or modification of this agent.

Figure 17 also shows the "SM" behavior carrying out operations that causes the activation of the "Register consumption" operation. It is verified that this operation has an entry called "Measurement data received" event, which corresponding output is represented by the "Consumption report" object. The "Recorded record" event represents the end of the operation.

Figure 16 presents the "SM" agent's requirements and expectations.

**Figure 16.** Agent SM.

#### **6. Formalizing the Requirements Model**

Finally, the requirements model, composed of the objective, object, operation, and responsibility diagrams, could be transferred to a formal representation in linear temporal logic (LTL) or Petri Nets. Since we intend to work with automated processes, we will introduce a formal representation in Petri Nets, following the standard IEC 61850.

#### **7. Analysis of the Partial Results**

The outcomes of the proposed methods appear in the design process of the case study presented.

The proposed requirements cycle starts modeling the system-as-is (if a legacy system exists) to understand and analyze the current design situation. The system-as-is is scrutinized to find flaws or improvements to be inserted in the system-to-be. This part of the method is already proposed in existing material for KAOS [35,36,40].

We should also point out that we applied the goal-oriented approach, delaying the expression of discrimination between functional and non-functional aspects, and always relying on goals to collapse or hide this need. We avoided the pressure to balance functional and non-functional requirements at the beginning of the process while dealing with the problem definition (not with solutions) and with incomplete knowledge. Non-functional requirements will be included as domain restrictions later.

The service design appeared in the process only heuristically and although very useful, it still needs to be formalized in further work. For instance, the current model admits direct formal modeling for users' classes but the coupling between the service provided and the user agents was not formalized. In other words, it is essential to highlight the importance of value co-creation modeling to support (human) user interaction with the service. A formal approach for that is being developed by the authors and will be published later.

The Petri Net in Figure 18 can be analyzed using available environments to evaluate its transition graph (as an automaton) or to perform property analysis. Either way, we can extract and verify the desired properties or detect some unexpected behavior that should be removed from the control/service system. A Petri Net is a formal schema that captures the behavioral and structural properties of a target system. It is well used in modeling automated dynamical systems. The ISO/IEC 15.909 standard provides a unified definition of the formalism used by the market and academy.

The proposed method follows a cycle of model-driven requirements development for a distributed energy service system, mapping the interaction between all agents, be it humans or machines, and its relationship with the surrounding environment. This is very helpful to ensure sustainability and human well-being as part of the design process.
