A Systematic Identification of Formal and Semi-formalLanguages and Techniques for Software-intensiveSystems-of-Systems Requirements Modeling
This addresses the need for higher quality requirements in critical SoS domains like healthcare and transportation, but it is incremental as it provides a landscape review without new methods.
The paper tackles the problem of modeling requirements for Software-intensive Systems-of-Systems (SoS) by systematically mapping formal and semi-formal languages and techniques, revealing that most have been tested in safety-critical domains with formal methods like finite state machines used for critical parts and semi-formal ones like UML for non-critical parts.
Software-intensive Systems-of-Systems (SoS) refer to an arrangement of managerially and operationally independent systems(i.e., constituent systems), which work collaboratively towards the achievement of global missions. Because some SoS are developed for critical domains, such as healthcare and transportation, there is an increasing need to attain higher quality levels, which often justifies additional costs that can be incurred by adopting formal and semi-formal approaches (i.e., languages and techniques) for modeling requirements. Various approaches have been employed, but a detailed landscape is still missing, and it is not well known whether they are appropriate for addressing the inherent characteristics of SoS. The main contribution of this article is to present this landscape by reporting on the state of the art in SoS requirements modeling. This landscape was built by means of a systematic mapping and shows formal and semi-formal approaches grouped from model-based to property-oriented ones. Most of them have been tested in safety-critical domains, where formal approaches such as finite state machines are aimed at critical system parts, while semi-formal approaches (e.g., UML and i*) address non-critical parts. Although formal and semi-formal modeling is an essential activity, the quality of SoS requirements does not rely solely on which formalism is used, but also on the availability of supporting tools/mechanisms that enable, for instance, requirements verification along the SoS lifecycle