Kristian Beckers

Maritta Heisel

A Foundation for Requirements Analysis of Privacy Preserving Software *

Keywords: privacy, common criteria, compliance, requirements engineering

Privacy requirements are difficult to elicit for any given software engineering project that processes personal information. The problem is that these systems require personal data in order to achieve their functional requirements and privacy mechanisms that constrain the processing of personal information in such a way that the requirement still states a useful functionality. We present privacy patterns that support the expression and analysis of different privacy goals: anonymity, pseudonymity, unlinkability and unobservability. These patterns have a textual representation that can be instantiated. In addition, for each pattern, a logical predicate exists that can be used to validate the instantiation. We also present a structured method for instantiating and validating the privacy patterns, and for choosing privacy mechanisms. Our patterns can also be used to identify incomplete privacy requirements. The approach is illustrated by the case study of a patient monitoring system.

Introduction

Westin defines privacy as "the claim of individuals, groups, or institutions to determine for themselves when, how, and to what extent information about them is communicated to others" [START_REF] Westin | Privacy and Freedom[END_REF]. A number of guidelines for privacy are available. The Fair Information Practice Principles -or short FIPs) [START_REF]OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data[END_REF] -are widely accepted, which state that a person's informed consent is required for the data that is collected, collection should be limited for the task it is required for and erased as soon as this is not the case anymore. The collector of the data shall keep the data secure and shall be held accountable for any violation of these principles. The FIPs were also adapted into the Personal Information Protection and Electronic Documents Act in Canada's private-sector privacy law. In the European Union the EU Data Protection Directive, Directive 95/46/EC, does not permit processing personal data at all, except when a specific legal basis explicitly allows it or when the individuals concerned consented prior to the data processing [3]. The U.S. have no central data protection law, but separate privacy laws, e.g., the Gramm-Leach-Bliley Act for financial information, the Health Insurance Portability and Accountability Act for medical information, and the Children's Online Privacy Protection Act for data related to children [START_REF] Hansen | Privacy and Identity Management[END_REF]. These legal guidelines must be implemented by any given software system for which the guidelines apply.

However, in order to comply with these guidelines the privacy requirements for a given software system have to be elicited. In order to do this we have to formulate specific privacy goals. We use two distinct approaches that specify privacy terms that can used for this purpose, namely the terminology by Pfitzmann and Hansen [START_REF] Pfitzmann | A terminology for talking about privacy by data minimization: Anonymity, unlinkability, unobservability, pseudonymity, and identity management -version v0[END_REF] and the privacy specification in the ISO 15408 standard -Common Criteria for Information Technology Security Evaluation (or short CC) [START_REF]ISO and IEC: Common Criteria for Information Technology Security Evaluation -Part 2 Security functional components[END_REF]. Pfitzmann and Hansen [START_REF] Pfitzmann | A terminology for talking about privacy by data minimization: Anonymity, unlinkability, unobservability, pseudonymity, and identity management -version v0[END_REF] introduced a terminology for privacy via data minimization. They define central terms of privacy using items of interest (IOIs) , e.g., subjects, messages and actions. Anonymity means that a subject is not identifiable within a set of subjects, the anonymity set. Unlinkability of two or more IOIs means that within a system the attacker cannot sufficiently distinguish whether these IOIs are related or not. Undetectability of an IOI means that the attacker cannot sufficiently distinguish whether it exists or not. Unobservability of an IOI means undetectability of the IOI against all subjects uninvolved in it and anonymity of the subject(s) involved in the IOI even against the other subject(s) involved in that IOI. A pseudonym is an identifier of a subject other than one of the subject's real names. Using pseudonyms means pseudonymity. The CC contains the privacy requirements anonymity, pseudonymity, unlinkability, and unobservability [6, pp. 118-125].

In this paper, we provide patterns for these privacy requirements, building on the problem frame terminology, and we explain the difference between the privacy notions in the CC and the Pfitzmann and Hansen terminology.

The rest of the paper is organized as follows. Section 2 presents the problem frame approach, and Sect. 3 explains how to work with privacy patterns. We introduce our patterns in Sect. 4 and illustrate them using a case study. Section 5 contains related work, and Sect. 6 concludes.

Problem Frames

We use a problem frames approach to build our privacy patterns on, because problem frames are an appropriate means to analyze not only functional, but also dependability and other quality requirements [START_REF] Hatebur | A foundation for requirements analysis of dependable software[END_REF][START_REF] Alebrahim | A method to derive software architectures from quality requirements[END_REF].

Problem frames are a means to describe software development problems. They were proposed by Jackson [START_REF] Jackson | Problem Frames. Analyzing and structuring software development problems[END_REF], 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, interfaces and requirement.". It is described by a frame diagram, which consists of domains, interfaces between them, and a requirement. We describe problem frames using class diagrams extended by stereotypes as proposed by Hatebur and Heisel at Safecomp 2010 [START_REF] Hatebur | A UML profile for requirements analysis of dependable software[END_REF](see Fig. 1). All elements of a problem frame diagram act as placeholders, which must be instantiated to represent concrete problems. Doing so, one obtains a problem description that belongs to a specific kind of problem.

The class with the stereotype machine represents the thing to be developed (e.g., the software). The other classes with some domain stereotypes, e.g., CausalDomain or BiddableDomain represent problem domains that already exist in the application environment. Domains are connected by interfaces consisting of shared phenomena. Shared phenomena may be events, operation calls, messages, and the like. They are observable by at least two domains, but controlled by only one domain, as indicated by an exclamation mark. These interfaces are represented as associations, and the name of the associations contain the phenomena and the domains controlling the phenomena.

Jackson distinguishes the domain types CausalDomains that comply with some physical laws, LexicalDomains that are data representations, and BiddableDomains that are usually people. According to Jackson, domains are either designed, given, or machine domains. The domain types are modeled by the subclasses BiddableDomain, CausalDomain, and LexicalDomain of the class Domain. A lexical domain is a special case of a causal domain. This kind of modeling allows one to add further domain types, such as DisplayDomains as introduced in [START_REF] Côté | A systematic account of problem frames[END_REF] (see Fig. 1).

Problem frames support developers in analyzing problems to be solved. They show what domains have to be considered, and what knowledge must be described and reasoned about when analyzing the problem in depth.

Software development with problem frames proceeds as follows: first, the environment in which the machine will operate is represented by a context diagram. Like a frame diagram, a context diagram consists of domains and interfaces. However, a context 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 domains, phenomena, and interfaces. The instantiated frame diagram is called a problem diagram.

Since the requirements refer to the environment in which the machine must operate, the next step consists in deriving a specification for the machine (see [START_REF] Jackson | Deriving specifications from requirements: an example[END_REF] for details). The specification describes the machine and is the starting point for its construction.

Working with Privacy Patterns

We developed a set of patterns for expressing and analyzing privacy requirements, which are presented in more detail in Sect. 4. An important advantage of these patterns is that they allow privacy requirements to be expressed without anticipating solutions. For example, we may require data to be anonymized before these are transmitted without being obliged to mention k-Anonymity [START_REF] Sweeney | Achieving k-anonymity privacy protection using generalization and suppression[END_REF], which is a means to achieve anonymity.

The benefit of considering privacy requirements without reference to potential solutions is the clear separation of problems from their solutions, which leads to a better We provide a method for privacy requirements elicitation using our privacy patterns. The entire method is depict in Fig. 2. This approach helps to elicit and complete privacy requirements within a given software engineering process. We use the resulting set of requirements to choose privacy-enhancing mechanisms.

The first step in our method is to describe the environment, because privacy requirements can only be guaranteed for a specific intended environment. For example, a software may preserve privacy of its users in a social media setting, where it is only exchanging information about concert tickets, but not for a medical setting exchanging more sensible information about the health status of its stakeholders. This step results in a context diagram (see Sect. 2) of the intended software system.

