Martyn,

I apologize in advance, but I cannot get caught up in a
long email argument right now. I am trying very hard to
finish my book---which will explain to everyone how I 
think safer systems can be built. (For anyone interested,
a new version of the first half is available at 
 http://sunnyday.mit.edu/book2.html 
but the price of this free look is that I hope you will 
provide me with feedback if you have it about how to improve
what I've written. Also, you will be a little frustrated because
the real "how-to" part is the part that is not yet written).
This month is the only time I have to write---the school
year starts at the beginning of September and then I have
no time. I am, frankly, always sorry when I get pulled into
one of these web debates because it takes so much time and
produces so little. So I am afraid that I cannot 
  >...pursue this to a point where 
  >we agree, and where we can write a joint message that 
  >might clarify things.

So I have to limit my response to just two points. It sounds
to me that you believe the way to design complex systems is
for experts in the different pieces to design each of their
parts. I don't believe this. We learned 50 years ago of the
need for system engineers who do that design. Boeing used to
have some of the best system engineering around -- they 
abandoned that for distributed design in the 787 and have
learned the result.

You write:
 >At some point in the system partitioning and architectural design,
 >the different disciplines will start to describe the requirements for
 >their part, using techniques that are progressively more suited to
 >continuing development than to communicating with people outside their
 >discipline. For a spacecraft, the metallurgists will take decisions and
 >expect the domain experts to trust their expertise; so will the
 >structural engineers (who won't expect to review their finite element
 >analyses etc with the domain experts); so will the electronic engineers
 >(who won't expect the domain experts to read VHDL) and the
 >telecommunications engineers and the aeronauticals ... and so wll the
 >software engineers.<br>

This is not the way I understand complex system design. The
requirements should not be "described by the different 
disciplines", they should be written by the system engineers 
and the different disciplines will then implement them. The 
disciplines may write design specifications for their 
components, but not requirements specs.

Actually, lots of groups do it your way -- which is a main
reason why, in my experience, we have so many disastrous 
complex systems projects.  In addition, for some reason 
I don't understand the software engineering community for 
some reason over the years has started to equate requirements 
specs and design specs. They are not and should not be the 
same thing. The software engineers can write their own 
design specs and the metallurgists will make their 
own design decisions about how to implement the requirements
in the "metal" parts of the system, but they need to be 
provided with requirements that specify exactly what 
behavior their designs must produce (like the wings must
not crack when bent to a certain degree).  And in the 
very critical systems on which I work, the System Safety 
engineers DO go in evaluate these specs, they do not
"trust" the domain experts.

I could go on, but I am writing the chapter on the system safety
engineering process right now for my book and would rather spend
the day on that. The type of limited interaction that is possible
by email is just not conducive to communication.

The second point is that I want to see a carefully controlled,
scientific study of the readability and error-proneness of formal
specification languages -- not just anecdotes and experience
statements. Many years ago, we did such an experiment. We used
the MD-11 flight management system, which most people would
agree is very complex. We had the subjects (graduate students
in aerospace engineering and in computer science at MIT) take
a spec written in different types of languages and answer questions 
about it. Both the computer science and aerospace students made
the most mistakes (both in answering questions and making changes)
in the formal specification language specs (formal logic). The
difference was statistically significant. Now one experiment 
can always be criticized.  There need to be lots of experiments.
But nobody else is doing these things. I gave up and decided 
I didn't really care enough about the whole argument
and could spend my time on more important endeavors than such 
experimentation. (Actually, we did one more experiment on 
visualization of requirements and are planning more in the 
future but not on specification language design). To be 
honest, although I do believe that formal specification 
languages can be more error-prone, unlike you, I just 
don't believe the specification language is very important 
to safety. Same with the implementation language (I have 
bowed out of the Ada vs. C arguents too). I have written 
250 pages (and will write another 200) in my new book 
and specification languages will only come up in terms 
of what they should provide (traceability, design rationale,
readability including small semantic distance)-- at most 
about 10 pages out of the total 500 pages on how to design 
and operate safer systems.

Anyway, as a scientist, I want to see scientific evidence of 
claims that I have not found to be true in my work with
industry. And I don't want to waste my time arguing about
what I have found to be the least important parts of the 
safety engineering problem.

So I doubt we will ever be able to write a joint statement
because we see the problem so differently.

Nancy