Aspect-Oriented Requirements Engineering with Problem Frames

Stephan Faßbender, Maritta Heisel and Rene Meispaluno - The Ruhr Institute for Software Technology University of Duisburg-Essen, Germany

{firstname.lastname}@uni-due.de

Keywords: Early Aspect, Problem Frames, Requirements Engineering

Abstract: Nowadays, the requirements of various stakeholders for a system do not only increase the complexity of thesystem-to-be, but also contain different cross-cutting concerns. In such a situation, requirements engineersare really challenged to master the complexity and to deliver a coherent and complete description of thesystem-to-be. Hence, they are in need for methods which reduce the complexity, handle functional and qualityrequirements, check completeness and reveal interactions, and are tool supported to lower the effort. Onepossible option to handle the complexity of a system-to-be is the separation of concerns. Both, aspect-orientedrequirements engineering and the problem frames approach implement this principle. Therefore, we pro-pose a combination of both, the AORE4PF (Aspect-Oriented Requirements Engineering for Problem Frames)method. AORE4PF provides guidance for classifying requirements, separating the different concerns, mod-eling requirements for documentation and application of completeness and interaction analyses, and weavingthe reusable parts to a complete and coherent system. AORE4PF provides tool support for most activities. Weexemplify our method using a smart grid case obtained from the NESSoS project. For validation, the resultsof a small experiment in the field of crisis management systems are presented.

1 Introduction

Keeping an eye on good and sufficient require-ments engineering is a long-known success fac-tor for software projects and the resulting softwareproducts (Hofmann and Lehner, 2001). Nonethe-less, larger software incidents are regularly reported,which originate in careless dealing with, for exam-ple, security requirements. Beside reputation damage,loss of market value and share, and costs for legalinfringement (Cavusoglu et al., 2004; Khansa et al.,2012), fixing defects that caused the incident is costly.Fixing a defect when it is already fielded is reported tobe up to eighty times more expensive than fixing thecorresponding requirements defects early on (Boehmand Papaccio, 1988; Willis, 1998). Therefore, it iscrucial for requirements engineers to identify, ana-lyze, and describe all requirements and related qualityconcerns. But eliciting good requirements is not aneasy task (Firesmith, 2003), even more when consid-ering complex systems.

Nowadays, for almost every software system, var-ious stakeholders with diverse interests exist. Theseinterests give rise to different sets of requirements.These diverse requirements not only increase thecomplexity of the system-to-be, but also contain dif-

ferent cross-cutting concerns, such as qualities, whichare desired by the stakeholders. In such a situation,the requirements engineer is really challenged to mas-ter the complexity and to deliver a coherent and com-plete description of the system-to-be.

One possible option to handle the complexity ofa system-to-be is the concept of separation of con-cerns (Parnas, 1972). In its most general form, theseparation of concerns principle refers to the abilityto focus on, and analyze or change only those partsof a system which are relevant for one specific prob-lem. The main benefits of this principle are a re-duced complexity, improved comprehensibility, andimproved reusability (Parnas, 1972).

Both, aspect-oriented requirements engineeringand the problem frame approach implement this prin-ciple, but for different reasons. The approach ofAORE (aspect-oriented requirements engineering),which originates from aspect-oriented programming,is to separate each cross-cutting requirement into anaspect. Instead of integrating and solving the cross-cutting requirement for all requirements it cross-cuts,the aspect is solved in isolation. Hence, aspect-orientation leads to a clear separation of concerns. Tocombine an aspect with a requirement, an aspect de-fines a pointcut (set of join points), which describes

how the aspect and a requirement can be combined.The problem frames approach (Jackson, 2001) gen-erally also follows the separation of concerns princi-ple. It decomposes the overall problem of buildingthe system-to-be into small sub-problems that fit toa problem frame. Each sub-problem is solved by amachine, which has to be specified using the givendomain knowledge. All machines have to be com-posed to form the overall machine. We will show thataspect-orientation gives guidance for the process ofdecomposing the overall problem and especially forthe composition of the machines. As both ways ofseparating concerns seem to be complementary, it ispromising to combine both. Hence, we propose theAORE4PF (Aspect-Oriented Requirements Engineer-ing for Problem Frames) method that provides guid-ance for classifying requirements, separating the dif-ferent concerns, modeling requirements for documen-tation and application of completeness and interactionanalyses, and weaving the reusable parts to a com-plete and coherent system. Furthermore, AORE4PFprovides tool support for most activities.

The rest of the paper is structured as follows. Sec-tion 2 introduces a smart grid scenario, which is usedas a case study. In Section 3, we briefly introducethe problem frames approach and UML4PF as back-ground of this paper. Our method for the integrationof AORE into the problem frames approach is pre-sented in Section 4. A small experiment for validationis presented in Section 5. Work related to this paper isdiscussed in Section 6. Finally, Section 7 concludesthe paper and presents possible future work.

2 Case Study

To illustrate the application of the AORE4PFmethod, we use the real-life case study of smart grids.As sources for real functional requirements, we con-sider diverse documents such as “Application CaseStudy: Smart Grid” provided by the industrial part-ners of the EU project NESSoS1, the “Protection Pro-file for the Gateway of a Smart Metering System”(Kreutzmann et al., 2011) provided by the GermanFederal Office for Information Security2, and “Re-quirements of AMI (Advanced Multi-metering Infras-tructure”) (OPEN meter project, 2009) provided bythe EU project OPEN meter3.

We define the terms specific to the smart grid do-main and our use case in the following. The smart

1http://www.nessos-project.eu/2www.bsi.bund.de3http://www.openmeter.com/

