Ivan Jureta

Corentin Burnay, Ivan Jureta

The overall objective of Requirements Engineering is to specify, in a systematic way, a system that satisfies the expectations of its stakeholders. Despite tremendous effort in the field, recent studies demonstrate this is objective is not always achieved. In this paper, we discuss one particularly challenging factor to Requirements Engineering projects, namely the change of requirements. We proposes a rough discussion of how learning and time explain requirements changes, how it can be introduced as a key variable in the formulation of the Requirements Engineering Problem, and how this induces costs for a requirements engineering project. This leads to a new discipline of requirements economics.

Sarah Bouraga, Ivan Jureta, Stéphane Faulkner

This paper addresses the modelling of requirements for a content Recommendation System (RS) for Online Social Networks (OSNs). On OSNs, a user switches roles constantly between content generator and content receiver. The goals and softgoals are different when the user is generating a post, as opposed as replying to a post. In other words, the user is generating instances of different entities, depending on the role she has: a generator generates instances of a "post", while the receiver generates instances of a "reply". Therefore, we believe that when addressing Requirements Engineering (RE) for RS, it is necessary to distinguish these roles clearly. We aim to model an essential dynamic on OSN, namely that when a user creates (posts) content, other users can ignore that content, or themselves start generating new content in reply, or react to the initial posting. This dynamic is key to designing OSNs, because it influences how active users are, and how attractive the OSN is for existing, and to new users. We apply a well-known Goal Oriented RE (GORE) technique, namely i-star, and show that this language fails to capture this dynamic, and thus cannot be used alone to model the problem domain. Hence, in order to represent this dynamic, its relationships to other OSNs' requirements, and to capture all relevant information, we suggest using another modelling language, namely Petri Nets, on top of i-star for the modelling of the problem domain. We use Petri Nets because it is a tool that is used to simulate the dynamic and concurrent activities of a system and can be used by both practitioners and theoreticians.

Ivan Jureta

Requirements Engineering (RE) focuses on eliciting, modelling, and analyzing the requirements and environment of a system-to-be in order to design its specification. The design of the specification, usually called the Requirements Problem (RP), is a complex problem solving task, as it involves, for each new system-to-be, the discovery and exploration of, and decision making in, new and ill-defined problem and solution spaces. The default RP in RE is to design a specification of the system-to-be which (i) is consistent with given requirements and conditions of its environment, and (ii) together with environment conditions satisfies requirements. This paper (i) shows that the Requirements Problem for Adaptive Systems (RPAS) is different from, and is not a subclass of the default RP, (ii) gives a formal definition of RPAS, and (iii) discusses implications for future research.

Corentin Burnay, Ivan Jureta, Stéphane Faulkner

Requirements engineers should strive to get a better insight into decision making processes. During elicitation of requirements, decision making influences how stakeholders communicate with engineers, thereby affecting the engineers' understanding of requirements for the future information system. Empirical studies issued from Artificial Intelligence offer an adequate groundwork to understand how decision making is influenced by some particular contextual factors. However, no research has gone into the validation of such empirical studies in the process of collecting needs of the future system's users. As an answer, the paper empirically studies factors, initially identified by AI literature, that influence decision making and communication during requirements elicitation. We argue that the context's structure of the decision should be considered as a cornerstone to adequately study how stakeholders decide to communicate or not a requirement. The paper proposes a context framework to categorize former factors into specific families, and support the engineers during the elicitation process.

Ivan Jureta

Requirements Engineering Methods (REMs) support Requirements Engineering (RE) tasks, from elicitation, through modeling and analysis, to validation and evolution of requirements. Despite the growing interest to design, validate and teach REMs, it remains unclear what components REMs should have. A classification framework for REMs is proposed. It distinguishes REMs based on the domain-independent properties of their components. The classification framework is intended to facilitate (i) analysis, teaching and extension of existing REMs, (ii) engineering and validation of new REMs, and (iii) identifying research challenges in REM design. The framework should help clarify further the relations between REM and other concepts of interest in and to RE, including Requirements Problem and Solution, Requirements Modeling Language, and Formal Method.