Axel van Lamsweerde’s research while affiliated with Catholic University of Louvain and other places

What is this page?


This page lists works of an author who doesn't have a ResearchGate profile or hasn't added the works to their profile yet. It is automatically generated from public (personal) data to further our legitimate goal of comprehensive and accurate scientific recordkeeping. If you are this author and want this page removed, please let us know.

Publications (92)


Obstacle Analysis in Requirements Engineering: Retrospective and Emerging Challenges
  • Article

January 2025

·

4 Reads

IEEE Transactions on Software Engineering

Emmanuel Letier

·

Axel van Lamsweerde

With the growing adoption of AI-based systems, effective risk management is more important than ever. Obstacle analysis is a requirements engineering technique introduced three decades ago for designing dependable software systems despite failures, exceptions, and unforeseen behaviors in both the software and its environment. An obstacle is an undesirable situation that violates a stakeholder goal, an environment assumption, or a software requirement. Obstacles include safety hazards, security threats, user errors, and other adverse situations. Obstacle analysis provides a structured, systematic approach for identifying, analyzing, and resolving obstacles at the requirements level. In this retrospective paper, we summarize the original technique and discuss its impacts on research and practice. We also propose a research agenda to extend obstacle analysis to address emerging challenges in AI systems engineering.



Runtime Monitoring and Resolution of Probabilistic Obstacles to System Goals

August 2019

·

48 Reads

·

27 Citations

ACM Transactions on Autonomous and Adaptive Systems

Software systems are deployed in environments that keep changing over time. They should therefore adapt to changing conditions to meet their requirements. The satisfaction rate of these requirements depends on the rate at which adverse conditions prevent their satisfaction. Obstacle analysis is a goal-oriented form of risk analysis for requirements engineering (RE), whereby obstacles to system goals are identified, assessed, and resolved through countermeasures. The selection of effective countermeasures relies on environment assumptions and on the assessed likelihood and criticality of the corresponding obstacles. Those various factors estimated at RE time may, however, evolve at system runtime. To meet the system’s goals under changing conditions, this article proposes to defer obstacle resolution to system runtime. Techniques are presented for monitoring obstacle satisfaction rates; deciding when adaptation should be triggered; and adapting the system on-the-fly to countermeasures that are more effective. The approach relies on a model where goals and obstacles are refined and specified in a probabilistic linear temporal logic. The techniques allow for monitoring the satisfaction rate of probabilistic leaf obstacles; determining the severity of obstacle consequences on goal satisfaction rates computed from the monitored obstacle satisfaction rates; and shifting to countermeasures that better meet the required goal satisfaction rates. Our approach is evaluated on fragments of an ambulance dispatching system.


Fig. 1. A simple g-HMSC process model for cancer radiotherapy
Fig. 3. Specifications for the goals in Fig. 2 (a)
Fig. 4. States and transitions in the execution of a task instance
Fig. 6. Simplified radiotherapy process Fig. 7. Simplified chemotherapy process
Process Execution and Enactment in Medical Environments
  • Conference Paper
  • Full-text available

July 2017

·

89 Reads

·

4 Citations

Lecture Notes in Computer Science

Process models are increasingly recognized as an important asset for higher-quality healthcare. They may be used for analyzing, documenting, and explaining complex medical processes to the stakeholders involved in the process. Models may also be used for driving single processes or for orchestrating multiple ones. Model-driven software technologies therefore appear promising. In particular, process enactment provides software-based support for executing operational processes. A wide variety of possible enactment schemes are available in medical environments, e.g., to maintain daily medical worklists, to issue warnings or reminders in specific process states, to schedule tasks competing for resources, to provide on-the-fly advice in case of staff unavailability, and so forth. Such variety of possible process enactments calls for a common conceptual framework for defining, comparing, classifying, and integrating them. The paper introduces such a framework and describes a number of patterns for process execution and enactment based on it. These patterns result from a simple generic, goal-oriented model of medical process execution aiming at clarifying the role of software within the process and its environment. The patterns are illustrated on two real, non-trivial case studies.

