Model-Driven Requirements Engineering: Synchronising Models in an Air Traffic Management Case Study

Abstract

. Modeldriven requirements engineering: Synchronising models in an air traffic management case study. Lecture Notes in Computer Science: Advanced Information Systems Engineering, 3084, pp. 368-383. doi: 10.1007/978-3-540-25975-6_27 This is the unspecified version of the paper.This version of the publication may differ from the final published version. This paper describes the application of RESCUE, a process that integrates 4 modelling techniques to model and analyse stakeholder requirements for DMAN, a system for scheduling and managing the departure of aircraft from major European airports. It describes how human activity, use case and i * modelling were applied and integrated using synchronisation checks t o model requirements on DMAN. Synchronisation checks applied at predefined stages in RESCUE revealed omissions and potential inconsistencies in the models and stakeholder requirements that, in turn, led to improvements to the models and resulting specification. The paper ends with implications for requirements model integration, and describes future work to extend and apply RESCUE. Permanent

Managing requirements uncertainty with partial models

“…A requirements process may make use of multiple types of models, for example, to separate "early", high-level modeling from "later" RE stages ( [32]), as a form of expressive redundancy, to ensure important aspects of the domain are captured (e.g., [20] [8]), or to move towards system design (e.g., [30], [15]). We illustrate uncertainty representation and mapping on a scenario moving from early to late RE models (see Figure 2).…”

“…Participant needs to provide details to the scheduler, but will list these details later"). It may be especially useful to record uncertainty if the process of creating the model is long and may be interrupted, i.e., via successive modeling workshops [20].…”

“…Traceability relations are used to link the elements of different artifacts (including models) in a development process and can be used to express different relationships such as overlap, dependency, satisfaction, refinement, etc. Various approaches to RE modeling introduce traceability relations between multiple types of models used in RE (e.g., [2], [20]). For example, Figure 4 shows traceability between i* and class diagram meta-models.…”

“…We consider mappings between requirements models as part of managing uncertainty across multiple models. Although we use a particular traceability mapping in our example (adapted from [2]), our approach is meant to apply to any mapping between models (other examples can be found in [20], [15], [30]). Traceability amongst software artifacts has received much attention (see [28] for an overview of software traceability, including traceability as part of RE), much of it geared towards traceability from models to requirements (e.g., [4], [7]), or from requirements to architecture (e.g., [31], [6]).…”

Exploring the Effectiveness of Normative i* Modelling: Results from a Case Study on Food Chain Traceability

“…i* has been applied successfully to model requirements for air traffic management tools [8,9] and decision support aids in agriculture [11] as well as to support individuals and groups in the work of charitable organisations [17]. Reported benefits to our projects have included automatic requirements generation from i* models [9] and detection of omissions from UML requirements specifications [8]. However, the focus on modelling systems as networks of heterogeneous but inter-dependent actors provides limited capabilities for addressing the broader, system-wide properties and norms that also influence the specification and design of socio-technical systems.…”