We apply our patterns after a privacy threat analysis has been conducted, e.g., according to the PIA method of the Australian Government [START_REF]Privacy Impact Assessment Guide[END_REF], and functional requirements of the system have been elicited. The requirements describe how the environment should behave when the machine is in action. The description of the requirements must consist of domains and phenomena of the environment description. The functional requirements and privacy threats, as well as our privacy patterns are used to instantiate privacy patterns. For each privacy threat, a textual representation of a privacy pattern is instantiated using the context diagram. This results in an initial set of privacy requirements. These are linked to the previously described functional requirements.

The next step is to validate the instantiated privacy patterns using the corresponding privacy predicates. Our privacy requirements patterns are expressed in natural language and logical predicates. The natural text has parts written in bold, which have to be instantiated with domains of a context diagram for the system. These present a structured analysis of the required elements in order to specify the requirement. In addition, the logical predicates refer to domain types in a context diagram that have a kind-of relationship to the domains in the natural language pattern. This allows us to check if the instantiated domains have the correct domain types.

Privacy requirements are separated from functional requirements. On the one hand, this limits the number of patterns; on the other hand, it allows one to apply these pat-terns to a wide range of problems. For example, the functional requirements for data transmission or automated control can be expressed using a problem diagram. Privacy requirements for anonymity, unlinkability, unobservability, and pseudonymity can be added to that description of the functional requirement, as shown in Sect. [START_REF] Hansen | Privacy and Identity Management[END_REF].

The predicate patterns are expressed using the domain types of the meta-model described in Figure 1, i.e., Domain, BiddableDomain, CausalDomain, and Lexical-Domain. From these classes in the meta-model, subclasses with special properties are derived. We explain the domain types that are relevant for this step in the method:

-A Stakeholder is a BiddableDomain (and in some special cases also a CausalDomain) with some relation to stored or transmitted personal information. It is not necessary that a stakeholder has an interface to the machine. -A CounterStakeholder is a BiddableDomain that describes all subjects (with their equipment) who can compromise the privacy of a Stakeholder at the machine. We do not use the term attacker here, because the word attacker indicates a malicious intent. Privacy of stakeholders can also be violated by accident. -PersonalInformation is a CausalDomain or LexicalDomain that represents personal information about a Stakeholder. The difference between these domains is that a LexicalDomain describes just the stored information, while a CausalDomain also includes the physical medium the data is stored upon, e.g., a hard drive. -StoredPersonalInformation is PersonalInformation, which is stored in a fixed physical location, e.g., a hard drive in the U.S. -TransmittedPersonalInformation is PersonalInformation, which is transmitted in-between physical locations, e.g., data in a network that spans from Germany to the U.S. -InformationAboutPersonalInformation is is a CausalDomain or LexicalDomain that represents information about PersonalInformation, e.g., the physical location of the name and address of a stakeholder.

The check if privacy requirements are complete is a check that all the textual gaps are instantiated. For example, a requirement that has to be instantiated with a Stakeholder has to name an instance of a biddable domain from the context diagram, e.g., Patients.

Several privacy patterns require instantiation with sets of biddable domains. For example, a privacy pattern might not only be directed towards Patients, but also towards Visitors of patients. In this case we can reason for all biddable domains in the context diagram if they are a Stakeholder or not.

In addition, a requirement might be missing, e.g. because of an incomplete threat analysis. In order to execute this check all personal information in the system has to be elicited. For each CausalDomain or LexicalDomain, we have to check if these are StoredPersonalInformation, TransmittedPersonalInformation or InformationAbout-PersonalInformation. If this is the case, we check if these were considered in the privacy threat analysis. If this is not the case, we have to re-do the privacy threat analysis and start our process again.

The last step of our approach is to choose a privacy mechanism that solves the problem. For example, to achieve pseudonymity, a privacy-enhancing identity management systems [START_REF] Clauß | Privacy enhancing identity management: protection against re-identification and profiling[END_REF] can be chosen.

Privacy Patterns

We illustrate our method with the development of a patient monitoring system (PMS), which monitors the vital signs of patients, reports these to physicians and nurses, and controls an infusion flow according to specified rules. The context diagram of the system is shown in Fig. 3. The configuration is stored in a database of the system, as well as the monitoring data of each patient over time and the medical history of each patient. This history shall help physicians to determine the correct settings for the PMS. Nurses and physician have access to alarm messages of the system and the information about the vital signs of patients. An administrator has access to the system for maintenance purposes. The system also allows a remote access for the vendor in order to receive status messages and send updates or repair the system. In addition, the system provides information of monitored data to researchers. The privacy threat to be avoided is that a counterstakeholder reveals personal information of the patient to one or more unauthorized persons. 1 Examples for the described environment are the properties of the infusion pump and the heartbeat and O2 flow sensors. Further examples are the assumed opportunities of a counterstakeholder to gather personal information about patients and to distribute it. A possible counterstakeholder can be a stakeholder of the system. In addition, we assume here that a counterstakeholder, who is not also a stakeholder of the system, can only access the WAVE/WLAN interface. Stakeholders and counterstakeholders are biddable domains in the context diagram shown in Fig. 3. The elicitation of stakeholders and counterstakeholders from biddable domains is part of the instantiation process. Hence, the reasoning of which biddable domain is either a stakeholder or counterstakeholder or both is essential. The information from the privacy threat serves as a support in this task. The functional requirement of the PMS is to keep the infusion flow controlled according to the configuration. We instantiate privacy requirements as a next step. We describe privacy patterns as textual patterns. The parts of the pattern's textual description printed in bold and italics should be instantiated according to the concrete problem. Hence, the instantiation should use only domains from the context diagram. We complement the textual description of the patterns with predicates. They must be described in such a way that it is possible to demonstrate that the privacy predicate holds for all objects of this class. The instantiated predicates are helpful to analyze conflicting requirements and the interaction of different privacy requirements, as well as for finding missing privacy requirements.

R1

Anonymity

For the functional requirement R4, we formulate a privacy requirement for anonymity. The textual pattern for anonymity requirements is:

Preserve anonymity of Stakeholders and prevent disclosure of their identity by CounterStakeholders.

The privacy requirement pattern can be expressed by the anonymity predicate:

anon cs : BiddableDomain × P BiddableDomain → Bool
The suffix "cs" indicates that this predicate describes a requirement considering a certain CounterStakeholder. The definition of anonymity by Pfitzmann and Hansen [START_REF] Pfitzmann | A terminology for talking about privacy by data minimization: Anonymity, unlinkability, unobservability, pseudonymity, and identity management -version v0[END_REF] states that a stakeholder shall not be identifiable from a set of stakeholders. This is the so-called anonymity set, which is represented in our pattern by a biddable domain and in turn a specific type of biddable domain called Stakeholder. We interpret a domain according to Jackson [START_REF] Jackson | Problem Frames. Analyzing and structuring software development problems[END_REF] also as a set. Hence, all the persons that are Stakeholders used to instantiate the anonymity pattern form the anonymity set. The second argument of the predicate anon cs must be instantiated with a set of biddable domains, because we might have more than one kind of counterstakeholder. We analyze the context diagram (see Fig. 3) for counterstakeholders that might gain personal information using the Re-moteAccessTerminal. This leads to the Researcher.

Preserve anonymity of Patients and prevent disclosure of their identity by Researchers.

In this case all instances of Patients are elements of the anonymity set. We validate the instantiated privacy pattern by checking if predicate is instantiated with domains belonging to the required domain types: The Patient is a biddable domain and the Researcher is also a biddable domain, which forms the only member of the set of counterstakeholder. Hence, the anonymity predicate is instatiated in a type-correct way. As a next step we check if the privacy requirement is complete.

