From specification models to requirements

Model-based working is one way of dealing with increasing complexity. However, it is not easy to work successfully in a team based on models. In this respect, it is often helpful to get impulses from practice. In today's guest article, Carsten Pitz reports on how specification models help to bridge the gap between requirements and the world of modeling.

Guest article by Carsten Pitz

I recently had an interesting exchange of ideas with a system verifier/certifier in aviation. The point was that DO-331 distinguishes between specification models and design models. My discussion partner was only familiar with design models. This led to an intensive discussion from which I learned a lot and which inspired me to write this article.

DO-331 defines rules for DO-178C and DO-278A compliant MBSE.

https://www.apt-research.com/wp-content/uploads/2017/05/MBSESSS_DO-331_Alford_Hendrix.pdf

What are specification models?

In my interpretation, specification models are nothing new. For me, the following are examples

• the views NAV (NATO All View), NCV (NATO Capability View) and NOV (NATO Operational View) of NAFv3,
• the Strategic and Operational shifts of the UAF,
• the Operational Analyses and System Analyses layers of Arcadia
• as well as the Analyze the Problem and Despribe System Idea and System Objectives steps of the SysMod
• or also the Operational architecture of my approach

all to specification models.

Why specification models?

All of these views scrutinize the what and lead to a specification of the system to be developed. The specification is not about the how, it is exclusively about the what. The what is supplemented by under what boundary conditions and in what quality. Boundary conditions are, for example, weather conditions. Under quality I subsume e.g. reaction times or control accuracy. But I also include the RAM from RAMS (Reliability, Availability, Maintainability, Safety) under quality. For safety-critical systems in particular, the boundary conditions and quality must be clearly defined.

Accordingly, specification models for safety-critical systems specify behavior. Behavior is the basis for hazard analysis. On the other hand, the risk assessment provides the boundary conditions to be complied with and the necessary quality. In my opinion, this interplay between the roles of system architect (specification) and functional safety engineer (hazard analysis and risk assessment) must be subject to the dual control principle. As a system architect, I value the dual control principle. Also because an open discussion with the functional safety engineer often reveals potential for improvement.

A small note: The brake shown in the teaser image consists of two independent brakes in one housing. In other words, 2 encoder pistons with one brake pad each. So a total of 4 master pistons and 4 brake pads. The design is such that if one (partial) brake fails, the other (partial) brake still provides enough braking power to overbrake the wheel at any time. Gives me a good feeling ;-)

Carsten Pitz

Specification model is a requirements document

A specification model is therefore also a requirements document. Whether a collection of requirements is left as a partial model (e.g. as a finite state machine) or the requirements represented in the state machine, e.g. as transition conditions, are converted into textual requirements depends on the project context. CIL4Sys and I have also had good experiences generating textual requirements from the model using model2text transformation.

I hope that this article also stimulates thought and discussion.

Image source: Carsten Pitz