Download


Risk-Driven Revision of Requirements Models

May 2016

·

71 Reads

·

10 Citations

·

Axel van Lamsweerde

·

·

[...]

·

Requirements incompleteness is often the result of unanticipated adverse conditions which prevent the software and its environment from behaving as expected. These conditions represent risks that can cause severe software failures. The identification and resolution of such risks is therefore a crucial step towards requirements completeness. Obstacle analysis is a goal-driven form of risk analysis that aims at detecting missing conditions that can obstruct goals from being satisfied in a given domain, and resolving them. This paper proposes an approach for automatically revising goals that may be under-specified or (partially) wrong to resolve obstructions in a given domain. The approach deploys a learning-based revision methodology in which obstructed goals in a goal model are iteratively revised from traces exemplifying obstruction and non-obstruction occurrences. Our revision methodology computes domain-consistent, obstruction-free revisions that are automatically propagated to other goals in the model in order to preserve the correctness of goal models whilst guaranteeing minimal change to the original model. We present the formal foundations of our learning-based approach, and show that it preserves the properties of our formal framework. We validate it against the benchmarking case study of the London Ambulance Service.


Fig. 1. Partial goal model for a fire alarm system 
Fig. 2. Partial obstacle model for leaf goals in Fig. 1 
Fig. 3. Satisfaction uncertainty for Achieve [BuildingEvacuatedWhenFire] 
Fig. 4. Satisfaction uncertainty for SmokeDetectorBroken 
Fig. 6. BDD for obstruction superset of Achieve [FireNoticedInTimeWhenHeat] 
Handling Knowledge Uncertainty in Risk-Based Requirements Engineering

August 2015

·

351 Reads

·

32 Citations

Requirements engineers are faced with multiple sources of uncertainty. In particular, the extent to which the identified software requirements and environment assumptions are adequate and sufficiently complete is uncertain; the extent to which they will be satisfied in the system-to-be is uncertain; and the extent to which obstacles to their satisfaction will occur is uncertain. The resolution of such domain-level uncertainty requires estimations of the likelihood that those different types of situations may or may not occur. However, the extent to which the resulting estimates are accurate is uncertain as well. This meta-level uncertainty limits current risk-based methods for requirements engineering. The paper introduces a quantitative approach for managing it. An earlier formal framework for probabilistic goals and obstacles is extended to explicitly cope with uncertainties about estimates of likelihoods of fine-grained obstacles to goal satisfaction. Such estimates are elicited from multiple sources and combined in order to reduce their uncertainty margins. The combined estimates and their uncertainties are up-propagated through obstacle refinement trees and then through the system's goal model. Two metrics are introduced for measuring problematic uncertainties. When applied to the probability distributions obtained by up-propagation to the top-level goals, the metrics allow critical leaf obstacles with most problematic uncertainty margins to be highlighted. The proposed approach is evaluated on excerpts from a real ambulance dispatching system.


Integrating exception handling in goal models

August 2014

·

53 Reads

·

19 Citations

Missing requirements are known to be among the major sources of software failure. Incompleteness often results from poor anticipation of what could go wrong with an over-ideal system. Obstacle analysis is a model-based, goal-anchored form of risk analysis aimed at identifying, assessing and resolving exceptional conditions that may obstruct the behavioral goals of the target system. The obstacle resolution step is obviously crucial as it should result in more adequate and more complete requirements. In contrast with obstacle identification and assessment, however, this step has little support beyond a palette of resolution operators encoding tactics for producing isolated countermeasures to single risks. In particular, there is no single clue to date as to where and how such countermeasures should be integrated within a more robust goal model. To address this problem, the paper describes a systematic technique for integrating obstacle resolutions as countermeasure goals into goal models. The technique is shown to guarantee progress towards a complete goal model; it preserves the correctness of refinements in the overall model; and keeps the original, ideal model visible to avoid cluttering the latter with a combinatorial blow-up of exceptional cases. To allow for this, the goal specification language is slightly extended in order to capture exceptions to goals seperately and distinguish normal situations from exceptional ones. The proposed technique is evaluated on a non-trivial ambulance dispatching system.


