4.1.1 Description of smart grids

To use energy in an optimal way, smart grids make it possible to couple the generation, distribution, storage, and consumption of energy. Smart grids use information and communication technology (ICT), which allows for financial, informational, and electrical transactions.

Figure 4.2 shows the simplified context of a smart grid system based on the protection profile (Kreutzmann et al., 2011). We first define the terms specific to the smart grid domain taken from the protection profile:

Gateway represents the central communication unit in a smart metering system. It is responsible for collecting, processing, storing, and communicating meter data.

Meter data refers to meter readings measured by the meter regarding consumption or production of a certain commodity.

Meter represents the device that measures the consumption or production of a certain commodity and sends it to the gateway.

Authorized external entity could be a human or IT unit that communicates with the gateway from outside the gateway boundaries through a Wide Area Network (WAN). The roles defined as external entities that interact with the gateway and the meter are consumer, supplier, gateway operator, gateway administrator, etc. (For the complete list of possible external entities see the protection profile (Kreutzmann et al., 2011)).

WAN (Wide Area Network) provides the communication network that interconnects the gateway with the outside world.

LMN (Local Metrological Network) provides the communication network between the meter and the gateway.

HAN (Home Area Network) provides the communication network between the consumer and the gateway.

LAN (Local Area Network) provides the communication network that interconnects domestic equipment or metrological equipment.⁵

Consumer refers to the end user or producer of commodities (electricity, gas, water, or heat).

For the smart grid, different quality requirements have to be taken into account. Detailed information about consumers’ energy consumption can reveal privacy-sensitive data about the persons staying in a house. Hence, we are concerned with privacy issues. A smart grid involves a wide range of data that should be treated in a secure way. Additionally, introducing new data interfaces to the grid (smart meters, collectors, and other smart devices) provides new entry points for attackers. Therefore, special attention should be paid to security concerns. The number of smart devices to be managed has a deep impact on the performance of the whole system. This makes performance of smart grids an important issue.

Due to the fact that different stakeholders with diverse and partially contradicting interests are involved in the smart grid, the requirements for the whole system contain conflicts or undesired mutual influences. Therefore, the smart grid is a very good candidate to illustrate our method.

4.1.2 Functional requirements

The use cases given in the documents of the open meter project are divided into three categories: minimum, advanced, and optional. Minimum-use cases are necessary to achieve the goals of the system, whereas advanced-use cases are of high interest, but might not be absolutely required, and optional-use cases provide add-on functions. Because treating all 20 use cases would go beyond the scope of this work, we decided to consider only the use case Meter Reading for Billing. This use case is concerned with gathering, processing, and storing meter readings from smart meters for the billing process. The considered use case belongs to the category minimum.

The protection profile (Kreutzmann et al., 2011) states that “the Gateway is responsible for handling Meter Data. It receives the Meter Data from the Meter(s), processes it, stores it and submits it to external parties” (p. 18). Therefore, we define the requirements RQ1-RQ3 to receive, process, and store meter data from smart meters. The requirement RQ4 is concerned with submitting meter data to authorized external entities. The gateway shall also provide meter data for consumers for the purpose of checking the billing consistency (RQ5). Requirements with their descriptions are listed in Table 4.1.

4.1.3 Security and privacy requirements

To ensure security of meter data, the protection profile (Kreutzmann et al., 2011, pp. 18, 20) demands protection of data from unauthorized disclosure while received from a meter via the LMN (RQ7), while temporarily or persistently stored in the gateway (RQ9, RQ16), while transmitted to the corresponding external entity via the WAN (RQ11), and while transmitted locally within the LAN (RQ14). The gateway shall provide the protection of authenticity and integrity when receiving meter data from a meter via the LMN to verify that the meter data have been sent from an authentic meter and have not been altered during transmission (RQ6, RQ8). The gateway shall provide the protection of authenticity and integrity when sending processed meter data to an external entity, to enable the external entity to verify that the processed meter data have been sent from an authentic gateway and have not been changed during transmission (RQ10, RQ12, RQ13, RQ15). Privacy of the consumer data shall be protected while the data is transferred in and from the smart metering system (RQ17).

4.1.4 Performance requirements

The report “Requirements of AMI” (Remero et al., 2009a, pp. 199-201) demands that the time to retrieve meter data from the smart meter and publish it through WAN shall be less than 5 s. Due to the fact that we decompose the whole functionality from retrieving meter data to publishing it into requirements RQ1-RQ4, we also decompose this performance requirement into requirements RQ18 (complementing RQ1), RQ20 (complementing RQ2), RQ22 (complementing RQ3), and RQ24 (complementing RQ4). The requirements RQ18, RQ20, RQ22, and RQ24 shall be fulfilled in a way that in total they do not need more than 5 s.

