In each iteration of the Define/Destroy method, definitions of terms are changed in order to reflect new ideas. At the beginning of an iteration, we may have a definition D1 of a term T, and at the end, we have D2. The reason we change D1 into D2 is to align the documented meaning of…
How can definitions make it easy to do some things, and hard to do others? How do they impose constraints on future choices? If you commit to a definition, meaning you choose one definition of a term over others, then you also take additional commitments. It is a case of getting more than you bargained…
A definition is a record of past decisions. This is a simple idea that’s interesting to unpack. Let’s take the example of the term “Service” that was redefined in another text. There, I took the common definition of “Service” from WordNet, which was the following: Service: work done by one person or group that benefits…
There are two ideas which cause trouble when thinking about definitions, and what a good definition may look like. The first toxic idea is that you can produce a definition which explains all meanings of a term, for everyone, anytime, and everywhere. It is the idea that you can make a successful universal definition. The…
When you try to define something, that thing – be it concrete or abstract, chairs or thoughts – is what your definition is about. If there is exactly one, unique such thing, your definition should, ideally, unequivocally identify it. If I were to learn that definition, I would know exactly what it is that you…
Belnap is less concerned than Kant with categories of definitions, than with the ”good” properties of definitions. For him, a definition tries to explain the meaning of a word or phrase. ”I consider [definitions] only in the sense of explanations of the meanings of words or other bits of language. (I use ’explanation’ as a…
For Kant, to define is to identify all primitive properties of that which you are trying to define, whereby that set of properties allows you, me, others, to unambiguously distinguish the thing from others. It is important that all these properties in the set, i.e., properties which together make up the definition, are primitive. Primitive…
The Define/Destroy method makes, destroys, rebuilds definitions. A definition is, in other words, the key thing that is made, changed, discarded when applying the method. These definitions are unstable by design, and this makes them very different from ones in glossaries of mature domains of knowledge. In Define/Destroy, a definition is temporary, whereas in, say,…
This text goes into the details of a single Define/Destroy iteration, in a project I was part of in 2017. I show how the Define/Destroy iteration was done, including the detail of the glossary built in the Define part of the iteration, and the glossary remade as a result of the Destroy part of that first iteration.
Define/Destroy consists of doing a specific set of activities iteratively. This short text outlines how each iteration looks, what it uses as its inputs, and what it produces as its output.
Innovation is iterative: start from an idea, find flaws, replace it with a better one, repeat. Each cycle destroys to rebuild. This is intentional constructive destruction; it isn’t Schumpeter’s creative destruction from systemic contradictions. Invent, destroy, repeat. If ideas are willingly exposed to, and revised in response to constructive criticism, then the more iterations, the…
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…
Figures 1 and 2 show cost versus time; Figure 1 shows long iterations, Figure 2 short iterations. We choose to do something at time zero, at the origin of the graph in the Figure, and when we do so, we do it under some assumptions that we made at that time. Dashed red lines convey…
Can “an artificial intelligence machine be an ‘inventor’ under the Patent Act”? According to the Memorandum Opinion filed on September 2, 2021, in the case 1:20-cv-00903, the US Patent and Trademark Office (USPTO) requires that the inventor is one or more people [1]. An “AI machine” cannot be named an inventor on a patent that…
Are decision problems and design problems related? Is one part of the other? Or is the relationship different? In a decision problem, there are, roughly speaking options and an objective, and the problem is to select the one option that best satisfies the objective. (There are other things in a decision problem, such as preferences…
“Objective”, as in, for example, “what I’m saying is objective”, or “that statement is objective”, or “we need objective criteria when making these decisions”, is a complicated term. It takes a lot of effort to make sure it is understood as intended (or closely enough). It is therefore a costly word to use. Why is…
There is no single definition of the term “evidence”, and trying to make one isn’t the purpose of this text. But there are ways of telling if something might be evidence, and knowing when it clearly isn’t. Such knowledge helps you develop a taste, so to speak, in evidence. Isn’t that valuable, given how frequently you may be giving evidence to support your ideas, and how frequently others do the same to you?
Many people spent a lot of time, across centuries, trying to build good explanations, and trying to distinguish good from bad ones. While there is no consensus on what “explanation” is (always and everywhere), it is worth knowing what good explanations may have in common. It helps develop a taste in explanations, which is certainly helpful given how frequently you may need to explain something, and how often others offered explanations to you.
If competence shortens learning, then its value is proportional to the cost of learning, that is, of iterations that would have been needed to achieve the effects of competence, but without having access to it.
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….
This short interview on my research on decision making and use of it in companies, was done in 2018 with fnrs.tv, part of the Belgian Fonds de la Recherche Scientifique – FNRS, in Brussels. Each of my first two academic books led to the founding of a spin-off; see the books here.
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…
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…
Over the last decade, online social networks (OSNs) have been growing quickly to become some of the largest systems in use. Their users are sharing more and more content, and in turn have access to vast amounts of information from and about each other. This increases the risk of information overload for every user. We…
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…
Innovative companies need an agile approach towards product and service requirements, to rapidly respond to and exploit changing conditions. The agile approach to requirements must nonetheless be systematic, especially with respect to accommodating legal and non-functional requirements. This paper examines how to support lightweight, agile requirements processes which can still be systematically modeled, analyzed and…