The counterstakeholders are a set of biddable domains. This demands that we inspect the context diagram (see Fig. 3) again for further possible counterstakeholders. Another biddable domain has access to the RemoteAccessTerminal, the Vendor. Therefore, we add the Vendor to the list of counterstakeholders. We choose a privacy mechanism as a final step for anoymity, e.g., based upon the work in [START_REF] Cormode | Anonymized data: generation, models, usage[END_REF].

anon cs : Patients × {Researcher , Vendor } → Bool
Common Criteria The common criteria divides requirements for anonymity into two categories. The first one is just called anonymity and the second one is a refinement of the first and called anonymity without soliciting information. The first demands from a privacy mechanism that it shall ensure that a set of "users" or "subjects" are unable to determine the "real name" related to a set of "subjects or operations or objects" [6, p. 119]. This demand is similar to the requirement above. The set of users is translated into CounterStakeholders and subjects are Stakeholders. The second kind of anonymity the CC considers is the so-called "anonymity without soliciting information" about the real user name for a set of services and subjects [6, p. 119]. This requirement needs the first requirements as a prerequisite.

We formulate an anonymity without soliciting personal information requirement : Preserve anonymity of Stakeholders via not soliciting personal information via ConstrainedDomains and, thus, prevent disclosure to certain Counter-Stakeholders.

where a ConstrainedDomain is a CausalDomain or a ConnectionDomain that is constrained by a functional or privacy requirement. The privacy requirement pattern can be expressed by the anonymity without soliciting personal information predicate:

anonCC cs : BiddableDomain × P LexicalDomain × P ConstrainedDomain →Bool
The first kind anonymity requirement of the CC is instantiated with the requirement stated above. We instantiate also the textual pattern for the second kind of requirement using the context diagram. We instantiate the ConstrainedDomain with the RemoteAc-cessTerminal and the personal information with MedicalHistory:

Preserve anonymity of Patients via not soliciting MedicalHistory via RemoteAc-cessTerminal and, thus, prevent disclosure to Researchers and Vendors.

Unlinkability

The textual pattern for unlinkability requirements is:

Preserve unlinkability of two or more ConstrainedDomains for Stakeholders and prevent CounterStakeholders of disclosing that the ConstrainedDomains have a relation to the Stakeholder.

The privacy requirement pattern can be expressed by the unlinkability predicate:

unlink cs : P CausalDomain × BiddableDomain × P BiddableDomain →Bool
We also instantiate privacy requirements for the functional requirement R3. The following privacy requirement for unlinkability can be stated using the textual pattern:

Preserve unlinkability of Configurations, MonitoringData, and MedicalHistory for a Patient and prevent Nurses and Administrators of disclosing that the Configurations, MonitoringData, and MedicalHistory have a relation to the Patient.

We again validate the instantiated privacy pattern by checking if predicate is instantiated with domains belonging to the required domain types: The domains Configurations, MonitoringData, and MedicalHistory are lexical domains according to the context diagram (see Fig. 3) and these are refined causal domains (see Fig. 1). The Patient is a biddable domain and Nurses and Administrators are also biddable domains. Hence, the unlinkability predicate is instatiated in a type-correct way.

We check if the privacy requirement is complete. The LocalPhysician also has access Terminal, but R3 states that the LocalPhysician requires access to these data. Thus, LocalPhysicians are excluded from the unlinkability requirement. We choose a privacy mechanism for unlinkability, e.g., based upon the work in [START_REF] Kapadia | Distributed enforcement of unlinkability policies: Looking beyond the chinese wall[END_REF].

Common Criteria The common criteria lists requirements for unlinkability of just one category. This demands from a privacy mechanism that it shall ensure that a set of "users" or "subjects" are unable to determine if "operations" are used by the same users or have other recurring relations [6, p. 122].

Unobservability

The textual pattern for unobservability requirements is:

Preserve unobservability of ConstrainedDomains that are used by Stakeholders and prevent CounterStakeholders from recognizing that the ConstrainedDomains exist.

The privacy requirement pattern can be expressed by the unobservability predicate:

unobserv cs : P CausalDomain × BiddableDomain × P BiddableDomain →Bool
An example of an instantiated unobservability requirement is:

Preserve unobservability of a MedicalHistory that is used by LocalPhysicians and prevent Administrator(s),Nurse(s) from recognizing that the MedicalHistory exists.

Common Criteria The common criteria divides requirements for unobservability into four categories. The first demands from a privacy mechanism that it shall ensure that a set of "users" or "subjects" are unable to observe certain "operations" on "objects" [6, p. 123-125]. This first requirements is equivalent to the requirement stated previously.

The second kind of unobservability the CC considers is the so-called "allocation of information impact unobservability". The CC demands a privacy mechanism that ensures that "unobservability related information" is distributed to different parts of the machine, such that specific conditions hold, which ensure allocation of information impact unobservability [6, p. 123-125]. The standard does not specify these conditions. This kind of unobservability needs the first kind of unobservability requirement as a prerequisite.

We formulate an allocation of information impact unobservability requirement: Distribute InformationAboutPersonalInformation of Stakeholders on the machine, such that a CounterStakeholder cannot recognize its existence. Specific conditions have to be derived in order to be able to check whether the requirement is fulfilled. The privacy requirement pattern can be expressed by the unobservability related information predicate:

unobservRelInf cs : CausalDomain × BiddableDomain × P BiddableDomain →Bool
The third kind of unobservability the CC considers is the so-called "unobservability without soliciting information". This demands unobservability without soliciting information about personal information [6, p. 123-125].

We formulate an unobservability without soliciting personal information requirement:

Preserve unobservability without soliciting personal information of Stakeholders via not soliciting PersonalInformation and, thus, prevent disclosure to a certain CounterStakeholder.

The privacy requirement pattern can be expressed by the unobservability without soliciting personal information predicate:

unobservWoSol cs : BiddableDomain × LexicalDomain × P BiddableDomain →Bool
The fourth kind of unobservability the CC considers is the so-called "authorized user observability". The standard demands a solution that offers a list of "authorized users" that can observe the usage of "resources and services" [6, p. 123-125].

We formulate an authorized user observability unobservability requirement :

Provide access of authorized Stakeholders to InformationAboutPersonalInformation.

We also instantiate privacy requirements for the functional requirement R3. The privacy requirement pattern can be expressed by the unobservability related information predicate: The privacy requirement pattern can be expressed by the pseudonymity predicate:

unobservRelInf cs : P BiddableDomain × LexicalDomain → Bool
pseudo cs : LexicalDomain × BiddableDomain × P BiddableDomain →Bool
For the functional requirement R5, we formulate a privacy requirement for pseudonymity:

Preserve pseudonymity of Patients via preventing Administrators from relating Pseudonyms to Patients.

Common Criteria The common criteria divides requirements for pseudonymity into three categories [6, p. 120-121]. The first demands from a privacy mechanism that it shall ensure that a set of "users" or "subjects" are unable to determine the real user name of "subjects or operations or objects" or "operations" or "objects". In addition, the privacy mechanism shall use "aliases" of the real user name for "subjects". Moreover, the privacy mechanism shall decide which "alias" the user gets assigned. The "alias" has to conform to an "alias metric". The following kinds of pseudonymity requirements have the first kind of pseudonymity requirements as a prerequisite.

The second kind of pseudonymity the CC considers is the so-called "reversible pseudonymity". This demands that authorized users can determine the user identity under a list of conditions [6, p. 120-121]. The standard does not specify these conditions further.

We formulate an reversible pseudonymity requirement:

Preserve pseudonymity of Stakeholders via preventing that a certain Coun-terStakeholder from relating a Pseudonym to its Stakeholder. An Authorized User shall be able to relate a Pseudonym to its Stakeholder.

The privacy requirement pattern can be expressed by the reversible pseudonymity predicate:

