Ivan J. Jureta

• PhD
• Chercheur qualifie at University of Namur

The last decade has seen an increasing number of online social network (OSN) users. As they grew more and more popular over the years, OSNs became also more and more profitable. Indeed, users share a considerable amount of personal information on these sites, both intentionally and unintentionally. And thanks to this enormous user base, social netw...

Disease control through Online Social Networks (OSNs) has become particularly relevant in the past few months. Given the sensitive nature of the data collected and manipulated in that context, a major concern for (potential) users of such surveillance applications is privacy. The concept of privacy has been studied from many different angles and th...

Blockchain has been one of Gartner’s Top 10 Strategic Technology Trends for several consecutive years. The technology has evolved from a platform allowing transactions of cryptocurrency between peers (e.g. Bitcoin) to a platform allowing the design of Decentralized Applications (DApps). Despite their growing popularity, little attention has been pa...

What are the necessary and sufficient conditions for a proposition to be called a requirement? In Requirements Engineering research, a proposition is a requirement if and only if specific grammatical and/or communication conditions hold. I offer an alternative, that a proposition is a requirement if and only if specific contractual, economic, and e...

In requirements engineering (RE), an early yet critical activity consists in eliciting the requirements from various stakeholders, who usually have different assumptions, knowledge, and intentions. The goal during elicitation is to understand what stakeholders expect from a given software, expectations which then feed the analysis, prioritization,...

Business Intelligence (BI) intends to provide business managers with timely information about their company. Considerable research effort has been devoted to the modeling and specification of BI systems, with the objective to improve the quality of resulting BI output and decrease the risk of BI projects failure. In this paper, we focus on the spec...

Online social networks (OSNs) such as Facebook and LinkedIn are now widely used. They count users in the hundreds of millions. This chapter surveys popular social networks in order to present a pattern of recurring functional requirements as well as non-functional requirements, and a model of that pattern in the i* requirements modelling language....

The last decade has seen an increasing number of online social network (OSN) users. As they grew more and more popular over the years, OSNs became also more and more profitable. Indeed, users share a considerable amount of personal information on these sites, both intentionally and unintentionally. And thanks to this enormous user base, social netw...

Several techniques can be used to solve multi-criteria decision making (MCDM) problems and to provide a global ranking of the alternatives considered. However, in a context with a high number of alternatives and where decision criteria relate to soft goals, the decision problem is particularly hard to solve. This paper analyzes the use of artificia...

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 pro...

I assume in this paper that the proposition “I cannot know your intentional states” is true. I consider its consequences on the use of so-called “intentional concepts” for Requirements Engineering. I argue that if you take this proposition to be true, then intentional concepts (e.g., goal, belief, desire, intention, etc.) start to look less relevan...

I assume in this paper that the proposition "I cannot know your intentional states" is true. I consider its consequences on the use of so-called "intentional concepts" for Requirements Engineering. I argue that if you take this proposition to be true, then intentional concepts (e.g., goal, belief, desire, intention, etc.) start to look less relevan...

This paper focuses on improving requirements quality in agile projects by determining requirements prioritization. Current methods suggest to take into account business value in order to determine the requirements priority rank. In practice it was observed that many other factors enter into the equation, such as implementation cost and functionalit...

The last decade has seen an increasing number of Online Social Network OSN users. As they grew more and more popular over the years, OSNs become also more and more profitable. Indeed, users share a considerable amount of personal information on these sites, both intentionally and unintentionally. And thanks to this enormous user base, social networ...

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...

A significant proportion of organizations delivering it services follows and combines some it management frameworks. At the organizational level, they often act in accordance with itil, the most used it service management (itsm) framework. At the project management level, a growing part of them are willing to work with agile methods. However, itil...

Requirements Elicitation (RE) consists in collecting requirements for a future system. It involves engineers who are eliciting information, and stakeholders who are involved in the project to provide information. This research note aims to stimulate research about the impact of stakeholders' commitment on RE. We define commitment, discuss how it ca...

Online Social Networks (OSNs), such as Facebook and LinkedIn, are now widely used. They count users in the hundreds of millions. This paper surveys popular OSNs in order to identify and present a pattern of recurring requirements, and a model of that pattern in the i-star requirements modelling language. The pattern can serve as a starting point fo...

Valuation consists of associating variables to model parts, and functions to relations over the model parts. The aim is to have models where values of some variables depend on the values of others. Given the values of some, you can then compute those of others. Value type, value assignment, and outcome are central notions in valuation. A value type...

