Requirements, Airbus, brain drain and a beautiful spark

In this issue: a new book on requirements engineering; what makes a good definition; the Airbus recall; a beautiful spark; reverse brain drain? (no); keynote for VERIFAI.

A new book on requirements engineering

Jean-Michel Bruel , Sophie Ebersold , Mariya Naumcheva: Applying Requirements and Business Analysis, Springer, 2025, about 168 pages. Book page at Springer: https://link.springer.com/book/10.1007/978-3-031-92160-5#toc

Requirements are often the neglected weak link of software development. Requirements engineering is typically done very poorly in industry — basically, throw in a few use cases — but they deserve renewed attention today with the rise of vibe coding: it is all well and good to say “just specify and the AI will do the rest” but of course the “just specify” part is requirements engineering, and a challenge.

The book by Bruel, Ebersold and Naumcheva provides a wealth of practical insights into how to perform good requirements. It was conceived as a “companion” to my own Handbook on requirements engineering, published in 2022, which is concise and concentrates on the concepts, with only short examples. The new book applies these concepts to significant examples, some educational and some practical, including a large one from an industrial project.

It uses the PEGS approach to requirements engineering (Project, Environment, Goals, System), which takes a comprehensive, holistic view or requirements and includes a Standard Plan of 4 books (one for each of the PEGS) totaling 26 chapters, serving as a checklist of all the questions you should ask during a requirements effort. The plan is available as a sample chapter on the Handbook page. It has been refined over many applications and the new book uses it extensively.

Requirements deserve to be done better, not as an end in themselves, but as an obligatory ingredient of high-quality systems. The new book provides a unique resource to reach this goal.

What makes a good definition

One of the critical conditions for success in science and technology is to be able to rely on good definitions. I have been flabbergasted over the years to see how bad some of the accepted technical definitions in software engineering are, including in widely cited standards from the IEEE and others. For example, a definition should be descriptive, not prescriptive (a definition of speed states that it is the ratio of distance traveled to time, it does not prescribe a speed limit). I wrote a blog article for the Communications of the ACM explaining what makes definitions bad or good. The article was too long for them, so I split it into three parts, the first two now published: part 1 here and part 2 there, the third one to appear soon (CACM controls the schedule). 

The parts already published are mostly critical, analyzing inadequate definitions, such as those of requirements in an IEEE standard and of digital twins from the Digital Twin consortium. Part 3 turns positive and proposes rules for good definitions. In fact, I was surprised to realize that there is in the end just one basic rule and that all others follow from it.

If you prefer to get the whole thing in one sitting, I will republish a variant as a single article on my personal blog once the third part has been made available. (In general duplication is bad but in this case it makes sense to have one place with all my posts since I have no control over what CACM does in the long term. Also, I can occasionally couch the ideas in a slightly different way on my own site.)

The Airbus recall: beyond the mystery

Recently Airbus had to recall 6000 planes. You may have read that it was a “software glitch” and that it was due to “intense solar radiation”. Wait a minute. Solar radiation does not cause software issues. Can we make sense of what happened?

Actually we can. The overall picture is the following. Airbus is famously all into “fly-by-wire”, using very few mechanical connections. Much of the coordination happens through computers. In particular, the ELAC (Elevator and Aileron Computer), processes pilot input and stability data. Now it turns out that intense solar radiation can, in extreme circumstances, flip a bit in the ELAC memory or registers. In other words, affecting data, as one would effect. Such so-called SEU (Single Event Upset) bit flips are a known phenomenon, and the software is supposed to be written so as to handle it.

It seems that a software update messed up that SEU handling; the patch simplyconsisted of reverting to the previous version. That is also the reason why the interruption was relatively short and the fix could be performed remotely; in the end (with, for some reason, the exception of some airlines in South America) most planes were grounded for less than a day. Admittedly, it is possible that I am viewing it like this because I was not affected; had I been traveling and stranded I might have a less irenic attitude.

This discussion is based on information available now. It may have to be revised, and the software engineering lessons drawn, when (if?) more becomes known.

From Probable to Provable

My article on AI for software engineering, mentioned in the last newsletter, is still not out in CACM but is available on arXiv: https://arxiv.org/abs/2511.23159.

A beautiful spark

More programmers than before know at least a bit of lambda calculus, thanks to the advent of functional languages. Very few, though, know that there is an even more stunning theory: CL, Combinatory Logic. It does away with variables. Your read this right. Variables considered harmful.

Those in the know usually ascribe the theory, not incorrectly, to the American mathematician Haskell Curry, who exposed and developed it starting in the 1930s. Few realize that it came — as honestly acknowledged by Curry — from a beautiful spark (multilingual pun intended): a 1920 presentation by Moses Schönfinkel in Hilbert's group in Göttingen, published in 1924. Schönfinkel, a fascinating and tragic figure, did not even write the paper: a colleague (later to become a faithful member of the NSDAP, the Nazi party) published his notes of the talk, adding his own (uninteresting) comments.

The paper is one of the most beautiful I have ever seen. It is available in German, and also in a very good English translation here, part of a book which, as well as its author, also has an enthralling story (but let's not get diverted). Viewed in terms suitable for a software engineering audience, it bases the entirety of programming and computer science on three operators, called combinators: C, S, and I. Wait, two are enough (we can reconstruct I from the other two). Wait, one is enough, J, from which we can deduce C and S. And yes, everything that we know can be reconstructed from that core. Programs, data, termination, undecidability, the whole farrago. There is even a programming language, iota, based on just this combinator. It is a curiosity (you can look it up) but for example John Backus's FP is a more realistic application of the Schönfinkel ideas.

I may come back to Schönfinkel in a future newsletter, analyzing his contributions from a software engineering perspective. We know little about him, including that he died in Moscow around 1942, and also that earlier the secretary of the Hilbert group wrote on the page of the registry that recorded his leaving Göttingen “thank goodness he is gone!”. This detail, like most of what I have learned about Schönfinkel, comes from a riveting article that Stephen Wolfram devoted to him a few years ago, after performing considerable historical research. You can find the 2020 article here with a 2021 follow-up here.

By the way, currying should be called schönfinkeling. That is for another time.

Brain drain reversed? Not so fast

Today's Washington Post has an article stating that foreign scientists are no longer willing to put up with visa and other issues in the US, and are looking elsewhere. You can find the article here (and thank me for “gifting” it to the recipients of this newsletter through this link, as it normally sits behind a paywall).

Things are tough, a predictable consequence of what is universally acknowledged as the worst US administration ever, but I do not think the article has it right. The US remains the top attractor.

Keynote for VERIFAI

The VERIFAI workshop of 8-11 March 2026, on The Interplay between Software Engineering and Formal Verification, now has its first announced keynote: by Tim Menzies from North Carolina State University, on the topic “Beyond Testing: How to Herd the Chaos of Nondeterminate Systems”. As a reminder, the call for contributions (extended abstract OK) is open, with a deadline of 20 December. See https://www.laser-foundation.org/verifai-26/.

Cover photo: Zurich, evening