IEC-62304模板（精編版）

1、company：file no.file ：軟件驗證報告revised no. 1公司名稱：company name:公司地址：company address:軟件名稱：softw arename:版本號：version number:軟件適用范圍:softw are applic ations： 軟件發(fā)布時間:softw are release time： 標準：standard:軟件驗證報告en 62304:2006 medical devicesmedical device software-software life cycle processes結論：result:符合en 6230

2、4:2006 要求編寫compiled by: (name/title/dept.)日期date:評審reviewed by (name/title/dept.)日期date:批準approved by: (name/title/dept.)日期date:page 22 of 22en 62304 ： 2006 的應用軟件預期目的和用途識別的危害的可能來源與處理醫(yī)療器械數據有關的危害判定已知和合理可預見的危害已進行的安全性標準驗證已進行的風險控制方法軟件安全性級別：a 級 b級 c 級確定軟件安全性級別的依據：en 62304 ： 2006章和條第四章全部要求iec 62304:2006軟件安

3、全性級別要求a級xb級xc級x5.1xxxxxxxxxxxxxxxxxxxxxxx5.6全部要求xx5.7全部要求xxxxxxx6.16.1xxxxxxxx6.3全部要求xxx7.1全部要求xx7.2全部要求xx7.3全部要求xxxxxxx第8章全部要求xxx第9章全部要求xxxen 62304 ： 2006possible test case verdicts:- test case does not apply to the test object- test object does meet the requirement- test object does not meet the r

4、equirement:n/a pass (p)fail (f)iec 62304 ： 2006clauserequirement + testresult - remarkverdict4 general requirementsquality management systemthe manufacturerof medical device softwareshall demonstrate the ability to providemedical device softwarethat consistently meets customer requirements and appli

5、cableregulatory requirements.r isk managementthe manufacturershall apply arisk management process complying with iso 14971.software safety classificationa) themanufacturershall assign to eachsoftware systema software safety class (a, b, orc) according to the possible effects on the patient, operator

6、, or other people resulting froma hazard to which thesoftware systemcan contribute.the software safety classes shall initially be assigned based on severity as follows:class a: no injury or damage to health is possible class b: non-serious injuryis possible class c: death orserious injuryis possible

7、 if the hazard could arise from a failure of the software systemto behave as specified, the probability of such failure shall be assumed to be 100 percent.if the risk of death orserious injuryarising from a software failure is subsequentlyreduced to an acceptable level (as defined by iso14971) by a

8、hardwarerisk control measure, either by reducing the consequences of the failure or by reducing the probabilityof death orserious injuryarising from that failure, the software safety classification maybe reduced from c to b; and if therisk of non-serious injuryarising from a softwarefailure is simil

9、arly reduced to an acceptable level by a hardwarerisk controlmeasure, the software safety classification may be reduced from b to a.b) themanufacturershall assign to each software systemthat contributes to the implementation of arisk controlmeasure a software safety class based on the possible effec

10、ts of thehazard that therisk control measure is controlling.c) themanufacturershall document the software safety class assigned to eachsoftwaresystem in the risk management file.iec 62304 ： 2006clauserequirement + testresult - remarkverdictd) when asoftware systemis decomposed intosoftware items , a

11、nd when asoftwareitem is decomposed into furthersoftware items , such software itemsshall inherit thesoftware safety classification of the originalsoftware item(or software system) unlessthe manufacturerdocuments a rationale for classification into a different software safety class. such a rationale

12、 shall explain how the new software itemsare segregated so thatthey may be classified separately.e) themanufacturershall document the software safety class of eachsoftware itemif thatclass is different from the class of thesoftware item from which it was created bydecomposition.f) for compliance wit

13、h this standard, wherever a process is required forsoftware itemsof a specific classification and theprocess is necessarily applied to a group ofsoftwareitems , the manufacturershall use theprocessesand tasks which are required by theclassification of the highest-classifiedsoftware item in the group

14、 unless themanufacturerdocuments in therisk managementfile a rationale for using a lower classification.g) for eachsoftware system, until a software safety class is assigned, class crequirements shall apply.5 software developmentprocesssoftware development planning software development planthe manuf

15、acturershall establish a software development plan (or plans) for conducting the activities of the software developmentprocess appropriate to the scope, magnitude, andsoftware safety classifications of thesoftware system to be developed. the software development life cycle modelshall either be fully

16、 defined or be referenced in the plan (orplans). the plan shall address the following:a) theprocesses to be used in the development of the software system(see note 4);b) thedeliverables (includes documentation) of the activities and tasks ;c) traceability betweensystem requirements, software require

