© 2014 | infoteam software ag | v 3 seite 1 der anwender. das …€¦ · each software system of...

www.infoteam.de© 2014 | infoteam Software AG | V 3

� Requirements und Usability

Engineering

� Software Design & Development

� Verification & Validation

� Maintenance, Service and Support

� Standard Compliant ALM

(IEC 62304)

� Consulting

Kurzvorstellung

Der Anwender. Das Produkt. Die Anforderungen.Seite 2


Agenda

� Das Anforderungsmanagement

� Was fordert die IEC 62304

� Beispiel

� Unterstützendes Tooling



Hintergrund Fachaussschuss

� VDI Fachausschuss „Qualitätssicherung für Software in der Medizintechnik“

• Base Practices ( Was muss getan werden)

• Best Practices (Wie kann man es tun)

• Arbeitsgruppen zur Ausarbeitung von Best Practices auf Basis der Base Practices bestehend aus Mitgliedern unterschiedlicher Firmen, z.B. AG2 : „Software Requirements Management“

� Best Practices Anforderungsmanagement

= Leitlinien und Handlungsempfehlungen zur Umsetzung des Prozess für Anforderungsmanagement, um den Vorgaben für die Entwicklungvon Medizinsoftware gerecht zu werden



Systemanforderungen

Wo stehen wir im Projekt Easy Homecare?


Softwareanforderungen Software-anforderungen

Arzt Patient


Das Anforderungs-management


Software-AnforderungsanalyseZiel und notwendige Ergebnisse


� Ziel

� Ergebnisse (Outcomes)

� Der Anwendungsbereich der Software ist spezifiziert

� Die Hauptbedienfunktionen sind spezifiziert

� Die Gebrauchstauglichkeitsanforderungen sind spezifiziert

� Die Anforderungen an die einzelnen Software System-Komponenten und deren Schnittstellensind definiert.

� Die Software Anforderungen sind hinsichtlich deren Richtigkeit und Testbarkeit geprüft.

� Die Prioritäten zur Implementierung der Software Anforderungen sind festgelegt und dokumentiert

� Konsistenz und Rückverfolgbarkeit (Traceability) zwischen den Software Anforderungen und den System Anforderungen ist hergestellt.

� Risikokontrollmaßnahmen sind in den Software Anforderungen abgebildet.

� Die Risikoanalyse wurde überprüft und ggf. überarbeitet.

� Die System Anforderungen wurden überprüft und ggf. überarbeitet.

� Die Software Anforderungen wurden überprüft und freigegeben.

UE

RM


Ursprung von AnforderungenWer macht was und dokumentiert wo?


Anforderungen

Produkt Entwicklung

(IEC 60601-x, IEC 62304)

Risiko-management

(ISO 14971)

Gebrauchs-

Tauglichkeit

(IEC 62366)

Problemlösung und Wartung

(IEC 62304,

ISO 14971)

Usability Engineering

File

RiskManagement

File

Change-Request

Entwicklungsakte


Best Practice Spezifiziere die Anwendung (SD.3.BP.1)


� SD.3.BP.1: Specify the application. Specify the application of the software, including the medical purpose, the patient population, the intended operator profile and the environment. Refer to the intended use of the system.

� Softwarerelevant

� Keine Forderung aus der IEC 62304


Best Practice Spezifiziere die Anwendung (SD.3.BP.1)


� SD.3.BP.1: Specify the application. Specify the application of the software, including the medical purpose, the patient population, the intended operator profile and the environment. Refer to the intended use of the system.

� Handlungsempfehlungen

� Prüfe, ob die Software Teil eines Medizinproduktes ist und ob es bereits Definitionen der Zweckbestimmung, der Patientengruppen und der Anwender gibt.

� Dokumentiere den Einfluss der Zweckbestimmung auf die Software

� Dokumentiere die Patientengruppe, die Benutzergruppe und das Benutzungsumfeld

� Dokumentiere die Nutzungsszenarien der Software


Was fordert die IEC 62304?


Entwicklung des Gesamtsystems

IEC 62304

Software-LifeCycle nach IEC 62304


Gesamt-System Spezifikation

Abnahmetest (Gesamtsystem)

SW-Entwicklungs-

planung

SW- Anforderungs-

Analyse

Design der SW-Architektur

Detailliertes SW-Design

Implementierung und Modultests

SW-Integration und Integrationsprüfung

Softwarefreigabe

Prüfung des Software-Systems

SW- Anforderungs-

Analyse


Software-Risikomanagement

Software-Konfigurationsmanagement

Software-Problemlösung


Entwicklung des Gesamtsystems

IEC 62304

Software-LifeCycle nach IEC 62304



Abnahmetest (Gesamtsystem)

SW-Entwicklungs-

planung

SW- Anforderungs-

Analyse

Design der SW-Architektur

Detailliertes SW-Design

Implementierung und Modultests

SW-Integration und Integrationsprüfung

Softwarefreigabe

Prüfung des Software-Systems

SW- Anforderungs-

Analyse



Wesentliche Inhalte der IEC 62304 bzgl. Anforderungen


� Kap. 5.2.: Analyse der Software-Anforderungen

� 5.2.1: Ableitung der Software-Anforderungen aus den SYSTEM-Anforderungen und Dokumentation

� 5.2.2: Inhalt der SW-Anforderungen

� 5.2.3: Einbeziehung von Risikokontroll-Maßnahmen in die Software-Anforderungen

� 5.2.4: Erneute Evaluation der Risikoanalyse

� 5.2.5: Aktualisierung von System-Anforderungen

� 5.2.6: Verifizierung von Software-Anforderungen

� Kap. 5.3.1: Umsetzung von SW-Anforderungen in eine Architektur

� Kap. 5.5.3: Akzeptanzkriterien für SW-Einheiten

