Warum sich gutes Requirement Engineering lohnt
Die Auswirkungen schlechten Requirement Engineerings auf die Systemverifizierung
Im Folgenden erhalten Sie eine Übersicht aus der Perspektive der Systemverifikation, warum es sich lohnt, ausreichend Ressourcen in das Requirement Engineering zu investieren. Zunächst geht es um die Erfüllung der Forderungen der DIN EN ISO 13485:2016. Die Erfahrung zeigt, dass diese Forderungen nicht lästig, sondern sinnvoll für die Definition der Requirements sind und das Fundament für den gesamten Projektverlauf und das Projektziel bilden.
Sind zu Beginn eines Projekts die Anforderungen an Ihr System unzureichend definiert, ergeben sich daraus negative Folgen auch für die Systemverifizierung.
Was heißt „unzureichend“? Was heißt „negative Folgen“?
Die Attribute, an denen sich die Qualität von Requirements widerspiegelt, sind u.a. „vollständig“, „korrekt“, „verständlich“, „eindeutig“, „konsistent“, „strukturiert“, „atomar“, „prüfbar“.
Werden diese Eigenschaften nicht erfüllt, müssen bereits im Projektverlauf, d.h. während laufender Implementierung und Verifikation Requirements korrigiert und neu definiert werden und es muss in die bestehende Struktur eingegriffen werden. Das kann Fehlerquellen darstellen für die:
- Gesamtstruktur der Requirements,
- Zuordnung von Requirements zu Testfällen und anderen Elementen,
- Definition von Akzeptanzkriterien (erwartetes Ergebnis) der Testfälle.
Ein Beispiel
Akzeptanzkriterien der entsprechenden Testfälle definieren sich anhand der Requirements. Werden Mängel an den Eigenschaften von Requirements erst bei der Testfallerstellung oder -durchführung entdeckt, kommt es zur Wiederholung einer Kette von Aktivitäten: Überarbeitung der Requirements, der Testfälle und Wiederholung der Testdurchführung.
Sind Requirements nicht „atomar“, sondern weiter zerlegbar, ergibt sich daraus eine schlechte Planbarkeit für die Verifikation und eine unübersichtliche Teststruktur. Die Herausforderung der Gap- Analyse ist es dann festzustellen, ob alle Requirements vollständig abgeprüft sind. Das trifft beispielsweise zu, wenn ein Requirement zwei oder mehrere Module eines Systems adressiert, um dadurch eine Anforderung für mehrere Betriebsmodi zusammenzufassen.
Fazit
Unzureichende Definition von Requirements resultiert allein aus der Perspektive der Verifikation in:
- negativem Einfluss auf die Gesamtverifikation
- redundanter Arbeit
- ineffizienter Ressourcennutzung
- Frustration der Mitarbeiter
- Verärgerung des Managements
- bis hin zur Gefährdung der Projektlaufzeit und -kosten.
Es lohnt sich, ausreichend Zeit, Personal und Kosten in gutes Requirement Engineering zu investieren.