17、ments,software systemtest, andrisk controlmeasures implemented in software;iec 62304 ： 2006clauserequirement + testresult - remarkverdictd) software configuration and change management, includingsoup configuration itemsand software used to support development; ande) software problem resolution for h

18、andlingproblems detected in thesoftware products, deliverablesand activities at each stage of the life cycle.class a, b, ckeep software development plan updatedthe manufacturershall update the plan as development proceeds as appropriate.class a, b, csoftware development plan reference tosystemdesign

19、 and developmenta) as inputs for software development,systemrequirements shall be referenced in thesoftware development plan by themanufacturer .b) themanufacturershall include or reference in the software development plan proceduresfor coordinating the software development and the design and develo

20、pment validationnecessary to satisfy 4.1.software development standards, methods and tools planningthe manufacturershall include or reference in thesoftware development plan:a) standards,b) methods, andc) toolsassociated with the development ofsoftware items of class c. class csoftware integration a

21、nd integration testing planningthe manufacturershall include or reference in the software development plan, a plan tointegrate thesoftware items(includingsoup ) and perform testing during integration. class b,csoftwareverificationplanningthe manufacturershall include or reference in the software dev

22、elopment plan the followingverificationinformation:a) deliverablesrequiringverification ;b) the requiredverification tasksfor each life cycle activity ;c) milestones at which thedeliverablesareverified ; andd) the acceptance criteria forverificationof thedeliverables .class a, b, csoftwarerisk manag

23、ementplanningiec 62304 ： 2006clauserequirement + testresult - remarkverdictthe manufacturershall include or reference in the software development plan, a plan toconduct theactivities and tasks of the software risk management process, including the management ofrisks relating tosoup . class a, b, cdo

24、cumentation planningthe manufacturershall include or reference in the software development plan informationabout the documents to be produced during thesoftware development life cycle. for each identified document or type of document the following information shall be included or referenced:a) title

25、, name or naming convention;b) purpose;c) intended audience of document; andd) procedures and responsibilities for development, review, approval and modification.class a, b, csoftware configuration management planningthe manufacturershall include or reference software configuration management inform

26、ation in the software development plan. the software configuration management information shall include or reference:a) the classes, types, categories or lists of items to be controlled;b) the software configuration managementactivities and tasks ;c) the organization(s) responsible for performing so

27、ftware configuration management and activities ;d) their relationship with other organizations, such as software development or maintenance;e) when the items are to be placed under configuration control; andf) when the problem resolutionprocess is to be used.class a, b, csupporting items to be contr

28、olledthe items to be controlled shall include tools, items or settings, used to develop themedicaldevice software, which could impact themedical device software. class b, csoftwareconfiguration itemcontrol beforeverificationthe manufacturershall plan to place configuration itemsunder documented conf

29、igurationmanagement control before they areverified . class b, csoftware requirements analysisiec 62304 ： 2006clauserequirement + testresult - remarkverdictdefine and document software requirements fromsystem requirementsfor eachsoftware systemof the medical device ,the manufacturershall define andd

30、ocumentsoftware systemrequirements from thesystem level requirements. class a, b, c software requirements contentas appropriate to themedical device software, the manufacturershall include in thesoftware requirements:a) functional and capability requirements;b) software systeminputs and outputs;c) i

31、nterfaces between thesoftware systemand other systems ;d) software-driven alarms, warnings, and operator messages;e) security requirements;f) usability engineering requirements that are sensitive to human errors and training;g) data definition and database requirements;h) installation and acceptance

32、 requirements of the deliveredmedical device softwareat the operation and maintenance site or sites;i) requirements related to methods of operation and maintenance;j) user documentation to be developed;k) user maintenance requirements; andl) regulatory requirements. class a, b, cincluderisk controlm

33、easures in softwarerequirementsthe manufacturershall includerisk controlmeasures implemented in software forhardware failures and potential software defects in the requirements as appropriate to themedical device software. class b, c re- evaluate medical device risk analysisthe manufacturershall re-

34、 evaluate the medicaldevice risk analysiswhen software requirements are established and update it as appropriate. class a, b, cupdatesystem requirementsthe manufacturershall ensure that existing requirements, includingsystem requirements, are re- evaluated and updated as appropriate as a result of t

35、he software requirements analysisactivity . class a, b, cverify software requirementsiec 62304 ： 2006clauserequirement + testresult - remarkverdictthe manufacturershall verify and document that the software requirements:a) implementsystem requirements including those relating torisk control ;b) do n

36、ot contradict one another;c) are expressed in terms that avoid ambiguity;d) are stated in terms that permit establishment of test criteria and performance of tests todetermine whether the test criteria have been met;e) can be uniquely identified; andf) are traceable tosystem requirements or other so

