Opaque, Complex, Biased, and Unpredictable AI
| |

Opaque, Complex, Biased, and Unpredictable AI

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…

Decreasing the Odds of Misunderstanding
| |

Decreasing the Odds of Misunderstanding

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…

Are Refinement and Decomposition Equivalent?
|

Are Refinement and Decomposition Equivalent?

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…

Requirements Satisfaction ≠ Customer Satisfaction
| |

Requirements Satisfaction ≠ Customer Satisfaction

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…

Requirements Evolution, Change, and Update
| |

Requirements Evolution, Change, and Update

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],…

Requirements Satisfaction as Expected Utility Maximization
|

Requirements Satisfaction as Expected Utility Maximization

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…

When Is a Requirement Accurate?
| |

When Is a Requirement Accurate?

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…

Approaches to Requirements Satisfaction
|

Approaches to Requirements Satisfaction

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…

Requirements as Decision Criteria
|

Requirements as Decision Criteria

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…

Building a Loop around a Requirement
|

Building a Loop around a Requirement

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…

Labeled Directed Graphs from Requirements Loops
|

Labeled Directed Graphs from Requirements Loops

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…

What Is Destructive in a Requirements Loop?
| |

What Is Destructive in a Requirements Loop?

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…

Requirements Loops: Decomposing an Example
| |

Requirements Loops: Decomposing an Example

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…

Requirements Loops: Examples
| |

Requirements Loops: Examples

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…

Requirements Loops: Definition & Purpose
| | |

Requirements Loops: Definition & Purpose

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…

| | |

Requirements Contracts: Definition, Design, and Analysis

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

| | | |

What Lies behind Requirements? Statement Grounds in Requirements Elicitation

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

| | |

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…

| | | |

What Happens to Intentional Concepts in Requirements Engineering if Intentional States Cannot Be Known?

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…

| | |

Monitoring in Business Intelligence Requirements Engineering

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,…

| | | | |

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…

| | |

AnalyticGraph: Next Generation Requirements Modeling and Reasoning Tools

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…

| | | | |

Requirements for Content Recommendation Systems

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…

| | | | |

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…

| | | |

Towards a General Formal Framework of Coherence Management in RE

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 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,…

| | | |

Topic Relevance in Requirements Elicitation

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…

| | | |

How Stakeholders’ Commitment May Affect the Success of Requirements Elicitation

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…

| | | |

What Stakeholders Will or Will not Say: Topic Importance in Requirements Engineering Elicitation Interviews

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…

| | |

Legal Compliance of Roles and Requirements

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,…

| | |

An Overview of Requirements Evolution

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…

| | | | |

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…

| | |

Context Factors and Requirements Problems

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…

| | |

Toward Benchmarks to Assess Advancement in Legal Requirements Modeling

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

| | |

Adaptability of Process-based Service Compositions

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…

| |

Structure and Design of Business Analysis and Requirements Engineering Methods

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.

| | |

Product Portfolio Scope Optimization based on Features and Goals

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…

| | |

Influence of Context on Decision Making during Requirements Elicitation

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…

| | |

Context-driven Elicitation of Default Requirements

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: A Classification Framework

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…

| | |

Finding Incremental Solutions for Evolving Requirements

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…

| | |

Towards Conceptual Foundations of Requirements Engineering for Services

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…

| | | |

Requirements Engineering for Self-Adaptive Systems: Core Ontology and Problem Statement

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

| | | | |

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…

| | |

Mixed-Variable Requirements Roadmaps for Adaptive Systems

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…

| | |

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…