meter gateway represents the central communicationunit in a smart metering system. It is responsible forcollecting, processing, storing, and communicatingmeter data. The meter data refers to readings mea-sured by smart meters regarding consumption or pro-duction of a certain commodity. A smart meter rep-resents the device that measures the consumption orproduction of a certain commodity and sends it to thegateway. An authorized external entity can be a hu-man or an IT unit that communicates with the gatewayfrom outside the gateway boundaries through a widearea network (WAN). The WAN provides the commu-nication network that interconnects the gateway withthe outside world. The LMN (local metrological net-work) provides the communication network betweenthe meter and the gateway. The HAN (home area net-work) provides the communication network betweenthe consumer and the gateway. The term consumerrefers to end users of commodities (e.g., electricity).

For the rest of the paper, we have chosen a smallselection of requirements to exemplify our method.These requirements are part of the 13 minimumuse cases defined for a smart meter gateway givenin the documents of NESSoS and the open meterproject. The considered use cases are concerned withgathering, processing, and storing meter readingsfrom smart meters for the billing process. Therequirements are described as follows:

(R1) Receive meter data The smart meter gatewayshall receive meter data from smart meters.

(R17) New firmware The gateway should accept anew firmware from authorized external entities. Thegate shall log the event of successful verification of anew version of the firmware.

(R18) Activate new firmware On a predetermineddate the gateway executes the firmware update. Thegateway shall log the event of deploying a newversion of the firmware.

(R28) Prevent eavesdropping The Gateway shouldprovide functionality to prevent eavesdropping. Thegateway must be capable of encrypting communi-cations and data by the safest and best encryptionmechanisms possible.

(R29) Privacy and legislation Many countries pro-tect customers’ and people’s rights by laws, to ensurethat personal and confidential information will notbe disclosed easily within communicating systems.Grid systems shall not be a way to reveal information.

3 UML-Based Problem Frames

Problem frames are a means to describe softwaredevelopment problems. They were proposed by Jack-son (Jackson, 2001), who describes them as follows:“A problem frame is a kind of pattern. It defines anintuitively identifiable problem class in terms of itscontext and the characteristics of its domains, inter-faces and requirement.” It is described by a framediagram, which consists of domains, interfaces be-tween domains, and a requirement. We describe prob-lem frames using UML class diagrams extended bystereotypes as proposed by Hatebur and Heisel (Hate-bur and Heisel, 2010). All elements of a problemframe diagram act as placeholders, which must be in-stantiated to represent concrete problems. Doing so,one obtains a problem diagram that belongs to a spe-cific class of problems.

Figure 2 shows a problem diagram in UML no-tation. The class with the stereotype �machine�represents the thing to be developed (e.g., the soft-ware). The classes with some domain stereotypes,e.g., �causalDomain� or �lexicalDomain� representproblem domains that already exist in the applica-tion environment. Jackson distinguishes the domaintypes causal domains that comply with some physi-cal laws, lexical domains that are data representations,biddable domains that are usually people, and con-nection domains that mediate between domains.

Domains are connected by interfaces consistingof shared phenomena. Shared phenomena may beevents, operation calls, messages, and the like. Theyare observable by all connected domains, but con-trolled by only one domain, as indicated by an ex-clamation mark. For example, in Figure 2 the nota-tion LMN!{forwardData} means that the phenomenon inthe set {forwardData} is controlled by the domain LMNand observable by the machine domain SMGReceiver,which is connected to it. These interfaces are rep-resented as associations, and the name of the associ-ations contain the phenomena and the domains con-trolling the phenomena.

In Figure 2, the lexical domain TemporaryMeterDatais constrained and the SmartMeter is referred to, be-cause the machine SMGReceiver has the role to requestmeter data from the SmartMeter and store the responseas TemporaryMeterData for satisfying requirement R1.These relationships are modeled using dependenciesthat are annotated with the corresponding stereotypes.

The full description for Figure 2 is as follows:The causal domain SmartMeter controls the sendDatacommand, which is forwarded by the LMN and finallyobserved by the machine domain SMGReceiver. TheSMGReceiver controls the phenomenon writeTemporary-

Data, which stores the received information in thelexical domain TemporaryMeterData. Additionally, theSMGReceiver can requestData which is forwarded bythe LMN to the SmartMeter. The connection domainLMN forwards the data and requests it observes. The re-quirement R1 constrains the TemporaryMeterData andrefers to the SmartMeter.

Software development with problem frames pro-ceeds as follows: first, the environment in which themachine will operate is represented by a context di-agram. Like a problem diagram, a context diagramconsists of domains and interfaces. However, a con-text diagram contains no requirements. Then, theproblem is decomposed into subproblems. If everpossible, the decomposition is done in such a way thatthe subproblems fit to given problem frames. To fita subproblem to a problem frame, one must instan-tiate its frame diagram, i.e., provide instances for itsdomains, phenomena, and interfaces. The UML4PFframework provides tool support for this approach. Amore detailed description can be found in (Cote et al.,2011).

4 Method

An illustration of our method is given in Figure 1.The initial input for our method is a textual infor-mal description of the requirements the system-to-beshall fulfill. These requirements are classified intopreliminary aspect requirements (or short aspects),which are functional and cross-cutting, preliminaryquality requirements (or short qualities), which arenon-functional and cross-cutting, and base require-ments (or short bases), which are not cross-cutting.Additionally, the relations between requirements andaspects or qualities are documented as preliminarycross-cut relations. Then all identified base require-ments are modeled following the problem frames ap-proach introduced in Section 3, such that for eachbase requirement a base problem diagram is created.Additionally, we create a sequence diagram for eachproblem diagram. The sequence diagrams serve as abase problem specification. To prepare the complete-ness analysis, we identify for all preliminary aspect

Figure 2: Problem Diagram R1: Receive meter data

DescriptionInformal

RequirementsBase

DiagramsProblemBase

SpecificationsProblemBase

RequirementsQuality

RelationsCross−CutPreliminary

RequirementsAspectPreliminary

RequirementsQualityPreliminary

AspectRequirements

RelationsCross−Cut

SpecificationsProblemWeaved

RelationsWeaving

DiagramsProblemAspectConsolidated

DiagramsProblemBaseConsolidated

SpecificationsProblemWeavedConsolidated