Further, the report “Requirements of AMI” states that for the benefit of the consumer, actual meter readings are to be provided to the end consumer device through HAN. It demands that the time to retrieve meter data from the smart meter and publish it through HAN shall be less than 10 s. Similar to the previous requirement, we decompose this requirement into requirements RQ19 (complementing RQ1), RQ21 (complementing RQ2), RQ23 (complementing RQ3), and RQ25 (complementing RQ5). These requirements together shall be fulfilled in less than 10 s.

Figure 4.3 shows five quality requirements RQ10, RQ11, RQ12, RQ17, and RQ24 that complement the functional requirement RQ4.

4.2.1 The i* framework

In the i* framework (Yu, 1996, 1997), goal graphs serve to visualize the goals of an actor. Hence, the first element of a goal graph is the actor visualized by the actor boundaries (see Figure 4.5: light gray rectangles with rounded corners). Actor boundaries indicate intentional boundaries of a particular actor. All of the elements within a boundary for an actor are explicitly desired by that actor. For our use case, the consumer, the billing manager, and the grid operator Tesla Inc. are actors. A goal of an actor represents an intentional desire of this actor. The i* framework distinguishes between hard goals, soft goals, and tasks. A hard goal defines a desire for which the satisfaction criteria are clear, but the way of satisfying it is unspecified. Hard goals are visualized as ellipses (see Figure 4.5). An example is the hard goal of Tesla Inc.: “Get Money.” It is satisfied whenever Tesla Inc. receives its money from the consumer but is not specific about the process to get the money. A soft goal is even more underspecified, because for a soft goal no clear satisfaction criteria are known. Soft goals are denoted as clouds (see Figure 4.5). An example is the high-level goal “Performance,” because at this level one cannot give a process for achieving performance nor can one give an overall criterion when a consumer perceives a system as performant. In contrast, a task defines both the criteria for fulfilling the goal and the process to do so. Tasks are denoted as hexagons (see Figure 4.5).

Goals are connected by links. The first kind of link is the contribution link. Contribution links are visualized using arrows with filled arrowheads (see Figure 4.5). A contribution link between a child goal (tail of the arrow) and a parent goal (arrow head) means that the child goal influences the satisfaction of the parent goal. The annotation of the arrow specifies the kind of contribution. A break denotes that the child denies the parent. A make denotes that if the child is satisfied the parent is satisfied, too. An or means that at least one of the children has to be satisfied for the satisfaction of the parent. For an and contribution all children have to be satisfied. Hurts specifies a negative influence, which does not necessarily break the parent goal. Helps is used whenever the child goal has a positive influence but is not necessarily needed to fulfill the parent goal. The second kind of link is the decomposition link. It is used to decompose a goal to more fine-grained parts. A decomposition link is denoted as arrow with a T-head (see Figure 4.5).

4.2.2 Problem-oriented requirements engineering

Problem frames (Jackson, 2001) are a means to describe and classify software development problems. A problem frame represents a class of software problems. A problem frame is described by a frame diagram, which basically consists of domains, interfaces between them, and a requirement.

Domains describe entities in the environment. Michael Jackson distinguishes the domain types biddable domains that are usually people, causal domains that comply with some physical laws, and lexical domains that are data representations. Interfaces connect domains, and they contain shared phenomena. Shared phenomena may be events, operation calls, messages, and the like. They are observable by at least two domains, but controlled by only one domain, as indicated by the name of that domain and “!”. In Figure 4.3 the notation MD!{data} (between MeterData and SubmitMD) means that the phenomenon data is controlled by the domain MeterData and observed by the machine SubmitMD.

When we state a requirement, we want to change something in the world with the software to be developed. Therefore, each requirement constrains at least one domain. Such a constrained domain is the core of any problem description, because it has to be controlled according to the requirements. A requirement may refer to several other domains. The task is to construct a machine (i.e., software) that improves the behavior of the environment (in which it is integrated) in accordance with the requirements.

Requirements analysis with problem frames proceeds as follows: First the environment in which the machine will operate is represented by a context diagram. A context diagram consists of machines, domains, and interfaces. Then, the problem is decomposed into sub-problems, which are represented by problem diagrams. A problem diagram consists of one submachine of the machine given in the context diagram, the relevant domains, the interfaces between these domains, and a requirement.

