SOFTWARE / FIRMWARE  V&V  "MODEL"

The key document that supplies the model for all SW V&V documentation that I recommend is in Table 3 of the following:

http://google2.fda.gov/search?q=cache:Sp9J-y5akHwJ:www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm089593.pdf+guidance+on+510(k)+with+software&client=FDAgov&site=FDAgov&lr=&proxystylesheet=FDAgov&output=xml_no_dtd&ie=UTF-8&access=p&oe=UTF-8

Per that Guidance, a software / firmware V&V "package" / test report should must consist of the following 11 documents:

01.  Level of Concern;
02.  Software Description;
03.  Hazard List (I recommend the ISO 14971 Product Risk Management File / Report);
04.  Software Requirements Spec;
05.  Design Spec;
06.  Development;
07.  Architecture;
08.  V&V[T] (sic) -- the test cases, e.g., IQ, OQ (and Pt 11 if aplicable), PQs; or comparable;
09.  Traceability [Matrix], esepcially 04/05 Requirements to 08 test cases;
10.  Unresolved anomalies ("bugs");
11.  Revision(s) / Release Number.

While this is geared to devices and a 510(k) submission, I have successfully used it as a model for all regulated industries and all software / firmware V&V, in-, as-product, in test / production equipment, process, facilities, et al.  I have never had a problem in any US FDA audit, ISO audit, or vendor audit.  And it is a requirement for any device submitted to the FDA for IDE, 510(k), or PMA review.

Validation principles in general , e.g., Rqmts Specs, IQ, OQ, PQs, are readily available on the fda.gov website. 

21 CFR Part 11 (when using e-records and/or e-sigs to document CGMP actions / records:

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=11


The fda.gov website also has other guidance docs on SW V&V.  But the above two provide much of the "meat" for SW V&V.

You will find much contradictory "advice" on the Internet, including some that contradicts the above.  However, I emphasize that if the medical device has to undergo any US FDA review or audit, its software documentation MUST confirm to the above guidance document with its 11 documentation requirements.  And the original author of that guidance emphasized in a phone conversation with me when it first came out that it's requirements were basically taken from the non-regulated software industry itself, not created by the FDA in some 'vacuum'.