RelationsWeavingConsolidated

SpecificationsProblemAspect

DiagramsProblemAspect

Document

Requirements

Classify RequirementsBaseModel

QualitiesUnderlying

Identify

Analyse

Completeness RequirementsAspectModel Weave

Requirements

ou

tpu

tin

pu

t /

ou

tpu

tin

pu

t /

information flow control flow Activity generated automatically generated semi−automatically

Analyze

Interactions

pro

ce

ss

Figure 1: The AORE4PF method

requirements the underlying qualities they address.The already known preliminary quality requirementscan aid the identification. As a result, we get a set ofquality requirements. Based on the identified qualityand base requirements, we can analyze whether thereis a cross-cut relation between a quality requirementand a base requirement not discovered yet. Thus, weanalyze the completeness of the preliminary cross-cut relations and update them if necessary. The re-sults are a set of cross-cut relations and also updatedaspect requirements. Next, the aspect requirementsare modeled in a similar way as requirements usingspecialized problem diagrams, called aspect problemdiagrams. Again, we specify the machine behav-ior using sequence diagrams, which results in aspectproblem specifications. For the next step, weave re-quirements, the base problem specifications and as-pect problem specifications are weaved to fulfill thebase and aspect requirements as defined by the baseproblem diagrams and aspect problem diagrams. Forthe weaving, we have to accomplish two activities.First, we define the weaving relations. These relationsrefine the cross-cut relations. Then, we can automat-ically generate for each requirement a weaved prob-lem specification representing the weaved system be-havior. Last, we have to analyze the base and aspectproblem diagrams for unwanted interactions, such asconflicts. The weaving relations and the weaved prob-lem specifications can support this activity. The re-sults of this step are consolidated base and aspectproblem diagrams as well as consolidated weavingrelations and problem specifications. We will discussall steps of our method in detail in the following sec-tions.

4.1 Classify Requirements

As a first step, we have to identify and analyze therequirements contained in the informal description.We have to separate and classify these requirements

as they will be treated differently afterwards. A re-quirement can be 1) a base, which is functional andnot cross-cutting, 2) an aspect, which is functionaland cross-cutting, and 3) a quality, which is non-functional and cross-cutting. Note that we see qualityrequirements as requirements, which are not opera-tionalized to an aspect right now. Hence, there is aclear relation between qualities and aspects, and wewill later on refine qualities to aspects. Normally,statements in an informal description are not giventhat clear-cut as given by the three discussed classesof requirements. Hence, one can find requirementsmixing different classes, for example, aspects are al-ready combined with the corresponding bases or qual-ities are mentioned in the according bases. In con-sequence, identifying statements which constitute re-quirements is only half of the job, but also a separa-tion of mixed requirements has to be performed.

First, we separate functional and quality require-ments. A tool like OntRep (Moser et al., 2011) cansupport the requirements engineer in this step. Thisway we identify R29 as requirement containing twoquality requirements (R29A and R29B) and R28 con-taining one quality (R28A) and one functional require-ment (R28B):

(R28A) Security The Gateway should provide func-tionality to prevent eavesdropping. [. . . ]

(R29A) Privacy [. . . ] to ensure that personal andconfidential information will not be disclosed easilywithin communicating systems. Grid systems shallnot be a way to reveal information.

(R29B) Compliance Many countries protect cus-tomers’ and people’s rights by laws, [. . . ]

Thus, we have identified and separated the prelimi-nary quality requirements.

Second, we have to analyze the functional require-ments for aspects and separate them. For this ac-tivity tools like EA-Miner (Sampaio et al., 2007),Theme/Doc (Baniassad and Clarke, 2004) or REAs-

sistant4 can aid the requirements engineer. This waywe identify the following two aspects:

(R28B) Encryption [. . . ] The gateway must be ca-pable of encrypting communications and data by thesafest and best encryption mechanisms possible.

(R30) Logging The gate shall log the occurring im-portant events.

Note that while eavesdropping is already formulatedas separate aspect, logging is introduced as a new as-pect that is extracted from R17 and R18 which bothcontain the logging aspect:

(R17B) New firmware: Logging The gate shall logthe event of successful verification of a new versionof the firmware.

(R18B) Activate new firmware: Logging The gate-way shall log the event of deploying a new version ofthe firmware.

Thus, we have identified and separated the prelimi-nary aspect requirements.

The remaining functional requirements form thebase requirements for our system:

(R1) Receive meter data The smart meter gatewayshall receive meter data from smart meters.

(R17A) New firmware The gateway should accept anew firmware from authorized external entities.

(R18A) Activate new firmware On a predetermineddate the gateway executes the firmware update.

We document the relations between the separatedfunctional, quality, and aspect requirements in a pre-liminary cross-cut relation table. These relations aregiven in Table 1 with crosses in italic. If a require-ment is separated into a functional requirement (baseor aspect) and a quality, then we add a cross in thecorresponding cell of the table. In Table 1, we doc-umented that the aspect R28B is related to the qualityR28A. If functional requirements are separated intobase and aspect requirements, then we also add re-spective crosses. In Table 1, we documented that theaspect R30 cross-cuts the base requirements R17A andR18A. Note that everything given in bold is discov-ered later on in the annotated step (x).

4.2 Model Base Problems

In this step, we model the functional requirementsidentified in the previous step. For each functional re-quirement, we create a problem diagram as proposed

4https://code.google.com/p/reassistant/

Table 1: Requirements (Cross-Cut) Relation Table for theSmart Grid Scenario

Quality Aspect

R28A R29A R29B R31 R28BR30

(R17B,R18B)

Base R1 X4 X4 X4 X4 X4 X4

R17A X4 X3 X4 XR18A X3 X

Quality R28A I7 I7 I7 XR29A I7 I7 I7 X4

R29B I7 I7 I7 X4 X4

R31 I7 I7 I7 X3

