How Definitions Embed Past Choices
| |

How Definitions Embed Past Choices

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…

Theories of Definition: Crowds
| |

Theories of Definition: Crowds

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…

Theories of Definition: Kripke
|

Theories of Definition: Kripke

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…

Theories of Definition: Belnap
|

Theories of Definition: Belnap

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…

Theories of Definition: Kant
| |

Theories of Definition: Kant

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…

Plastic Definitions
| |

Plastic Definitions

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

Define/Destroy a Business Services Marketplace
| |

Define/Destroy a Business Services Marketplace

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: A Paradox to Accelerate Innovation
|

Define/Destroy: A Paradox to Accelerate Innovation

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…

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…

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…

Speed vs Uncertainty
| |

Speed vs Uncertainty

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…

Machine/AI as Inventor? Notes on Thaler v. USPTO
| | |

Machine/AI as Inventor? Notes on Thaler v. USPTO

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…

When (if ever) Is a Claim Objective?
| | |

When (if ever) Is a Claim Objective?

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

What Is Evidence?
| | | |

What Is Evidence?

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?

What Is an Explanation?
| | | |

What Is an Explanation?

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.

Value of Competence
| |

Value of Competence

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.

| | |

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

| | | | |

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…

| | | | |

Representation of Rules for Relevant Recommendations to Online Social Networks Users

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…

| | | |

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…

| | | |

Agile Requirements Evolution via Paraconsistent Reasoning

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…

| | |

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…