Alexei Lapouchnian

Requirements-driven design and configuration management of business processes

The success of a business process (BP) depends on whether it meetsits business goal as well as non-functional requirements associated with it. BPspecifications frequently need to accommodate changing business priorities,varying client preferences, etc. However, since business process goals and preferencesare Rarely captured explicitly in the dominant BP modeling approaches,adapting business processes proves difficult. We propose a systematic requirements-driven approach for BP design and configuration management that usesrequirements goal models to capture alternative process configurations and providesthe ability to tailor deployed processes to changing business priorities orcustomer preferences (i.e., non-functional constraints) by configuring their correspondinggoal models at the goal level. A set of design time and runtime toolsfor configuring business processes implemented using WS-BPEL is provided,allowing to easily change the behaviour of deployed BP instances at a highlevel, based on business priorities and stakeholder preferences.

Awareness requirements for adaptive systems

Recently, there has been a growing interest in self-adaptive systems. Roadmap papers in this area point to feedback loops as a promising way of operationalizing adaptivity in such systems. In this paper, we define a new type of requirement - called Awareness Requirement - that can refer to other requirements and their success/failures. We propose a way to elicit and formalize such requirements and offer a requirements monitoring framework to support them.

Requirements-driven design of autonomic application software

Autonomic computing systems reduce software maintenance costs and management complexity by taking on the responsibility for their configuration, optimization, healing, and protection. These tasks are accomplished by switching at runtime to a different system behaviour - the one that is more efficient, more secure, more stable, etc. - while still fulfilling the main purpose of the system. Thus, identifying the objectives of the system, analyzing alternative ways of how these objectives can be met, and designing a system that supports all or some of these alternative behaviours is a promising way to develop autonomic systems. This paper proposes the use of requirements goal models as a foundation for such software development process and demonstrates this on an example.

Towards requirements-driven autonomic systems design

Autonomic computing systems reduce software maintenance costs and management complexity by taking on the responsibility for their configuration, optimization, healing, and protection. These tasks are accomplished by switching at runtime to a different system behaviour - the one that is more efficient, more secure, more stable, etc. - while still fulfilling the main purpose of the system. Thus, identifying and analyzing alternative ways of how the main objectives of the system can be achieved and designing a system that supports all of these alternative behaviours is a promising way to develop autonomic systems. This paper proposes the use of requirements goal models as a foundation for such software development process and sketches a possible architecture for autonomic systems that can be built using the this approach.

From goals to high-variability software design

Software requirements consist of functionalities and qualities to be accommodated during design. Through goal-oriented requirements engineering, stakeholder goals are refined into a space of alternative functionalities. We adopt this framework and propose a decision-making process to generate a generic software design that can accommodate the full space of alternatives each of which can fulfill stakeholder goals. Specifically, we present a process for generating complementary design views from a goal model with high variability in configurations, behavioral specifications, architectures and business processes.

Reverse engineering goal models from legacy code

A reverse engineering process aims at reconstructing high-level abstractions from source code. This paper presents a novel reverse engineering methodology for recovering stakeholder goal models from both structured and unstructured legacy code. The methodology consists of the following major steps: 1) Refactoring source code by extracting methods based on comments; 2) Converting the refactored code into an abstract structured program through statechart refactoring and hammock graph construction; 3) Extracting a goal model from the structured programs abstract syntax tree; 4) Identifying nonfunctional requirements and derive soft goals based on the traceability between the code and the goal model. To illustrate this requirements recovery process, we refactor stakeholder goal models from two legacy software code bases: an unstructured Web-based email in PHP (SquirrelMail) and a structured email client system in Java (Columba).

Configuring features with stakeholder goals

Goal models are effective in capturing stakeholder needs at the time when features of the system-to-be have not yet been conceptualized. Relating goals to solution-oriented features gives rise to a requirement traceability problem. In this paper, we present a new model-driven extension to an Early Requirements Engineering tool (OpenOME) that generates an initial feature model of the system-to-be from stakeholder goals. Enabled by such generative mapping, configuration constraints among variability features can be obtained by reasoning about stakeholder goals.

Configuring common personal software: a requirements-driven approach

We investigate the personalization capabilities of common personal software systems. We use a typical e-mail client as an example of such a system, and examine the configuration screens it offers to its users. We discover that each configuration value reflects each of the ways with which the user goals can be satisfied. Thus, we construct a goal model in which alternative ways for satisfying high level goals are matched with alternative system configurations. This way, automatic configuration of the system by reasoning about the overlaying goal model can be achieved. We find that the vast majority of the configuration options that refer to system functionality can be configured using this method, facilitating thereby the personalization tasks for users with no technical background, and ensuring, at the same time, consistency and meaningfulness in the configuration result.

Modeling Domain Variability in Requirements Engineering with Contexts

Various characteristics of the problem domain define the context in which the system is to operate and thus impact heavily on its requirements. However, most requirements specifications do not consider contextual properties and few modeling notations explicitly specify how domain variability affects the requirements. In this paper, we propose an approach for using contexts to model domain variability in goal models. We discuss the modeling of contexts, the specification of their effects on system goals, and the analysis of goal models with contextual variability. The approach is illustrated with a case study.

System identification for adaptive software systems: a requirements engineering perspective

Control Theory and feedback control in particular have been steadily gaining momentum in software engineering for adaptive systems. Feedback controllers work by continuously measuring system outputs, comparing them with reference targets and adjusting control inputs if there is a mismatch. In Control Theory, quantifying the effects of control input on measured output is a process known as system identification. This process usually relies either on detailed and complex system models or on system observation. In this paper, we adopt a Requirements Engineering perspective and ideas from Qualitative Reasoning to propose a language and a systematic system identification method for adaptive software systems that can be applied at the requirements level, with the system not yet developed and its behavior not completely known.