This chapter focuses on how to have models with constraints over value assignments which are richer than mutual exclusion from Chap. 12. Here are some constraints other than mutual exclusion: If x and z are both satisfied, then the implementation cost of y should double. If x is not acceptable, then estimated revenue from y will decrease by 30 %. I...

This chapter presents several genuine problem situations . For some, it outlines the outcomes of only the very first steps of requirements problem solving. One case is used to illustrate the languages defined in this book and the others are given as exercises. In later chapters, there is typically a definition of a requirements modeling language ,...

What if you need models to say that a value assignment is uncertain, and to quantify that uncertainty? What if models need to include random variables? This chapter focuses on how to represent that value assignments to model parts are uncertain. This is done by allowing random variables to be associated with model parts, and defining probability sp...

Requirements engineering designates both the rigorous practice of requirements problem solving and the field of research that studies this practice and ways to improve it. This chapter connects the ideas discussed in Chaps. 1 and 2 to the basic ideas and terminologies of requirements engineering. This is important because various requirements model...

This chapter clarifies what requirements problem solving is. Section 1.1 gives reasons why it is interesting to study requirements problem solving and learn how to create artificial intelligence, which automates tasks of requirements problem solving. Sections 1.2–1.4 give the characteristics of requirements problem solving, by describing the proble...

When there are several outcomes, all of which include a pick you are interested in, which one of these outcomes do you choose? How do you choose it? Which one is the “best”? What tells you, in a model, if an outcome is “better” than another? This chapter focuses on how to enable languages to represent preferences and criteria, and then identify the...