by the problem frames approach introduced in Sec-tion 3. For reasons of space, we only show the prob-lem diagrams for the requirements R1 and R17A, butthese two problem diagrams are sufficient to under-stand the rest of the paper, even though we use the fiveselected requirements for exemplifying our method.The problem diagram for R1 is shown in Figure 2 andexplained in Section 3. Figure 3 shows the problemdiagram for R17A. The biddable domain Authorized-ExternalEntity controls the updateFirmware command,which is observed by the connection domain WAN.The SMGFirmwareStorage controls the phenomenonstoreNewFirmware, which is observed by the lexical do-main FirmwareUpdate. The WAN forwards the firmwareupdate it observes. The requirement R17A (for a tex-tual description see Section 2) constrains the Firmware-Update and refers to the AuthorizedExternalEntity.

For every problem diagram, we have to providea reasoning, called frame concern (Jackson, 2001),why the specification of the submachine together withthe knowledge about the environment (domain knowl-edge) leads to the satisfaction of the requirement. Tovisualize how frame concern is addressed in the spe-cific problems, we create at least one sequence dia-gram for each problem diagram. These sequence dia-grams describe the specification (behavior of the ma-chine) and the domain knowledge (behavior of the do-mains) which is necessary to satisfy the requirement.How to systematically create the sequence diagramsis out of scope of this paper, but the approach pre-sented by Jackson and Zave (Jackson and Zave, 1995)can be used for this task. Figure 4 shows the se-quence diagram for the sub-problem New firmware.The interaction is started by an AuthorizedExternalEn-tity causing the phenomenon updateFirmware (require-ment). This request is forwarded via the WAN to

Figure 3: Problem Diagram R17A : New firmware

Figure 4: Sequence diagram for R17A

the sub-machine SMGFirmwareStorage (domain knowl-edge). The sub-machine then performs a verificationon the received firmware update (specification). Inthe case of a successful verification, the new firmwareis stored in the lexical domain FirmwareUpdate (spec-ification). Hence, the gateway accepts new firmwarefrom authorized external entities (requirement).

4.3 Identify Underlying Qualities

In order to check whether the cross-cut relation iscomplete, we identify for all aspects the softwarequalities they address. Note that the relationship be-tween aspects and qualities is many-to-many. Thatis, an aspect can address multiple software qualities.For example, the logging of system events possiblyaddresses the software qualities accountability, trans-parency, maintainability, performance, and traceabil-ity. On the other hand, a software quality can be ad-dressed by multiple aspects, for example, the softwarequality confidentiality could be addressed by the fol-lowing aspects: encryption, authentication and autho-rization, and data minimization. For the identificationof underlying qualities tools such as QAMiner (Ragoet al., 2013) can be used. This way we discover thatin our case the aspect R30 has the underlying qualitymaintainability:

(R31) Maintainability All events which are useful totrace a malfunction of the gateway shall be logged.

4.4 Analyze Completeness

Based on the identified qualities, we can re-usequality-dependent analysis techniques on problemframes to check the completeness of the cross-cutrelation. For example, for privacy one can use theProPAn method (Beckers et al., 2014), the law (iden-tification) pattern method (Faßbender and Heisel,2013) provides guidance for compliance, security iscovered by the PresSuRE method (Faßbender et al.,2014), and so forth. These analysis techniques iden-tify for a given problem frames model and the re-spective quality in which functional requirements thequality has to be considered. At this point of ourmethod, we have all inputs that the analysis tech-niques need. Using the results of the analysis tech-

Figure 5: AORE4PF UML Profile

niques, we can update the cross-cut relation and checkwhether the selected aspects together with the de-fined cross-cut relation guarantee the intended soft-ware qualities. In this way, we identify that, for ex-ample, several qualities are relevant for R1. Privacy(R29A) is relevant as the consumption data meteredby the smart meters enables one to analyze what thepersons in the household are currently doing. Hence,the consumption data is an asset which has to be pro-tected. As result, the security analysis also showsthat the consumption data has to be protected againsteavesdropping (R28A). Maintainability (R31) is alsorelevant for R1, as a malfunction can also occur whilereceiving consumption data. The compliance anal-ysis (R29B) reveals and strengthens the importanceof privacy because of different data protection acts.Additionally, the logging mechanism is not only rel-evant for maintainability but also for compliance asseveral laws require the fulfillment of accountabilityrequirements whenever there is a contractual relationbetween different parties. The already existing as-pect requirements are sufficient to cover the newlyfound relations. This information is used to updatethe cross-cut relation table (see Table 1).

4.5 Model Aspect Requirements

To model aspect requirements in a similar wayas base requirements, we extended the UML pro-file of the UML4PF tool with aspect-oriented con-cepts. The AORE4PF UML profile is shown inFigure 5. To differentiate aspect requirements,the machines that address them, and the diagramthey are represented in, from base requirementsand their machines and diagrams, we introducethe new stereotypes �Aspect�, �AspectMachine�,and �AspectDiagram� as specialization of thestereotypes�Requirement�,�ProblemDiagram�, and�Machine�, respectively. In addition to problem di-agrams, an aspect diagram has to contain a set of joinpoints, which together form a pointcut. These joinpoints can be domains and interfaces. Hence, we in-troduced the new stereotype �JoinPoint�, which canbe applied to all specializations of the UML meta-class NamedElement. During the weaving, join pointsare instantiated with domains of the problem dia-grams the aspect cross-cuts.

To create an aspect diagram, we have to identify

Figure 6: Aspect diagram for aspect requirement R28

Figure 7: Sequence diagram for aspect requirement R28

the join points which are necessary to combine theaspect with the base problems it cross-cuts and to un-derstand the problem of building the aspect machine.In most cases, we have a machine, besides the aspectmachine, as join point in an aspect diagram. Thismachine will be instantiated during the weaving withthe machine of the problem diagram that the aspect isweaved into. The interface between this join point andthe aspect machine describes how a problem machinecan utilize an aspect. We have to define appropriateinterfaces between the aspect machine and the iden-tified join points, so that the aspect can be combinedwith all base requirements in a uniform way. Besidesthe specialized stereotypes for the machine and therequirement, and the definition of join points for thelater weaving, the process of building an aspect di-agram is similar to the process of building problemdiagrams. As for problem diagrams, we also create asequence diagram for each aspect diagram.