pseudoRe cs : LexicalDomain × BiddableDomain × P BiddableDomain × BiddableDomain → Bool
The third kind of pseudonymity the CC considers is the so-called "alias pseudonymity". This demands if a Stakeholder gets a Pseudonym assigned it shall either be always the same or the two Pseudonyms shall not be related at all [6, p. 120-121].

We formulate an alias pseudonymity requirement:

Provide the same Stakeholder with the same or completely unrelated Pseudonyms.

The privacy requirement pattern can be expressed by the alias pseudonymity predicate:

pseudoAl cs : LexicalDomain × BiddableDomain → Bool

Related Work

The authors Deng et al. [START_REF] Deng | A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements[END_REF] generate a threat tree for privacy based upon the threat categories: linkability, identifiablitiy, non-repudiation, detectability, information disclosure, content unawareness, and policy/consent noncompliance. These threats are modeled for the elements of an information flow model, which has data flow, data store, processes and entities as components. Privacy threats are described for each of these components. This method can complement our own. The results of the privacy threat analysis from Deng et al. can be used as an input for our method. The PriS method elicits privacy requirements in the software design phase. Privacy requirements are modeled as organizational goals. Further privacy process patterns are used to identify system architectures, which support the privacy requirements [START_REF] Kalloniatis | Addressing privacy requirements in system design: the pris method[END_REF]. The PriS method starts with a conceptual model, which also considers enterprise goals, stakeholders, privacy goals, and processes [START_REF] Kalloniatis | Addressing privacy requirements in system design: the pris method[END_REF]. In addition, the Pris method is based upon a goal oriented requirements engineering approach, while our work uses a problem based approach as a foundation. The difference is that our work focuses on a description of the environment as a foundation for the privacy analysis, while the Pris method uses organizational goals as a starting point.

Hafiz described four privacy design patterns for the network level of software systems. These patterns solely focus on anonymity and unlinkability of senders and receivers of network messages from protocols e.g. http [START_REF] Hafiz | A collection of privacy design patterns[END_REF]. The patterns are specified with several categories. Among them are intent, motivation, context, problem and solution, as well as forces, design issues and consequences. Forces are relevant factors for the applicability of the pattern e.g. number of users or performance. Design issues describe how the forces have to be considered during software design. For example, the number of stakeholders have to have a relevant size for the pattern to work. Consequences are the benefits and liabilities the pattern provides. For example, an anonymity pattern can disguise the origin of a message, but the pattern will cause a significant performance decrease [START_REF] Hafiz | A collection of privacy design patterns[END_REF]. This work focuses on privacy issues on the network layer and can complement our work in this area.

Hatebur and Heisel proposed similar patterns for expressing and analyzing dependability requirements [START_REF] Hatebur | A foundation for requirements analysis of dependable software[END_REF].

Conclusions

In this paper, we have presented a set of patterns for eliciting and analyzing privacy requirements. These patterns are separated from the functional requirements and expressed without anticipating solutions. They can be used to create re-usable privacy requirements descriptions for a wide range of problems.

Our work also includes a structured method for instantiating privacy patterns and validates the correctness and completeness of the instantiated patterns in a systematic way. The patterns are based upon natural language privacy goals: anonymity, unlinkability, unobservability, and pseudonymity. The instantiated parameters of the patterns refer to domains of the environment descriptions and are used to describe the privacy requirements precisely. Predicates exist for each of the patterns, which can be used to validate that the instantiated parameters from the environment description have the correct domain types. In addition, several values of the privacy patterns can be instantiated with a set of subclasses of a specific domain type. Hence, we can reason about all domains of that type in the environment description, if they are part of this set or not. In summary, our pattern system has the following advantages:

-The privacy patterns are re-usable for different projects.

-A manageable number of patterns can be applied on a wide range of problems, because they are separated from the functional requirements. -Requirements expressed by instantiated patterns only refer to the environment description and are independent from solutions. Hence, they can be easily re-used for new product versions.

-The patterns closely relate textual descriptions and predicates. The textual description helps to instantiate the privacy requirements, while the predicates are used for validation of the instantiation. -The patterns help to structure and classify the privacy requirements. For example, requirements considering anonymity can be easily distinguished from unlinkability requirements. It is also possible to trace all privacy requirements that refer to one domain.

-The patterns also have variations to satisfy the privacy requirements stated in the common criteria.

In the future, we plan to elaborate more on the later phases of software development.

For example, we want to apply our patterns to software components to show that a certain architecture enforces privacy for its intended usage. Additionally, we plan to systematically search for privacy requirements using existing specifications (e.g., public privacy statements). Moreover, we want to evaluate a chosen privacy mechanism against the capabilities of the known counterstakeholders in order to evaluate its usefulness.

Fig. 1 .

 1 abbreviation: String description: String <<Stereotype>> Domain

Fig. 2 .

 2 Fig. 2. A Method for Using Privacy Patterns

Fig. 3 .

 3 Fig. 3. Patient Monitoring System Context Diagramm

  The PMS shall control the infusion flow of a Patient using the InfusionPump according to the Configuration given by a Physician based upon the vital signs of the Patient, which are transmitted using a wireless network (WAVE/WLAN interface). R2 The PMS should raise an alarm for Physicians and Nurses using the Terminal, if the vital signs of a Patient exceed the limits defined in the Configuration. R3 Physicians can change the Configuration, according to the MonitoringData of the vital signs and the MedicalHistory of a Patient in the PMS using the Terminal, which sends the Configuration to the PMS using a wireless network (WAVE/WLAN interface). R4 Researchers can use the collected data about Patients' vital signs for a long term medical study using the RemoteAccessTerminal that sends the data over a wired network (LAN interface) from the PMS. The Vendor can query the status of the PMS and send patches to the PMS using the RemoteAccessTerminal. R5 Administrators can use the Terminal to maintain the PMS.

4. 4 PseudonymityA

 4 Pseudonym is a LexicalDomain used as an identifier of a Stakeholder without revealing PersonalInformation. An Authorized User is a Stakeholder who is allowed to know the identity of the Stakeholder the Pseudonym belongs to.The textual pattern for pseudonymity requirements is:Preserve pseudonymity of Stakeholders via preventing CounterStakeholders from relating Pseudonyms to Stakeholders.

The privacy threat analysis is left out here.

Acknowledgements

We thank Stephan Faßbender and Denis Hatebur for their extensive and valuable feedback on our work.

supported by the EU project Network of Excellence on Engineering Secure Future Internet Software Services and Systems (NESSoS, ICT-2009.1.4 Trustworthy ICT, Grant No. 256980).


Kristian Beckers

Stefan Eicker

Stephan Faßbender

Maritta Heisel

Holger Schmidt
email: h.schmidt@itesys.de

Widura Schwittek

Ontology-Based Identification of Research Gaps and Immature Research Areas

Keywords: ontologies, research gaps, knowledge management, facetted search

Researchers often have to understand new knowledge areas, and identify research gaps and immature areas in them. They have to understand and link numerous publications to achieve this goal. This is difficult, because natural language has to be analyzed in the publications, and implicit relations between them have to be discovered. We propose to utilize the structuring possibilities of ontologies to make the relations between publications, knowledge objects (e.g., methods, tools, notations), and knowledge areas explicit. Furthermore, we use Kitchenham's work on structured literature reviews and apply it to the ontology. We formalize relations between objects in the ontology using Codd's relational algebra to support different kinds of literature research. These formal expressions are implemented as ontology queries. Thus, we implement an immature research area analysis and research gap identification mechanism. The ontology and its relations are implemented based on the Semantic MediaWiki+ platform.

Introduction

Getting an overview of existing engineering methods, tools and notations (referred to as Knowledge Objects -KOs) for specific fields (referred to as Knowledge Areas -KAs) is of major importance for software engineering researchers. This knowledge is the basis for finding research gaps and problems in this field, which require their attention. Our objective is to develop a technique for finding missing methods, notations and tools in specific knowledge areas.

