Azadeh Alebrahim

Towards systematic integration of quality requirements into software architecture

We present a model- and pattern-based approach that allows software engineers to take quality requirements into account right from the beginning of the software development process. The approach comprises requirements analysis as well as the software architecture design, in which quality requirements are reflected explicitly.

A Method to Derive Software Architectures from Quality Requirements

We present a model- and pattern-based method that allows software engineers to take quality requirements into account right from the beginning of the software development process. The method comprises requirements analysis as well as the derivation of a software architecture from requirements documents, in which quality requirements are reflected explicitly. For requirements analysis, we use an enhancement of the problem frame approach, where software development problems are represented by problem diagrams. The derivation of a software architecture starts from a set of problem diagrams, annotated with functional as well as quality requirements. First, we set up an initial software architecture, taking into account the decomposition of the overall software development problem into sub problems. Then, we incorporate quality requirements into that architecture by using security or performance patterns or mechanisms. The method is tool-supported, which allows developers to check semantic integrity conditions in the different models.

Optimizing Functional and Quality Requirements According to Stakeholders’ Goals

High-quality software has to consider various quality issues and different stakeholder goals. Such diverse requirements may be conflicting, and the conflicts may not be visible at first sight. We propose a method to obtain an optimal set of requirements that contains no conflicts and satisfies the stakeholder goals and quality requirements to the largest possible extent. We first capture the stakeholders’ goals and then analyze functional and quality requirements using an extension of the problem frame approach. To obtain an optimal set of requirements, we first determine candidates for requirements interaction. For negatively interacting requirements, we derive alternatives in a systematic way. To prepare for the optimization, we need to assign values to the different requirements. To determine those values, we apply the Analytical Network Process (ANP). Finally, we use existing optimizer tools to obtain a set of requirements that has a maximal value with respect to the previously determined values and that does not contain any conflicting requirements. We illustrate our method with the real-life example of smart metering.

A Structured Approach for Eliciting, Modeling, and Using Quality-Related Domain Knowledge

In requirements engineering, properties of the environment and assumptions about it, called domain knowledge, need to be captured in addition to exploring the requirements. Despite the recognition of the significance of capturing and using the required domain knowledge, it might be missing, left implicit, or be captured inadequately during the software development. This results in an incorrect specification. Moreover, the software might fail to achieve its quality objectives because of ignored required constraints and assumptions. In order to analyze software quality properly, we propose a structured approach for eliciting, modeling, and using domain knowledge. We investigate what kind of quality-related domain knowledge is required for the early phases of quality-driven software development and how such domain knowledge can be systematically elicited and explicitly modeled to be used for the analysis of quality requirements. Our method aims at improving the quality of the requirements engineering process by facilitating the capturing and using of implicit domain knowledge.

A Framework for Combining Problem Frames and Goal Models to Support Context Analysis during Requirements Engineering

Quality requirements, like security requirements, are difficult to elicit, especially if they cross multiple domains. Understanding these domains is an important issue in the requirements engineering process for the corresponding systems. Well-known requirements engineering approaches, such as goal-oriented techniques provide a good starting point in capturing security requirements in the form of soft-goals in the early stage of the software engineering process. However, such approaches are not sufficient for context and problem analysis. On the other hand, the context and problem modeling approaches like e.g., problem frames, do not address the system goals. Integrating the relevant context knowledge into goal models is a promising approach to address the mutual limitations. In this paper, we propose a framework for combining goal models and problem frames. The framework makes it possible to document the goals of the system together with the corresponding knowledge of the system’s context. Furthermore, it supports the process of refining (soft-) goals right up to the elicitation of corresponding security requirements. To show the applicability of our approach, we illustrate its application on a real-life case study concerning Smart Grids.

Supporting quality-driven design decisions by modeling variability

