The A400 crash may well be the first known accident due entirely to a problem with DAL A software. All I know about it is what I've read in news accounts and I'm anxiously awaiting the official report (hopefully Airbus/Rolls won't use the military aspects of the A400 to make the report confidential). But the news reports point to a glaring requirements error - properly designed FADEC software should have put up a 'no dispatch' warning if a critical calibration was undefined.
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.