Y
Traceability of software requirements
This is a long post so I apologize in advance.
My company's software procedures have just been audited for the first time for compliance with ISO9001. We manufacture computers for embedded applications and have had ISO9001 certification for our hardware development, production, and testing for some time, but we have only recently implemented formal procedures in the software area. Our software consists mostly of drivers, diagnostics, and operating systems kernels that reside on our hardware products or are intended for incorporation by customers into their software applications.
The auditor who checked our software procedures and documents was generally satisfied with our system, but has witheld certification because he claims that there is no documented traceability of requirements from one document to the next.
For example, if we are designing and manufacturing a computer system in accordance with a customer specification that calls out specific Built-in Tests (BIT), we will write a Software Requirements Specification (SRS) that specifies what the BIT software must do. Of course, the SRS must reflect the customer's requirements, but I don't think it's necessary to document the mapping of the spcification requirements to the SRS.
Once the software has been written, it must be tested in accordance with a Software Test Description (STD) document. The STD must have a one-to-one correleation with the SRS, but again, I'm not sure it's necessary to document this correlation.
Software test results are documented in a Software Test Report (STR). The auditor insists that there be documented correlation from the STR back to the requirements of the customer specification.
Theoretically, whoever reviews and approves each document should verify that all requirements are covered. Nevertheless, I do not deny that the requested traceability is desireable, and it is quite likely that we will use some kind of compliance matrix to verify that requirements are met, but I'd prefer to avoid commiting to this in written procedures.
I have not found any mention in ISO9000-3 of a requirement for this kind of documented traceability and I do not believe that the auditor is within his authority when insisting upon it. Certainly we have never been required to document requirements traceability with respect to mechanical and hardware related documents, so why for software?
I'd appreciate anyone's thoughts on this.
YossiD
This is a long post so I apologize in advance.
My company's software procedures have just been audited for the first time for compliance with ISO9001. We manufacture computers for embedded applications and have had ISO9001 certification for our hardware development, production, and testing for some time, but we have only recently implemented formal procedures in the software area. Our software consists mostly of drivers, diagnostics, and operating systems kernels that reside on our hardware products or are intended for incorporation by customers into their software applications.
The auditor who checked our software procedures and documents was generally satisfied with our system, but has witheld certification because he claims that there is no documented traceability of requirements from one document to the next.
For example, if we are designing and manufacturing a computer system in accordance with a customer specification that calls out specific Built-in Tests (BIT), we will write a Software Requirements Specification (SRS) that specifies what the BIT software must do. Of course, the SRS must reflect the customer's requirements, but I don't think it's necessary to document the mapping of the spcification requirements to the SRS.
Once the software has been written, it must be tested in accordance with a Software Test Description (STD) document. The STD must have a one-to-one correleation with the SRS, but again, I'm not sure it's necessary to document this correlation.
Software test results are documented in a Software Test Report (STR). The auditor insists that there be documented correlation from the STR back to the requirements of the customer specification.
Theoretically, whoever reviews and approves each document should verify that all requirements are covered. Nevertheless, I do not deny that the requested traceability is desireable, and it is quite likely that we will use some kind of compliance matrix to verify that requirements are met, but I'd prefer to avoid commiting to this in written procedures.
I have not found any mention in ISO9000-3 of a requirement for this kind of documented traceability and I do not believe that the auditor is within his authority when insisting upon it. Certainly we have never been required to document requirements traceability with respect to mechanical and hardware related documents, so why for software?
I'd appreciate anyone's thoughts on this.
YossiD