Design decisions should take quality characteristics into account. To support such decisions, we capture various solution artifacts with different levels of satisfying quality requirements as variabilities in the solution space and provide them with rationales for selecting suitable variants. We present a UML-based approach to modeling variability in the problem and the solution space by adopting the notion of feature modeling. It provides a mapping of requirements variability to design solution variability to be used as a part of a general process for generating design alternatives. Our approach supports the software engineer in the process of decision-making for selecting suitable solution variants, reflecting quality concerns, and reasoning about it.

Problem-Based Requirements Interaction Analysis

[Context] The ability to address the diverse interests of different stakeholders in a software project in a coherent way is one fundamental software quality. These diverse and maybe conflicting interests are reflected by the requirements of each stakeholder. [Problem] Thus, it is likely that aggregated requirements for a software system contain interactions. To avoid unwanted interactions and improve software quality, we propose a structured method consisting of three phases to find such interactions. [Principal ideas] For our method, we use problem diagrams, which describe requirements in a structured way. The information represented in the problem diagrams is translated into a formal Z model. Then we reduce the number of combinations of requirements, which might conflict. [Contribution] The reduction of requirements interaction candidates is crucial to lower the effort of the in depth interaction analysis. For validation of our method, we use a real-life example in the domain of smart grid.

Towards a Computer-Aided Problem-Oriented Variability Requirements Engineering Method

In theory, software product lines are planned in advance, using established engineering methods. However, there are cases where commonalities and variabilities between several systems are only discovered after they have been developed individually as single systems. In retrospect, this leads to the hindsight that these systems should have been developed as a software product line from the beginning to reduce costs and effort. To cope with the challenge of detecting variability early on, we propose the PREVISE method, covering domain and application engineering. Domain engineering is concerned with exploring the variability caused by entities in the environment of the software and the variability in functional and quality requirements. In application engineering, the configuration for a concrete product is selected, and subsequently, a requirement model for a concrete product is derived.

1st Workshop on VAriability for QUalIties in SofTware Architecture (VAQUITA): Workshop Introduction

Azadeh Alebrahim paluno The Ruhr Institute for Software Technology Working group Software Engineering University of Duisburg-Essen, Germany azadeh.alebrahim @uni-due.de Stephan Faßbender paluno The Ruhr Institute for Software Technology Working group Software Engineering University of Duisburg-Essen, Germany stephan.fassbender @uni-due.de Martin Filipczyk paluno The Ruhr Institute for Software Technology Working group Specification of Software Systems University of Duisburg-Essen, Germany martin.filipczyk @paluno.uni-due.de Michael Goedicke paluno The Ruhr Institute for Software Technology Working group Specification of Software Systems University of Duisburg-Essen, Germany michael.goedicke @paluno.uni-due.de Maritta Heisel paluno The Ruhr Institute for Software Technology Working group Software Engineering University of Duisburg-Essen, Germany maritta.heisel @uni-due.de Uwe Zdun Research Group Software Architecture University of Vienna uwe.zdun@univie.ac.at

Towards systematic selection of architectural patterns with respect to quality requirements

The design of software architecture for a system-to-be is a challenge, since required functionality as well as the desired quality requirements have to be considered. Building upon common knowledge and best practices captured in architectural patterns has shown to be valuable in this context. However, existing solutions for deriving architectures from requirements mostly rely on experienced architects. Beside the required experience, it is often a problem that the decision is not properly reasoned and documented. In this paper, we propose a process to select appropriate architectural patterns with regards to given (quality) requirements for the system-to-be. The process uses problem frames for modeling requirements and relates requirements to architectural patterns by means of a question catalog. The answers to the questions indicate suitable architectural pattern candidates. The final decision making about the pattern to be used is supported with several steps and also takes tactics and their applicability for a pattern into account. This way, our proposed process connects requirements and architecture, guides even less experienced software engineers through the pattern selection process, provides support for decision making, and makes the decision rationale transparent. The expected target audience for this paper consists of both experienced and less-experienced software architects.