Will we finally get interactive specifications?
Specifications define systems and describe their behavior. What could be more obvious than making the specifications themselves interactive? The idea is not new and has been around for decades. However, interactive specifications are not really widespread and are more likely to be found in niches. However, for some time now, Jupyter notebooks that fit into this category have been being passed around more and more frequently. Reason enough to take a closer look at this topic.
Interactive specifications
An interactive specification is very similar to a simulation. In a simulation, a simulation environment makes it possible to interact with the system. A simple example is the specification of a traffic light. An event-oriented simulation would display the states of the traffic lights (colors) to the user and enable interaction. For example, the user could trigger the equivalent of pressing a button. The simulation works without having to build the traffic lights (lamps, buttons, etc.) first. However, the simulation environment is not identical to the specification environment.
In an interactive specification, the specification and simulation environment are combined. This gives the user immediate feedback on changes to the specification. Bret Victor showed what this can look like in practice back in 2012 in the impressive video "Inventing on Principle" (the demo starts at 3:30).
Jupyter Notebooks
Bret Victor's example is about programming. Software code is a specification, but a highly specialized one. Jupyter notebooks take a different approach:
A Jupyter Notebook is a web-based interactive environment that looks like a document but contains interactive elements. The content of the notebook can be changed directly in a corresponding environment.
Jupyter notebooks are widely used, especially in teaching, as they combine learning material, exercises and examples in a seamless environment. Students can change the examples and see the effects immediately.
The name Jupyter comes from the three programming languages Julia, Python and R. Programming skills are required to create an interesting Jupyter notebook. But not necessarily to read (and experiment).
Interactive specifications in systems engineering
As already mentioned, simulations have long been an integral part of systems engineering. Tests in particular are also a form of simulation. Therefore, the right arm of the V-model can be used for this. A nice visualization can be seen in the following video by Willert:
On the one hand, I find the video very impressive because it shows how powerful end-to-end modeling can be. On the other hand, I have worked with many of the tools shown from the IBM portfolio. Some of them are decades old and not really user-friendly. IBM and other manufacturers are in the process of reinventing many of these tools: Web-based and with a strong focus on ease of use and integration.
A good example of a modern web-based tool is, for example Innoslatewhich supports simulation, but no interactive specifications.
Conclusion
Systems engineering has to contend with complexity. Teams are getting bigger and different disciplines have to work together. Interactive specifications could be a way to avoid frictional losses here.
The success of the Jupyter notebooks shows that interactive descriptions finally have the potential to go mainstream (well, at least in research). Similar solutions for systems engineering would alleviate many of the current challenges. I am curious to see whether we will see new developments here in the next few years, or whether Jupyter notebooks will also establish themselves in industrial use.
