Sad to say, this is a situation that I see time and time again, and it
inevitably leads to problems in validating safety critical systems.
Verification of the code to low level design through low level module
testing providing MC/DC coverage is easy, but demonstrating that the
system validly accurately meets the unformed user requirements is much
harder. Using formal methods to create the requirements is one way of
addressing this, as it leaves fewer corners for ambiguities to hide. Z
was used extensively for iFACTS, and on a couple of other projects I
have worked on have used a variety of logic tables to specify
requirements where possible.

Nick

On 19/02/2014 12:28, Michael J. Pont wrote:
> The companies that I deal with> produce systems ranging from aerospace systems to household appliances.>> In many cases (probably the majority of cases that I see), there is limited> evidence of "process" or documentation available from the "embedded team"> when I arrive at the company door. Requirements documents are often*very*> basic, if they exist at all.