Imagine someone designing and constructing a bridge, and right after it was possible to walk gingerly across one part of it, the people in charge of the project said "hmm, could you put a parking area in the middle?". And then, right after you had done that, came back and said "great, but we'd like to make the whole thing a double decker so we can run a train line across the lower level?". Miraculously, you pull this off, and then they announce that they've realized that the bridge needs to open in the middle to allow large boats through.
We (generally) do not allow engineering projects rooted in the physical world to have fluid specifications, because of the cost and complexity of doing so.
Although there is a real cost and huge complexity to allowing software engineering to accomodate goal flexibility as much as we do, it is vastly less than would be the case for most mechanical and chemical engineering projects.
And the reality is that human goals do change as exposure to a project takes place. There are probably many people involved in bridge specifications who wish they could have gone back and significantly altered some part of the design, based on things learned during construction and early use. But we don't allow that, and so we're left with an impression that only non-software engineers are good at handling performance specifications. It's not true.
In the realm of software engineering I don't know that we've had a catastrophic failure where the infrastructure costs of repair were in the billions or there was tangible loss of life. The biggest example that comes to mind was the explosion of the Ariane rocket because the software caused the rocket to rotate in the wrong direction so the ground-controllers executed a self-destruct... maybe pieces of a Tesla that crashed while on auto-pilot would be a candidate for physical objects we can hold in our hands to remind us that software bugs can kill?
However, that search took me to an example that I didn't recall, resulting in loss of life. I'll probably reference this story about the Therac-25 in the future as it hits on a number of clear software engineering failures:
-- https://www.bugsnag.com/blog/bug-day-race-condition-therac-2...
You can also chalk it up as a non software engineering failure because the sensor hardware is what failed first.
It's not very clear cut.
The multi-day 2003 blackout in the Northeast US states and Ontario, Canada qualifies in terms of impact (many billions of $). It was a systemic flaw with a software bug as a proximate cause. I think most major failures with high impact in a software-intensive system will sort of look similar: a software fault that cascades to the real world.
https://en.m.wikipedia.org/wiki/Northeast_blackout_of_2003
Other examples might be the various outages in airline reservation systems.
If you’re interested in this kind of thing, the archives of the Usenet newsgroup comp.risks are interesting (not sure if it’s still active).
This same style of development could be applied to any software development venture, but it's usually not, because most software doesn't benefit from it enough to warrant the extra time and expense.
(The majority of my avionics work has actually been directly working on such simulation systems, building and certifying them for formal verification use, but I have done some verification work on avionics boxes as well.)
Outside of my personal experience, I am aware of projects using things like TLA+. I suspect that is more common the higher up you go in system criticality. Even within avionics, not every system requires the same level of scrutiny... for example, you need to more exhaustively test a flight controls system than a flight management system.
In any case, the FAA does not dictate particular tools. They dictate a level of quality that any tools used must adhere to (the tools themselves must be certified based on how they are used), but otherwise a project is welcome to use whatever tools they wish. Or, no tools.
This is Real Scottsman nonsense. Algorithms can be easily tested, and can be modified and optimized to meet a host of requirements, from computational complexity to real-world efficiency to fairness to privacy. We specify the performance requirements of software all the time.
That would be system programming, part of computer engineering actually [1], not software engineering. Also software engineering usually does include some computer engineering.
Source: I studied EE, did not get a PE or any sort of license beyond my degree, and worked in defense, and commercial engineering jobs