The Paraconsistency Tax
The Paraconsistency Tax is the additional cost of having to tolerate inconsistency. What is that cost? Where does it come from? Why is it a tax?
Business Forecasts as Verifiable Explanations of Expected Value
An OECD report [1] estimated that there were about 41,000 publicly traded companies in the world in 2019. Given the usual reporting requirements of listed companies, each maintains a forecast of future conditions that may matter to its financials. In other words, each of these companies has a narrative about a future, according to what…
What If People Learn Requirements Over Time?
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…
Planning Optimal Agile Releases via Requirements Optimization
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 functionality dependencies. Since agile methods suggest…
Book | Conceptual Modeling | Paraconsistency | Peer-Reviewed | Preferences | Requirements Engineering
The Design of Requirements Modelling Languages
This book explains in detail how to define requirements modelling languages – formal languages used to solve requirement-related problems in requirements engineering. It moves from simple languages to more complicated ones and uses these languages to illustrate a discussion of major topics in requirements modelling language design. The book positions requirements problem solving within the…
Adaptability | Decision Analysis | Paper | Paraconsistency | Peer-Reviewed | Preferences | Requirements Engineering
Requirements Problem and Solution Concepts for Adaptive Systems Engineering
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,…
Representation of Rules for Relevant Recommendations to Online Social Networks Users
In our prior work, we identified rules for use in recommendation algorithms on Online Social Network (OSN) in order to increase the relevance of content suggested to a user. The resulting recommendation algorithms filter out and prioritize event types for OSN users (such as photo posts by friends, status posts, shared content, etc.), and are…
The Requirements Problem for Adaptive Systems
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, and decision making in a…
Choosing Compliance Solutions through Stakeholder Preferences
Compliance to relevant laws is increasingly recognized as a critical, but also expensive, quality for software requirements. 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 these compliance alternatives and ensure that the requirements specification she is putting…
Techne Family of Formalisms for the Resolution of Requirements Problems
Between 2010 and 2013, I argued that Techne should be extended into a family of formalisms; this was related to some extent to the idea that Techne is an “abstract” requirements modeling language, something that a reviewer remarked in relation to the original Techne paper here. This led to a lot of discussions and writing…
Requirements Oracles
A requirements database contains the information elicited or otherwise collected, used, and produced during requirements engineering. From a requirements database, the requirements oracle selects information relevant for the resolution of the requirements problem, such as which goals aresatisfied, which domain assumptions are violated or maintained, which tasks cannot be executed together. Implemented oracles should enable…
Reasoning with Optional and Preferred Requirements
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 this paper, we…
Techne: Towards a New Generation of Requirements Modeling Languages
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 to stakeholders. We motivate the need…
From Decision Theory to Techne, and back
I gave two talks on the topic of qualitative decision analysis, which is what Techne was designed to support. At the time, we were looking for conceptual foundations for doing qualitative decision analysis, an alternative to standard decision analysis, which assumes richer information than what we typically have during requirements engineering and system design. Much…
Acceptability Condition for the Relative Validity of Requirements
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…
Dealing with Quality Tradeoffs during Service Selection
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 the given…
Revisiting the Core Ontology and Problem in Requirements Engineering
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…
Achieving, Satisficing, and Excelling
Definitions of the concepts derived from the goal concept (including functional and nonfunctional goal, hardgoal, and softgoal) used in requirements engineering are discussed, and precise (and, when appropriate, mathematical) definitions are suggested. The concept of satisficing, associated to softgoals is revisited. A softgoal is satisficed when thresholds of some precise criteria are reached. Satisficing does…