This chapter is on how to define guidelines for problem solving in requirements modeling languages . Guidelines recommend how to do something in problem solving so as to move closer to a solution. The chapter focuses on the following questions. 1. How to find guidelines for problem solving and embed them in requirements modeling languages (Sect. 8....

This chapter focuses on how to represent mutual exclusion in models. If parts A and B in a model are mutually exclusive and the model represents one or more problem and/or solution instances, then none of these problems and solutions includes both A and B. In such a model, it may be that some problem (or solution) instances include A, others only B...

Requirements modeling languages are formal languages specialized for use in requirements problem solving. This chapter clarifies what a formal language is normally made of, and explains its role in problem solving in general. To give a clearer idea of where requirements modeling languages come from and look like, this chapter gives a rough historic...

This chapter presents three simple tools called language checklists, templates, and services, and explains why and how they are used in this book. They help make it manageable to define many languages, compare them, and carry their features from one to another. Language checklists give items to include in a definition of a requirements modeling lan...

This chapter looks at why and how to organize fragments into categories. “Requirement,” “domain knowledge,” “specification,” “goal,” and so on are examples of recurrent categories in requirements engineering. I focus on the following issues, moving from simpler to more complicated topics on categories. 1. Why and how to use independent categories....

This chapter deals with how to relate languages in this book to formal logics. The convention in the chapter is that a formal theory, or simply a theory, is a name for a set of formulas with no free variables in some formal logic. So how can you map (parts of) models to theories, and why should we do so? Relationships between requirements modeling...

This chapter is about defining relations over bits and pieces of information used in problem solving. The discussion revolves around how to define individual relations, issues in defining languages that have many relations, and on two requirements engineering concerns, called influence and rationale below, which have usually been addressed via spec...

This chapter connects requirements problem solving with central ideas and terminology of problem solving and artificial intelligence. Section 2.1 clarifies what automation means in this book, and why it is interesting to automate tasks in requirements problem solving. Section 2.2 argues that requirements problem solving is one type of ill-structure...

Over the last decade, online social networks (OSNs) have been growing quickly to become some of the largest systems in use. Their users are sharing more and more content, and in turn have access to vast amounts of information from and about each other. This increases the risk of information overload for every user. We define a set of event types, w...

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 explorati...

Requirements elicitation consists in collecting information about the requirements and the environment of a system-to-be. It usually involves business analysts who are eliciting information, and stakeholders who are providing information. This paper investigates how the commitment of stakeholders to a RE project influences the results of elicitatio...

Requirements elicitation is the activity in requirements engineering (RE) which focuses on the collection of information about requirements of the system-to-be and its environment. One important challenge is elicitation incompleteness; it occurs when information, which may have been relevant for requirements engineering, is not elicited. This may b...

Many organizations providing it services try to be service-oriented at the business layer and at the it layer. To do so, these organizations follow a service-orientation for their management and business processes while working with a service-oriented system (sos). This should improve, i.a., their work organization during the service implementation...

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 explicitl...

Changing requirements are common in today's organizations, and have been a central concern in Requirements Engineering (RE). Over time, methods have been developed to deal with such variability. Yet, the latter often require considerable amount of time to be applied. As time-to-value is becoming a critical requirement of users, new types of systems...

The problem of regulatory compliance for a software system consists of ensuring through a systematic, tool-supported process that the system complies with all elements of a relevant law. To deal with the problem, we build a model of the law and contrast it with a model of the requirements of the system. In earlier work, we proposed a modelling lang...

Bringing together the ICT and the business layer of a service-oriented system (SoS) remains a great challenge. Few papers tackle the management of SoS from the business and organizational point of view. One solution is to use the well-known ITIL v.3 framework. The latter enables to transform the organization into a service-oriented organizational w...

This paper proposes requirements patterns for Online Social Networks (OSNs). Patterns are based on features observed on currently popular OSNs, and are defined as i-star models. Patterns are relevant for the requirements engineering of new OSNs. They can help in requirements elicitation, in order to avoid missing important OSN requirements. They ca...

Innovative companies need an agile approach towards product and service requirements, to rapidly respond to and exploit changing conditions. The agile approach to requirements must nonetheless be systematic, especially with respect to accommodating legal and non-functional requirements. This paper examines how to support lightweight, agile requirem...

Interviewing stakeholders is a common way to elicit information about requirements of the system-to-be and the conditions in its operating environment. One difficulty in preparing and doing interviews is how to avoid missing the in-formation that may be important to understand the requirements and environment conditions. Some information may remain...

Business intelligence (BI) is perceived as a critical activity for organizations and is increasingly discussed in requirements engineering (RE). RE can contribute to the successful implementation of BI systems by assisting the identification and analysis of such systems’ requirements and the production of the specification of the system to be. With...

New business models are set up, thanks to Web technologies. In this work, we focus on services intermediary companies. They generate value through the (automatic) selection of third-party services and the (automatic) delivery of the combinations of these services to consumers. Such companies face the problem of deciding which services to select and...

Knowledge-Base Recommendation (or Recommender) Systems (KBRS) provide the user with advice about a decision to make or an action to take. KBRS rely on knowledge provided by human experts, encoded in the system and applied to input data, in order to generate recommendations. This survey overviews the main ideas characterizing a KBRS. Using a classif...

Requirements Engineering (RE) focuses on eliciting, modeling, and analyzing 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 because it involves, for each new system, the discovery and exploration of, an...

Assessing the development costs of an application remains an arduous task for many project managers. Using new technologies and specific software architectures makes this job even more complicated. In order to help people in charge of this kind of work, we propose a model for estimating the effort required to implement a service-oriented system. It...

Changing requirements are widely regarded as one of the most significant risks for software systems development. However, in today’s business landscape, these changing requirements also represent opportunities to exploit new and evolving business conditions. In consonance with other agile methods, we advocate requirements engineering techniques tha...

As software engineers create and evolve information systems to support business practices, these engineers need to address constraints imposed by laws, regulations and policies that govern those business practices. Requirements modeling can be used to extract important legal constraints from laws, and decide how, and evaluate if an information syst...

When implementing (semi-)automatic business processes with services, engineers are facing two sources of variability. One source of variability are alternative refinements and decompositions of requirements. The other source of variability is that various (combinations of) services can be used to satisfy the same requirements. We suggest a method b...

[Context and motivation] Compliance to relevant laws is increasingly recognized as a critical, but also expensive, quality for software requirements. [Question/Problem] Laws contain elements such as conditions and derogations that generate a space of possible compliance alternatives. During requirements engineering, an analyst has to select one of...

When eliciting requirements, it is important to understand why some information may remain implicit, while other are shared by stakeholders. This requires knowing which variables influence if an individual shares implicit information during requirements elicitation. Based on our past experimental work on decision-making, we identify variables - Con...

In Requirements Engineering, requirements elicitation aims the acquisition of information from the stakeholders of the system-to-be. An important task during elicitation is to identify and render explicit the stakeholders' implicit assumptions about the system-to-be and its environment. Purpose of doing so is to identify omissions in, and conflicts...

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 Intelligen...

Norms such as laws and regulations are an additional source of requirements as they cause domain actors to modify their goals to reach compliance. However, norms can not be modeled directly as goals because of both an ontological difference, and an abstraction gap that causes the need to explore a potentially large space of alternatives. This paper...

Regulatory compliance is increasingly viewed as an essential element of requirements engineering. Laws, but also regulations and policies, frame their provisions through complex structures made of conditions, derogations, exceptions, which together generate a high number of alternative compliance solutions. This paper addresses the problem of model...

In this paper we propose a mathematical program able to optimize the product portfolio scope of a software product line and sketch both a development and a release planning. Our model is based on the description of customer needs in terms of goals. We show that this model can be instantiated in several contexts such as a market customization strate...

Innovative companies need an agile approach for the engineering of their product requirements, to rapidly respond to and exploit changing conditions. The agile approach to requirements must nonetheless be systematic, especially with respect to accommodating legal and nonfunctional requirements. This paper examines how to support a combination of li...

The engineering of a service-oriented system requires the specification of functions that Web services (WSs) should provide, before WSs are built or selected. Written in a service description language, the service specification instantiates concepts different than those used for requirement engineering (RE): the former speaks in terms of operations...

[Context and motivation] Self-adaptive systems (SAS) monitor and adapt to changing end-user requirements, operating context conditions, and resource availability. Specifying requirements for such dynamic systems is not trivial. Most of the research on self-adaptive systems (SAS) focuses on finding solutions to the requirements that SAS is built for...

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 d...

Business intelligence (BI) systems gather, store, and process data to turn it into information that ismeaningful and relevant for decision-making in businesses and organizations. Successful engineering, use, and evolution of BI systems require a deep understanding of the requirements of decision-making processes in organizations, of the kinds of in...

This paper investigates aspects of the problem of software evolution resulting from top-level requirements change. In particular, while most research on design for software focuses on finding some correct solution, this ignores that such a solution is often only correct in a particular, and often short-lived, context. Using a logic-based goal-orien...

The vision for self-adaptive systems (SAS) is that they should continuously adapt their behavior at runtime in response to changing user’s requirements, operating contexts, and resource availability. Realizing this vision requires that we understand precisely how the various steps in the engineering of SAS depart from the established body of knowle...

This paper introduces a mixed modeling and argumentation framework applied to assess the compliance of requirements with legal norms, and reports the results of its application in an industrial project in healthcare. Domain experts applied a goal-oriented modeling framework for the representation of requirements and norms, then used argumentation t...

A service-oriented system should be engineered to satisfy the requirements of its stakeholders. Requirements are understood in terms of stakeholder goals, softgoals, quality constraints, preferences, tasks, and domain assumptions. The service-oriented system is viewed in terms of services, mediators, choreographies, and orchestrations, among others...

The requirements roadmap concept is introduced as a solution to the problem of the requirements engineering of adaptive systems. The concept requires a new general definition of the requirements problem which allows for quantitative (numeric) variables, together with qualitative (binary boolean) propositional variables, and distinguishes monitored...

Five arguments were presented and defended in this book. The first argument is that advice is a tool of coordination. Analysis of advice is thereby a way to understand certain aspects of mechanisms of coordination, and in particular to study the characteristics of information that is exchanged as advice within such mechanisms. Design of advice is i...

Most people only very rarely know exactly what they are talking about. If this were so, then it would only ensue that their advice is very rarely worth much.

A photograph shows a woman’s face out of focus; she holds her index finger in front of it, pointing up. Her finger is covered from its tip onwards up to about one-third of its length in indelible black ink (Marai 2009). Her dignified expression is closest perhaps to indifference. The face is carefully veiled. Her brown eyes look straight into the c...

It is common to hear advice being qualified as good or bad. Advisors’ reputation may depend on such qualifications, and consequently their current and future public’s acceptance of the advice they dispense. To be good, advice should presumably lead the recipient to achieve the desired consequences in his decision situation. Advice could also be cal...

An engineered ontology is an essential part of any set of assertions produced toward explanation and prediction. It is an integral part of any theory, regardless of it being scientific. To perform its explanatory and predictive roles, a theory must include a language through which it points to, refers to universals and particulars, concepts and phe...

Three processes shape developed contemporary societies and give the analysis of advice its central role: the advancing division of labor, the widening field of personal decision, and the decreasing cost of distributing information.

The premise that giving advice is a design problem is central to this book. It means that advice is seen as an artefact, as information communicated by an advisor to an advisee. Drawing on arguments in philosophy, recent empirical research in individual and group decision-making, and in information systems engineering, the book offers a rigorous ap...

As for other information systems, Service-Oriented Systems (SOSs) should be engineering to satisfy the requirements of its stakeholders. But, while requirements are understood in terms of, e.g., goals and assumptions, services are viewed in terms of, e.g., preconditions and effects. In order to reduce the gap between those two conceptualizations, w...

The growth of Web 2.0 encouraged the consideration not only of technological and content aspects but also the social interactions and its relational aspects. Researches in the academic context also have followed this trend. Methods and applications have ...

Of particular concern in requirements engineering is the selection of requirements to implement in the next release of a system. To that end, there has been recent work on multi-objective optimization and user-driven prioritization to support the analysis of requirements trade-offs. Such work has focused on simple, linear models of requirements; in...

The engineering of a web service-oriented system requires the specification of the functions that the various Web Services (WSs) should provide, before WSs are either built or selected. Being written in a service description language, the service specification instantiates concepts different than those of interest during the requirement engineering...

Techne is an abstract requirements modeling language that lays formal foundations for new modeling languages applicable during early phases of the requirements engineering process. During these phases, the requirements problem for the system-to-be is being structured, its candidate solutions described and compared in terms of how desirable they are...

Service Level Agreements (SLAs) are used in Service- Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define these obligations, including for instance the expected service levels to be delivered by the provider, and the payment expected from the client. The obligations of the parties must be made explicit...

Regulatory compliance is increasingly being addressed in the practice of requirements engineering as a main stream concern. This paper points out a gap in the theoretical foundations of regulatory compliance, and presents a theory that states (i) what it means for requirements to be compliant, (ii) the compliance problem, i.e., the problem that the...

A requirements engineering artifact is valid relative to the stakeholders of the system-to-be if they agree on the content of that artifact. Checking relative validity involves a discussion between the stakeholders and the requirements engineer. This paper proposes (I) a language for the representation of information exchanged in a discussion about...

A requirements engineering artifact is valid relative to the stakeholders of the system-to-be if they agree on the content of that artifact. Checking relative validity involves a discussion between the stakeholders and the requirements engineer. This paper proposes (i) a language for the representation of information exchanged in a discussion about...

In a service-oriented system, a quality (or Quality of Service) model is used (i) by service requesters to specify the expected quality levels of service delivery; (ii) by service providers to advertise quality levels that their services achieve; and (iii) by service composers when selecting among alternative services those that are to participate...

This paper advocates that WS compositions optimal w.r.t. a set of criteria need to be learned at runtime and revised as new WS appear and availability of old WS changes, whereby the learning should be based on observed WS performance, and not the performance values advertised by the service providers. To enable such learning, a selection procedure...

In their seminal paper (ACM T. Softw. Eng. Methodol., 6(1) (1997), 1-30), Zave and Jackson established a core ontology for Requirements Engineering (RE) and used it to formulate the "requirements problem", thereby defining what it means to successfully complete RE. Starting from the premise that the stakeholders of the system-to-be communicate to t...

Today, a high volume of goods and services is being traded using online auction systems. The growth in size and complexity of architectures to support online auctions requires the use of distributed and cooperative software techniques. In this context, the agent software development paradigm seems appropriate for their modeling, development, and im...

In their seminal paper in the ACM Transactions on Software Engineering and Methodology, Zave and Jackson established a core ontology for Requirements Engineering (RE) and used it to formulate the "requirements problem", thereby defining what it means to successfully complete RE. Given that stakeholders of the system-to-be communicate the informatio...

Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g.,...

Analysis of temporal properties of nonfunctional – i.e., quality – requirements (NFRs) has not received significant attention. In response, this paper introduces basic concepts and techniques needed for the specification and analysis of time properties of NFRs.

A pluripotent information system is an open and distributed information system that (i) automatically adapts at runtime to changing operating conditions, and (ii) satisfies both the requirements anticipated at development time, and those unanticipated before but relevant at runtime. Engineering pluripotency into an information system therefore resp...

In a service-oriented system (SoS) service requests define tasks to execute and quality of service (QoS) criteria to optimize. A service request is submitted to an automated service selector in the SoS, which allocates tasks to those service that, together, can "best" satisfy the given QoS criteria. When the selector cannot optimize simultaneously...