We represent problem frames using UML class diagrams, extended by a new UML profile (UML4PF) as proposed by Hatebur and Heisel (2010c). Using specialized stereotypes, the UML profile allows us to express the different diagrams occurring in the problem frame approach using UML diagrams. Figure 4.3 illustrates one subproblem expressed as a problem diagram in UML notation in the context of our smart grid example. It describes that smart meter gateway submits meter data to an authorized external entity. The submachine SubmitMD is one part of the smart meter gateway. It sends the MeterData through the causal domain WAN to the biddable domain AuthorizedExternalEntity. The requirement RQ4 constrains the domain WAN. This is expressed by a dependency with the stereotype  constrains . It refers to the domains MeterData and AuthorizedExternalEntity as expressed by dependencies with the stereotype  refersTo .

Requirements analysis based on the classical problem frames does not support analyzing quality requirements. So, we extended it by explicitly taking into account quality requirements, which complement functional requirements (Alebrahim et al., 2011a). Figure 4.3 shows five quality requirements RQ10, RQ11, RQ12, RQ17, and RQ24 that complement the functional requirement RQ4. This is expressed by dependencies from the quality requirements to the functional requirement with the stereotype  complements . We use a UML profile for dependability (Hatebur and Heisel, 2010c) to annotate problem diagrams with security requirements. For example, we apply the stereotypes  integrity ,  confidentiality , and  authenticity  to represent integrity, confidentiality, and authenticity requirements as it is illustrated in Figure 4.3. To annotate privacy requirements, we use the privacy profile (Beckers et al., 2012b) that enables us to use the stereotype  privacyRequirement . To provide support for annotating problem descriptions with performance requirements, we use the UML profile MARTE (Modeling and Analysis of Real-time and Embedded Systems) (UML Revision Task Force, 2011). We annotate each performance requirement with the stereotype  gaStep  to express a response time requirement. Note that for each type of quality requirement, a new UML profile should be created if not existing. This needs to be done only once.

As a basis for our QuaRO method, we use the problem frames approach, because it allows us to obtain detailed information from the structure of problem diagrams. Such information is crucial for our proposed approach, because it enables us to perform interaction analysis and optimization, whereas other requirements engineering approaches such as scenario-based approaches and use cases do not contain detailed information for such analyses.

4.2.3 Valuation of requirements

For valuating and comparing alternatives among each other, several methods are known, such as direct scoring (Pomerol and Barba-Romero, 2000), Even Swaps (Mustajoki and Hämäläinen, 2007), win-win negotiating, the analytical hierarchy process (AHP) (Saaty, 2005; Saaty and Ozdemir, 2003) or the ANP (Saaty, 2008a, 2005). They all support decision making (process of selecting a solution among a set of alternatives) by either eliminating alternatives successively or ranking them. For the QuaRO method, we decided to use the ANP (reasons for the decision are discussed in Section 4.6), which will be explained in the following.

The ANP is a generalization of the more widely known AHP (Saaty, 2008a, 2005). Both rely on goals, criteria, and alternatives. These elements are grouped by clusters, which can be ordered in hierarchies (AHP, ANP) or networks (ANP) (see Figure 4.4). A goal in this context is the desired outcome of a decision process, otherwise known as the “best system” or the “optimal marketing strategy.” A criterion is one important property, which has an influence on the decision regarding the goal. An alternative is one possible solution (part) to fulfill the goal and is compared to other alternatives with respect to the criteria. Hierarchy means that there is a strict order of influence between elements of different hierarchy levels. So, sub-criteria are compared with respect to criteria but not the other way around. The top level of the hierarchy is formed by the elements not influenced by any other element. The bottom level forms the elements that do not influence other elements. In contrast to AHP, which only allows influential relations between elements of adjacent hierarchy levels and only from the higher level to the lower one (see Figure 4.4, left-hand side), ANP allows one to consider influential relations between elements within one level and bidirectional relations between all hierarchy levels forming a network (see Figure 4.4, right-hand side). Note that ANP allows a mixture of hierarchy and (sub-) networks (see Figure 4.9 in Section 4.6). Hence, ANP allows one to model more complex decision makings more accurately than AHP. The downside of ANP compared to AHP is the increasing number of comparisons to be made and the complex calculations to be executed (Saaty, 2005). On the one hand, ANP takes more time and the final decision is more difficult to understand, but on the other hand, ANP allows a much deeper problem understanding and modeling and avoids errors due to oversimplification, which often occur when using AHP (Saaty, 2005; Saaty and Ozdemir, 2003). The steps of ANP are as follows (Saaty, 2008a,b, 2005; Saaty and Ozdemir, 2003):