For reasons of space, we will only discuss the as-pect requirement R28 in detail. R28 covers the preven-tion against eavesdropping attacks in the smart gridscenario by encrypting all communication. The cor-responding aspect diagram is presented in Figure 6. Itcontains the aspect machine SMGEavesdropping, whichhas access to the public and private keys for the en-cryption and decryption. The keys are stored in theKeyStorage. Furthermore, the aspect diagram containsthree domains as join points. The machine SMGRe-quester will be instantiated by a problem machine andthe interface b describes that the problem machineis able to send a request to SMGEavesdropping in or-der to decryptData and encryptData. SMGEavesdroppingreturns decryptedData and encryptedData, respectively.The join points Network and SenderReceiver are addedto refer to the network an attacker may eavesdrop and

to the sender or receiver of the data to be transmitted.Hence, we can have two different scenarios for the as-pect of preventing eavesdropping. The first scenariois concerned with the decryption of data a problemmachine received from a sender, and the second sce-nario is concerned with the encryption of data a prob-lem machine shall send to a receiver. The sequencediagram for the first scenario is shown in Figure 7.The sequence diagram shows that when the machineSMGRequester receives data from some sender over anetwork, it asks the aspect machine SMGEavesdrop-ping to decrypt the received data (aspect requirement).Then the aspect machine retrieves the needed publickey from the KeyStorage to decrypt the data in order tosend it back to the machine SMGRequester (specifica-tion). The sequence diagram for the second scenariois built in a similar way, but left out due to space lim-itations.

Note that the modularization of the preventionagainst eavesdropping into an aspect allows us to eas-ily change the encryption mechanism if a better andnewer mechanism is available, so that we are able toencrypt communications and data by the safest andbest encryption mechanisms possible.

4.6 Weave Requirements

For each base requirement, we now create a sequencediagram that describes how the aspect requirementshave to be weaved into it to address the cross-cut re-lation. The basis for the weaving sequence diagram isthe sequence diagram of the requirement. The behav-ior of the sub-machine is extended with the invocationof the aspects given by the row of the base require-ment in the cross-cut relation table (see Table 1).

The cross-cut relation (see Table 1) is not suffi-cient to weave the aspect requirements into the baserequirement. The reason is that the cross-cut relationdoes not define how and when an aspect has to be in-tegrated into the base problem. We create a table foreach base requirement that defines how the aspectsare integrated into the base problem. A row in the ta-ble consists of a message of the sequence diagram ofthe base requirement, a keyword, and the aspect thatshall be weaved into the requirement. For this paper,we use the keywords before and after, but we plan toextend this list, to provide more possibilities to inte-grate aspects into problems. The keyword describeswhether the aspect has to be integrated before or afterthe message. If multiple aspects shall be integratedbefore or after a message, we have to define the orderin which the aspects are integrated. Table 2 shows therefined cross-cut relation for base requirement R17A.

Because of the aspect requirement R28 all commu-

Figure 8: Weaved sequence diagram for R17A

Table 2: Refined Cross-cut relation table for R17AMessage Key Aspect Sequence Diagramforward-Update-Firmware

after Eavesdropping[WAN/Network, Authorized-ExternalEntity/Sender, SMGFirmware-Storage/SMGRequester]

storeNew-Firmware

before Logging[SMGFirmwareStorage/SMG-Requester]

nications have to be encrypted to prevent eavesdrop-ping attacks. This implies that all external messagesthat a sub-machine receives have to be decrypted.For R28 we express this in the first row of Table 2.The row defines that after the message forwardUpdate-Firmware was received by the sub-machine the se-quence diagram Eavesdropping of aspect requirementR28 shall be integrated. Additionally, it is definedthat the join points Network, Sender, and SMGRequesterare instantiated with the domains WAN, AuthorizedEx-ternalEntity, and SMGFirmwareStorage. In this way, weaddressed the concern that external messages have tobe decrypted in the base requirement R28.

The refined cross-cut relations are used to auto-matically generate the weaving sequence diagramsfrom the sequence diagrams of the problem and as-pect diagrams. These automatically generated se-quence diagrams have then to be adjusted, such thatthe overall behavior satisfies the weaving require-ment. The generated sequence diagram is shown inFigure 8. For the sake of readability, we highlightedthe messages from the integrated aspect specificationsusing a bold font. The other messages are the mes-sages from the problem specification, which form thebasis of the weaving sequence diagram. In accor-dance with Table 2, the sequence diagrams Eaves-dropping is integrated after the message forwardUpdate-Firmware and the sequence diagrams Logging beforethe message storeNewFirmwareBase. The latter ad-dresses the concern that the event of a successfulfirmware verification shall be logged (aspect require-ment R17B). For the presented example, we do notneed further adjustments because it already addresses

the combination of the base requirement with its as-pect requirements adequately.

4.7 Analyze Interactions

For reasons of space, we do not go into detail for thisstep. Alebrahim et al. provide methods for interac-tion analysis using problem frames. In (Alebrahimet al., 2014b) functional requirements are treated, and(Alebrahim et al., 2014a) describes how to analyzequality requirements for interactions. Both works usethe smart grid as a case study. Hence, we re-used themethods and results also for this work. The results aredocumented in Table 1 using bold I.

5 Validation

To validate our method, we applied it to the cri-sis management system (CMS) (Kienzle et al., 2010)that Kienzle et al. proposed as a case study for aspect-oriented modeling. We derived an informal scenariodescription and the textual use case descriptions fromthe original as input for our method5. The method wasexecuted by a requirements expert, who did not knowthe case beforehand. From the information providedto the requirements analyst, he identified 13 base re-quirements that he modeled using 10 problem dia-grams, 8 aspect requirements that he modeled using5 aspect diagrams, and 6 quality requirements.

