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…

| | |

Theory of Regulatory Compliance for Requirements Engineering

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…

From Decision Theory to Techne, and back
| | |

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…

| | | |

A Core Ontology for Requirements

In their seminal paper (ACM T. Softw. Eng. Methodol., 6(1) (1997), 1–30), 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. Starting from the premise that the stakeholders of the system-to-be communicate to the software engineer…

| | | |

Clear Justification of Modeling Decisions for Goal-oriented Requirements Engineering

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…

| | | |

Timing Nonfunctional Requirements

Analysis of temporal properties of nonfunctional – i.e., quality – requirements (NFRs) has not received significant attention. In response, this paper introduces basic concepts and techniques needed for the specification and analysis of time properties of NFRs. Jureta, I.J. and Faulkner, S., 2008, October. Timing Nonfunctional Requirements. In International Conference on Conceptual Modeling (pp. 302-311). Springer, Berlin,…

| | | | |

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…

| | | |

Clarifying Goal Models

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 goal modeling is arriving at a shared understanding of a goal model instance, mainly due to different backgrounds of the system stakeholders who participate in modeling, and the…

| | | | |

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…

| | | | |

Dynamic Requirements Specification for Adaptable and Open Service-Oriented Systems

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…

| | | |

Allocating Goals to Agent Roles During Multi-Agent Systems Requirements Engineering

Allocation of goal responsibilities to agent roles in Multi-Agent Systems (MAS) influence the degree to which these systems satisfy nonfunctional requirements. This paper proposes a systematic approach that starts from nonfunctional requirements identification and moves towards agent role definition guided by the degree of nonfunctional requirements satisfaction. The approach relies on goal-dependencies to allow potential…