1. Describe the decision problem. The first step of ANP is to understand the decision problem in terms of stakeholders, their objectives, the criteria and sub-criteria, alternatives, and the influential relations among all those elements. ANP gives no guidance for this step, but it is crucial for the success of the whole process.

2. Set up control criteria. In addition to the criteria and sub-criteria relevant for the decision, Saaty recommends using control criteria for many decisions. He suggests benefits, opportunities, costs, and risks (BOCR) as control criteria (Saaty, 2008b). Using control criteria allows one to model different dimensions of a decision problem and to combine negative and positive dimensions. Using control criteria is optional.

3. Set up clusters. To structure the (sub-)criteria and alternatives and to make the network and the later comparisons better manageable, the (sub-)criteria and alternatives can be merged into clusters, regarding, for example, their relation to a parent criterion. It is also allowed to have elements that represent sub-networks to the network the element resides in within a cluster. In this way very complex networks can be handled in a “divide-and-conquer” style.

4. Relate elements of the network. The (sub-)criteria and alternatives have to be related according to their influence on each other. At this point the relation is undirected. Only the elements of one cluster are allowed to be directly related (inner dependence influence). Clusters are related whenever at least one element of the first cluster is related to at least one element of the second cluster (outer dependence influence).

5. Determine the influence direction. For each relation it has to be decided whether it is an unidirectional or bidirectional relation. One has also to decide whether a direction means “influences target element” or “is influenced by target element.” The first option is recommended.

6. Set up supermatrix. For each control criterion a supermatrix has to be constructed. Each element has to have a row and column representing it. Rows and columns are grouped according to the clusters. The cells of the supermatrix are marked whenever the element of the column influences the element of the row or the cluster the column element belongs to influences the cluster of the row element.

7. Compare elements. In this step, the pairwise comparison of elements, according to the inner and outer dependences of the cluster they belong to, has to be carried out. This results in an unweighted supermatrix.

8. Compare clusters. To weight the different clusters, all clusters are compared pairwise with respect to a (control/sub-)criterion or goal. The resulting weights are then used to weight the cells of the columns whose elements belong to the cluster. In this way, one obtains the weighted supermatrix.

9. Compute limited supermatrix. The limited supermatrix is computed by raising the weighted supermatrix to a certain power k. The constant k can be freely chosen. For a low k the limited supermatrix might not be stable in the sense that for some elements, given by their row, the actual value does not converge to the final value. Hence, the priority of the element is not stable and cannot be determined. For a high k small priorities might drop to zero.

10. Synthesize results to the control level. Set up a formula and weights for relating the control criteria. The result is the weighted prioritization of alternatives regarding the control criteria.

4.2.4 Optimization

The process of optimizing systematically and simultaneously a collection of objective functions is called multi-objective optimization (MOO) or vector optimization (Marler and Arora, 2004). MOO is used whenever certain solutions or parts of solutions exist, the values of the solutions with respect to objectives are known, there are some constraints for selecting solutions, but the complexity of the optimization problem hinders a human to figure out the optimum or an automated selection is desired. The optimization problem can be complex due to the sheer number of solutions, the number of constraints, and/or the number of relations between solution parts. The following definitions are used in the rest of the chapter:

The general MOO problem is posed as follows (Note that ≥ constraints can be easily transformed to ≤ constraints. The same is true for maximization objectives.):

$\mathrm{Minimize}\mathbf{F}\left(\mathbf{x}\right)={\left[F_1\left(\mathbf{x}\right),F_2\left(\mathbf{x}\right),\dots ,F_m\left(\mathbf{x}\right)\right]}^{\mathrm{T}}$

$\mathrm{subject}\mathrm{to}{g}_j\le 0,j=1,2,\dots ,n$

$\mathrm{subject}\mathrm{to}{h}_k=0,k=1,2,\dots ,o$

where m is the number of objective functions, n is the number of inequality constraints, and o is the number of equality constraints. x ∈ E^q is a vector of design variables (also called decision variables), where q is the number of independent variables x_i with type E, which can be freely chosen. F(x) ∈ E^k is a vector of objective functions F_i(x) : E^q → E¹. F_i(x) are also called objectives, criteria, payoff functions, cost functions, or value functions. The feasible design space X (often called the feasible decision space or constraint set) is defined as the set {x|g_j(x) ≤ 0, j = 1, 2, …, n ∧ h_i (x) = 0, i = 1, 2, …, o}. x_i* is the point that minimizes the objective function F_i(x). An ${F_i}^{\mathrm{o}}$ utopia point is the value attainable at best for F_i(x) respecting the constraints. The total optimum is the value attainable at best for F_i(x) not respecting the constraints.