37、urce.class a, b, csoftwarearchitecturaldesigntransform software requirements into anarchitecturethe manufacturershall transform therequirements for themedical device softwareinto adocumentedarchitecturethat describes the software s structure and identifies thesoftware items . class b, cdevelop anarc

38、hitecture for the interfaces ofsoftware itemsthe manufacturershall develop and document anarchitecturefor the interfaces betweenthe software itemsand the components external to the software items(both software and hardware), and between thesoftware items . class b, cspecify functional and performanc

39、e requirements ofsoup itemif a software itemis identified assoup , the manufacturershall specify functional and performance requirements for thesoup item that are necessary for its intended use. classb, cspecifysystem hardware and software required by soup itemif a software itemis identified assoup

40、, the manufacturershall specify thesystem hardware and software necessary to support the properoperation of thesoup item. class b, cidentify segregation necessary forrisk controlthe manufacturershall identify the segregation betweensoftware itemsthat is essential to risk control , and state how to e

41、nsure that the segregation is effective. class cverify softwarearchitectureiec 62304 ： 2006clauserequirement + testresult - remarkverdictthe manufacturershall verify and document that:a) thearchitectureof the software implements system and software requirements including those relating torisk contro

42、l ;b) the softwarearchitectureis able to support interfaces betweensoftware itemsand betweensoftware itemsand hardware; andc) the medical device architecturesupports proper operation of anysoup items.class b, csoftware detailed designrefinesoftware architectureintosoftware unitsthe manufacturershall

43、 refine the software architectureuntil it is represented bysoftware units . class b, cdevelop detailed design for eachsoftware unitthe manufacturershall develop and document a detailed design for eachsoftware unitofthe software item . class cdevelop detailed design for interfacesthe manufacturershal

44、l develop and document a detailed design for any interfaces betweenthe software unitand external components (hardware or software), as well as any interfaces betweensoftware units . class cverify detailed designthe manufacturershall verify and document that the software detailed design:a) implements

45、 the softwarearchitecture ; andb) is free from contradiction with the softwarearchitecture .class csoftware unitimplementation and verification implement eachsoftware unitthe manufacturershall implement eachsoftware unit . class a, b, cestablishsoftware unit verification processthe manufacturershall

46、 establish strategies, methods and procedures for verifying each software unit . whereverificationis done by testing, the test procedures shall beevaluated for correctness. class b, csoftware unitacceptance criteriathe manufacturershall establish acceptance criteria forsoftware unitsprior to integra

47、tion into largersoftware itemsas appropriate, and ensure thatsoftware unitsmeet acceptance criteria. class b, cadditionalsoftware unitacceptance criteriaiec 62304 ： 2006clauserequirement + testresult - remarkverdictwhen present in the design, themanufacturer shall include additional acceptance crite

48、ria as appropriate for:a) proper event sequence;b) data and control flow;c) planned resource allocation;d) fault handling (error definition, isolation, and recovery);e) initialisation of variables;f) self-diagnostics;g) memory management and memory overflows; andh) boundary conditions.class csoftwar

49、e unit verificationthe manufacturershall perform thesoftware unit verificationand document the results.class b, csoftware integration and integration testing integratesoftware unitsthe manufacturershall integrate thesoftware units in accordance with the integration plan(see 5.1.5). class b, c verify

50、 software integrationthe manufacturershall verify and record the following aspects of the software integration in accordance with the integration plan (see 5.1.5):a) thesoftware unitshave been integrated into software itemsand thesoftware system ; andb) the hardware items,software items , and suppor

51、t for manual operations (e.g., humanequipmentinterface, on-line help menus, speech recognition,voice control) of thesystemhave been integrated into thesystem . class b, ctest integrated softwarethe manufacturershall test the integrated software itemsin accordance with the integration plan (see 5.1.5

52、) and document the results. classb, cintegration testing contentfor software integration testing, themanufacturershall address whether the integrated software itemperforms as intended. class b, cverify integration test proceduresthe manufacturershall evaluate the integration test procedures for corr

53、ectness. class b, cconduct regression testsiec 62304 ： 2006clauserequirement + testresult - remarkverdictwhen software items are integrated, themanufacturershall conductregression testingappropriate to demonstrate that defects have not been introduced into previously integrated software. class b, ci

54、ntegration test record contentsthe manufacturershall:a) document the test result (pass/fail and a list ofanomalies );b) retain sufficient records to permit the test to be repeated; andc) identify the tester. class b, cuse software problem resolutionprocessthe manufacturershall enteranomalies found during software integration and integrationtesting into a software problem resolutionprocess . class b, csoftware systemtestingestablish tests for software r