Methodology

This document is also available in pdf

Introduction

This document aims at providing an approach to describe case studies. The approach suggests a way to describe and classify case studies with the objective to make them comparable and reusable in the context of different projects. It is based on work developed within the S-Cube Network of Excellence . Case studies descriptions can include different material, depending on their purposes. For instance, they can include a specific software solution or proof of concept, or they can simply describe an application case without offering a specific implementation solution. Of course, while in the first case the case study description contains also design, implementation, and even deployment and operation details, in the second case it should be implementation and technology agnostic. In this document we refer to case study case descriptions of the second kind as they can be reusable assets that could be exploited as reference cases in the context of various projects. As such, the description should focus on what expectations the software should address more than on how these should be addressed. In other terms, the description should be focusing on eliciting those goals and assumptions that the software should address [4]. Details about how to describe a case study are given in Sec. 2. A proper classification allows us to cluster case studies according to their application domain and the research topics that are relevant for them. For this reason, we introduce two levels of classification:

• Domain-oriented classification: it defines a high level classification that makes possible to identify in which domain a case study applies. This classification proposes a list of macro-areas inspired by the EC Workprogramme. Each case study is associated to one of these areas. (See Sec. 3.1)
• Research-oriented classification: it defines a classification of research challenges that are interesting in a given research area (see Sec. 3.2). Using this classification, a case study can be associated to research challenges that emerge from the case study or that needs to be addressed in order to develop a solution for the case study.

Based on this methodology, a public repository of case studies can be made available in the future. The projects will take advantage of this facility to publish their case studies. In addition, the proposed classification will be included in the repository to categorize the published case studies and to drive other projects to find the case studies most relevant for their research challenges.

Elements

In order to make case studies comparable and easy to understand, S-Cube has defined a case study description approach based on the classical the Requirements Engineering literature [1] and that leverages from the results achieved by NEXOF-RA [2]. S-Cube has also experimented the approach by revisiting a number of cases described in the NEXOF-RA deliverables. This has allowed us to highlight inconsistencies and incompleteness in the previous descriptions. According to the methodology, a case study is described in terms of:

• A list of Business Goals and Domain Assumptions for the case study.
• A Domain description.
• A list of Scenario descriptions.

Business Goal and Domain Assumptions

Business Goals define objectives to be pursued and functionalities to be offered. Domain Assumptions describe properties that are assumed to be true in a certain domain. Table 1 defines a template for describing Domain Assumptions and Business Goals. The description includes the involved stakeholders, the rationale, the priority and the material supporting the description, if any.

Table 1. Business Goal and Domain Assumption description template

Field	Description
UniqueID	ID
Short Name
Type	Business Goals.
Description
Rationale
Involved Stakeholders
Conflicts
Supporting Material
Priority of accomplishment

Case study Domain description

The set of phenomena occurring in the world together with the laws that regulate such world (e.g., physical laws, social rules, conventions that need to be respected) define the application domain. In the case a software system (a machine) is needed in order to fulfill certain goals, such machine needs to have an impact on the world. Thus, the two corresponding domains have to partially overlap. The phenomena that are at the intersection between the world and the machine are called shared phenomena. These can be either controlled by the world and observed by the machine, or, conversely, controlled by the machine and observed by the world. The study of such phenomena is particularly important since they define the interface between the machine and the world. Of course, shared phenomena (and therefore scenarios) can be understood in the context of the world in which the machine will work and of the laws governing the world. Also, the boundaries between the world and the machine have to be clearly identified. In order to address these aspects we suggest to include in the case study domain description the following items:

• A glossary that defines the main terms of the world.
• A description of the relationships between the terms of the glossary. The glossary alone does not highlight the relationships between the various terms nor their relative importance. Thus we need to build a model that highlights these aspects. Class diagrams are usually a good tool for this purpose since they allow the engineer to identify main entities as classes and to express several kinds of relationships between these. Entity-relationship diagrams as well as semantic networks for our purposes have an expressive power that is similar to class diagrams and therefore can be used as well.
• A description of any law that is relevant in the world. Such laws can be expressed in any form that is typical of the application domain that we are considering: mathematics, logics, natural language, ...
• Strategic Dependency Diagrams (SDDs) [2]. These are used to model the dependencies between the different actors in the organisational context. They especially help to model user (roles) together with their relations. Dependency edges in the diagram link the actors with needs (dependers) to actors with the capability of meeting those needs (dependees). The needs are expressed in terms of goals (positioned on the edges).
• Context Diagrams (CDs) [1]. These identify the agents that operate in a certain context as well as the machine that needs to be developed. Moreover, they highlight the phenomena shared between agents and machine. Figure 1 shows the notation of context diagrams. In a context diagram, any active entity on the case study to be modeled is represented as a box, while a directed arrow describes phenomena between agents. Both the SDDs and the CDs represent the agents/actors involved in the domain, but while the SDDs show the dependencies among them, CDs highlight also other kinds of relationships among them. Moreover, they clearly identify the boundaries between the machine and the world.

