What stakeholders will or won׳t say: A theoretical and empirical study of topic importance in Requirements Engineering elicitation interviews

We have a new paper out:

Corentin Burnay, Ivan J. Jureta, Stéphane Faulkner, What stakeholders will or won׳t say: A theoretical and empirical study of topic importance in Requirements Engineering elicitation interviews, Information Systems, Available online 2 June 2014, ISSN 0306-4379, http://dx.doi.org/10.1016/j.is.2014.05.006.
(http://www.sciencedirect.com/science/article/pii/S0306437914000908)

Abstract: Interviewing stakeholders is a way to elicit information about requirements for a system-to-be. A difficulty when preparing such elicitation interviews is to select the topics to discuss, so as to avoid missing important information. Stakeholders may spontaneously share information on some topics, but remain silent on others, unless asked explicitly. We propose the Elicitation Topic Map (ETM) to help engineers in preparing interviews. ETM is a diagram showing topics that may be discussed during interviews, and shows how likely stakeholders discuss each of these topics spontaneously. If a topic is less likely to be discussed spontaneously, then this suggests that engineers may want to prepare questions on it, before the interview. ETM was produced through theoretical and empirical research. The theoretical part consisted of identifying topic sets based on a conceptual model of communication context, grounded in philosophy, artificial intelligence, and computer science. The empirical part involved interviews with Requirements Engineering professionals to identify the topic sets and topics in each set, surveys of business people in order to evaluate how likely they would spontaneously share information about topics, and evaluations of how likely students would share information about each topic, when asked about requirements for social network websites.

Keywords: Requirements Engineering; Elicitation; Interview; Context; Topic Map; Quantitative study; Social network

A talk outline that starts with questions, ends with answers

Typical talks / presentations that I happen to attend go like this:

  1. We are doing research on X;
  2. Here is what we did, in detail;
  3. Q&A.

This is fine IF I already know exactly 1) what the problem is, AND 2) why it matters to solve that problem.

Why would I pay attention if I don’t?

In most cases I don’t. And this is not because I am dumb, arrogant, etc., but because we are probably not working on exactly the same problems, or I have simply not identified that problem, or if I did, I don’t find it motivating enough to dedicate time to it (i.e., we do not have the same priorities).

I would much rather prefer that you motivate me to think about that problem, before you tell me what you did about it.

And if you could do it via commonsense notions and vocabulary, I’d be more than happy. Because jargon is too often just a mask for incompetence.

A nicer outline would be:

  1. Suppose you, the person in the audience, are in the situation X… (add a photo or two, to make it more concrete);
  2. …and the problem you have is Y;
  3. Think about how you would solve it;
  4. Who (what groups of people) need to solve such problems?
  5. What are the typical ways in which others have been solving such problems so far?
  6. Here is how we solved it;
  7. Here is what is nice, and what doesn’t work in what w did;
  8. Go to (say where), or read (say what) if you want to know more;
  9. Q&A.

Not very hard to do.

Decision Analysis & Problem-solving course, the 2013-2014 edition

I wrote and taught the Decision Analysis & Problem-solving course for the first time in the second semester of 2013-2014. The audience were students in the MSc programme in Information Management, at the Department of Business Administration, University of Namur. This course replaced my Knowledge Representation and Reasoning for Business Analysis course.

Purpose of the course

To introduce students to concepts and techniques of decision analysis and problem-solving, which are relevant for doing business analysis.

Target audience

MSc and PhD-level students interested in:

  • Business analysis;
  • Management consulting;
  • Systems engineering.

Course & lecture format

Approximately 12 lectures.

Each 120-minute lecture is divided in 6 parts:

  • Problem: 5 to 10-minute presentation of a problem;
  • Theory: 60 to 80-minute presentation of problem-related theories;
  • Break: 5 to 10-minute break;
  • Paper: 20-minute paper presentation by a student;
  • Discussion: 10 to 20-minute paper discussion by everyone;
  • Solution: 10 to 20-minute discussion of how to solve the problem.

In the first four weeks, students are divided into pairs, each pair gets a Harvard Business School case, and a question. They have three weeks to produce an answer, that is a recommendation.

In the last four weeks, students are asked to write an essay on a topic. They get a list of suggested topics, and can choose one, or suggest one of their own.

Reading list

The reading list includes mandatory and optional readings, mostly classical papers on decision theory, decision analysis, and empirical research on decision making and problem-solving.

Slides

  1. Course basics
  2. The business & IT alignment challenge
  3. Decision Analysis basics
  4. Business Analysis basics
  5. A business analysis method
  6. Preparation and elicitation
  7. Rigorous definition
  8. Conceptual modelling
  9. Ontology engineering

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

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