Definition Pareto Optimal: A point, x^* ∈ X, is Pareto optimal if there does not exist another point, x ∈ X, such that F(x) ≤ F(x*), and F_i(x) < F_i(x*) for at least one function from F.

4.3.1 Understanding the purpose of the system

The phase Understanding the Purpose aims at understanding the purpose of the system-to-be, its direct and indirect environment, the relevant stakeholders, and other already established systems, assets, and other entities that are directly or indirectly related to the system-to-be. In the first step Context Elicitation, we consider all relevant entities of the environment. The second step Goal Elicitation captures the goals to be considered for optimization. Hence, we have to analyze the goals of each stakeholder in relation to the system-to-be. Detecting requirements interactions early at the goal level will eliminate some interactions among requirements related to those goals, which we would face later at the requirements level. Detecting and eliminating conflicts on the goal level is the purpose of the third step Goal Interaction.

For the elicitation of the context, we introduced so-called context elicitation patterns in earlier work of ours (Beckers et al., 2013b, 2012a, 2011). Such patterns exhibit typical elements occurring in the environments such as cloud computing systems or service-oriented architectures. For a structured elicitation of information about the context of a smart grid software, we adapted the existing patterns for smart grids, conducting an in-depth analysis of several documents as described in Section 4.1. The resulting pattern is not shown for reasons of space. Using the pattern, we identified three major stakeholders. The consumer, the grid provider, and the billing manager, as authorized external entity, were described in detail in terms of a general description, their motivation and top-level goals, such privacy, performance, economy, and so forth.

For refining the top-level goals, we used the i* notation (Mylopoulos et al., 2001; Yu, 1996, 1997). We refined the top-level goals for each stakeholder independently, obtaining three actor boundaries containing the goal graphs. In the end we got 67 softgoals, like “Responsive User Interface” or “Maximize Number of Sold Products,” 9 hard goals, like “Pay Bill in time,” and 47 tasks, like “Analyze Consumption” or “Send Bill.” In step goal interaction, we discovered 37 positive goal interactions, such as “Collect Grid Information” helps “Offer Attractive Products and Services,” and 4 cases where a goal hurts another goal, like “Collect Maximum of Information”(grid provider) and “Authorized Parties get Needed Data” (consumer). For reasons of space and readability the full goal graphs cannot be shown. A small part, which is sufficient for the rest of this chapter, is shown in Figure 4.5.

The goal graphs serve two purposes. First, to refine the top-level goals to the leaves. For example, refine “Privacy” to “Private Data not Disclosed” to “Authorized Parties get Needed Data.” For the further procedure the leaves (goals without sub-goals) are of specific interest. For Tesla Inc. these are “Establish & Maintain Reputation,” “Collect Maximum of Information,” “Collect Customer Information,” “Reasonable Reaction Times,” and “Fast Delivery.” “Household not Manipulated,” “Responsive User Interface,” “Authorized Parties get Needed Data,” “Bill not Manipulated,” “Consumption Data not Manipulated,” “Analyze Consumption,” “Communicate Confidential,” and “Verify Consumption Data” are the leaves for the consumer. The leaves will serve as criteria for the valuation.

The second purpose is the use of the graphs for the optimization. The graphs already contain alternatives for fulfilling the goals. Every or contribution like “Minimize Consumption” and “Optimize Consumption” for the soft goal “Minimize Bill” is an option for optimization. Additionally, whenever a goal cannot be fulfilled, all of its sub-goals do not have to be fulfilled. Hence, all requirements related to these sub-goals can be ignored. As result, the goal graphs serve for constraining the optimization and adding alternatives.

4.3.2 Understanding the problem

The phase Understanding the Problem aims at understanding the system-to-be and the problem it shall solve, and therefore understanding the environment it should influence according to the requirements. In the first step Problem Context Elicitation, we obtain a problem description by eliciting all domains related to the problem to be solved, their relations to each other, and the software to be constructed. The step Functional Requirements Elicitation is concerned with decomposing the overall problem into sub-problems that describe a certain functionality, as expressed by a set of related requirements. The functionality of the software is the core, and all quality requirements are related in some way to this core. Eliciting quality requirements and relating them to the system-to-be is achieved in the step Quality Requirements Elicitation. Once eliciting the functional and quality requirements is accomplished, one has to ensure that the system-to-be complies to regulations such as laws. To this end, we derive requirements from laws, standards, and policies in the step Compliance Requirements Elicitation.

