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] *
***************************************************************************
|