ISO9000-3 - Software Traceability Requirements

[YossiD]

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

 

[Claes Gefvenberg]

Hi YossiD, and welcome to the Cove

Interesting question. At first glance I agree with your conclusions, but I'd like to think it through for a while.

And hey, don't apologize... I've seen posts a lot loger than this one...

/Claes

 

[Vincnet]

Well YossiD,

my feeling is the following, if you :

1) lay-out your customers requirement in an organised numbered way with a unique id for each of them.
2) write your SRS following the same organisation as in the customer's requirement file or at least refering to each requirement with it's unique id in the SRS.
3) Keep the same organisation in the STD.

Then you can keep fulll traceability without having to do any mapping or cross reference table. And your auditor shouldn't say anything or it would be abuse of power.

In fact, I would just refer documents in cascade, SRS having the customer's requirement file name in it's header. and the STD having both customer's req and SRS refered in it's header.

Repeating everything all the time sounds stupid to me, it's giving up dictionaries and putting word definitions in the body of a text.

Well that's my opinion but I might be too permissive an completely wrong in my reading of the standard.

Anyway sack you auditor

Good luck !

Vinc

 

[howste]

I noticed that you didn't specify which version of ISO 9001. Are you being audited to 1994 or 2000? Assuming it's the 2000 edition, here's what you need to comply with:

7.3.3 Design and development outputs
The outputs of design and development shall be provided in a form that enables verification against the design and development input and shall be approved prior to release.
Design and development outputs shall
a) meet the input requirements for design and development,
b) provide appropriate information for purchasing, production and for service provision,
c) contain or reference product acceptance criteria, and
d) specify the characteristics of the product that are essential for its safe and proper use.

It doesn't say you must maintain "traceability" but it does say that your requirements (inputs) need to correlate with the results (outputs). Your design & development review records must show that you compared the outputs against the inputs and the requirements were met.

 

[YossiD]

Thanks everyone for your replies.

Our previous audit was to ISO 9001:1994 but the next one will be to 9001:2000 so the auditor was already in that mindset.

In any event, the auditor granted certification after further discussions and minor revisions to the procedures. We maintained that it is the responsibility of the persons reviewing and approving the SRS and STD to ensure that all customer requirements are covered and that ISO 9001 does not mandate that the review process be documented.

While documenting traceability is not such a large effort initially, our projects tend to be characterized by continuously changing requirements, which is not uncommon in embedded systems. Each change triggers revision of an entire chain of documents, so you can see where this is going.

I agree that documented traceability from customer requirement to SRS to STD to STR is a good idea, but the time required to do this is a luxury that we cannot always afford, and this is why I did not want to commit to it in the procedures.