To elicit the problem context, we set up a context diagram consisting of the machine Gateway, the domains LMN, HAN, WAN, MeterData, AuthorizedExternalEntities, Consumer, etc. and interfaces between these domains. To provide billing information to external parties and also to the consumer, the gateway receives the meter data from the meter(s) (RQ1), processes it (RQ2), and stores it (RQ3). The gateway submits the stored data to external parties (RQ4). The stored data can also be provided to the consumer to allow the consumer to verify an invoice (RQ5). We set up problem diagrams to model the functional requirements RQ1-RQ5. Figure 4.3 shows the problem diagram for the functional requirement RQ4. Besides the functionalities that the gateway has to provide, it is also responsible for the protection of authenticity, integrity, and confidentiality of data temporarily or persistently stored in the gateway, transferred locally within the LAN and transferred in the WAN (between gateway and authorized external entities). In addition, as stated by the protection profile (Kreutzmann et al., 2011), the privacy of the consumer shall be protected. Furthermore, it is demanded that functional requirements shall be achieved within a certain response time.

Hence, we annotate all problem diagrams with quality requirements as proposed in earlier work of ours (Alebrahim et al., 2011a). For example, we annotate the problem diagram for submitting meter readings (Figure 4.3) with security requirements RQ10 (integrity), RQ11 (confidentiality), RQ12 (authenticity), which complement the functional requirement RQ4. The privacy requirement RQ17 and the performance requirement RQ24 also complement the functional requirement RQ4.

4.4.1 Initialization phase: Initial setup

In this phase, we make use of the structure of the problem diagrams and contained information regarding quality requirements (domain knowledge, see input in Figure 4.6) to set up the initial QRQ tables. These tables are used for the identification of interactions among quality requirements in later phases. Furthermore, we set up life cycle expressions that represent the order in which the requirements must be achieved.

4.4.2 Phase 1: Treating case 1

In this phase, we compare the rows in each table to identify potential conflicts among quality requirements concerning the first case of Table 4.3. The aim is to detect conflicts among the same type of quality requirements that are related to the same functional requirement. To deal with this case of requirements conflicts, we consider each table separately.

Step 1.1:Eliminating irrelevant tables. To eliminate irrelevant tables, we make use of the initial interaction table (Table 4.2) we set up before. According to this table, interactions among quality requirements of the same type can only happen when considering two performance requirements. Therefore, we mark Tables 4.5 (left), 5 (right), and 6 as irrelevant for requirements interactions and continue only with Table 4.4 for the treatment of first case.

Step 1.2: Eliminating irrelevant rows. In each table under consideration, we perform a pairwise comparison between quality requirements related to the same functional requirement. We check, if such quality requirements constrain the same domains (contain crosses in the same columns). We consider the rows related to such quality requirements as relevant and remove the irrelevant rows from Table 4.4. Doing so, we obtain Table 4.7. We also removed the columns WAN and HAN, because they did not contain any entry after removing irrelevant rows.

Step 1.3: Detecting interaction candidates. Considering the new performance table from the previous step, we look at each two rows sharing the same functional requirement. We determine that the requirements RQ18 and RQ19 share the same domains LMN, SmartMeter, and CPU. Further, the requirements RQ20 and RQ21 share the same domain CPU. The same is the case for the requirements RQ22 and RQ23. We identify these requirements as candidates for requirement interactions. Table 4.8 summarizes all detected interaction candidates.

4.4.3 Phase 2: Treating case 2

This phase is concerned with the second case of Table 4.3, dealing with possible conflicts among different types of quality requirements related to the same functional requirement. Hence, we compare quality requirements related to the same functional requirement in each two tables to identify potential conflicts.

Step 2.1: Eliminating irrelevant tables. To eliminate irrelevant tables, we make use of the initial interaction table (Table 4.2) to determine which two tables should be compared with each other. For our example, we can reduce the number of table comparisons to four: 4.5 (left) and 4.4, 4.6 and 4.5 (right), 4.6 and 4.4, 4.5 (right) and 4.4.

Note that in each phase, we have to consider the initial QRQ tables such as Table 4.4 and not the new reduced tables such as 4.7. The reason is that in each phase, we eliminate different rows from the initial QRQ tables according to Table 4.3.

Step 2.2: Detecting interaction candidates. To identify interactions among quality requirements related to the same functional requirement, we have to look in different tables at the rows with the same related functional requirement and check, if same the domains (columns) contain crosses. Such requirements are candidates for interactions.