Researchers usually have to rely on their experience during a research area analysis, which includes the activities of finding research gaps and identifying research areas. This can lead to a biased outcome of a research area analysis. Hence, research gaps or immature research areas might be overlooked repeatedly. In addition, researchers have to find relations between publications, which are sometimes implicit.

In order to ameliorate this situation, we propose a structured approach for research area analysis. This approach utilizes the extensive research of Kitchenham et al. [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF] for structured literature reviews. We apply Kitchenham's methods to a special ontology, the Common Body of Knowledge (CBK) of the EU project Network of Excellence (NoE) on Engineering Secure Future Internet Software Services and Systems (NES-SoS) 3 . One of the major goals of this NoE is the integration of the disciplines of software, service, and security engineering. Hence, the CBK ontology contains information about these areas in numerous KOs that refer to KAs.

Our approach is threefold: We carry over Kitchenham's research for structured literature reviews to informal queries for the CBK, and we also extend the CBK to support these informal queries. In the next step we refine these informal queries into formal CBK relations using Codd's relational algebra [START_REF] Codd | A relational model of data for large shared data banks[END_REF]. For this purpose, we apply the DOOR method by Allocca et al. [START_REF] Allocca | DOOR -towards a formalization of ontology relations[END_REF] for capturing the semantics of relations in ontologies and to formally specify these relations. The technical realization of the CBK is a Semantic MediaWiki+ platform, and we implemented the relational algebra expressions as CBK queries. 4The queries result in tables that show the relations between KAs and KOs. The tables also contain the information of how many KOs are in a KA and what kind of KOs exist in it, e.g., methods, tools, techniques, and notations. These compact results of a query are more effective than analyzing the natural language in publications. Moreover, the creation and execution of a query in the CBK is less time consuming than finding relevant literature for a KA and analyzing it.

The paper is organized as follows: we explain background about structured literature surveys and the NESSoS CBK in Sect. 2. We present in Sect. 3 a structured research area analysis method, which contains research gap analysis and immature research area identification. We show in Sect. 4 our realization of the approach for the field of engineering secure software and services using the NESSoS CBK. Section 5 presents related work. Finally, we conclude and raise ideas for future work in Sect. 6.

Background

We explain Kitchenham's structured approach to structured literature reviews in Sect. 2.1 and the basic structure of the NESSoS Common Body of Knowledge in Sect. 2.2.

Literature Research According to Kitchenham

To gain a structured overview of the state of the art and existing literature before starting new research is one fundamental element of scientific work. For the area of software engineering, Kitchenham was one of the first, who described a structured literature review process [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF]. Over the years this inital process was extended and improved by Kitchenham herself and others [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF].

There are several reasons and goals why researchers might want to perform a literature review. And there are also different types of literature reviews, which can serve

Open

Fig. 1: Types of literature researches and reasons and goals to perform them [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF] the different goals. Fig. 1 shows a condensed view of findings and statements from different publications in the field of systematic literature reviews in software engineering [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF]. The overall reason to do any kind of literature research is Information Gain. This top-level goal can be refined into the goal to get a mere Overview without a specific motivation [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF]. In contrast, the goals of Aggregation of Results and Search for Research Areas have a well-founded motivation.

When aggregating results, one might want to Refine New Findings based an the aggregated data [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF]. Or the findings and data of other publications are used to Strengthen Own Results [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF]. A last reason for aggregation is to give a Background / Positioning of Own Work [START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF] When searching for research areas, a Detection of Problems & Boundaries [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF] of a certain method or set of methods can be the goal. Another option is to search for Assumptions or Unvalidated claims [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF]. These two sub-goals aim at finding immature research areas and improve them with further research. In contrast, finding Open Questions and Gaps aims at research fields, where no publications about solutions exist [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF].

All types of Literature Reviews support the goal of obtaining an overview. The quality of the overview differs in how structured and planned the literature review was performed. A special type is the Structured Literature Review (SLR) [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF]. A SLR is a comprehensive literature review considering a specific research question. Kitchenham's method to perform a SLR was developed to find empirical primary studies considering a specific question and to aggregate the data in the first place. Additionally it turned out later that SLRs also make it possible for researchers to find immature research areas [START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF]. A special kind of the SLR is the Tertiary Study [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF]. Such a study aggregates the results of other SLRs, hence it relies on secondary studies. Another type of literature review is the Mapping Study [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF]. Here it is not the aim to extract any data, but to map studies to research fields or problems. When also the problems and gaps discussed in the studies are obtained while doing the mapping, a Problem / Gap Study as a special kind of mapping study is the result [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF]. This kind of study serves to find real gaps or to find immature methods. For assessing immaturity, a gap study should be combined with a SLR. Kitchenham et al also propose a process to conduct SLRs [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF]. It is shown in Fig. 2. This process can be also used for mapping studies with some slight adaptions [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF]. The process is split up in three major phases. First the Planning phase takes place, followed by the Conducting Review phase, and finally the Reporting Review phase ends the review process.

The Planning starts with an Identification of need for review step The next step is optional as in Commissioning of Review the SLR is tendered to other research groups. The first real step towards a SLR is to Formulate RQ (Research Questions). The research questions are the core of an SLR. All later decisions and results are checked against the RQ later on. In Develop Protocol the review itself is planned. The step Evaluate Protocol is performed to detect misunderstandings, ambiguities, and insufficient definitions. To ease the planning there are predefined Satisfaction Checklists / Questionaries, Question Types, Question Structure Templates, and Protocol Templates. For Question Structure Templates, Kitchenham and Chaters proposes to use the PICOC criteria framework to structure research questions [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF]. PICOC stands for the criteria population, e.g. application area or specific groups of people, intervention, e.g. the method which is of interest, comparison, e.g. the benchmark, outcomes, what is the improvement to be shown, and context, a description of the setting in which the comparison takes place. All these documents serve as an input and guide for certain planning steps. The result of the planning phase are the Research Questions and the Review Protocol. They serve as input to the Conducting Review phase.

The review starts with the Identification of Research, which results in a set of studies which might be relevant. According to defined inclusion and exclusion criteria the step Selection of Primary Studies is performed. The selected studies are then rated in the step Assessment of Study Quality. For those studies with a satisfying quality level the data contained in the studies is extracted in the step Data Extraction and Monitoring. Afterwards the Data Synthesis is performed. The input to this phase are a List of Sources to Search In, Quality Checklist Templates, Extraction Form Templates, and Synthesis Types. Outputs produced in the conducting review phase are the Selected And Rated Studies, the Data Sets extracted form these studies, and the Results and Findings of the data synthesis.

All previously generated outputs serve as an input for the last phase Reporting Review. As external input, Report Templates are given. Based on the inputs, the step Specifying Dissemination Mechanism is executed Then the report is actually written in the step Write and Format Report. As last activity a Evaluate Report step is performed The Report is the output of the entired SLR process.

NESSoS Common Body of Knowledge

Ontologies are used to capture knowledge about some domain of interest. In our case, that domain is the field of engineering secure software and services. An ontology provides a catalogue of the classes of objects that exist in the domain. Moreover, an ontology consists of relations between these classes, and of the objects contained in the classes. We present the ontology we use in this paper in Fig. 3 as a Unified Modeling Language (UML) class diagram. 5 , this ontology presents the subset of the CBK, which is relevant for this work. The classes in light grey represent the most relevant classes in our ontology for this work, and the classes in dark grey are classes that inherit from the most relevant classes.