The effort spent for conducting our method onthe CMS is summarized in Table 3. It took 5 hoursto classify the requirements. Note that for the casestudy this step was done manually. The reason wasthat tools such as, for example, OntRep (Moser et al.,2011) or EA-Miner (Sampaio et al., 2007) requiresome additional input like training documents or anexisting ontology. But unfortunately, such inputs

5For the inputs and the results see http://imperia.uni-due.de/imperia/md/content/swe/aore4pf cms report.pdf

Table 3: Effort spent (in person-hours/minutes) for conducting the method

Number of items

Ø per item 11min 36min 7min 7min 34min 23min 6minTotal 5h 00min 6h 3min 45min 1h 15min 2h 51min 3h 53min 1h 45min

Classify Requirements

Model Base Requirements

Identify Underlying Qualities

Analyze Completeness

Model Aspect Requirements

Weave Requirements

Analyze Interactions

27 requirements

10 base requirements

6 aspect requirements

10 base requirements

5 aspect requirements

10 base requirements

16 functional requirements

Table 4: Requirements identified1)

Fun

ctio

nal

2) A

vaila

bilit

y

3) R

elia

bilit

y

4) P

ersi

sten

ce

5) R

eal-T

ime

6) S

ecur

ity

7) M

obili

ty

8) S

tatis

tic L

oggi

ng

9) M

ulti-

Acc

ess

10)

Saf

ety

11)

Ada

ptab

ility

12)

Acc

urac

y

13)

Mai

ntai

nabi

lity

14)

Per

form

ance

15)

Sca

labi

lity

Su

m

Sam

e C

lass Identified 100% 33% 50% 0% 0% 67% 0% 0% 0% 75% 0% 0% 30%

Partly 0% 0% 0% 0% 0% 33% 0% 0% 0% 0% 0% 0% 3%

Not Identified 0% 0% 0% 0% 0% 0% 33% 0% 0% 25% 0% 75% 13%

Oth

er C

lass Identified As 13) 2) 1) 14) 1) 1) 15) 1) 1)

Identified 0% 67% 50% 100% 67% 0% 67% 100% 100% 0% 25% 25% 45%

Partly 0% 0% 0% 0% 33% 0% 0% 0% 0% 0% 75% 0% 10%

Ag

gre

gat

ed Identified 100% 100% 100% 100% 67% 67% 67% 100% 100% 75% 25% 25% 75%

Partly 0% 0% 0% 0% 33% 33% 0% 0% 0% 0% 75% 0% 13%

Not Identified 0% 0% 0% 0% 0% 0% 33% 0% 0% 25% 0% 75% 13%

were not available. Hence, the first step can be spedup significantly using these tools. Another big blockof effort is the modeling of base and aspect require-ments. Here the tool support already helps to speed upthe modeling, but is subject for further improvement.Note that the modeling steps do not only include themodeling itself, but also the analysis and improve-ment of the original requirements, which make therequirements more precise and unambiguous. There-fore, parts of the effort spend on the modeling stepsare unavoidable even when using another method ornotation. And the modeling itself pays off as it allowsthe usage of the broad spectrum of methods and toolswhich need problem frame models as input. For ex-ample, the analysis of completeness uses these mod-els and takes about an hour for different kinds of qual-ities. The weaving of aspects is quite time consumingright now. Here the tool support is on an experimen-tal level, but the observations taken during the casestudy imply that a full fledged tool support will signif-icantly drop the effort. The interaction analysis takesround about two hours, which is significantly belowthe effort of doing such an analysis without a prob-lem frame model (see (Alebrahim et al., 2014b) forfurther information). All the effort spent sums up to21,5 person hours, which is significant but reasonable

with regards to the results one gets. And comparedto efforts other authors report, the effort spent for ourmethod seems to be even low. For example, Landuytet al. (Landuyt et al., 2010) report an effort spent fortheir method of 170 hours for the requirements engi-neering related activities,

To asses the sufficiency of the method and theused tools, the requirements and qualities foundwithin our method were compared to the original doc-ument as described by Kienzle et al. Table 4 showsthe comparison. Overall, the results are satisfying asmost requirements were found and classified in thecorrect class (30%) or in another, also correct, class(45%). The high amount of requirements classifieddifferently are due to specific classes given in the orig-inal documents. For example, persistence and statis-tical logging were completely described as functionalrequirements in the documents but treated as quali-ties. For such requirements it is a more general dis-cussion if they are quality requirements or not. Hence,we accepted both views as correct. For some specificqualities, such as mobility or accuracy, the overall ob-servation cannot be acknowledged. The reasons aresubject to further investigations.

To asses the aspects identified, we compared theresults of our method to the results given in other pub-

Table 5: Aspects identified

Found and separated 83% 75%Found and not separated 17% 25%Not Found 0% 0%

Not Mentioned 38% 25%

Landuyt et al., 2010 Mussbacher et al.,2010

lications considering requirements engineering usingthe same scenario (Landuyt et al., 2010; Mussbacheret al., 2010). The result of the comparison is shown inTable 5. Overall, our results are very similar. Theresult of applying our method includes all require-ments which are treated as aspects in the other works.And most of these found requirements are also sepa-rated as aspects by our method (Row “Found and sep-arated”). Only a minor number was not treated as as-pect (Row “Found and not separated”), but a detailedinvestigation showed that both views on these require-ments are reasonable. The indicator, “Found and sep-arated”, computes as ((requirement present as aspectin both documents ) / (requirements present as aspectin the publication at hand)). In respect, “Found andnot separated”, computes as ((requirement present inboth documents but not as aspect in our results) /(requirements present as aspect in the publication athand)). Some of the aspects our method found werenot mentioned in the other works (Row “Not Men-tioned”). This indicator computes as ((requirementsonly present in our result) / (all requirements presentin our results)). Reasons for the missing requirementsmight be that they were not reported due to lack ofspace or that they were not found.