This is mostly the case for performance and security requirements. The reason is that solutions for achieving security requirements are time-consuming and this is at the expense of performance. As an example, we describe how we compare the Tables 4.5 (left) and 4.4. We consider the rows related to the same functional requirement. The rows related to the functional requirement RQ1 contain entries in the columns LMN and CPU. This implies that we might have a conflict between the integrity requirement RQ6 and the performance requirements RQ18 and RQ19. Comparing each further two rows results in the following potential conflicts: RQ10 with RQ24, and RQ13 with RQ25. Table 4.8 summarizes all detected interaction candidates.

4.4.4 Phase 3: Treating case 3

In this phase, we deal with case three of Table 4.3. In other words, we consider different functional requirements complemented with the same type of quality requirement. Table 4.2 enables us to eliminate irrelevant tables. Additionally, we make use of the information contained in the life cycle expression regarding the concurrent achievement of requirements.

Step 3.1: Eliminating irrelevant tables. According to Table 4.3, we have to consider each table separately. According to Table 4.2, no interactions will occur among different integrity, confidentiality, and authenticity requirements. Hence, we mark Tables 4.5 (left), 4.5 (right), and 4.6 as irrelevant. The only type of quality requirements to be considered are performance requirements as given in Table 4.4.

Step 3.2: Eliminating irrelevant rows. In each table under consideration, we perform a pairwise comparison between the rows. According to Table 4.3, interactions can only arise when quality requirements must be satisfied in parallel. We make use of the life cycle expression to identify requirements that must be achieved in parallel. According to the life cycle, we cannot eliminate any row in Table 4.4, because although the requirements RQ1, RQ2, and RQ3 can be satisfied sequentially, they must be achieved in parallel with the requirements RQ4 and RQ5.

Step 3.3: Detecting interaction candidates. In this step, we check if the requirements with parallel satisfaction contain entries in the same column. We see in Table 4.4 that all requirements concern the same domain CPU. Therefore, we identify a number of interaction candidates as given in Table 4.8.

4.4.5 Phase 4: Treating case 4

This phase is concerned with case four of Table 4.3, which deals with different functional requirements complemented with different types of quality requirements. Table 4.2 enables us to eliminate irrelevant tables. Additionally, we take the life cycle expression into account to reduce the number of comparisons within each table.

Step 4.1:Eliminating irrelevant tables. According to Table 4.2, we can reduce the number of table comparisons to three: 4.5 (left) and 4.4, 4.6 and 4.4, 4.5 (right) and 4.4.

Step 4.2: Eliminating irrelevant rows. According to the life cycle, although the requirements RQ1, RQ2, and RQ3 must be achieved sequentially, they must be achieved in parallel to requirements RQ4 and RQ5. Therefore, we cannot remove any row from the tables under consideration.

Step 4.3: Detecting interaction candidates. According to Table 4.2 and the results obtained from the previous steps, we only have to compare the rows in the following three tables: 4.5 (left) and 4.4, 4.6 and 4.4, 4.5 (right) and 4.4. We get a large number of interaction candidates between the integrity and performance requirements, confidentiality and performance requirements, as well as authenticity and performance requirements. Table 4.8 presents the overall result of applying the method.

Discussion of the results. At this point, we have to check if we can reduce the number of interaction candidates. Looking at the result, we see that most interactions might be among performance and security requirements and among different performance requirements. Additionally, we identified three pairs of interaction candidates among authenticity and confidentiality requirements (Table 4.8, phase 2). We figure out that the interaction depends on the order of applying confidentiality and authenticity solution mechanisms. If we sign the data first and then encrypt it, we can achieve both confidentiality and authenticity. The other way around, if we encrypted the data first and then signed it, the confidentiality and authenticity requirements would interact with each other. Under this condition, we can exclude interactions among requirement pairs RQ7 and RQ8, RQ11 and RQ12, RQ14 and RQ15 (crossed out in Table 4.8). Of course, we have to document this condition for the design and implementation phases. All other candidates have to be taken into account in the subsequent phases of the QuaRO method.

4.5.1 Relaxation template for security

For security it is the type of attacker that influences the restrictiveness of a security requirement. How much resources and effort to spend on a requirement, how much influence security has on the behavior of the overall system-to-be, and which solution has to be chosen to fulfill the requirement later on all depend on the abilities of the attacker. While it is almost impossible to secure a system against an almighty attacker, defending against a layman (see International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), 2009) can be easily achieved without big impact on the rest of the system.

To describe the attacker, we use the properties as described by the Common Methodology for Information Technology Security Evaluation (CEM) (International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), 2009) for vulnerability assessment of the TOE (target of evaluation i.e., system-to-be). How to integrate this attacker description into problem frames is described in earlier work of ours (Hatebur and Heisel, 2009b, 2010a). The properties to be considered (according to CEM) are (International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), 2009):

