Disagreement with auditor

I work for an AS9100D certified company.

During a recent certification audit the auditor reviewed an in-house specification for a product we developed as a subassembly for a system that we have designed, and which has its own specification.

Although it is a subassembly of the system, this product can also be used in other systems, or even sold as a standalone product that others can integrate into their own systems. Its specification is therefore self contained and does not rely on the system specification in any way. Any system requirements that are applicable to the product have been copied into the product specification.

Nevertheless, the auditor insists that we include the system specification as a referenced document in the product specification, and has cited us for this omission in the audit report.

I maintain that even though the product was developed as a subassembly of the system, it is now a standalone product so its specification need not be linked to that of the product.

Obviously I can add the system specification as a referenced document in the product specification, in order to satisfy the auditor, but I do not want to set a precedent that will affect other projects. Furthermore, adding a referenced document that is not cited anywhere in the specification is, as far as I am concerned, meaningless, particularly since the referenced documents section includes a statement that the referenced documents are applicable to extent specified.

Can anyone comment on this? Also, is there a point of contact in the AS9100 Working Group who might give me an official reading on this?

Thanks very much.

 

First of all, a bit of background. I am not part of the Quality organization though I do have some QA background. I handle documentation in our Projects group, which is why this issue came to me.

Upon further investigation, I have found that the auditor was referring to AS9100D para 8.3.3 (Design and Development Inputs), in connection with a different specification (not the one that I mentioned in my original question. The remark in the writeup was "The related HLR not part of the Spec reference document list."

As a result of this our QA added a requirement to an internal procedure that all specification documents must include a reference to a requirements document. so essentially, my beef is with our QA and not with the auditor.

While I completely understand the need for documents traceability, I also believe that there are times when it is reasonable to forego preparation of a High level Requirements (HLR) document and start the development process with an internal specification. In this case, the new product is similar to an existing product, so the specification for the "new" one is heavily based on that of the "old" one. In such a case I believe that preparation of an new HLR is simply a paper exercise, and nothing more. Once the internal specification is signed/approved, it becomes the high level requirement.

In the best of all possible worlds, with unlimited resources, preparation of an HLR for the "new" product, would probably be a good idea, but that's not quite the situation.

I understand that we will soon be acquiring a requirements management tool, in which case these issues might be handled as part of the workflow and electronic approvals in that tool, making some of these documents unnecessary.

Thoughts?

 

Since our QA has added this requirement to our procedures, my beef is with them. I have been instructed to take the path of least resistance and do what they want, so I have done so. It goes against my better judgement, but this has become a case of choose your battles, and this is a relatively minor one.

In any event, the Referenced Documents section of my specification says that the listed documents are applicable to the extent stated, and since the document I added isn't referenced anywhere in the specification, it doesn't much matter. I just don't like doing things a particular way because someone decided that's how it has to be, even if it doesn't make much sense.

Thanks for the support.