Opacity, complexity, bias, and unpredictability are key negative nonfunctional requirements to address when designing AI systems. Negative means that if you have a design that reduces opacity, for example, relative to another design, the former is preferred, all else being equal. The first thing is to understand what each term refers to in general, that…
IP compliance requirements on generative AI reduce the readily and cheaply available amount of training data, with a few consequences on how product development and product operations are done.
A requirements model is, in simplest terms, a set of labeled propositions: most of it is natural language text. If so, how can you reduce the odds of it being misunderstood? Natural language is vague, ambiguous, unclear, while systems/products/services we make to solve requirements tend to be well defined, at least when they’re made; hence…
In requirements modeling languages, refinement and decomposition show up as two relationships over requirements. Both terms are also, somewhat confusingly, used to refer to processes for changing the information in a requirements model. Although they have different origins, and appear in different modeling languages, they are actually not independent relationships. I will argue below that…
There is engineering quality of a product or service, which is fitness to the specification, and there is perceived quality, or subjective quality, which is proportional to the distance between expectations and experience of the person asked. What is the relationship between these, between specification, requirements, expectations, and experience? This is a longstanding question in…
If a requirement can be easily rephrased as a criterion in a decision problem (as I argued elsewhere), then what is advice?
What could it mean that a “requirement evolves”? Is it the same to say that a requirement evolves and that it changes? How are requirements evolution and change related to updates of sets of requirements? The term “evolution” has rigorous definitions in biology. A textbook one is as follows (it is carried over from [1],…
What are the implications of seeing requirements satisfaction as a case of utility maximization? Expected Utility Theory is the mainstream framework (or, at least the one taught first) in economics for conceptualizing rational decision making. Can the problem of satisfying some given set of requirements be translated into that framework? What, if anything, is gained…
What conditions should a requirement satisfy, to be considered accurate? It turns out that this is a very complicated question. Two easy, yet unsatisfying ways out are (i) to think the question is irrelevant, and (ii) to claim that the validation of a requirement answers that question (i.e., if a stakeholder A gave the requirement…
Given a set of requirements to satisfy, and assuming they can be satisfied together, are we always aiming to find the solution that maximizes the level of satisfaction of all these requirements? Maximization of satisfaction, or more generally, finding an optimal solution to given requirements, is a common way of thinking about what we want…
Assuming two or more alternative solutions are available, to make a decision means to pick only one of these, or, equivalently here, to commit to one and ignore others. What role do requirements play in such decision making situations? In classical decision theory [1], the best solution is the one that yields the highest expected…
In this text, I take a requirement, explain why it exists, identify variables that matter, hypothesize their relationships, and explain how to use this information when designing a solution to the requirement, and the mechanism for evaluating how well the solution satisfies the requirement. In other words, I take a requirement and build a Requirements…
For any Requirements Loop, it is possible (and not difficult) to define directed labeled graphs that reflect, in a well defined format, specific properties of that loop. The graphs can be used to compute answers to some specific questions about the propositions and relationships between propositions in a Requirements Loop. In turn, we can make…
Why is a Requirements Loop a loop, and why is it a destructive loop? Any Requirements Loop has three explanations: an explanation of requirements, of a solution to these requirements, and of how to show that the solution satisfies requirements. Simply put, if an explanation gives the mechanism generating some events of interest (as in…
An exercise I used to do with students in my Decision Analysis & Requirements Engineering lecture was to ask them to identify a problem that they have at university, and to describe it. My goal was to have them work in that lecture on problems that affected them. One group of students, in the 2019-2020…
Several examples of Requirements Loop concept instances (actual Requirements Loops) are given below. Each example is represented simply as text. No specific modeling language is used. This is because the Requirements Loop concept ignores the specifics one or of the language mix that may be best suited to represent the information which makes up an…
A “Requirements Loop” is an evidence-supported explanation of How observed events in an environment have led or are leading to the creation and persistence of those requirements, How to change the environment in order to satisfy the requirements in the future, and How to measure the change in the environment, in order to evaluate the…
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….
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….
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…
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…
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. Within RE for BI systems,…
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…
Graphical Requirements Modeling (GRM) consists of representing requirements in diagrams: requirements (and other relevant information) are represented as nodes, and relationships between them as edges. Relationships can show, for example, that one requirement refines another, that some are in conflict with others, that they are more or less desirable, and so on. Various software tools…
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…
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…
Coherence Management refers to all efforts one needs to invest, in order to ensure that information shown in, and implied by a representation of requirements makes sense as a whole, is coherent. Coherence Management is an umbrella term we use to cover, and more importantly, stimulate research on relationships between identification, measurement, and action on…
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,…
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 be due to various factors, such as that…
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 elicitation. We suggest a way to measure the commitment…
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 explicitly. We propose the Elicitation Topic…
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,…
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 that embrace and accommodate requirements change. This agile approach to…
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…
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 – Context Factors (CFs) – which influence whether implicit…
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 system design complies to applicable laws….
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 based on the use of a goal…
The work on Techne (here) can be seen as a case study in developing a new business analysis and requirements engineering mehods. I gave a general talk on this topic in 2013, at the Sauder School of Business, at the University of British Columbia, in Vancouver. The presentation used at the talk is below.
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…
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…
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…
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…
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-oriented requirements modeling language, the…
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. To engineer the system according to requirements, it is necessary to…
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 knowledge in information systems engineering….
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…
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…
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 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…