The class KnowledgeArea divides the field of secure software and services into knowledge areas (KA). The central class in our ontology is the class KnowledgeObject, which represents all types of knowledge objects (KO) we want to capture. As examples, we consider the KOs of the types Tool, Method, and Notation. The equally named classes inherit general properties from the class KnowledgeObject. In general, the properties that are inside of a class box are simple properties, e.g., of type String or Boolean, while there also exist structured properties connected to class boxes via associations. Simple properties are, for instance, contextDescription, problemDescription, and solutionDescription, which represent textual descriptions of the context, the tackled problem, and the solution for tools, methods, and notations. These properties are part of the class KnowledgeObject. An example for a structured property is the association publications, which connects the class KnowledgeObject and the class Publication. This property is structured, because every publication consists of a BibTeX entry or links to DBLP 6 (bibtexEntriesOrLinksToDBLP), and a flag indicating the importance of a publication (isPrimaryLiterature).

The class CommonTerm has several defined terms, and these can be related to terms of KOs. Moreover, some structured properties refer to enumeration types labeled with the UML enumeration stereotype, e.g., the association maturityLevel that connects the class KnowledgeObject and the class MaturityLevel. This enumeration type allows us to rate every tool, method, and notation according to its maturity. 8Multiplicities at the association ends specify constraints on the number of elements contained in an association end. For instance, the 1 at the association end of the association maturityLevel describes that each KO has exactly one maturity level. KOs have several relations between each other, e.g., that one KO Uses another. However, these were extended for the contribution of this work and, hence, we explain them in Sect. 3.2. Specific types of KOs are Notations, which can be supported by Tools (IsSupportedBy). A Notation supports a grade of formality (GradeOfFormality). Methods can be divided into Activities. Activities (Activity) help to structure Methods and to describe workflows based on Inputs, Outputs, and a Description. This means that an activity can use the output of another activity as input. Techniques have just one action, which makes them less complex than Methods.

Using the presented ontology structure, we can adequately capture and process knowledge in the field of engineering secure software and services. In addition, we evolved the ontology for this work with the elements Term, Study, and Subknowl-edgeArea and we also extended the attributes of KnowledgeObject. We explain these new elements in Sect. 3.2.

Structured Research Area Analysis

This section describes the main scientific contribution of this paper. We present in Sect. 3.1 how our work integrates into the approach of Kitchenham described in Sect. 2.1. We show the preparation of our ontology in order to support research area analysis in Sect. 3.2. We describe how to support research area analysis in Sect. 3.3. In Sect. 3.4, we specify the relations between the different ontology parts in detail. These relations enable us to substantiate the envisaged research area analysis by the semantics of the knowledge stored in the ontology.

Extension/Integration of Kitchenham and CBK

There are several points of integration for the CBK and the literature review process introduced in Sec. 2.1. These points are the inputs Question Types, Question Structure Templates, and the List of Sources to Search In, and the process steps Formulate RQ, Identification of Research, and Selection of Primary Studies (see Fig. 2). To improve the integration for some of these points, the CBK and / or the literature review process have to be adapted.

Question Types

The original question types defined by Kitchenham at al are formulated for SLRs [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF]. For mapping studies, a selection of questions and their generalization can be found in the works of Kitcheham et al [START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF], and Petersen et al. [START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF].These insights combined with the structure of the CBK (see Fig. 3) result in some new question types:

-How many different KOs exist for the KA in question? -Which KA(s) are covered by a certain KO? -Which are the problems and future work mentioned for (a) given KA(s)? -What is the maturity of KOs for (a) given KA(s)? -What are the main publications for a given KO or KA? Question types help to formulate research questions. They give evidence which questions can be of interest and how to formulate them. Moreover, whenever a research question within an actual review maps to one of the questions types given above, this question can be answered by the CBK directly. Question Structure Templates For the question structure template, Kitchenham and Chaters proposes to use the PICOC criteria framework to structure research questions [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF] as we already described in Sect. 2.1. But when investigating the CBK meta-model (see Fig. 3) it seems to be reasonable to add some criteria. The main addition is to define the knowledge area(s) explicitly, unlike having them implicit in the context. In most cases of conducting a SLR or mapping study, there is a very specific focus on a special part of software engineering. An overview given by Kitchenham et al. shows that evidence [START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF]. This focus should be captured within the criteria, because some electronic sources support to select knowledge areas [START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF]. Moreover, for mapping studies these knowledge areas are often used for structuring the report [START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF]. In the case of the CBK the knowledge areas are one of the core concepts, and searching the CBK utilizes the knowledge areas. A minor addition is to distinguish between general terms of the population and special terms of the knowledge area(s). The special terms have a great weight when searching and can help to structure the results [START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF].

Using this new question structure makes important parts of the questions more explicit. And they ease the use of the CBK, because the separation between general search terms,common terms and knowledge areas are directly reflected in the formulation of the search queries (We will see in Sect. 3.4).

List of Sources to Search In

The CBK and its searching capabilities has to be added to the list of sources to search in [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF]. Adding the CBK itself is trivial, but for the capabilities it has also to be checked which new capabilities the CBK introduces. For example, the missing relations between KOs and between publications, which has been found as issue for all existing search sources [START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF], is explicitly addressed in the CBK. A detailed discussion is skipped at this point due to the lack of space.

Having the CBK in the source list with an explanation of its capabilities helps to plan the research and clarifies in which cases the CBK is of superior use in comparison to other sources. Formulate RQ Besides the two inputs, the Question Types and the Question Structure Templates, the CBK can directly support the formulation of research questions.

The CBK already defines an ontology of knowledge areas. With an extension, it will support sub-knowledge areas (see Sec. 3.2). Those areas can help to focus the research questions, because it gives an orientation how to refine knowledge areas and how knowledge areas are related. To find the focus for the own research is considered challenging without such a support [START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF]. Additionally the adapted CBK presented in Sec. 3.2 provides the common terms used in these knowledge areas. These terms help to sharpen the questions and to avoid ambiguities.

The integration of the CBK and Formulate RQ improves the outcome of the whole literature review process, because it helps to avoid the formulation of imprecise search questions with respect to missing / wrong focus and wrong / ambiguous wording.

Identification of Research

