The 1st International Workshop on Conceptual Modeling in Requirements and Business Analysis

There is a new workshop on requirements and business analysis, the 1st International Workshop on Conceptual Modeling in Requirements and Business Analysis. The workshop is collocated with the 2014 International Conference on Conceptual Modeling (ER 2014).

From the Call for Papers:

The MReBA workshop aims to provide a forum for discussing the interplay between Requirements Engineering topics and conceptual modeling, and in particular how requirements modeling can be effectively used as part of business analysis and systems engineering. We ask: What are the fundamental objectives and premises of requirements engineering and conceptual modelling respectively, and how can they complement each other? What conceptual modelling techniques can be taken advantage of in requirements engineering? How can RE modeling be applied successfully in a business environment? What lessons are there to be learnt from industrial experiences? What empirical data are there to support the cost-benefit analysis when adopting RE modeling methods? Are there applications domains or types of project settings for RE/BA modeling approaches are particularly suitable or not? What degree of formalization and automation or interactivity are feasible and appropriate for what types of participants during RE/BA modeling?





The Requirements Problem for Adaptive Systems

What is the design and decision-making problem to solve, when engineering adaptive systems?

With Alexander Borgida at Rutgers, Neil Ernst at the Software Engineering Institute Carnegie Mellon University, and John Mylopoulos at University of Trento, I proposed a statement of this problem, and a formal language to represent the problem and its solutions. The paper will be published at the ACM Transactions on Management Information Systems.

The abstract is below. I will post the paper as soon as ACM publishes it.

Requirements Engineering (RE) focuses on eliciting, modelling, and analysing the requirements and environment of a system-to-be in order to design its specification. The design of the specification, known as the Requirements Problem (RP), is a complex problem solving task, as it involves, for each new system, the discovery and exploration of, and decision making in a new problem space.

A system is adaptive if it can detect deviations between its runtime behaviour and its requirements, specifically situations where its behaviour violates one or more of its requirements. Given such a deviation, an Adaptive System uses feedback mechanisms to analyse these changes and decide, with or without human intervention, how to adjust its behaviour as a result.

We are interested in defining the Requirements Problem for Adaptive Systems (RPAS). In our case, we are looking for a configurable specification such that whenever requirements fail to be fulfilled, the system can go through a series of adaptations that change its configuration and eventually restore fulfilment of the requirements.

From a theoretical perspective, this paper formally shows the fundamental differences between standard RE (notably Zave & Jackson) and RE for Adaptive Systems (see the seminal work by Fickas & Feather, Letier & van Lamsweerde, Whittle et al.). The main contribution of this paper is to introduce the RPAS as a new RP class that is specific to Adaptive Systems. We relate the RPAS to RE research on the relaxation of requirements, the evaluation of their partial satisfaction, and the monitoring and control of requirements, all topics of particular interest in research on adaptive systems.

From an engineering perspective, we define a proto-framework for solving RPAS, which illustrates features needed in future frameworks for adaptive software systems.





Topic importance in requirements elicitation interviews

Daniel Huntington, The Atlantic Cable Projectors

Consider this problem:

A new system needs to be made, say, some software, and you need to define what it should do. There are different people who are investing in it, who will use it, and others, so you need to interview them all, to understand what they expect from this system.

What topics do you discuss with them, at these interviews?

A common way to start making new systems (software or otherwise), or changing existing ones, is to interview stakeholders – investors, users, and others – to try to understand their expectations; in technical terms, to elicit their requirements.

Requirements elicitation often involves interviews.

One difficulty when preparing interviews, is to decide which topics to cover, and how.

If you let the stakeholders talk spontaneously, they may privilege some topics, and not mention others. Yet it could be that the overlooked information is important.

Corentin Burnay, Stéphane Faulkner, and I attacked this problem by trying to understand what topics stakeholders tend to spontaneously talk about, and which others they tend to discuss only if they are asked.

The result, which is based both on theoretical research and exploratory empirical results, is what we called the Elicitation Topic Map (see below). It shows many topics, and how likely the stakeholders (in our sample) tended to spontaneously share information about them.

In the Elicitation Topic Map, the closer a topic is to the marker “Explicit”, the more likely it will be discussed spontaneously by stakeholders. The closer it is to “Implicit”, the less likely it is going to be discussed, unless the interviewer proactively mentions it and asks questions about it.

Elicitation Topic Map

The Elicitation Topic Map nicely illustrates that many topics can be overlooked, unless the interviewer is proactive in asking questions on them; these are the topics that stakeholders tend not to talk about spontaneously. It makes sense to prepare questions on them, before going into interviews.

Details of this research are in the following paper:

Corentin Burnay, Ivan Jureta, Stéphane Faulkner. An Exploratory Study of Topic Importance in Requirements Elicitation Interviews. 26th International Conference on Advanced Information Systems Engineering. 2014.





At le Lambermont, with Elio Di Rupo and François Englert

IMG_0017

It was a pleasure and an honor to be invited to the reception that the Prime Minister of Belgium organised for a selection of Belgian scientists, together with the Fonds de la Recherche Scientifique – FNRS. The reception took place at le Lambermont in Brussels, on November 25, 2013.

It was great to see François Englert in person there; he shared the 2013 Nobel prize in physics with Peter Higgs.

IMG_0013





Requirements problem and solution concepts for adaptive systems

Below are the slides for my talk at Engineering Adaptive Software Systems (EASSy) meeting, from Mon 9 Sep 2013 to Thu 12 Sep 2013 in Shohan, near Tokyo, Japan. It is organized by the National Institute of Informatics Japan.

Talk abstract

When we do Requirements Engineering (RE) for adaptive systems, are we doing RE as usual? Do adaptive systems pose new challenges to RE? If yes, what kinds of challenges are these? The talk gives preliminary answers to these questions.

The main argument of the talk, is that the requirements problem and solution concepts for adaptive systems are different from the de facto standard problem and solution concepts in RE, introduced by Pamela Zave and Michael Jackson in their seminal 1997 ACM Transactions on Software Engineering and Methodology paper, “Four dark corners of requirements engineering”. In the talk, I argue that the solution concept in adaptive systems RE is not a single specification as in Zave & Jackson’s requirements problem, but more specifications along with evolution requirements that impose constraints on which specifications we can switch between at runtime, whereby switching occurs when we observe that the system has failed to satisfy requirements to the desired extent. I relate this to key ideas in RE for adaptive systems, including monitoring, feedback loops, probabilistic relaxation, fuzzy relaxation, and evolution
requirements.





next