-
Requirements Contracts: Definition, Design, and Analysis
Authors:
Ivan J. Jureta
Abstract:
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 engineering relationships hold. I introduce and def…
▽ More
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 engineering relationships hold. I introduce and define the concept of "Requirements Contract" which defines these conditions. I argue that seeing requirements as propositions governed by specific types of contracts leads to new and interesting questions for the field, and relates requirements engineering to such topics as economic incentives, interest alignment, principal agent problem, and decision-making with incomplete information.
△ Less
Submitted 29 April, 2021;
originally announced April 2021.
-
What If People Learn Requirements Over Time? A Rough Introduction to Requirements Economics
Authors:
Corentin Burnay,
Ivan Jureta
Abstract:
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 propo…
▽ More
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.
△ Less
Submitted 24 November, 2017;
originally announced November 2017.
-
What Happens to Intentional Concepts in Requirements Engineering If Intentional States Cannot Be Known?
Authors:
Ivan J. Jureta
Abstract:
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 relevant (though not irrelevant), despite being the focus…
▽ More
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 relevant (though not irrelevant), despite being the focus of significant research attention over the past three decades. I identify substantial problems that arise if you use instances of intentional concepts to reflect intentional states. I sketch an approach to address these problems. In it, intentional concepts have a less prominent role, while notions of time, uncertainty, prediction, observability, evidence, and learning are at the forefront.
△ Less
Submitted 30 June, 2017;
originally announced June 2017.
-
Modelling Requirements for Content Recommendation Systems
Authors:
Sarah Bouraga,
Ivan Jureta,
Stéphane Faulkner
Abstract:
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, dep…
▽ More
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.
△ Less
Submitted 18 June, 2016;
originally announced June 2016.
-
Requirements Problem and Solution Concepts for Adaptive Systems Engineering, and their Relationship to Mathematical Optimisation, Decision Analysis, and Expected Utility Theory
Authors:
Ivan Jureta
Abstract:
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…
▽ More
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.
△ Less
Submitted 22 July, 2015;
originally announced July 2015.
-
Aligning a Service Provisioning Model of a Service-Oriented System with the ITIL v.3 Life Cycle
Authors:
Bertrand Verlaine,
Ivan J. Jureta,
Stéphane Faulkner
Abstract:
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 which focuses on the value provided to the service…
▽ More
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 which focuses on the value provided to the service customers. In this paper, we align the steps of the service provisioning model with the ITIL v.3 processes. The alignment proposed should help organizations and IT teams to integrate their ICT layer, represented by the SoS, and their business layer, represented by ITIL v.3. One main advantage of this combined use of ITIL and a SoS is the full service orientation of the company.
△ Less
Submitted 12 September, 2014;
originally announced September 2014.
-
Context-Driven Elicitation of Default Requirements: an Empirical Validation
Authors:
Corentin Burnay,
Ivan Jureta,
Stéphane Faulkner
Abstract:
In Requirements Engineering, requirements elicitation aims the acquisition of information from the stakeholders of a 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 between requirements. This paper offers a conceptua…
▽ More
In Requirements Engineering, requirements elicitation aims the acquisition of information from the stakeholders of a 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 between requirements. This paper offers a conceptual framework for the identification and documentation of default requirements that stakeholders may be using. The framework is relevant for practice, as it forms a check-list for types of questions to use during elicitation. An empirical validation is described, and guidelines for elicitation are drawn.
△ Less
Submitted 4 December, 2013; v1 submitted 12 November, 2012;
originally announced November 2012.
-
Influence of Context on Decision Making during Requirements Elicitation
Authors:
Corentin Burnay,
Ivan Jureta,
Stéphane Faulkner
Abstract:
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…
▽ More
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.
△ Less
Submitted 29 October, 2012; v1 submitted 26 October, 2012;
originally announced October 2012.
-
Requirements Engineering Methods: A Classification Framework and Research Challenges
Authors:
Ivan Jureta
Abstract:
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…
▽ More
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.
△ Less
Submitted 8 March, 2012;
originally announced March 2012.
-
Mixed-Variable Requirements Roadmaps and their Role in the Requirements Engineering of Adaptive Systems
Authors:
Ivan Jureta,
Alexander Borgida,
Neil A. Ernst
Abstract:
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 from controlled variables for use in control loops…
▽ More
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 from controlled variables for use in control loops. We study the consequences of these changes, and argue that the requirements roadmap concept bridges the gap between current general definitions of the requirements problem and its notion of solution, and the research into the relaxation of requirements, the evaluation of their partial satisfaction, and the monitoring and control of requirements, all topics of particular interest in the engineering of requirements for adaptive systems [Cheng et al. 2009]. From the theoretical perspective, we show clearly and formally the fundamental differences between more traditional conception of requirements engineering (e.g., Zave & Jackson [1997]) and the requirements engineering of adaptive systems (from Fickas & Feather [1995], over Letier & van Lamsweerde [2004], and up to Whittle et al. [2010] and the most recent research). From the engineering perspective, we define a proto-framework for early requirements engineering of adaptive systems, which illustrates the features needed in future requirements frameworks for this class of systems.
△ Less
Submitted 21 February, 2011;
originally announced February 2011.
-
Theory of Regulatory Compliance for Requirements Engineering
Authors:
Ivan Jureta,
Alberto Siena,
John Mylopoulos,
Anna Perini,
Angelo Susi
Abstract:
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 engineer should resolve in order to verify whet…
▽ More
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 engineer should resolve in order to verify whether requirements are compliant, and (iii) testable hypotheses (predictions) about how compliance of requirements is verified. The theory is instantiated by presenting a requirements engineering framework that implements its principles, and is exemplified on a real-world case study.
△ Less
Submitted 19 February, 2010;
originally announced February 2010.
-
Towards a Theory of Requirements Elicitation: Acceptability Condition for the Relative Validity of Requirements
Authors:
Ivan Jureta,
John Mylopoulos,
Stephane Faulkner
Abstract:
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 the relative validity of an artifact; (ii) the…
▽ More
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 the relative validity of an artifact; (ii) the acceptability condition, which, when it verifies in a discussion captured in the proposed language, signals that the relative validity holds for the discussed artifact and for the participants in the discussion; and (iii) reasoning procedures to automatically check the acceptability condition in a discussions captured by the proposed language.
△ Less
Submitted 5 February, 2009;
originally announced February 2009.
-
Revisiting the Core Ontology and Problem in Requirements Engineering
Authors:
Ivan Jureta,
John Mylopoulos,
Stephane Faulkner
Abstract:
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 information needed to perform RE, we show that Zave and Ja…
▽ More
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 information needed to perform RE, we show that Zave and Jackson's ontology is incomplete. It does not cover all types of basic concerns that the stakeholders communicate. These include beliefs, desires, intentions, and attitudes. In response, we propose a core ontology that covers these concerns and is grounded in sound conceptual foundations resting on a foundational ontology. The new core ontology for RE leads to a new formulation of the requirements problem that extends Zave and Jackson's formulation. We thereby establish new standards for what minimum information should be represented in RE languages and new criteria for determining whether RE has been successfully completed.
△ Less
Submitted 26 November, 2008;
originally announced November 2008.
