Decision Governance Is Interdisciplinary
Designing effective decision governance systems requires drawing on a wide range of academic disciplines, each of which provides valuable insights into different aspects of decision-making.
Decision Governance Concepts: Outcomes to Explanations
Let’s assume that there is a situation you observed, and you want to understand the decision that led to it – maybe there is something particularly good about the situation and you want to see how to increase the probability that this happens again, or there is something you would want to prevent from happening…
Business Processes Implement Decision Governance. How?
A business process describes how something is done by highlighting mainly the actions to take, their dependencies (including their sequence), the roles in the firm who do these actions, as well as what triggers the process to start, and how we know when the process ends. Business processes implement decision governance in several ways. It…
Decision Responsibilities in Decision Governance
Being entitled to make decisions carries with it the responsibility for outcomes of actions that the decisions led to. Accountability can be implemented through decision governance by defining responsibilities for outcomes of decisions. The idea that decision responsibilities are the counterpart to decision rights is easy to understand. However, defining useful decision responsibilities involves finding…
Role of Decision Rights in Decision Governance
Decision rights are entitlements to act in a certain way and have access to specific information and resources required to make decisions. An executive may be asked to decide if an investment should be made or not, a manager may be deciding between candidates to hire – both are entitlements to make a decision. The…
Decision Governance Concepts: Situations, Actions, Commitments and Decisions
This is the first of several notes which will introduce concepts necessary to design and do decision governance. The aim is to develop a more precise idea of what decision governance is, how it works, and what it means to design it and evaluate its benefits and costs. The focus in this first note is…
What is a “Decision” in an Artificial Intelligence System?
In the context of human decision making, a decision is a commitment to a course of action (see the note here); it involves mental states that lead to specific actions. An AI system, as long as it is a combination of statistical learning algorithms and/or logic, and data, cannot have mental states in the same…
Critical Decision Concept in the Algorithmic Accountability Act
The Algorithmic Accountability Act of 2022, here, applies to systems that help make, or themselves make (or recommend) “critical decisions”. Determining if something is a “critical decision” determines if a system is subject to the Act or not. Hence the interest in the discussion, below, of the definition of “critical decision”. The Act defines a…
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….
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…
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…
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…
Engineering Pluripotent Information Systems
A pluripotent information system is an open and distributed information system that (i) automatically adapts at runtime to changing operating conditions, and (ii) satisfies both the requirements anticipated at development time, and those unanticipated before but relevant at runtime. Engineering pluripotency into an information system therefore responds to two recurring critical issues: (i) the need…
Tracing the Rationale Behind UML Model Change Through Argumentation
Neglecting traceability—i.e., the ability to describe and follow the life of a requirement—is known to entail misunderstanding and miscommunication, leading to the engineering of poor quality systems. Following the simple principles that (a) changes to UML model instances ought be justified to the stakeholders, (b) justification should proceed in a structured manner to ensure rigor…
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…
A More Expressive Softgoal Conceptualization for Quality Requirements Analysis
Initial software quality requirements tend to be imprecise, subjective, idealistic, and context-specific. An extended characterization of the common Softgoal concept is proposed for representing and reasoning about such requirements during the early stages of the requirements engineering process. The types of information often implicitly contained in a Softgoal instance are highlighted to allow richer requirements…