@peekay4:
Yea, although that might be indicative of something more than just a requirements error -- pointing to a larger process breakdown.
Typically there are high level requirements, specific system / software requirements, low-level requirements, etc., which all need to be traceable up and down between them, and also have full traceability to the code, to the binary, and to all the test cases (and/or formal methods verifications as applicable).
For all data elements, there should be specifications to check for valid ranges for values (data domain), missing values (null checks), etc. Functions also need to have preconditions & postconditions on what parameter values acceptable as part of the interface contract, and assertions which must hold true.
There should've also been models of both the specifications and the design and processes to check these models for completeness.
And even if there are data errors, as mentioned before the software should be designed to be fault-tolerant and fail safe instead of simply freezing up at 400' AGL.
What you don't want to do is to fix this one specific requirement while there may be other missing/incomplete/incorrect requirements out there. So you have to take a look into the SDLC process and figure out why the requirement was missed to begin with.
YOu may have worked in the past with Orthogonal Defect Classification. This is where things get scary. In nailing down a coding error at one stage we drilled through to the conclusion that the error was a "missing typo". At the meeting we collapsed in laughter. The problem essentially conisted of the fact that a typo hadn't been propagated right throughout the development cycle. When we recovered ourselves we realised how utterly catastrophic such an error might be.
With teams using US and UK ENglish there were multiple risks of variable typos, with each being separately close enought to the other to pass muster, but with yet untested fallback routines failing in th event.
Avionic software at least appears to fall back to the backstop of handing things over to the pilot(s). The day that they stop doing so is the day that I keep my feet on the ground.
Systems are never perfect, and they don't exist in a vacuum; parallel systems may make un desired demands of them.
I'm not flying hen the person in the seat is a systems administrator; I want a pilot up there. One who can over-ride every damn system. Yes, they make mistakes, but at least they can react according to their skills, and at least their ass is on the line too.