Analyzing Critical Decision-Based Processes

April 2014

·

30 Reads

·

5 Citations

IEEE Transactions on Software Engineering

Decision-based processes are composed of tasks whose application may depend on explicit decisions relying on the state of the process environment. In specific domains such as healthcare, decision-based processes are often complex and critical in terms of timing and resources. The paper presents a variety of tool-supported techniques for analyzing models of such processes. The analyses allow a variety of errors to be detected early and incrementally on partial models, notably: inadequate decisions resulting from inaccurate or outdated information about the environment state; incomplete decisions; non-deterministic task selections; unreachable tasks along process paths; and violations of non-functional process requirements involving time, resources or costs. The proposed techniques are based on different instantiations of the same generic algorithm that propagates decorations iteratively through the process model. This algorithm in particular allows event-based models to be automatically decorated with state-based invariants. A formal language supporting both event-based and state-based specifications is introduced as a process modeling language to enable such analyses. This language mimics the informal flowcharts commonly used by process stakeholders. It extends High-Level Message Sequence Charts with guards on task-related and environment-related variables. The language provides constructs for specifying task compositions, task refinements, decision trees, multi-agent communication scenarios, and time and resource constraints. The proposed techniques are demonstrated on the incremental building and analysis of a complex model of a real protocol for cancer therapy.


Fig. 5. Obstacles for Achieve [FireVehicleOnScene When Dispatched]
Fig. 6. Resolutions of obstacle FireVehicleDestinationConfused
Fig. 7. Context diagram for bCMS agents
Modeling car crash management with KAOS

July 2013

·

395 Reads

·

3 Citations

Getting the right software requirements under the right environment assumptions is a critical precondition for developing the right software. KAOS is a goal-driven, model-based approach for elaborating a complete, adequate, consistent, and well-structured set of measurable software requirements and environment assumptions. The modeling language and method cover the intentional, structural, functional, and behavioral facets of the target system. Declarative and operational sub-models are integrated. Semi-formal and formal techniques complement each other for model construction, analysis and evolution. They support early and incremental reasoning on partial models for a variety of purposes including goal satisfaction arguments, property checks, animations, the evaluation of alternative options, the analysis of risks, threats and conflicts, and traceability management. The paper illustrates the modeling language and method on a car crash management case study. The overall produced model integrates the goal, object, agent, operation and behavior submodels of the system. The paper outlines some of the features supported by KAOS for incremental model elaboration, including goal identification and refinement, the structuring of domain concepts, risk analysis for increased requirements completeness, goal operationalization, the derivation of agent interfaces and the derivation of state machine behavior models.


Citations (81)


... In this case study, we show how complex LTL patterns (e.g., CNFs and DNFs) can be expressed using our technique. The idea of invariant weakening, or more generally, specification weakening, comes from requirements engineering [35], [36]. As the environmental conditions for a software system may change over time and space, original requirements might become inadequate or inconsistent with the new environment, necessitating adaptation or weakening. ...

Reference:

Constrained LTL Specification Learning from Examples
Adapting requirements models to varying environments
  • Citing Conference Paper
  • June 2020

... Goal-Oriented Requirements Engineering is founded on the premise that functional requirements for information systems can be derived from stakeholder goals through a systematic process [1]. For example, the goal Schedule a Meeting in a university setting might be fulfilled by a system that supports a set of functions (gather constraints automatically, find free slots, send out reminders, etc.) as well as actions carried out by external actors (participants, a meeting initiator etc.). ...

Goal-directed requirements acquisition
  • Citing Article
  • April 1993

Science of Computer Programming