We could not asses our completeness analysisquantitatively as the other works using the scenariostick to the original requirements. But the qualitativeinvestigation of the completeness analysis showedreasonable results. This observation is also true forthe cross cut relations. We also compared the weavedspecification with sequence diagrams or state ma-chines given by the original document and works in(Kienzle et al., 2010). Here we observed that thespecifications produced by our method were at leastas good as the chosen assessment artifacts. Again,the interaction analysis could not be assessed quan-titatively due to missing benchmarks. But the foundinteractions seemed to be real problems which haveto be resolved in a real case.

6 Related Work

There are many works considering early aspects(Rashid, 2008; Yu et al., 2004; Jacobson and Ng,2004; Whittle and Araujo, 2004; Sutton and Rou-

vellou, 2002; Moreira et al., 2005; Grundy, 1999).Most of these approaches deal with goal-oriented ap-proaches and use-case models. But goal or use-case models are of a higher level of abstractionthan problem frames. Additionally, goal and use-case models are stakeholder-centric, while problemframes are system-centric. Therefore, refining func-tional requirements taking into account more de-tail of the system-to-be and analyzing the system-to-be described by the functional requirements is re-ported to be difficult for such methods (Alrajeh et al.,2009). Recently, there were papers which reported asuccessful integration of goal- and problem-orientedmethods (Mohammadi et al., 2013; Beckers et al.,2013). Hence, one might benefit from integratinggoal-models in our method.

Conejero et al. (Conejero et al., 2010) present aframework alike the method presented in this paper.Their process also starts with unstructured textual re-quirements. Then different tools and modeling nota-tions are used along the frame work to identify andhandle aspects. In difference to our process, they donot consider a completeness or interaction analysisand especially for the modeling of aspects they lacktool support.

Only few approaches consider the integrationof early aspects in the problem frames approach.Lencastre et al. (Lencastre et al., 2008) also inves-tigated how early aspects can be integrated into prob-lem frames. Their method to model aspects in theproblem frames approach differs from ours. For anaspect, the authors first select a problem frame as PFPointcut Scenario. This pointcut scenario defines intowhich problems the aspect can be integrated. Thepointcut scenario is then extended to the PF Aspec-tual Scenario, which is similar to our aspect diagrams,with the difference that the pointcut always has to bea problem frame. This reduces flexibility, because anaspect (e.g., logging of all system events) may have tobe integrated into different problem diagrams.

7 Conclusions

In this paper, we presented the AORE4PF methodwhich integrates aspect-orientation and the problemframes approach. We extended the UML4PF profilewith stereotypes that allow us to create aspect dia-grams. We further introduced a structured methodol-ogy to separate aspects from requirements, to modelaspects, and to weave aspects and requirements to-gether. We considered both the static and the be-havioral view on the requirements, aspects, and theirweaving. We exemplified our method using a smart

grid scenario from the NESSoS project as case studyand validated it using a crisis management system.

The contributions of this work are 1) the integra-tion of aspects into the problem frames approach, 2)a structured way of separating base, quality and as-pect requirements, starting from a textual description,3) the detection of implicit qualities given by aspects,4) identification of all base requirements relevant for aquality and the related aspects, 5) a structured methodto weave base and aspect requirements, and 6) the in-tegration of an interactions analysis between the re-sulting requirements. The AORE4PF method is 7)tool-supported in most steps.

For future work, we plan to improve the tool sup-port and provide an integrated tool chain. Addition-ally, we plan to integrate our new model elements intomore already existing methods and analyses based onUML4PF to cover a broader spectrum of qualities.

Acknowledgment

Part of this work is funded by the GermanResearch Foundation (DFG) under grant numberHE3322/4-2.

References

Alebrahim, A., Choppy, C., Faßbender, S., andHeisel, M. (2014a). Optimizing functional andquality requirements according to stakeholders’goals. In System Quality and Software Architec-ture. Elsevier. to appear.

Alebrahim, A., Faßbender, S., Heisel, M., and Meis,R. (2014b). Problem-based requirements inter-action analysis. In Requirements Engineering:Foundation for Software Quality, volume 8396of LNCS, pages 200–215. Springer.

Alrajeh, D., Kramer, J., Russo, A., and Uchitel, S.(2009). Learning operational requirements fromgoal models. In IEEE 31st International Confer-ence on Software Engineering, pages 265–275.IEEE Computer Society.

Baniassad, E. and Clarke, S. (2004). Finding as-pects in requirements with Theme/Doc. InEarly Aspects: Aspect-Oriented RequirementsEngineering and Architecture Design, pages 15–22. http://trese.cs.utwente.nl/workshops/early-aspects-2004/workshop papers.htm.

Beckers, K., Faßbender, S., Heisel, M., and Meis, R.(2014). A problem-based approach for computer

aided privacy threat identification. In PrivacyTechnologies and Policy, volume 8319 of LNCS,pages 1–16. Springer.

Beckers, K., Faßbender, S., Heisel, M., and Paci, F.(2013). Combining goal-oriented and problem-oriented requirements engineering methods. InAvailability, Reliability, and Security in Informa-tion Systems and HCI, volume 8127 of LNCS,pages 178–194. Springer.

Boehm, B. W. and Papaccio, P. N. (1988). Un-derstanding and controlling software costs.IEEE Transactions on Software Engineering,14(10):1462–1477.

Cavusoglu, H., Mishra, B., and Raghunathan, S.(2004). The effect of internet security breachannouncements on market value: Capital marketreactions for breached firms and internet securitydevelopers. International Journal of ElectronicCommerce, 9(1):70–104.

Conejero, J. M., Hernandez, J., Jurado, E., andvan den Berg, K. (2010). Mining early aspectsbased on syntactical and dependency analyses.Science of Computer Programming, 75(11).

