Conference PaperPDF Available

Aspect-oriented Requirements Engineering with Problem Frames

  • Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen

Abstract and Figures

Nowadays, the requirements of various stakeholders for a system do not only increase the complexity of the system-to-be, but also contain different cross-cutting concerns. In such a situation, requirements engineers are really challenged to master the complexity and to deliver a coherent and complete description of the system-to-be. Hence, they are in need for methods which reduce the complexity, handle functional and quality requirements, check completeness and reveal interactions, and are tool supported to lower the effort. One possible option to handle the complexity of a system-to-be is the separation of concerns. Both, aspect-oriented requirements engineering and the problem frames approach implement this principle. Therefore, we propose a combination of both, the AORE4PF (Aspect-Oriented Requirements Engineering for Problem Frames) method. AORE4PF provides guidance for classifying requirements, separating the different concerns, modeling requirements for documentation and application of completeness and interaction analyses, and weaving the reusable parts to a complete and coherent system. AORE4PF provides tool support for most activities. We exemplify our method using a smart grid case obtained from the NESSoS project. For validation, the results of a small experiment in the field of crisis management systems are presented.
Content may be subject to copyright.
Aspect-Oriented Requirements Engineering with Problem Frames
Keywords: Early Aspect, Problem Frames, Requirements Engineering
Abstract: Nowadays, the requirements of various stakeholders for a system do not only increase the complexity of the
system-to-be, but also contain different cross-cutting concerns. In such a situation, requirements engineers are
really challenged to master the complexity and to deliver a coherent and complete description of the system-
to-be. Hence, they are in need for methods, which reduce the complexity, which handle functional and quality
requirements, which check completeness and reveal interactions, and which are tool supported to lower the
effort. One possible option to handle the complexity of a system-to-be is the separation of concerns. Both,
aspect-oriented requirements engineering and the problem frames approach implement this principleThere-
fore, we propose a combination of both, the AORE4PF (Aspect-Oriented Requirements Engineering for Prob-
lem Frames) method. AORE4PF provides guidance for classifying requirements, separating the different
concerns, modeling requirements for documentation and application of completeness and interaction analy-
ses, and weaving the reusable parts to a complete and coherent system. AORE4PF provides tool support for
most activities. We exemplify our method using a smart grid case obtained from the NESSoS project. For
validation, the results of 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 software
products (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 legal
infringement (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 to
be up to eighty times more expensive than fixing the
corresponding requirements defects early on (Boehm
and Papaccio, 1988; Willis, 1998). Therefore, it is
crucial for requirements engineers to identify, ana-
lyze, and describe all requirements and related quality
concerns. But eliciting good requirements is not an
easy task (Firesmith, 2003), even more when consid-
ering complex systems.
Nowadays, for almost every software system, var-
ious stakeholders with diverse interests exist. These
interests give rise to different sets of requirements.
These diverse requirements not only increase the
complexity of the system-to-be, but also contain dif-
ferent cross-cutting concerns, such as qualities, which
are 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 of
a system-to-be is the concept of separation of con-
cerns (Parnas, 1972). In its most general form, the
separation of concerns principle refers to the ability
to focus on, and analyze or change only those parts
of a system which are relevant for one specific prob-
lem. The main benefits of this principle are a re-
duced complexity, improved comprehensibility, and
improved reusability (Parnas, 1972).
Both, aspect-oriented requirements engineering
and the problem frame approach implement this prin-
ciple, but for different reasons. The approach of
AORE (aspect-oriented requirements engineering),
which originates from aspect-oriented programming,
is to separate each cross-cutting requirement into an
aspect. 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. To
combine 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 building
the system-to-be into small sub-problems that fit to
a problem frame. Each sub-problem is solved by a
machine, which has to be specified using the given
domain knowledge. All machines have to be com-
posed to form the overall machine. We will show that
aspect-orientation gives guidance for the process of
decomposing the overall problem and especially for
the composition of the machines. Hence, we pro-
pose the AORE4PF (Aspect-Oriented Requirements
Engineering for Problem Frames) method that pro-
vides guidance for classifying requirements, separat-
ing the different concerns, modeling requirements for
documentation and application of completeness and
interaction analyses, and weaving the reusable parts
to a complete and coherent system. Furthermore,
AORE4PF provides tool support for most activities.
The rest of the paper is structured as follows. Sec-
tion 2 introduces a smart grid scenario, which is used
as a case study. In Section 3, we briefly introduce
the problem frames approach and UML4PF as back-
ground of this paper. Our method for the integration
of AORE into the problem frames approach is pre-
sented in Section 4. Work related to this paper is dis-
cussed in Section 6. Finally, Section 7 concludes the
paper and presents possible future work.
2 Case Study
To illustrate the application of the AORE4PF
method, we use the real-life case study of smart
grids. As sources for real functional requirements,
we consider diverse documents such as “Application
Case Study: Smart Grid” provided by the industrial
partners of the EU project NESSoS1, and “Require-
ments of AMI (Advanced Multi-metering Infrastruc-
ture”) (OPEN meter project, 2009) provided by the
EU project OPEN meter2.
We define the terms specific to the smart grid do-
main and our use case in the following. The smart
meter gateway represents the central communication
unit in a smart metering system. It is responsible for
collecting, processing, storing, and communicating
meter 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 or
production of a certain commodity and sends it to the
gateway. An authorized external entity can be a hu-
man or an IT unit that communicates with the gateway
from outside the gateway boundaries through a wide
area network (WAN). The WAN provides the commu-
nication network that interconnects the gateway with
the outside world. The LMN (local metrological net-
work) provides the communication network between
the meter and the gateway. The HAN (home area net-
work) provides the communication network between
the consumer and the gateway. The term consumer
refers to end users of commodities (e.g., electricity).
For the rest of the paper, we have chosen a small
selection of requirements to exemplify our method.
These requirements are part of the 13 minimum
use cases defined for a smart meter gateway given
in the documents of NESSoS and the open meter
project. The considered use cases are concerned with
gathering, processing, and storing meter readings
from smart meters for the billing process. The
requirements are described as follows:
(R1) Receive meter data The smart meter gateway
shall receive meter data from smart meters.
(R17) New firmware The gateway should accept a
new firmware from authorized external entities. The
gate shall log the event of successful verification of a
new version of the firmware.
(R18) Activate new firmware On a predetermined
date the gateway executes the firmware update. The
gateway shall log the event of deploying a new
version of the firmware.
(R28) Prevent eavesdropping The Gateway should
provide functionality to prevent eavesdropping. The
gateway must be capable of encrypting communi-
cations and data by the safest and best encryption
mechanisms possible.
(R29) Privacy and legislation Many countries pro-
tect customer’s and people’s rights by laws, to ensure
that personal and confidential information will not
be 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 software
development problems. They were proposed by Jack-
son (Jackson, 2001), who describes them as follows:
“A problem frame is a kind of pattern. It defines an
intuitively identifiable problem class in terms of its
context and the characteristics of its domains, inter-
faces and requirement. It is described by a frame
diagram, which consists of domains, interfaces be-
tween domains, and a requirement. We describe prob-
lem frames using UML class diagrams extended by
stereotypes as proposed by Hatebur and Heisel (Hate-
bur and Heisel, 2010). All elements of a problem
frame 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., causalDomainor lexicalDomainrepresent
problem domains that already exist in the applica-
tion environment. Jackson distinguishes the domain
types 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 consisting
of shared phenomena. Shared phenomena may be
events, operation calls, messages, and the like. They
are 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 in
the set {forwardData}is controlled by the domain LMN
and 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 TemporaryMeterData
is constrained and the SmartMeter is referred to, be-
cause the machine SMGReceiver has the role to request
meter data from the SmartMeter and store the response
as TemporaryMeterData for satisfying requirement R1.
These relationships are modeled using dependencies
that are annotated with the corresponding stereotypes.
The full description for Figure 2 is as follows:
The causal domain SmartMeter controls the sendData
command, which is forwarded by the LMN and finally
observed by the machine domain SMGReceiver. The
SMGReceiver controls the phenomenon writeTemporary-
Data, which stores the received information in the
lexical domain TemporaryMeterData. Additionally, the
SMGReceiver can requestData which is forwarded by
the LMN to the SmartMeter. The connection domain
LMN forwards the data and requests it observes. The re-
quirement R1 constrains the TemporaryMeterData and
refers to the SmartMeter.
Software development with problem frames pro-
ceeds as follows: first, the environment in which the
machine will operate is represented by a context di-
agram. Like a problem diagram, a context diagram
consists of domains and interfaces. However, a con-
text diagram contains no requirements. Then, the
problem is decomposed into subproblems. If ever
possible, the decomposition is done in such a way that
the subproblems fit to given problem frames. To fit a
subproblem to a problem frame, one must instantiate
its frame diagram, i.e., provide instances for its do-
Figure 2: Problem Diagram R1: Receive meter data
mains, phenomena, and interfaces.
The UML4PF framework provides tool support
for this approach. A more detailed description can
be found in (Cˆ
e 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-be
shall fulfill. These requirements are classified into
preliminary aspect requirements (or short aspects),
which are functional and cross-cutting, preliminary
quality requirements (or short qualities), which are
non-functional and cross-cutting, and base require-
ments (or short bases), which are not cross-cutting.
Additionally, the relations between requirements and
aspects or qualities are documented as preliminary
cross-cut relations. Then all identified base require-
ments are modeled following the problem frames ap-
proach introduced in Section 3, such that for each
base requirement abase problem diagram is created.
Additionally, we create a sequence diagram for each
problem diagram. The sequence diagrams serve as a
base problem specification. To prepare the complete-
ness analysis, we identify for all preliminary aspect
requirements the underlying qualities they address.
The already known preliminary quality requirements
can aid the identification. As a result, we get a set of
quality requirements. Based on the identified quality
and base requirements, we can analyze whether there
is a cross-cut relation between a quality requirement
and a base requirement not discovered yet. Thus, we
analyze the completeness of the preliminary cross-
cut relations and update them if necessary. The re-
sult are a set of cross-cut relations and also updated
aspect requirements. Next, the aspect requirements
are modeled in a similar way as requirements using
specialized problem diagrams, called aspect problem
diagrams. Again, we specify the machine behav-
ior using sequence diagrams, which results in aspect
problem specifications. For the next step, weave re-
quirements, the base problem specifications and as-
pect problem specifications are weaved to fulfill the
base and aspect requirements as defined by the base
problem diagrams and aspect problem diagrams. For
the weaving, we have to accomplish two activities.
First, we define the weaving relations. These relations
refine the cross-cut relations. Then, we automatically
can generate for each requirement a weaved problem
specification representing the weaved system behav-
ior. Last, we have to analyze the base and aspect
problem diagrams for unwanted interactions, such as
conflicts. The weaving relations and the weaved prob-
lem specifications can support this activity. The result
Informal Requirements
Classify Requirements
Completeness Requirements
Model Weave
input / output
input /
information flow control flow Activity generated automatically generated semi−automatically
Figure 1: The AORE4PF method
of this step are consolidated base and aspect problem
diagrams as well as consolidated weaving relations
and problem specifications. We will discuss all steps
of our method in detail in the following sections.
4.1 Classify Requirements
As a first step, we have to identify and analyze the
requirements 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 and
not cross-cutting, 2) an aspect, which is functional
and cross-cutting, and 3) a quality, which is non-
functional and cross-cutting. Note that we see quality
requirements as requirements, which are not opera-
tionalized to an aspect right now. Hence, there is a
clear relation between qualities and aspects, and we
will later on refine qualities to aspects. Normally,
statements in an informal description are not given
that clear-cut as given by the three discussed classes
of requirements. Hence, one can find requirements
mixing 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) can
support the requirements engineer in this step. This
way we identify R29 as requirement containing two
quality 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 and
confidential information will not be disclosed easily
within communicating systems. Grid systems shall
not be a way to reveal information.
(R29B) Compliance Many countries protect cus-
tomer’s 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-
sistant3can aid the requirements engineer. This way
we identify the following two aspects:
(R28B) Encryption [. . . ] The gateway must be ca-
pable of encrypting communications and data by the
safest and best encryption mechanisms possible.
(R30) Logging The gate shall log the occurring im-
portant events.
Note that while eavesdropping is already formulated
as separate aspect, logging is introduced as new as-
pect that is extracted from R17 and R18 which both
contain the logging aspect:
(R17B) New firmware: Logging The gate shall log
the event of successful verification of a new version
of the firmware.
(R18B) Activate new firmware: Logging The gate-
way shall log the event of deploying a new version of
the firmware.
Thus, we have identified and separated the prelimi-
nary aspect requirements.
The remaining functional requirements form the
base requirements for our system:
(R1) Receive meter data The smart meter gateway
shall receive meter data from smart meters.
(R17A) New firmware The gateway should accept a
new firmware from authorized external entities.
(R18A) Activate new firmware On a predetermined
date the gateway executes the firmware update.
We document the relations between the separated
functional, quality, and aspect requirements in a pre-
liminary cross-cut relation table. These relations are
given in Table 1 with crosses in italic. If a require-
ment is separated into a functional requirement (base
Table 1: Requirements (Cross-Cut) Relation Table for the
Smart Grid Scenario
Quality Aspect
R28A R29A R29B R31 R28B
Base R1 X4X4X4X4X4X4
R17A X4X3X4X
R18A X3X
Quality R28A I7I7I7X
R29A I7I7I7X4
R29B I7I7I7X4X4
R31 I7I7I7X3
or aspect) and a quality, then we add a cross in the
corresponding cell of the table. In Table 1, we doc-
umented that the aspect R28B is related to the quality
R28A. If functional requirements are separated into
base and aspect requirements, then we also add re-
spective crosses. In Table 1, we documented that the
aspect R30 cross-cuts the base requirements R17A and
R18A. 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 requirements
identified in the previous step. For each functional re-
quirement, we create a problem diagram as proposed
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, but
these two problem diagrams are sufficient to under-
stand the rest of the paper, even though we use the five
selected requirements for exemplifying our method.
The problem diagram for R1 is shown in Figure 2 and
explained in Section 3. Figure 3 shows the problem
diagram for R17A. The biddable domain Authorized-
ExternalEntity controls the updateFirmware command ,
which is observed by the connection domain WAN.
The SMGFirmwareStorage controls the phenomenon
storeNewFirmware, which is observed the lexical do-
main FirmwareUpdate. The WAN forwards the firmware
update 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 provide
a reasoning, called frame concern (Jackson, 2001),
why the specification of the submachine together with
the knowledge about the environment (domain knowl-
edge) leads to the satisfaction of the requirement. To
Figure 3: Problem Diagram R17A : New firmware
Figure 4: Sequence diagram for R17A
visualize 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 diagrams
is 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
the sub-machine SMGFirmwareStorage (domain knowl-
edge). The sub-machine then performs a verification
on the received firmware update (specification). In
the case of a successful verification, the new firmware
is stored in the lexical domain FirmwareUpdate (spec-
ification). Hence, the gateway accepts new firmware
from authorized external entities (requirement).
4.3 Identify Underlying Qualities
In order to check whether the cross-cut relation is
complete, we identify for all aspects the software
qualities they address. Note that the relationship be-
tween aspects and qualities is many-to-many. That
is, an aspect can address multiple software qualities.
For example, the logging of system events possibly
addresses 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 software
quality confidentiality could be addressed by the fol-
lowing aspects: encryption, authentication and autho-
rization, and data minimization. For the identification
of underlying qualities tools such as QAMiner (Rago
et al., 2013) can be used. This way we discover that
in our case the aspect R30 has the underlying quality
(R31) Maintainability All events which are useful to
trace a malfunction of the gateway shall be logged.
4.4 Analyze Completeness
Based on the identified qualities, we can re-use
quality-dependent analysis techniques on problem
frames to check the completeness of the cross-cut
relation. For example, for privacy one can use the
ProPAn method (Beckers et al., 2014), for compli-
ance the law (identification) pattern method (Faßben-
der and Heisel, 2013) provides guidance, security is
covered by ongoing work of the group led by Heisel
on PresSuRE4and so forth. These analysis techniques
identify for a given problem frames model and the
respective quality in which functional requirements
the quality has to be considered. At this point of
our method, we have all inputs that the analysis tech-
niques need. Using the results of the analysis tech-
niques, we can update the cross-cut relation and check
whether 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 metered
by the smart meters enables one to analyze what the
persons 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 shows
that the consumption data has to be protected against
eavesdropping (R28A). Maintainability (R31) is also
relevant for R1, as a malfunction can also occur while
receiving consumption data. The compliance anal-
ysis (R29B) reveals and strengthens the importance
of privacy because of different data protection acts.
Additionally, the logging mechanism is not only rel-
evant for maintainability but also for compliance as
several laws require the fulfillment of accountability
requirements whenever there is a contractual relation
between different parties. The already existing as-
pect requirements are sufficient to cover the newly
found relations. This information is used to update
the cross-cut relation table (see Table 1).
4.5 Model Aspect Requirements
To model aspect requirements in a similar way as base
requirements, we extended the UML profile of the
UML4PF tool with aspect-oriented concepts.To dif-
ferentiate aspect requirements, the machines that ad-
dress them, and the diagram they are represented in
from base requirements and their machines and dia-
grams, we introduce the new stereotypes Aspect,
AspectMachine, and AspectDiagram. In addi-
tion to problem diagrams, an aspect diagram has to
contain a set of join points, which together form a
pointcut. These join points can be domains and in-
terfaces. Hence, we introduced the new stereotype
JoinPoint, which can be applied to all specializa-
tions of the UML meta-class NamedElement. During
the weaving, join points are instantiated with domains
Figure 5: Aspect diagram for aspect requirement R28
Figure 6: Sequence diagram for aspect requirement R28
of the problem diagrams the aspect cross-cuts.
To create an aspect diagram, we have to identify
the join points which are necessary to combine the
aspect 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 aspect
machine, as join point in an aspect diagram. This
machine will be instantiated during the weaving with
the machine of the problem diagram that the aspect is
weaved into. The interface between this join point and
the aspect machine describes how a problem machine
can utilize an aspect. We have to define appropriate
interfaces between the aspect machine and the iden-
tified join points, so that the aspect can be combined
with all base requirements in a uniform way. Besides
the specialized stereotypes for the machine and the
requirement, and the definition of join points for the
later weaving, the process of building an aspect di-
agram is similar to the process of building problem
diagrams. As for problem diagrams, we also create a
sequence diagram for each aspect diagram.
For reasons of space, we will only discuss the
aspect requirement R28 in detail. R28 is about the
prevention against eavesdropping attacks in the smart
grid scenario by encrypting all communication. The
corresponding aspect diagram is presented in Fig-
ure 5. It contains the aspect machine SMGEavesdrop-
ping, which has access to the public and private keys
for the encryption and decryption. the keys are stored
in the KeyStorage. Furthermore, the aspect diagram
contains three domains as join points. The machine
SMGRequester will be instantiated by a problem ma-
chine and the interface bdescribes that the problem
machine is able to send a request to SMGEavesdropping
in order to decryptData and encryptData.SMGEaves-
dropping returns decryptedData and encryptedData, re-
spectively. The join points Network and SenderReceiver
are added to refer to the network an attacker may
eavesdrop and the sender or receiver of the data to
be transmitted. Hence, we can have two different
scenarios for the aspect prevent eavesdropping. The
first scenario is concerned with the decryption of data
a problem machine received from a sender, and the
second scenario is concerned with the encryption of
data a problem machine shall send to a receiver. The
sequence diagram for the first scenario is shown in
Figure 6. The sequence diagrams shows that when
the machine SMGRequester receives data from some
sender over an network, it asks the aspect machine
SMGEavesdropping to decrypt the received data (aspect
requirement). Then the aspect machine retrieves the
needed public key from the KeyStorage to decrypt the
data in order to send it back to the machine SMGRe-
quester (specification). The sequence diagram for the
second scenario is built in a similar way, but left out
due to space limitations.
Note that the modularization of the prevention
against eavesdropping into an aspect allows us to eas-
ily change the encryption mechanism if a better and
newer mechanism is available, so that we are able to
encrypt communications and data by the safest and
best encryption mechanisms possible.
4.6 Weave Requirements
For each base requirement, we now create a sequence
diagram that describes how the aspect requirements
have to be weaved into it to address the cross-cut re-
lation. The basis for the weaving sequence diagram is
the sequence diagram of the requirement. The behav-
ior of the sub-machine is extended with the invocation
of 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 base
requirement. The reason is, that the cross-cut relation
does not define how and when an aspect has to be in-
tegrated into the base problem. We create a table for
each base requirement that defines how the aspects
are integrated into the base problem. A row in the ta-
ble consists of a message of the sequence diagram of
the base requirement, a keyword, and the aspect that
shall be weaved into the requirement. For this paper,
we use the keywords before and after, but we plan to
extend this list, to provide more possibilities to inte-
grate aspects into problems. The keyword describes
whether the aspect has to be integrated before or after
the message. If multiple aspects shall be integrated
before or after a message, we have to define the order
in which the aspects are integrated. Table 2 shows the
refined cross-cut relation for base requirement R17A.
Because of the aspect requirement R28 all commu-
nications have to be encrypted to prevent eavesdrop-
Table 2: Refined Cross-cut relation table for R17A
Message Key Aspect Sequence Diagram
after Eavesdropping[WAN/Network,Authorized-
before Logging[SMGFirmwareStorage/SMG-
Figure 7: Weaved sequence diagram for R17A
ping attacks. This implies that all external messages
that 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 requirement
R28 shall be integrated. Additionally, it is defined
that the join points Network,Sender, and SMGRequester
are instantiated with the domains WAN,AuthorizedEx-
ternalEntity, and SMGFirmwareStorage. In this way, we
addressed the concern that external messages have to
be decrypted in the base requirement R28.
The refined cross-cut relations are used to auto-
matically generate the weaving sequence diagrams
from the sequence diagrams of the problem and as-
pect diagrams. These automatically generated se-
quence diagrams have then to be adjusted, such that
the overall behavior satisfies the weaving require-
ment. The generated sequence diagram is shown in
Figure 7. For the sake of readability, we highlighted
the messages from the integrated aspect specifications
using a bold font. The other messages are the mes-
sages from the problem specification, which form the
basis 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 before
the message storeNewFirmwareBase. The latter ad-
dresses the concern that the event of a successful
firmware verification shall be logged (aspect require-
ment R17B). For the presented example, we do not
need further adjustments because it already address
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 this
step. Alebrahim et al. provide methods for interac-
tion analysis using problem frames. In (Alebrahim
et al., 2014b) functional requirements are treated, and
(Alebrahim et al., 2014a) describes how to analyze
quality requirements for interactions. Both works use
the smart grid as case study. Hence, we re-used the
methods and results also for this work. The results
are documented 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 a informal scenario
description and the textual use case descriptions from
the original as input for our method5. The method
was executed by a requirements expert, which did not
know the case before hand. From this information, we
identified 13 base requirements that we modeled in
10 problem diagrams, 8 aspect requirements that we
modeled in 5 aspect diagrams, and 6 quality require-
ments. The effort spent for conducting our method on
the CMS is summarized in Table 5.
To asses the sufficiency of the method and the
used tools, the requirements and qualities found
within our method were compared to the original doc-
ument as described by Kienzle et al. Table 3 shows
the comparison. Overall, the results are satisfying as
most requirements were found and classified in the
correct class (30%) or in an other, also correct, class
(45%). For some specific qualities, such as mobility,
the overall observation cannot be acknowledged. The
reasons are subject to further investigations.
To asses the aspects identified we compared the
results of our method to the results given in other
publications using the same scenario (Landuyt et al.,
2010; Mussbacher et al., 2010). The result of the
comparison is shown in Table 4. Overall, our results
are very similar. The result of our method contains all
requirements which are treated as aspects in the other
5For the inputs and the results see http://imperia.uni- cms report.pdf
Table 3: Requirements identified
1) Functional
2) Availability
3) Reliability
4) Persistence
5) Real-Time
6) Security
7) Mobility
8) Statistic Logging
9) Multi-Access
10) Safety
11) Adaptability
12) Accuracy
13) Maintainability
14) Performance
15) Scalability
Same Class
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%
Other Class
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%
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%
works. And most of these requirements are also sepa-
rated as aspects by our method. Only a minor number
was not treated as aspect, but a detailed investigation
showed that both views on these requirements are rea-
sonable. Some of the aspects our method found were
not mentioned in the other works. Reasons might
be that they were not reported or that they were not
We could not asses our completeness analysis
quantitatively as the other works using the scenario
stick to the original requirements. But the qualitative
investigation of the completeness analysis showed
reasonable results. This observation is also true for
the cross cut relations. We also compared the weaved
specification with sequence diagrams or state ma-
chines given by the original document and works in
(Kienzle et al., 2010). Here we observed that the
specification produced by our method were at least
as good as the chosen assessment artifacts. Again,
the interaction analysis could not be assessed quan-
titatively due to missing benchmarks. But the found
interactions seemed to be real problems which have
to 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 abstraction
than problem frames. Additionally, Goal and use-
case models are stakeholder-centric, while problem
frames are system-centric. Therefore, refining func-
tional requirements taking into account more detail
of the system-to-be and analyzing the system-to-be
described by the functional requirements is reported
to be difficult for such methods(Alrajeh et al., 2009).
Recently, there were papers which reported a success-
ful integration of goal- and problem-oriented methods
(Mohammadi et al., 2013). Hence, one might benefit
of integrating goal-models in our method.
Conejero et al. (Conejero et al., 2010) present a
framework alike the method presented in this paper.
Their process also starts with unstructured textual re-
Table 4: 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 e t al.,2010
Table 5: Effort spent (in person-hours/minutes) for conducting the method
Classify Re-
Model Base
Identify Under-
lying Qualities
Model Aspect
Weave Re-
Analyze In-
Number of
10 base
6 aspect
10 base
5 aspect
10 base
16 functional
per item 11min 36min 7min 7min 34min 23min 6min
Total 5h 00min 6h 3min 45min 1h 15min 2h 51min 3h 53min 1h 45min
quirements. Then different tools and modeling nota-
tions are used along the frame work to identify and
handle aspects. In difference to our process, they do
not consider a completeness or interaction analysis
and especially for the modeling of aspects they lack
tool support.
Only few approaches consider the integration
of 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 the
problem frames approach differs from ours. For an
aspect, the authors first select a problem frame as PF
Pointcut Scenario. This pointcut scenario defines into
which problems the aspect can be integrated. The
pointcut 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 be
a problem frame. This reduces flexibility, because an
aspect (e.g., logging of all system events) may have to
be integrated into different problem diagrams.
7 Conclusions
In this paper, we presented the AORE4PF method
which integrates aspect-orientation and the problem
frames approach. We extended the UML4PF profile
with stereotypes that allow us to create aspect dia-
grams. We further introduced a structured methodol-
ogy to separate aspects from requirements, to model
aspects, and to weave aspects and requirements to-
gether. We considered both the static and the be-
havioral view on the requirements, aspects, and their
weaving. We exemplified our method using a smart
grid scenario from the NESSoS project as case study
and 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 a
quality and the related aspects, 5) a structured method
to 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 into
more already existing methods and analyses based on
UML4PF to cover a broader spectrum of qualities.
Alebrahim, A., Choppy, C., Faßbender, S., and
Heisel, M. (2014a). Optimizing functional and
quality 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 REFSQ, page 16.
Alrajeh, D., Kramer, J., Russo, A., and Uchitel, S.
(2009). Learning operational requirements from
goal models. In ICSE ’09, pages 265–275.
Baniassad, E. and Clarke, S. (2004). Finding aspects
in requirements with Theme/Doc. In Workshop
on Early Aspects at AOSD, pages 15–22.
Beckers, K., Faßbender, S., Heisel, M., and Meis, R.
(2014). A problem-based approach for computer
aided privacy threat identification. In APF 2012,
LNCS, pages 1–16. Springer.
Boehm, B. W. and Papaccio, P. N. (1988). Un-
derstanding and controlling software costs.
IEEE Transactions on Software Engineering,
Cavusoglu, H., Mishra, B., and Raghunathan, S.
(2004). The effect of internet security breach
announcements on market value: Capital market
reactions for breached firms and internet security
developers. Int. J. Electron. Commerce, 9(1):70–
Conejero, J. M., Hernandez, J., Jurado, E., and
van den Berg, K. (2010). Mining early aspects
based on syntactical and dependency analyses.
Science of Computer Programming.
e, I., Hatebur, D., Heisel, M., and Schmidt, H.
(2011). UML4PF - a tool for problem-oriented
requirements analysis. In RE, pages 349–350.
IEEE Computer Society.
Faßbender, S. and Heisel, M. (2013). From prob-
lems to laws in requirements engineering using
model-transformation. In ICSOFT ’13, pages
447–458. SciTePress.
Firesmith, D. (2003). Specifying good requirements.
Journal of Object Technology, 2(4):77–87.
Grundy, J. C. (1999). Aspect-oriented requirements
engineering for component-based software sys-
tems. In RE ’99, pages 84–91, Washington, DC,
USA. IEEE Computer Society.
Hatebur, D. and Heisel, M. (2010). A UML profile for
requirements analysis of dependable software. In
SAFECOMP, pages 317–331.
Hofmann, H. and Lehner, F. (2001). Require-
ments engineering as a success factor in software
projects. IEEE Software, 18(4):58–66.
Jackson, M. (2001). Problem Frames. Analyzing
and structuring software development problems.
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 the
stock market value of healthcare institutions, and
information 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 for
aspect-oriented modeling. In Katz, S., Mezini,
M., and Kienzle, J., editors, Transactions on
Aspect-Oriented Software Development VII, vol-
ume 6210 of LNCS, pages 1–22. Springer Berlin
Landuyt, D., Truyen, E., and Joosen, W. (2010). Dis-
covery of stable abstractions for aspect-oriented
composition in the car crash management do-
main. In Transactions on Aspect-Oriented Soft-
ware Development VII, volume 6210 of LNCS,
pages 375–422. Springer Berlin Heidelberg.
Lencastre, M., Moreira, A., Ara´
ujo, J., and Castro, J.
(2008). Aspects composition in problem frames.
In RE, 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 CD-ARES ’13, pages 272–288.
Moreira, A., Arajo, J., and Rashid, A. (2005).
A concern-oriented requirements engineering
model. In Pastor, O. and Falco e Cunha, J., ed-
itors, Advanced Information Systems Engineer-
ing, volume 3520 of LNCS, pages 293–308.
Springer Berlin Heidelberg.
Moser, T., Winkler, D., Heindl, M., and Biffl, S.
(2011). Requirements management with seman-
tic technology: An empirical study on automated
requirements categorization and conflict analy-
sis. In Advanced Information Systems Engineer-
ing, LNCS, pages 3–17. Springer.
Mussbacher, G., Amyot, D., Arajo, J., and Mor-
eira, A. (2010). Requirements modeling with
the aspect-oriented user requirements notation
(aourn): A case study. In Transactions on
Aspect-Oriented Software Development VII, vol-
ume 6210 of LNCS, pages 23–68. Springer
Berlin Heidelberg.
OPEN meter project (2009). Requirements of AMI.
Technical report, OPEN meter project.
Parnas, D. L. (1972). On the criteria to be used in
decomposing systems into modules. Commun.
ACM, 15(12):1053–1058.
Rago, A., Marcos, C., and Diaz-Pace, J. A. (2013).
Uncovering quality-attribute concerns in use
case specifications via early aspect mining. Re-
quirements Engineering, 18(1):67–84.
Rashid, A. (2008). Aspect-oriented requirements en-
gineering: An introduction. In RE, pages 306–
Sampaio, A., Rashid, A., Chitchyan, R., and Rayson,
P. (2007). Ea-miner: Towards automation in
aspect-oriented requirements engineering. In
Transactions on Aspect-Oriented Software De-
velopment III, 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 on
Aspect-oriented Software Development, AOSD
’02, pages 127–133, New York, NY, USA. ACM.
Whittle, J. and Araujo, J. (2004). Scenario mod-
elling with aspects. Software, IEE Proceedings,
Willis, R. (1998). Hughes Aircraft’s Widespread De-
ployment of a Continuously Improving Software
Process. AD-a358 993. Carnegie-Mellon Uni-
Yu, Y., Cesar, J., Leite, S. P., and Mylopoulos, J.
(2004). From goals to aspects: Discovering as-
pects from requirements goal models. In Int. RE
Conf., pages 38–47. Society Press.
... Integration To integrate controls into the requirements model, we make use of an aspect-oriented approach that has been proposed by Faßbender et al. [15]. For each control, we provide an aspect diagram which has a similar notation as problem diagrams. ...
... encryption mechanisms. To integrate controls into the requirements model, we follow an aspect-oriented approach for problem frames [15]. As input for this step, we consider the problem diagram related to the threat scenario and the aspect diagram given in the control description. ...
Due to the increasing number of security incidents in the last years, the consideration of security during software development becomes more and more important. A certain level of security can be achieved by applying suitable countermeasures. The ISO 27001 standard demands a risk-based selection of countermeasures, i.e. controls, for information security. Risk serves as a prioritization criterion for selecting controls. To reduce the development effort, security should be addressed as early as possible in the software development lifecycle.
... To link controls to functional requirements, we make use of an aspect-oriented approach [4,5,17] which is based on Jackson's problem frames approach [13]. In our template, a control is considered as an early aspect which can systematically be integrated into the requirements model to ensure traceability and consistency. ...
... In the present paper, we consider controls as cross-cutting concerns, also known as aspects. Faßbender et al. [4] proposed a method called AORE4PF to model such aspects with problem diagrams. ...
Conference Paper
Threats that harm the security of software become more and more frequent. Such incidents can lead to substantial damage, not only financially, but also in terms of reputation loss. The combination of that consequence and the likelihood of an incident is called risk. Risk management processes describe coordinated activities to identify, evaluate and treat those risks. To reduce costs, it is necessary to concentrate on the most severe risks and to address those risks as early as possible by following the principle of security-by-design. In this paper, we introduce a template that enables security analysts to specify controls to treat risks in a systematic manner. Instances of the template make knowledge about controls reusable in future development projects. We designed our template for an application during requirements engineering. Our aim is to bridge the gap between functional requirements engineering and security. To do so, we consider controls as early aspects and relate them to relevant functional requirements and threats which can be treated by the control. Our template makes explicit how those aspects can be integrated into a requirements model by using a problem-based approach. To simplify the evaluation of controls, we adapt the concept of the Common Vulnerability Scoring System. The defined attributes will later allow a semi-automatic suggestion and evaluation of suitable controls.
... • The concern is not a module: in modular-based software development, a module is a concrete component or class that contains detailed specification and implementation of its instructions. However, the concern can be described by one or more modules in the system, e.g., the stakeholder may request the system to be fast in response to certain actions (Faßbender, Heisel & Meis, 2014) (Albahar, 2015). ...
Requirements Engineering (RE) is a discipline that is concerned with the identification, handling, and specification of user and system requirements. It is the most important early stage of any software development project as it forms the foundation of the later stages in software development. Overlooked errors in RE can have a strong impact on the success of any software project in terms of time, effort, and budget. Traditional RE approaches suffer from the Tyranny of the Dominant Decomposition, which generates a description of requirements that are scattered throughout the system and tangled within its defining scope. These descriptions are called cross-cutting concerns, which are called aspects, and they are responsible for producing inconsistencies and duplicated implementations of features or behavior. Aspects are modularized implementation of crosscutting concerns. Aspect-Oriented Requirements Engineering (AORE) has emerged as a field that is directly responsible for identifying and specifying aspectual requirements as early as possible in software development. Approaches and techniques have been developed to adapt the aspect notion in the early stages. However, these proposals focus more on the identification of aspectual requirements and ignore the efforts to validate them. Therefore, this study investigates the problem of validating aspectual requirements. It demonstrates how to decompose each artifact, which might be a requirement or viewpoint, into concern as well as how to conduct two levels of validation on the resulting artifacts. A concern handling mechanism is introduced. The first level is to validate the cross-cutting relationship and its concerns in a semi-formal fashion. The second level is to validate the aspectual requirements with a checklist designed specifically to be handled by developers. The proposed solution is used to evaluate the resulting artifacts from other existing approaches based on viewpoint-XML and Theme/Doc. The results have been encouraging and prove that the proposed solution is valid.
... Faßbender et al. [5] describe a method to combine aspects with problem frames. Aspects are considered as cross-cutting concerns for different requirements. ...
Scenarios in which the security of software-based systems is harmed become more and more frequent. Such scenarios can lead to substantial damage, not only financially, but also in terms of loss of reputation. Hence, it is important to consider those threats to security already in the early stages of software development. However, it is non-trivial to identify all of them in a systematic manner. In particular, the knowledge about threats is not documented in a consistent manner. The Common Vulnerability Scoring System is a well known way to characterize vulnerabilities in a structured way. Our idea is to document threats in a similar way, using a template. A distinguishing feature of our approach is that we relate the threats to the envisaged functionality of the software. Our contribution is two-fold: first, we propose a general template to describe security threats that can be used in the early stages of software development. Second, we define a systematic and semi-automatic procedure to identify relevant threats for a software development project, taking the functionality of the software-to-be into account.
... Moreover, Problem Frames models have a semi-formal structure, which allows an (semi -automated) analysis of different qualities, such as, for example, privacy [9], security [10], and compliance with laws and standards [11,12], and an (semi -automated) interaction analysis for functional [13] as well as quality [14] requirements. Additionally, several topics such as aspect-orientation [15], variability [16], and requirements reconciliation and optimization [14] can be treated if necessary. Last but not least, Problem Frame models allow a seamless transition to the architecture and design phase [17]. ...
Conference Paper
Full-text available
An increase of process awareness within organizations and advances in IT systems led to a development of process-aware information systems (PAIS) in many organizations. UPROM is developed as a unified BPM methodology to conduct business process and user requirements analysis for PAIS in an integrated way. However, due to the purpose, granularity and form of UPROM artifacts, one cannot analyze the software requirements in detail with (semi-)formal methods for properties such as completeness, compliance and quality. In contrast, Problem Frames modeled using the UML4PF tool can be used for such analysis. But using the Problem Frames notation and corresponding methods alone does not cover a direct support for building a PAIS. Hence, in this work we propose to integrate UPROM and UML4PF using model transformation. We use eCompany, a project which is part of an e-government program, as running example.
... For reasons of space, we will only discuss the aspect requirement R30 in detail. The aspect R28B and the sequence diagram for the decryption of received data is described in [12]. R30 covers the logging of important events in the system. ...
Conference Paper
Full-text available
Requirements engineers not only have to cope with the requirements of various stakeholders for complex software systems, they also have to consider several software qualities (e.g., performance, maintainability, security, and privacy) that the system-to-be shall address. In such a situation, it is challenging for requirements engineers to develop a complete and coherent set of requirements for the system-to-be. Separation of concerns has shown to be one option to handle the complexity of systems. The problem frames approach address this principle by decomposing the problem of building the system-to-be into simpler subproblems. Aspect-orientation aims at separating cross-cutting functionalities into separate functionalities, called aspects. We propose a method called AORE4PF, which shows that aspect-orientation can be integrated into the problem frames approach to increase the separation of concerns and to benefit from several methods that exist on problem frames to develop a complete and coherent set of requirements. We validated our method with a small experiment in the field of crisis management.
Conference Paper
Cross-cutting concerns often arise when non-functional requirements are operationalized, because non-functional requirements are themselves cross-cutting. In the field of aspect-oriented requirements engineering (AORE), functional requirements that cross-cut multiple other functional requirements are called aspects. An aspect describes in most cases a solution for a non-functional requirement and how this solution can be integrated into the realization of the functional requirements it cross-cuts. Examples for cross-cutting concerns are logging, encryption, and access control. We observed that aspects often share a basic structure, behavior, and the way of how they have to be integrated into the realization of the functional requirements they cross-cut. We propose in this paper aspect frames. An aspect frame is a kind of pattern for aspects that share a common concern, behavior, and way how they are integrated into the realization of the functional requirements they cross-cut. These aspect frames support requirements engineers to describe concrete aspects that fit to an aspect frame.
Conference Paper
Full-text available
Recently, there has been an increase of reported privacy threats hitting large software systems. These threats can originate from stakeholders that are part of the system. Thus, it is crucial for software engineers to identify these privacy threats, refine these into privacy requirements, and design solutions that mitigate the threats. In this paper, we introduce our methodology named Problem-Based Privacy Analysis (ProPAn). The ProPAn method is an approach for identifying privacy threats during the requirements analysis of software systems using problem frame models. Our approach does not rely entirely on the privacy analyst to detect privacy threats, but allows a computer aided privacy threat identification that is derived from the relations between stakeholders, technology, and personal information in the system-to-be. To capture the environment of the system, e.g., stakeholders and other IT systems, we use problem frames, a requirements engineering approach founded on the modeling of a machine (system-to-be) in its environment (e.g. stakeholders, other software). We define a UML profile for privacy requirements and a reasoning technique that identifies stakeholders, whose personal information are stored or transmitted in the system-to-be and stakeholders from whom we have to protect this personal information. We illustrate our approach using an eHealth scenario provided by the industrial partners of the EU project NESSoS.
Conference Paper
Full-text available
[Context] The ability to address the diverse interests of different stakeholders in a software project in a coherent way is one fundamental software quality. These diverse and maybe conflicting interests are reflected by the requirements of each stakeholder. [Problem] Thus, it is likely that aggregated requirements for a software system contain interactions. To avoid unwanted interactions and improve software quality, we propose a structured method consisting of three phases to find such interactions. [Principal ideas] For our method, we use problem diagrams, which describe requirements in a structured way. The information represented in the problem diagrams is translated into a formal Z model. Then we reduce the number of combinations of requirements, which might conflict. [Contribution] The reduction of requirements interaction candidates is crucial to lower the effort of the in depth interaction analysis. For validation of our method, we use a real-life example in the domain of smart grid.
Full-text available
Quality-attribute requirements describe constraints on the development and behavior of a software system, and their satisfaction is key for the success of a software project. Detecting and analyzing quality attributes in early development stages provides insights for system design, reduces risks, and ultimately improves the developers’ understanding of the system. A common problem, however, is that quality-attribute information tends to be understated in requirements specifications and scattered across several documents. Thus, making the quality attributes first-class citizens becomes usually a time-consuming task for analysts. Recent developments have made it possible to mine concerns semi-automatically from textual documents. Leveraging on these ideas, we present a semi-automated approach to identify latent quality attributes that works in two stages. First, a mining tool extracts early aspects from use cases, and then these aspects are processed to derive candidate quality attributes. This derivation is based on an ontology of quality-attribute scenarios. We have built a prototype tool called QAMiner to implement our approach. The evaluation of this tool in two case studies from the literature has shown interesting results. As main contribution, we argue that our approach can help analysts to skim requirements documents and quickly produce a list of potential quality attributes for the system.
Full-text available
Quality requirements, like security requirements, are difficult to elicit, especially if they cross multiple domains. Understanding these domains is an important issue in the requirements engineering process for the corresponding systems. Well-known requirements engineering approaches, such as goal-oriented techniques provide a good starting point in capturing security requirements in the form of soft-goals in the early stage of the software engineering process. However, such approaches are not sufficient for context and problem analysis. On the other hand, the context and problem modeling approaches like e.g., problem frames, do not address the system goals. Integrating the relevant context knowledge into goal models is a promising approach to address the mutual limitations. In this paper, we propose a framework for combining goal models and problem frames. The framework makes it possible to document the goals of the system together with the corresponding knowledge of the system’s context. Furthermore, it supports the process of refining (soft-) goals right up to the elicitation of corresponding security requirements. To show the applicability of our approach, we illustrate its application on a real-life case study concerning Smart Grids.
Conference Paper
Nowadays, many legislators decided to enact different laws, which all enforce legal and natural persons to deal more carefully with IT systems. Hence, there is a need for techniques to identify and analyze laws, which are relevant for an IT system. But identifying relevant compliance regulations for an IT system and aligning it to be compliant to these regulations is a challenging task. In earlier works of ours we proposed patterns and a structured method to tackle these problems. One of the central crucial steps, while using the patterns and the method, is the transformation of requirements into a structure, allowing the identification of laws. The step is not trivial, as requirements, in most cases, focus on the technical parts of the problem, putting the knowledge about the environment of the system aside. In this work, we propose a method to structure the requirements, elicit the needed domain knowledge and transform requirements into law identification pattern instances. For this purpose, we make use of problem diagrams, problem frames, domain knowledge, and questionnaire. We present our method using a voting system as an example, which was obtained from the ModIWa DFGa project and the common criteria profile for voting systems.
High-quality software has to consider various quality issues and different stakeholder goals. Such diverse requirements may be conflicting, and the conflicts may not be visible at first sight. We propose a method to obtain an optimal set of requirements that contains no conflicts and satisfies the stakeholder goals and quality requirements to the largest possible extent. We first capture the stakeholders’ goals and then analyze functional and quality requirements using an extension of the problem frame approach. To obtain an optimal set of requirements, we first determine candidates for requirements interaction. For negatively interacting requirements, we derive alternatives in a systematic way. To prepare for the optimization, we need to assign values to the different requirements. To determine those values, we apply the Analytic Network Process (ANP). Finally, we use existing optimizer tools to obtain a set of requirements that has a maximal value with respect to the previously determined values, and that does not contain any conflicting requirements. We illustrate our method with the real-life example of smart metering.
Title 1 of the Health Insurance Portability and Accountability Act (HIPAA) was enacted to improve the portability of healthcare insurance coverage and Title II was intended to alleviate fraud and abuse. The development of a health information system was suggested in Title II of HIPAA as a means of promoting standardization to improve the efficiency of the healthcare system and ensure that electronic healthcare information is transferred securely and kept private. Since the legislation places the onus of providing the described improvements on healthcare institutions and part of these requirements relate to information technology (IT) and information security (IS), the process of complying with the legislation will necessitate acquiring products and services from IT/IS firms. From the viewpoint of stock market analysts, this increase in demand for IT/IS products and services has the potential to boost the profitability of public IT/IS firms, in turn positively enhancing their stock market valuation. Following the same logic, the legislation's compliance burdens shared by healthcare firms are expected to require hefty costs, thus potentially reducing the profitability of healthcare firms and reflecting negatively on their stock price. The intent of this paper is to evaluate the stock market reaction to the introduction of HIPAA legislation by evaluating the abnormal movement in the price of the stock of public healthcare institutions, IT, and IS firms. We conduct event-study analyses around the announcement dates of the various provisions of HIPAA. An event study is a standard statistical methodology used to determine whether the occurrence of a specific event or events results in a statistically significant reaction in financial markets. The advantage of the event study methodology for policy analysis is that it provides an anchor for determining value, which eliminates reliance on ad hoc judgments about the impact of specific events or policies on stock prices. While event studies have been conducted that examine the market effect of security and privacy breaches on firms, none has attempted to determine the impact, in terms of resulting market reaction, of the HIPAA legislation itself. The results of the study confirm the logic above, while also providing insight into specific stages of the legislative path of HIPAA.
The central idea of this book is to use problem frames in problem analysis and structure. They help you by defining different simple problem classes. When you structure a larger, realistic, problem, you choose the subproblems so that each one is a problem of the simple kind defined by some problem frame. Then, when you analyse the subproblem, you see what concerns it raises according to the problem frame that fits it. The frame shows you what you must do to solve it. A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions. They do this by emphasising the world outside the computer, the effects that are required there, and the relationships among things and events of the world by which your customer will ultimately judge whether those effects have been achieved.