... We adopted an n-gram-based solution and a probabilistic model approach because sequence analysis approaches are widely used in practice. As matter of fact, there are several research studies adopting n-grams (or similar algorithms) and probabilistic models to perform run-time detection of anomalies up to now (Khreich et al., 2017;Ariff et al., 2021;Brown et al., 2022;Cailliau and Lamsweerde, 2019;Carreon et al., 2021;Bartolo Burlò et al., 2021). Moreover, we did not include more complex approaches, such as neural networks-based approaches, since they require massive data for training (Islam et al., 2021;Huch et al., 2018;Girish and Rao, 2021). ...

Runtime Monitoring and Resolution of Probabilistic Obstacles to System Goals
  • Citing Article
  • August 2019

ACM Transactions on Autonomous and Adaptive Systems

... However, as highlighted by Daoutidis et al. [27], sustainability practices create operational challenges, motivating the employment of well-established process enactment methods. Process enactment is commonly defined as the use of software to support the execution of operational processes [78,130]. DevOps principles, especially those tailored to digital twins as the primary means of process enactment [61] offer particular upside in narrowing the gap between process modeling and process execution. ...

Process Execution and Enactment in Medical Environments

Lecture Notes in Computer Science

... This process is very important, which will have an impact on the quality of requirements generated by the model. In the GORE study, this area has not received much attention [7]; some studies emphasize the use of obstacles for risk analysis and conflict detection [8][9][10][11][12][13]. Some others use a formal approach to detect conflicts [14][15][16]. ...

Runtime Monitoring and Resolution of Probabilistic Obstacles to System Goals
  • Citing Conference Paper
  • May 2017

... Intuitively, it would be quite helpful to automatically recommend requirements specifications as long as the analysts can provide some simple related information almost effortlessly. To the best of our knowledge, most of the automated requirements specifications generation work focus on transforming software engineering models (e.g., the i* framework [6,7], KAOS [8][9][10], UML models [11][12][13]) or other semi-structured inputs (e.g., security goals in specific syntactic patterns [14]) into natural language requirements specifications based on pre-defined rules, which are usually brittle and restrict the usability of these approaches. What is more, constructing expressive and precise models is another complex work as well. ...

Deriving operational software specifications from system goals
  • Citing Conference Paper
  • January 2002

... The KAOS modelling language can support all the phases of requirements acquisition and modelling, starting from initial functional and non-functional goals, formalizing the meaning of such goals using temporal logic formulas and assigning the responsibility for the achievement of these goals to potential agents which may signify the system in question systems that interoperate with it, and human actors interacting with the system. KAOS has also been used by Feather et al (1998) in a framework that they developed to monitor system requirements at runtime and which incorporates some capabilities regarding the reconciliation of requirements with the runtime system behavior. ...

Reconciling system requirements and runtime behavior
  • Citing Article
  • January 1998

... For business experts, building a reasonable cognition on related technologies is quite meaningful, which would give the proposed business goals more supports. For requirements engineers, researchers have proposed some novel requirements modeling methods for machine learning applications in recent years, considering factors like privacy [183], security [76], scenarios [47] and goal revision [184]. For the other roles, the challenges mainly come from multidisciplinary and technical bottlenecks. ...

Risk-Driven Revision of Requirements Models
  • Citing Conference Paper
  • May 2016

... VarCORE + can assist to some extent in surfacing such errors since it checks that all the configurations identified as valid by FeatureIDE can be compiled and built for unit testing. Uncertainty modeling, as in [53], may offer a way to cope with uncertainties as to the extent to which the documented software requirements are adequate. Another threat to internal validity is that several steps in VarCORE + are manual (variability requirements/features extraction, features to code variables mapping) and require domain expertise, with results dependent on the accuracy of input provided by developers. ...

Handling Knowledge Uncertainty in Risk-Based Requirements Engineering

... Alma is designed to support the entire lifecycle of a software project, using syntax directed tools for the manipulation of formal texts [27]. The system is composed of two databases: the Project DB and the Model DB, both based on the Entity Relationship data model, and implemented on Unix with INGRES™, a relational DBMS. ...

The Kernel of a Generic Software Development Environment
  • Citing Article
  • January 1987

ACM SIGPLAN Notices