Let’s say that there was a requirements model M1, we made a change to it, and we call the changed model M2. What can be said about the relationship between the contents of M1 and M2? To make this simpler to discuss, suppose that we changed M1 by refining a requirement in it. To further…
In expected utility models, utility quantifies preferences, probability quantifies uncertainty. Sounds simple, elegant, but tends to be expensive. What if options can be identified, but there is no information about preferences or uncertainty in a format that can be translated into, respectively, utility and probability? What is an alternative decision process, which is still structured…
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?
An argumentation framework [1] is a graph of nodes called arguments, and edges called attacks. If arguments are propositions, and “p1 attacks p2” reads “if you believe p1 then you shouldn’t believe p2”, then an argumentation framework looks like something you can use to represent the relationship between arguments and counterarguments in, say, a debate….
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…
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, validation, and ultimately specification activities of the RE process….
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 techniques to assess the compliance of…
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…
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…
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…
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…
Representation and reasoning about goals of an information system unavoidably involve the transformation of unclear stakeholder requirements into an instance of a goal model. If the requirements engineer does not justify why one clear form of requirements is chosen over others, the subsequent modeling decisions cannot be justified either. If arguments for clarification and modeling…
Neglecting traceability—i.e., the ability to describe and follow the life of a requirement—is known to entail misunderstanding and miscommunication, leading to the engineering of poor quality systems. Following the simple principles that (a) changes to UML model instances ought be justified to the stakeholders, (b) justification should proceed in a structured manner to ensure rigor…
It is not feasible to engineer requirements for adaptable and open service-oriented systems (AOSS) by specifying stakeholders’ expectations in detail during system development. Openness and adaptability allow new services to appear at runtime so that ways in, and degrees to which the initial functional and nonfunctional requirements will be satisfied may vary at runtime. To…
Representation and reasoning about information system (IS) requirements is facilitated with the use of goal models to describe the desired and undesired IS behaviors. One difficulty in building and using goal models is in knowing why a model instance is as it is at some point of the requirements engineering (RE) process. If justifications for…