� Kap. 5.7.1: Festlegung von Prüfungen für SW-Anforderungen

� Kap. 5.8.1: Sicherstellen der Vollständigkeit der SW-Verifizierung


Best PracticeReferenzmodell für Anforderungen


Title

REQ-ID Revision

State Responsible

Level Type

Risk Control

Measure

Yes / No Regulatory

reference

ISO 14971/ IEC62304/ IEC 62366

Release Priority

Description

Reason/

Source

Verification

Type

Acceptance

Criteria

References

(Traceability)


Best PracticeAnforderungs - Zustandsautomat


Open

Review

Approved Obsolete

Implemented

Closed


Ebenen von Anforderungen und Arbeitsergebnisse


•Anforderungen an das Produkt aus Sicht der Kunden/ Anwender

•Customer Requirement Specification (CRS)

Customer (Product) Requirements

•beschreibt Anforderungen an das Gesamtsystem und dessen Sub-Systeme (HW + SW)

•System Requirement Specification (SRS)

System Requirement

•beschreibt Anforderungen das Softwaresystem. (Nicht Hardware oder Mechanik)

•Software System Requirement Specification (SSRS)

Software System Requirement

•beschreibt Anforderungen auf dem Level der Softwarekomponenten

•Software Design Description (SDD)

Software Requirement


Best Practice – Leite SW-Anforderungen aus Systemanforderungen ab


� SD.3.BP.4: Derive software requirements from system requirements. For each software system of the medical device, define and document software system requirements from the system level requirements.

Define and prioritize functional and non-functional requirements of the software elements of the system and their interfaces and document them in a Software Requirements Specification.

Analyze the software requirements for correctness, completeness, consistency, feasibility and testability. Identify any derived requirements.

� Erstelle Softwareanforderungen

� Definiere Anforderungen an die Funktionen der Systemschnittstellen

� Prüfe und komplettiere die Liste der Software-Anforderungen (u.a. mit Hilfe der Liste Kap 5.2.2 der IEC 62304)

� Dokumentiere und etabliere Regeln für „gute“ Anforderungen (messbar, eindeutig, testbar)

� Dokumentiere Anforderungen so, dass unterlagerte Testfälle darauf referenzieren können. (Verifizierbarkeit!)




SystemanforderungenSoftware-

anforderungen

Arzt Patient


Systemanforderung (System requirement):

SYSREQ.0004: Es muss immer ein valider Behandlungsplan auf dem Gerät verfügbar sein.

� Softwareanforderung (Software System Requirement)

Beim Starten der Easy-Pump muss die Software des Gerätes prüfen, ob ein valider Behandlungsplan verfügbar ist. Ist kein valider Behandlungsplan verfügbar, dann muss das Gerät einen Fehlerstatus ausgeben. (SSRS_EasyPump.00034)

� Softwareanforderung (Software Requirement)

Beim Starten der Easy-Pump muss sichergestellt werden, dass ein Behandlungsplan auf dem Gerät verfügbar ist. Ist ein Behandlungsplan verfügbar wird die Datenkonsistenz mit einer CRC 32 geprüft. Wenn diese Prüfungen fehlerhaft sind, dann blinkt die Status-LED rot. Eine Behandlung darf nicht möglich sein. (SDD_EasyPump.0007)






Title Verfügbarkeit eines Behandlungsplans in der Easy Pump

REQ-ID SSRS.0034 Revision 0001

State Open Responsible Birgit Stehlik

Level Software System Requirement Type Functional Requirement

Risk Control

Measure

Regulatory

reference

Release Priority

Description Beim Starten der Easy-Pump muss die Software des Gerätes prüfen, ob ein valider Behandlungsplan verfügbar ist. Ist kein valider Behandlungsplan verfügbar, dann muss das Gerät einen Fehlerstatus ausgeben.

Reason/

Source

Verification

TypeBlack-Box-Test

Acceptance

CriteriaDas Gerät geht im Falle eines nicht vorhandenen oder ungültigen Behandlungsplan in den Fehlerzustand.Eine Behandlung ist nicht möglich.

References

(Traceability)SYSREQ.0004SDD_EasyPump.0007


Unterstützendes Tooling


Dokumentation von Softwareanforderungen


� Unterstützendes Tooling durch ApplicationLifecycle Management Software ist notwendig und hilfreich

� Beispiele: Microsoft Team Foundation Server, Polarion, HP Quality Center u.v.m.#

� Vorteile:

� Artefakte und Workitems können elektronisch verwaltet werden

� Formularmasken wie das Requirement-Referenzmodell sind einfach abzubilden

� Zustände von Workitems werden unterstützt

� Traceability durch elektronische Verlinkungen zwischen Requirements ist möglich


Traceability


ALM Datenbank

Anforderung(SDD)

Anforderung(SDD)

TestfallTestfall

Anlegen von

TracingTool

Trace-Matrix

Anforderung(SSRS)

Anforderung(SSRS)


Wege aus dem Labyrinth


Kümmere dich um deine Requirements.

JETZT!

Nicht später.

Grenze die unterschiedlichen Anforderungsebenen

voneinander ab.Gutes Tooling kann dir das Leben einfacher machen!

Vergiss nicht den Input der anderen Disziplinen!


Dann klappt‘s auch mit dem Produkt


Vielen Dank für Ihre Aufmerksamkeit.


Kontakt

Telefon: +49 (0) 9131 / 78 00 -

Telefax: +49 (0) 9131 / 78 00 -

Am Bauhof 9

D-91088 Bubenreuth

www.infoteam.de


Birgit StehlikBusiness Segment Manager Medical Devices

833

[email protected]

© 2014 | infoteam software ag | v 3 seite 1 der anwender. das …€¦ · each software system of...

Documents