Elapsed time “Elapsed time is the total amount of time taken by an attacker to identify a particular potential vulnerability …, to develop an attack method and … to mount the attack …” We distinguish between the preparation time and the attack time.

Specialist expertise “Specialist expertise refers to the level of generic knowledge of the underlying principles, product type or attack methods ….”

Knowledge of the TOE “Knowledge of the TOE refers to specific expertise in relation to the TOE.”

Window of opportunity “Identification or exploitation of a vulnerability may require considerable amounts of access to a TOE that may increase the likelihood of detection. … Access may also need to be continuous, or over a number of sessions.”

IT hardware/software or other equipment “… the equipment required to identify or exploit a vulnerability.”

The resulting relaxation template is shown in Table 4.9.

4.5.2 Relaxation template for performance

As described in Section 4.4.1, in the initialization phase, analyzing the context of performance requires a focus on two issues, namely the workload behavior, described by an arrival pattern, and the number of requests and the resources, described by utilization and capacity. For modeling this information we use the MARTE profile (UML Revision Task Force, 2011), which is integrated into UML4PF in our previous work (Alebrahim et al., 2011b).

GaWorkloadEvent represents the kind of arrival pattern. A ClosedPattern is one kind of arrival pattern. It contains the attribute population that represents a fixed number of active users (UML Revision Task Force, 2011, pp. 308, 503).

DeviceResource represents an external device. It contains the attribute resMult that represents the maximum number of available instances of a particular resource (UML Revision Task Force, 2011, p. 613). The attribute speedFactor gives the relative speed of the unit as compared to the reference one (UML Revision Task Force, 2011, p. 506).

HwMemory contains the attributes memorySize that specifies the storage capacity and timing that specifies timings of the HwMemory (UML Revision Task Force, 2011, p. 597).

HwMedia is a communication resource that represents a means to transport information from one location to another. It contains the attributes bandWidth specifying the transfer bandwidth and packetTime specifying the time to transmit an element (UML Revision Task Force, 2011, p. 598).

HwProcessor is a generic computing resource symbolizing a processor. It contains the attributes nbCores, which specifies the number of cores within the HwProcessor and frequency (not contained in the specification, but in the implementation) (UML Revision Task Force, 2011, p. 670).

GaStep is part of a scenario and contains the attribute msgSize, which specifies the size of a message to be transmitted by the Step (UML Revision Task Force, 2011, p. 306).

The used types NFP _ … are complex data types defined in the MARTE profile (UML Revision Task Force, 2011). The resulting relaxation template for performance is shown in Table 4.10.

In the following, we describe our method to generate alternatives for interacting requirements to be used in further steps of QuaRO method (see Figure 4.7).

1. Select pair of interacting requirements. Table 4.8 is the input for the generation of alternatives. We have to analyze each pair for possible alternative requirements, which resolve or relax the interaction.

2. Select first/second requirement. For the selected pair, we have to check each of the two requirements for possibilities to resolve the interaction. Hence, we have to execute the next steps for both requirements.

3. Check decomposition potential of requirements. In the case of a complex requirement, it might help to separate the source of interaction from the rest of the requirement. The separated requirements can be treated differently. It might happen that an interaction would lead to a rejection of the whole complex requirement. In contrast, for the decomposed set of requirements, some parts of the original requirement might remain in the solution.

4. Execute and model decomposition. If a decomposition is possible, it has to be executed, and the result has to be modeled.

5. Select remaining interacting sub-requirements. In case of a decomposition, only the sub-requirement, which is the source of the interaction, has to be analyzed further.

6. Identify relaxation property candidates. Based on the type of requirement, there are different properties, which are candidates to be relaxed. These candidates are fixed for each kind of requirement. Hence, we can use predefined templates to identify these properties. For each property the actual value regarding the interacting requirement has to be stated. Next, it has to be decided if this value for the property is a hard constraint, which cannot be changed, or a soft constraint, which might be relaxed. In the second case, we identified a relaxation candidate.

7. Rank relaxation property candidates. When talking about reasonable relaxations, it is also important to know which properties are more important to the overall requirement than others.

8. Identify upper/lower relaxation bounds. For each property, the upper/lower bound, which is still acceptable, has to be identified. The upper/lower bounds of all properties form the worst-case scenario, which is still acceptable for a requirement.

9. Generate and model alternatives. The first alternative is the requirement realizing the worst-case scenario. Between the original requirement and this lower bound requirement, several other requirements can be generated by varying the relaxation candidates. For each generated requirement, it has to be checked, regardless of whether it eliminates the interaction. If it does not, further relaxation is needed. The generated alternatives have to be modeled.