Mr. Pauls:
     
     I am sorry - I should have been more careful in what I said in my 
     posting on the above subject.  I didn't mean to imply anything at all 
     about your particular spec, since I am not familiar with it (as I 
     said, what you said in your posting got me to thinking).  I have, 
     however, participated in many IPC working group meetings on other 
     standards, and I am familiar with the way that decisions are reached.  
     In my posting, I was wondering "out loud" whether other people had 
     considered the difference between consequences and risk of failure, 
     and whether it made sense to indicate in a standard how the differ- 
     ences that appear in it were arrived at.  Maybe it's true that in most 
     cases determining risk is just too difficult to be worth the effort - 
     I don't feel qualified to say.
     
     Certainly I did not mean to impugn the motives of the participants, 
     nor to imply that there was anything wrong with engineering judgment, 
     if that's all that's available, nor did I imagine a significant 
     lengthening of the standard to indicate sources of information.  I 
     don't agree that the "list [of sources of information] is endless".  A 
     footnote might simply refer to a published paper that participants 
     considered relevant to their decision, or it might simply say "This 
     requirement is based on the experience and judgment of the working 
     group, including unpublished data.  Relevant data (published or not) 
     would be welcomed for consideration in developing future revisions of 
     this standard".  If that's too long, the underlying idea could be 
     conveyed by a single symbol, or a note could say that where no source 
     of data is indicated for a requirement, it is based on engineering 
     judgment.  From my own experience, I know that some requirements are 
     agreed to without significant disagreement, and others take a long 
     time to hammer out.
     
     What I have in mind is some way of conveying to those who didn't have 
     the benefit of participating in the deliberations what the thinking 
     was that led to a requirement's being expressed in the way that it is. 
     I know the difference between reading a standard that I was not 
     involved with and one for which I was present at the meetings.  No 
     matter how well the requirements are written, I am able to understand 
     and explain a lot more when I got to participate.
     
     Years ago I found what I thought was excellent guidance for the pre- 
     paration of standards in MIL-STD-961, (now titled "Standard Practice 
     Defense Specifications").  (I've noticed that few other standards- 
     setting organizations have any standard or even published guidance on 
     how to write a standard.)  The wording of the part that stands out in 
     my mind (para. 5d) has not changed:
     
          A carefully documented. permanent record should be main- 
          tained by the specification preparing activity of the source 
          and reason behind particular requirements and changes to 
          requirements.  The rationale (measurement, testing, judg- 
          ment, etc.) behind a specific numerical level is one example 
          of what the record should contain.  Issues and controversial 
          areas during the coordination process should be noted, and 
          it may be desirable to summarize these issues and areas in 
          the "Notes" section of the document and solicit feedback as 
          experience develops.  This record should provide a basis for 
          related application guidance and a history useful in future 
          document revisions.
     
     Although it appears that few preparers of military specs and standards 
     actually follow this guidance, it still seems to me to be a goal worth 
     working toward for any preparing activity.
     
     Gordon Davy

***************************************************************************
* TechNet mail list is provided as a service by IPC using SmartList v3.05 *
***************************************************************************
* To unsubscribe from this list at any time, send a message to:           *
* [log in to unmask] with <subject: unsubscribe> and no text.        *
***************************************************************************
* If you are having a problem with the IPC TechNet forum please contact   *
* Dmitriy Sklyar at 847-509-9700 ext. 311 or email at [log in to unmask]      *
***************************************************************************