Requirements engineering

Abstract

Getting the right software requirements under the right environment assumptions is a critical precondition for developing the right software. This task is intrinsically difficult. We need to produce a complete, adequate, consistent, and well-structured set of measurable requirements and assumptions from incomplete, imprecise, and sparse material originating from multiple, often conflicting sources. The system we need to consider comprises software and environment components including people and devices. A rich system model may significantly help us in this task. Such model must integrate the intentional, structural, functional, and behavioral facets of the system being conceived. Rigorous techniques are needed for model construction, analysis, exploitation, and evolution. Such techniques should support early and incremental reasoning about partial models for a variety of purposes including satisfaction arguments, property checks, animations, the evaluation of alternative options, the analysis of risks, threats, and conflicts, and traceability management. The tension between technical precision and practical applicability calls for a suitable mix of heuristic, deductive, and inductive forms of reasoning on a suitable mix of declarative and operational specifications. Formal techniques should be deployed only when and where needed, and kept hidden wherever possible. The paper provides a retrospective account of our research efforts and practical experience along this route. Problem-oriented abstractions, analyzable models, and constructive techniques were permanent concerns.

Targeting uncertainty in smart CPS by confidence-based logic

“…Focusing on the requirements in self-adaptive systems and building on KAOS goal-oriented models (Lamsweerde, 2008), FLAG (Fuzzy Live Adaptive Goals for Self-adaptive systems) introduces the notions of fuzzy goals and adaptive goals . As opposed to crisp goals whose fulfillment is Boolean, fuzzy goals have a degree of satisfaction in the [0,1] range and are formulated in a fuzzy temporal language .…”

Involving the Application Domain Expert in the Construction of Systems of Systems

“…In this context, authors in [3] proposed mKAOS, an SoS mission description language. mKAOS extends KAOS [11] by specializing the KAOS elements and models to the SoS domain. In MKAOS, mission is a specialization of goal to SoS domain.…”

Towards an Automated Requirements-driven Development of Smart Cyber-Physical Systems

“…(a) Continuously monitor its energy level (battery) ; [9] (b) Continuously monitor its position) ; [7] (c) Continuously assess whether its energy level would be enough to complete the trip based on the distance left to cover; [8] (d) Have a plan to follow, which is based on its energy level and on the available parking slots in the parking places near the POI . [11,14] 2.…”

“…As far as we know, there are no attempts to automatize requirements processing for EBCS design. Nevertheless, a related approach is described in [3], in which authors propose an approach called NPL-KAOS that can automatically obtain a KAOS model from large volume of literature (KAOS [9] is a goal-oriented requirement engineering method and it was one of inspirations for the IRM-SA method). With the use of natural language processing tools and text mining techniques they process abstracts of scientific publications.…”