Originally Posted by
Bbtengineer
The software had faulty inputs.
I would expect a software engineer to anticipate faulty inputs, and to figure out how to detect them and deal with them.
Apparently they did neither.
In what universe was a totally unconstrained application of AND ever going to be appropriate?
It obviously didn’t work and I can’t quite actually believe we’re discussing a hypothesis that it did.
The flaw wasn't in the software - it acted exactly as the software requirements would have it react.
The flaw was in the software
requirements. Software is tested to confirm it conforms to the requirements - not to confirm it does what the designer intended...
This, unfortunately, is a common problem with software - poorly defined requirements that result in software not behaving as we'd like.
This is somewhat independent of s/w DAL (Design Assurance Level) - even DAL A (flight critical) software can behave in unanticipated ways if the requirements are not clearly defined.