The ontology of common terms and related synonyms contained in the CBK also helps to formulate the search queries, not only for the CBK, but also for other search sources. This formulation of search terms is a crucial step and the knowledge about relations between terms and the existence of a synonym list improves this step of finding research a lot [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF][START_REF] Kitchenham | Using mapping studies as the basis for further research -a participant-observer case study[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Budgen | Using Mapping Studies in Software Engineering[END_REF][START_REF] Petersen | Systematic Mapping Studies in Software engineering[END_REF]. Selection of Primary Studies For the selection of primary studies the CBK provides information for some comprehensive and sophisticated selection criteria. The CBK already contains information, which is very specific and useful to rate KOs, like the maturity level. And this information is available for all results obtained from the CBK. These criteria are hard to evaluate for results from other search sources [START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF]. Examples for inclusion criteria:

-Only include KOs and related publications with a certain maturity level -Only include KOs, which are a core concept of a KA and therefore many other KOs are based on these KOs -Only include publications, which are considered as most significant by the editors of KOs Having a set of precise selection criteria, which can be evaluated for all results, improves the outcome of the whole review process. The probability of excluding relevant studies and the bias caused by including literature of low quality can be reduced. And the whole review process speeds up when using the CBK, because the information for evaluating the criteria is available explicitly.

Preparing the Ontology

We prepared the NESSoS CBK ontology (see Sect. 2.2) in order to support the concepts of the structured literature reviews from Kitchenham explained in Sects. 2.1 and 3.1.

Hence, we extended the CBK ontology (see Fig. 3) with the classes SubKnowledgeArea, Publication, and Study.

We consider keywords and tags in knowledge objects. Keywords are given according to the guidelines of a specific system, e.g., the ACM-keyword-system [START_REF] Turner | Digital libraries and search engines for software engineering research: An overview[END_REF]. Tags are chosen without any restriction and provide the possibility to choose any possible word.

We want to use the CBK ontology for finding research gaps. This requires Knowled-geObjects that do not have a solution description yet, but only problem descriptions. We also included the MaturityLevel None for these KnowledgeObjects. In addition, Knowl-edgeObjects now have a FutureWork attribute that states research not yet carried out. The difference between these two is that KnowledgeObjects that only have a problem description represent a research area that needs a significant amount of research for providing a solution. The FutureWork attribute in KnowledgeObjects represents possible research that can build upon an existing solution. Researchers that use our approach might look for one or the other.

KnowledgeObjects have relations between each other. These relations are relevant for the investigation of research areas. KOs can be based on other KOs (IsBasedOn), and they can use each other (Uses). In addition, KOs can be used in combination. In this case, one KO Complements another. If KOs can be exchanged, these have a Substitutes relation.

We include the class Term that holds the terms a specific KnowledgeObject uses. The class CommonTerm contains a set of well-defined terms. A Term of a Knowled-geObject is either broader, synonymous, or narrower than a CommonTerm. This allows a comparison of KnowledgeObjects using the CommonTerms. Without these any comparison would lack precision, because terms and notions differ in KnowledgeObjects.

Identifing Research Gaps Using the CBK

While a

Mapping Study and a Problem/Gap Study is supported best by the CBK, it at least partially supports a Structured Literature Review and a Tertiary Study (see Fig. 1). In the following, the CBK support for all different kinds of studies, as defined by Kitchenham, is described in more detail. The support, as described in this section, sketches only a first idea, which will be refined in Sect. 3.4, where we only consider the well supported Mapping Study and Problem/Gap Study.

Mapping Study For a Mapping Study researchers have to specify one or more KAs, one or more sub-KAs or one or more common terms . Additionally, they can constrain the search by providing further search terms. The CBK returns KOs grouped by KAs. Depending on the scope of the search, 20 results,for example , for one KA can be interpreted as a sign for maturity of a field or immaturity of a field. For example, 20 results for the KA Requirements has a different meaning than 20 results for the sub-KA Goal-oriented Requirements including the search terms Cloud and Law. Problem/Gap Study Conducting a Problem/Gap Study is also well supported by the CBK. The researcher specifies one or more KAs, one or more sub-KAs or one or more common terms and provides search terms. In this case, the CBK not only groups KOs along the specified KAs, sub-KAs or common terms as described for the Mapping Study, but extends the search to the following classes and fields of the CBK ontology: ProblemDescription and FutureWork of the class KnowledgeObject, Problem and Border in the class Study. These results support the creation of a Problem/Gap Study because all relevant information is presented to the researcher in a structured way. Structured Literature Review While the researcher is able to retrieve KOs for the selected KAs, sub-KAs or common terms and, thus, all relevant literature references, can only be regarded as a starting point to conduct a full-fledged Structured Literature Review. A SLR involves an in-depth analysis of the actual literature, which is out of the CBK's scope. Tertiary Study Conducting a Tertiary Study is only supported in theory, because it requires all relevant secondary studies to be part of the CBK. If this is not the case, there is no support for this kind of study using the CBK.

Formalizing Research Area Analysis

We now identify and specify relevant relations for the identification of research gaps, making use of the ontology and the knowledge it stores and structures. For the analysis, the relations between different tools, methods, and notations, i.e., different KO types, and KAs are of particular relevance. Allocca et al. [START_REF] Allocca | DOOR -towards a formalization of ontology relations[END_REF] present the DOOR method to capture the semantics of relations between different ontologies and to formally specify these relations. While we partly adopt the DOOR steps to support our approach to identify and specify relations between different KOs, we abstain from building an ontology of these relations. We use the ontology structure presented in Sects. 2.2 and 3.2 on the one hand for typing the relations and, more importantly, on the other hand to refine the semantics of the relations. We divide our approach into the following three steps:

1. Identify and specify top-level relations 2. Identify and specify variants and sub-relations, and characterize their algebraic properties 3. Compose relations We will use the following abbreviations in the formalization: KA = Knowledge Area, SKA = SubKnowledgeArea KO = Knowledge Object P = Publication, ST = Study, CT = CommonTerm, T = Term, and ML = MaturityLevel.

Top-Level Relations:

The following relations are abstracted top-level relations that support the kinds of queries sketched in Sect. 3.3.

MappingStudy KAxKO Describes a mapping study as a relation between knowledge areas and knowledge objects. MappingStudy SKAxKO Describes a more fine granular mapping study as a relation between sub-knowledge areas and knowledge objects. MappingStudy CTxKO Describes a mapping study as a relation between common terms and knowledge objects. ProblemGapStudy KAxKOxST Describes a problem or gap study as a relation between knowledge areas, knowledge objects, and studies.

ProblemGapStudy SKAxKOxST Describes a more fine granular problem or gap study as a relation between sub-knowledge areas, knowledge objects, and studies. ProblemGapStudy CTxKOxST Describes a problem or gap study as a relation between common terms and knowledge objects and studies.

Variants, sub-relations, and Algebraic Properties: Variants and sub-relations shed light on various facets of the top-level relations with regard to the structured design of the ontology. We express the relations using relational algebra based upon the work of Codd [START_REF] Codd | A relational model of data for large shared data banks[END_REF]. We use an extention of the relational algebra [START_REF] Klug | Equivalence of relational algebra and relational calculus query languages having aggregate functions[END_REF][START_REF] Agrawal | Alpha: an extension of relational algebra to express a class of recursive queries[END_REF] that offers aggregation and grouping functionalites. The symbol ξ groups the output according to specifed atribute(s). π projects only specified columns of a table. σ selects rows in a table for which specified boolean expression(s) hold. joins tables according to common attributes. All rows that do not have these attributes are left out.

joins tables, but also displays rows of the left table that do not have all the common attributes. We use relational algebra, because the algebra expressions can be translated to SMW+ queries in a straightforward way, see Sect. 4.

For the specifications of the relations, we assume that the structural design of the ontology presented in Sect. 2.2 and 3.2 is given as tables. Classes that have 1..* cardinalities on both ends of the relation in our ontology require connection tables. Otherwise we would require multiple relations between tables, which is to be avoided during database design. For example, we want to create a table for knowledge objects. One row in the table is allowed to have multiple relations to rows in the knowledge area table. Instead, we would have to create numerous columns for these relations in the knowledge area, because we do not know how many relations we need. Hence, we create a further table for these relations. We denote these tables, which we add in the formalization, with "Connect" and append the names of the classes this table connects. For example, the connection table for the tables KnowledgeObject and KnowledgeArea is stated as: ConnectKAtoKO. These connection tables have two columns, which contain the the primary keys of each of the tables they connect.

Inheritance in the ontology is translated into one main table for the superclass and one table for each class that inherits from this class. These classes have a relation to the table that represents the superclass and have only the additional attributes of the inherited class. For example, the superclass KnowledgeObject has the class Tool that inherits from it, and one of the additional attributes is Input. Hence, we create a table KnowledgeObject and a table Tool, which has the attribute Input.

Searchterm: We define an algebraic expression ST, which represents a boolean expression for one or more searchterms.

ST ::= ST ST | κ = String | (ST) | ¬ST ::= ∧ | ∨ κ ::= Tag | Keywords | ExecutiveSummary | Name
For example, the expression " Tags='cloud' ∨ Tags='law' " can be used with σ for the table KnowledgeObject. This results in a table with all KOs that have 'cloud' or 'law' as tags.

Compose relations Complex relations can be composed from simple ones, as shown in the following example.

MappingStudy KAxSKAxKOxCT: We merge the different mappings for knowledge area, sub-knowledge area, and the common term and define the following relation that returns the name of the knowledge object, maturity level, the executive summary, the tags, and the keywords, grouped by knowledge area, sub-knowledge area and common terms. To sum up, we applied the DOOR method for the structured creation of ontology relations to the CBK ontology for implementing the Kitchenham structured research area analysis. First, we defined the top-level relations for mapping studies and problem/gap studies. We formalized these relations, using relational algebra, and we derived further relations from these. In addition, we have shown an example for a composed relation of the previously defined relations. We checked all the relational algebra expressions using the relational tool. 9 For future semi-automatic use of the relations and in the light of the technical realization (see Sect. 4), the composition of relations can be left to the users. For example, the Semantic MediaWiki+ allows its users to easily switch the predicates of the relations on and off to generate a result set as required.

MappingStudy

Realization

Our ontology behind the CBK allows us to specify various queries realizing the relations presented in Sect. 3.4 using the SMW query language (SMW-QL). SMW-QL Fig. 4: Mapping study support realized as SMW-QL query was introduced as a comfortable means to query the SMW [START_REF] Krötzsch | Semantic wikipedia[END_REF][START_REF] Bao | Knowledge representation and query in semantic mediawiki: A formal study[END_REF]. The SMW+ platform provides an inline syntax to integrate queries into a wiki page and a graphical query builder to support the creation of such queries (see Fig. 4). In the following, some of the queries specified previously in relational algebra will be translated into SMW-QL. We start with a simple query referring to the relation MappingStudy KAxKO, followed by a complex query referring to the relation ProblemGapStudy KAxKOxST.

The query given in Listing 1.1 is read like this: retrieve all KOs that belong to the KA Security Requirements and which contain the search term attacker and/or invader in the executive summary. The search term can be further specified using comparator operators and wildcards. The result is returned as a table. Each row represents one knowledge object, whereas each column represents an attribute specified in the query indicated by the question mark. In our case, the table contains the columns RefersTo-KnowledgeArea, HasMaturityLevel, ExecutiveSummary, Tags and Keywords. The table is sorted along the KAs and MaturityLevel. The user is able to customize sorting by clicking on the table's header. The SMW-QL query given in Listing 1.2 refers to the relation ProblemGapStudy KAxKOxST, thus supporting a Problem/Gap Study. Therefore In contrast to definition of ProblemGapStudy KAxKOxST in Sect. 3.4, the first SMW-QL query is not reused in this query. While subqueries are in principal possible with SMW-QL, it is recommended to express sub-queries as queries where possible. In this case, it is realized as a flat query, not only because of performance advantages, but also for the sake of simplicity.

Related Work

Tools for structured literature reviews that are regularly used by the software engineering research community are major search engines and digital libraries such as ACM, CiteSeer, IEEE Xplore, Google Scholar, Science Direct and Web of Science [START_REF] Turner | Digital libraries and search engines for software engineering research: An overview[END_REF]. All of these work similarly by specifying boolean search expressions. While they differ in evaluating search expressions and ranking the results, it can be stated that none of these search engines and digital libraries was created to support structured literature reviews [START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF], as our dedicated approach does.

Conclusion and Outlook

We have formalized the Kitchenham approach for structured literature reviews in relational algebra. Furthermore, we implemented these queries in an SMW+ ontology. Thus, we provide a semi-automatic support for the Kitchenham approach that eases the burden of manual literature reviews. Our approach offers the following main benefits:

-Systematic execution of mapping and problem/gap studies according to Kitchenham based upon ontologies for specific domains (here: secure software and service engineering) -A structured approach to analyze a research area -Improving the outcome of literature studies via structured processing of knowledge using ontologies -Further analysis of research domains can be executed with little effort Our approach has the limitation that it cannot detect research gaps that are not part of the content of the CKB. Hence, the quality of the outcome of our work is dependent on the quality and quantity of CBK content. However, the possibility also exists that

Fig. 2 :

 2 Fig.2: Process proposed by Kitchenham for undertaking a SLR[START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF][START_REF] Kitchenham | Guidelines for performing Systematic Literature Reviews in Software Engineering[END_REF][START_REF] Brereton | Lessons from applying the systematic literature review process within the software engineering domain[END_REF][START_REF] Kitchenham | Refining the systematic literature review process -two participant-observer case studies[END_REF]

Fig. 3 :

 3 Fig.3: An Ontology for the Common Body of Knowledge for Secure Software and Services.7

1

  {# ask : [[ Category : KnowledgeObject ]] 2 [[ RefersToKnowledgeArea :: Security Requirements ]] 3 [[ ExecutiveSummary ::˜* attacker *]] OR [[ ExecutiveSummary ::˜* invader *]] 4 | ? RefersToKnowledgeArea | ? HasMaturityLevel | ? ExecutiveSummary | ? Tags 5 | ? Keywords | s o r t = RefersToKnowledgeArea , HasMaturityLevel |} Listing 1.1: Query for supporting a Mapping Study Listing 1.2: Query for supporting a Problem/Gap Study it is necessary to additionally output the attributes ProblemDescription and FutureWork from the KO class and the attributes Problem and Border from the Study class.

  Finally we merge the different problem or gap study relations for knowledge area, sub knowledge area, and the common terms and define the following relation that returns the name of the knowledge object, common term, the executive summary, future work, the tags the keywords, title of the study, problem, borders and open questions grouped by knowledge area, sub-knowledge area and common terms. We specified this relation in the following.

	KAxSKAxKOxCT =
	ξ KnowledgeArea,Sub-KnowledgeArea,CommonTerm,MaturityLevel,Name,ExecutiveSummary,Tags,
	Keywords (
	π KnowledgeArea,Sub-KnowledgeArea,CommonTerm,Name,MaturityLevel,ExecutiveSummary,
	Tags,Keywords (MappingStudy KAxKO MappingStudy SKAxKO
	MappingStudy CTxKO))
	ProblemGapStudy KAxSKAxKOxCTxST: ProblemGapStudy KAxSKAxKOxCTxST =
	ξ KnowledgeArea,Sub-KnowledgeArea,CommonTerm,Name,ExecutiveSummary,FutureWork,Tags,
	Keywords,Title,Problem,Borders,OpenQuestions (
	π KnowledgeArea,Sub-KnowledgeArea,CommonTerm,Name,ExecutiveSummary,FutureWork,
	Tags,Keywords,Title,Problem,Borders,OpenQuestions (
	ProblemGapStudy KAxKOxST ProblemGapStudy SKAxKOxST
	ProblemGapStudy CTxKOxST))

http://www.nessos-project.eu/

http://www.nessos-cbk.org

http://www.uml.org/

http://www.informatik.uni-trier.de/ ˜ley/db/

The UML stereotype enumeration is used for classes that have a fixed set of attributes, which are referred to by other classes. This use differs from the specification in the UML standard.

In general, enumeration types allow us to pre-define values a property might have.

http://galileo.dmi.unict.it/wiki/relational/doku.php

supported by the EU project Network of Excellence on Engineering Secure Future Internet Software Services and Systems (NESSoS, ICT-2009.1.4 Trustworthy ICT, Grant No. 256980).

Authors Suppressed Due to Excessive Length

KnowledgeArea: We define KAB to be a boolean expression for the selection of one or more knowledge areas.

We defined Maturity Level (MLB), Sub-KnowledgeArea (SKAB), and Common Terms (CTB) in a similar manner. MappingStudy KAxKO: We specify queries for mapping studies as database relations. We explain the query in detail starting with the σ ST , where we join the tables We define ProblemGapStudy SKAxKOxST, ProblemGapStudy CTxKOxST in a similar manner.

publications might be overlooked when manually executing a literature review according to Kitchenham. Moreover, research gaps, ideas for future work, etc. that only exist in the heads of researchers also cannot be found by any of these approaches. The work presented here will be extended to support further, more extensive research questions in the future. Examples are the refinement of new findings or the strengthening of own results. We will also work on further automating our approach. We envision an extension of the approach towards other existing ontologies.