Memoiren eines Requirements - ASQF · Lastenheft vs. Pflichtenheft Lastenheft oft sehr ungleicher Detaillierungsgrad der Anforderungen nicht alles kann umgesetzt werden Pflichtenheft

Memoiren eines Requirements

Dr. Anne Kramer, sepp.med gmbh

[email protected] 2

Über uns

Mittelständischer IT-Service Provider

30 Jahre Industrieerfahrung

Unsere Referenzen� Medizintechnik

� Pharma

� Automotive

Expertise:

Komplexe und sicherheitskritische Systeme

[email protected] 3

[email protected] 4

[email protected] 5

Lastenheft vs. Pflichtenheft

Lastenheft� oft sehr ungleicher Detaillierungsgrad der Anforderungen

� nicht alles kann umgesetzt werden

Pflichtenheft� dokumentiert getroffene Festlegungen vertraglich bindend

� ähnlich, aber nicht identisch zur Funktionalen Spezifikation

� Mehrwert der Anforderungen oft fragwürdig

� Abgrenzung zum Lastenheft schwierig

� Abgrenzung der Testphasen schwierig („Folgefehler“)

[email protected] 6

Lastenheft vs. Pflichtenheft

sinnvolle Aufteilung� Auftraggeber schreibt User Requirement Specification

� Auftragnehmer schreibt Functional Requirement Specification

Schwierigkeit „Festpreisangebot“� gesonderter Auftrag für Spezifikation

� danach genauere Abschätzung der Implementierung möglich

� „agile“ Vertragsgestaltung� Eckpunkte „sine qua non“ im Vertrag festschreiben

� enge Zusammenarbeit zwischen Auftraggeber und -nehmer

[email protected] 7

[email protected] 8

[email protected] 9

[email protected] 10

System- vs. SW-Anforderungsspezifikation

Trennung in IEC 62304 gefordert� nicht zwangsläufig eigenes Dokument

� trotzdem klare Trennung

� SW-Anforderung hat eigenen Unique Identifier

nicht nur „Schikane“

� klare Verantwortlichkeiten

� Traceability vereinfacht� zur Implementierung

� zum Test

[email protected] 11

Sicherheitskritische Anforderungen

Risikominimierende Maßnahmen sind Anforderungen� müssen klar erkennbar sein

� z.B. im Namen

Risikoanalyse enthält SW-, HW- und Prozess-Maßnahmen� Traceability oft schwierig

� idealerweise alles in Anforderungen übersetzen� auch Prozessanforderungen

[email protected] 12

[email protected] 13

Quelle: W

ikipedia

[email protected] 14

[email protected] 15

[email protected] 16

Dokumentation von Anforderungen

idealer weise Mischung aus Prosa und Modellen� Satzschablone im Hinterkopf

� Vorlagen hilfreich

Use Cases und Workflows sind geeignet für oberste Ebene� können im Systemtest abgeprüft werden

� speziell bei unklarer Abgrenzung zwischen Lasten- und Pflichtenheft

� ermöglichen retrospektive Ermittlung „alter“ Anforderungen

Reviewtechniken ausnutzen� z.B. Checklisten oder perspektiven-basiertes Lesen

[email protected] 17

Attributierung

Anforderungsattribute sind wichtig� sicherheitskritisch (j/n)

� HW / SW

� Priorität

� gültig für Version

� IREB ® CPRE Foundation Level

Attribute ermöglichen spezielle Sichten (z.B. durch Filter)� nur sicherheitskritische Anforderungen

� alle Anforderungen für eine bestimmte Produktversion

� …

[email protected] 18

[email protected] 19

[email protected] 20

Testfallmodellierung

gute Tests verbessern die Anforderungen� Klärung offener Punkte und Abhängigkeiten

je früher mit den Tests begonnen wird, desto besser � Top-Down-Modellierung

� Testmodell als Diskussionsgrundlage

���� Requirements-Validierung beginnt weit vor dem Test !

(Wechsel der Darstellungsform ist eine bekannte Reviewmethode)

[email protected] 21

[email protected] 22

[email protected] 23

[email protected] 24

Werkzeugunterstützung

Traceability ohne Werkzeug kaum machbar

Werkzeug sollte vorab evaluiert werden� vermeidet böse Überraschungen

evtl. Werkzeugvalidierung erforderlich� idealer weise Workflow- und Modell-basiert

kritische Themen sind häufig � 21 CFR Part 11 compliance

� Langzeitarchivierung

Fragen?

[email protected]

www.seppmed.de

sepp.med gmbh

Gewerbering 9

91341 Röttenbach

+49 (0)9195/931-0