Figure 1 - Context Diagram notation

Scenario description

The phenomena shared between the world and the machine can be detailed through scenario descriptions. Scenarios have an operational flavour in the sense that they describe the steps that need to be followed by the machine and the world entities in order to accomplish a certain task. Table 2 describes how scenarios should be detailed and described, and it should be used as a template for any single scenario description. Here, a scenario is described using information about the business goals or the domain assumptions they refer to, the operational description of the scenario, the possible problems involved and the supporting material.

Table 2 - Scenario description template

Field	Description
UniqueID	ID
Short Name
Related To
Involved Actors
Detailed Operational Description
Problems and Challenges
Additional Material

Applying the methodology

The description of Business Goals, Domain Assumptions, Domains, and Scenarios are not necessarily obtained through a sequential process that starts from the identification of the goals then moves to the analysis of domain, and, finally, to the description of scenarios. Instead, as in many other highly intellectual processes, it is more likely to proceed iteratively, starting from any of the three points and compiling them more or less in parallel. What we can do is to provide a non-exhaustive list of simple rules that allow us to understand when we can decide that our case study description has reached a reasonably good form:

• The terms used in the scenarios and in the identification of the business goals and of the assumptions are properly described in the glossary and they are related to the other terms in the domain model.
• The entities identified in the domain model are used in some scenario or in some business goals and domain assumptions description.
• All actors that have been identified in the scenarios appear also in the context diagram (and/or in the Strategic Dependency diagram) and vice versa.
• From each scenario there exist at least one related business goal and vice versa.
• Scenarios are not overlapping. Relationships are possible but they should be explicitly identified.
• Goals are not overlapping. Relationships are possible but they should be explicitly identified.

Classification

Domain-oriented classification

As a first level of classification, each case study needs to be associated to an application domain. A list of possible application domain includes, and it is not limited to, the following topics:

• Business Application
• Small Medium Enterprise
• Large Enterprise
• E-Government
• Government to Government
• Government to Citizen
• Utilities
• Transportation
• Power supply

Research-oriented classification

An orthogonal classification considers the research topics that could have potential impact on a case study. In more detail, research topics are organized in two layers [5]:

• Research challenges. They define long-term research goals w.r.t. to the goals of research project in which the case study had been defined. For instance, in S-Cube, several research challenges around the life cycle of Service Based Applications are defined. As an example we have:
• QoS Aware Adaptation of Service Compositions
• Proactive Adaptation and Predictive Monitoring
• Research questions. Associated to a research challenges, a set of research questions may exist identifying specific short-terms research objectives. For instance, referring to the “QoS Aware adaptation research” challenge listed before, the following research questions can be identified:
• Adaptation of QoS-aware Service Compositions based on Influential Factor Analysis and Prediction.
• How can cost-based derivation of data-aware QoS for a service composition be used to drive adaptation?
• Linkage between Business Transactions and Service Compositions.

Relationships between a case study and one or more research questions should be defined and the rationale behind each of these associations needs to be properly described. In particular, a relationship exists if the case study will be used to give a valid answer to a research question, or a research question is highlighted by a typical situation as described in the case study.

Bibliography

1. Software requirements & specifications: a lexicon of practice, principles and prejudices. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co. .
2. (I*) “i-star software formalism,” http://www.ics.uci.edu/_alspaugh/software/istar.html.
3. (NEXOF-RA, 2009). NESSI Open Framework - Reference Architecture (NEXOF-RA): Scenarios and Requirements for Open Framework Construction.
4. (S-Cube, 2009a). Deliverable CD-IA-2.2.2 - Collection of Industrial Best Practices, Scenario and Business Cases.
5. (S- Cube, 2009b). Deliverable CD-IA-3.1.1 - Integration Framework Baseline.