Cote, I., Hatebur, D., Heisel, M., and Schmidt,H. (2011). UML4PF - a tool for problem-oriented requirements analysis. In Proceedingsof the 19th IEEE International RequirementsEngineering Conference, pages 349–350. IEEEComputer Society.

Faßbender, S. and Heisel, M. (2013). From prob-lems to laws in requirements engineering usingmodel-transformation. In ICSOFT ’13, pages447–458. SciTePress.

Faßbender, S., Heisel, M., and Meis, R. (2014). Func-tional requirements under security pressure. InICSOFT ’14. SciTePress. to appear.

Firesmith, D. (2003). Specifying good requirements.Journal of Object Technology, 2(4):77–87.http://www.jot.fm/issues/issue 2003 07/column7.

Grundy, J. C. (1999). Aspect-oriented requirementsengineering for component-based software sys-tems. In Proceedings of the IEEE InternationalSymposium on Requirements Engineering, pages84–91, Washington, DC, USA. IEEE ComputerSociety.

Hatebur, D. and Heisel, M. (2010). A UML profile forrequirements analysis of dependable software. InComputer Safety, Reliability, and Security, vol-ume 6351 of LNCS, pages 317–331. Springer.

Hofmann, H. and Lehner, F. (2001). Require-ments engineering as a success factor in softwareprojects. IEEE Software, 18(4):58–66.

Jackson, M. (2001). Problem Frames. Analyzingand structuring software development problems.Addison-Wesley.

Jackson, M. and Zave, P. (1995). Deriving specifica-tions from requirements: an example. In ICSE,USA, pages 15–24. ACM Press.

Jacobson, I. and Ng, P.-W. (2004). Aspect-Oriented Software Development with Use Cases.Addison-Wesley Professional.

Khansa, L., Cook, D. F., James, T., and Bruyaka,O. (2012). Impact of HIPAA provisions on thestock market value of healthcare institutions, andinformation security and other information tech-nology firms. Computers & Security, 31(6):750– 770.

Kienzle, J., Guelfi, N., and Mustafiz, S. (2010).Crisis management systems: A case study foraspect-oriented modeling. In Katz, S., Mezini,M., and Kienzle, J., editors, Transactions onAspect-Oriented Software Development VII, vol-ume 6210 of LNCS, pages 1–22. Springer.

Kreutzmann, H., Vollmer, S., Tekampe, N., andAbromeit, A. (2011). Protection profile for thegateway of a smart metering system. Technicalreport, BSI.

Landuyt, D., Truyen, E., and Joosen, W. (2010). Dis-covery of stable abstractions for aspect-orientedcomposition in the car crash management do-main. In Transactions on Aspect-Oriented Soft-ware Development VII, volume 6210 of LNCS,pages 375–422. Springer.

Lencastre, M., Moreira, A., Araujo, J., and Cas-tro, J. (2008). Aspects composition in problemframes. In Proceedings of the 16th IEEE Inter-national Requirements Engineering Conference,pages 343–344. IEEE Computer Society.

Mohammadi, N. G., Alebrahim, A., Weyer, T., Heisel,M., and Pohl, K. (2013). A framework for com-bining problem frames and goal models to sup-port context analysis during requirements engi-neering. In Availability, Reliability, and Securityin Information Systems and HCI, volume 8127of LNCS, pages 272–288. Springer.

Moreira, A., Arajo, J., and Rashid, A. (2005).A concern-oriented requirements engineeringmodel. In Pastor, O. and Falco e Cunha, J., ed-itors, Advanced Information Systems Engineer-ing, volume 3520 of LNCS, pages 293–308.Springer.

Moser, T., Winkler, D., Heindl, M., and Biffl, S.(2011). Requirements management with seman-tic technology: An empirical study on auto-mated requirements categorization and conflictanalysis. In Advanced Information Systems En-gineering, volume 6741 of LNCS, pages 3–17.Springer.

Mussbacher, G., Amyot, D., Araujo, J., and Mor-eira, A. (2010). Requirements modeling withthe aspect-oriented user requirements notation(AoURN): A case study. In Transactions onAspect-Oriented Software Development VII, vol-ume 6210 of LNCS, pages 23–68. Springer.

OPEN meter project (2009). Requirements of AMI.Technical report, OPEN meter project.

Parnas, D. L. (1972). On the criteria to be used indecomposing systems into modules. Communi-cations of the ACM, 15(12):1053–1058.

Rago, A., Marcos, C., and Diaz-Pace, J. A. (2013).Uncovering quality-attribute concerns in usecase specifications via early aspect mining. Re-quirements Engineering, 18(1):67–84.

Rashid, A. (2008). Aspect-oriented requirements en-gineering: An introduction. In Proceedings ofthe 16th IEEE International Requirements Engi-neering Conference, pages 306–309. IEEE Com-puter Society.

Sampaio, A., Rashid, A., Chitchyan, R., and Rayson,P. (2007). Ea-miner: Towards automation inaspect-oriented requirements engineering. InTransactions on Aspect-Oriented Software De-velopment III, volume 4620 of LNCS, pages 4–39. Springer.

Sutton, Jr., S. M. and Rouvellou, I. (2002). Mod-eling of software concerns in cosmos. In Pro-ceedings of the 1st International Conference onAspect-oriented Software Development, AOSD’02, pages 127–133, New York, NY, USA. ACM.

Whittle, J. and Araujo, J. (2004). Scenario mod-elling with aspects. IEE Proceedings Software,151(4):157–171.

Willis, R. (1998). Hughes Aircraft’s Widespread De-ployment of a Continuously Improving SoftwareProcess. AD-a358 993. Carnegie-Mellon Uni-versity.

Yu, Y., Cesar, J., Leite, S. P., and Mylopoulos, J.(2004). From goals to aspects: Discovering as-pects from requirements goal models. In Pro-ceedings of the 12th IEEE International Require-ments Engineering Conference, pages 38–47.IEEE Computer Society.