Critical Decision Concept in the Algorithmic Accountability Act
| | |

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…