Entwicklungsdokumentation



Anforderungen an Entwicklungen müssen in erster Linie so präzise formuliert sein, dass sie testbar sind und sich über die einzelnen Realisierungsstufen hinweg verfolgen lassen.

Meine Stärke ist es, die Fäden von den Anforderungen bis zum fertigen Produkt zu verfolgen und zu bündeln. Und zwar in erster Linie durch gezielte Fragen, durch Reviews, und nicht zuletzt mit einer gewissen Sturheit in der Methode. Und zwar immer aus der Perspektive des Anwenders und damit auch aus Sicht der Gebrauchstauglichkeit und des Risikomanagements.

Stellvertretend führe ich hier zwei Projektbeispiele auf.


Aufgabenstellung 1
Beurteilung einer Maschinensteuerung hinsichtlich Gebrauchstauglichkeit und Risiken, Prüfen der Entwicklungsdokumentation.

Durchführung
Anhand der vorhandenen Dokumentation und der bereits realisierten Steuerung habe ich Testfälle mit den zu erwartenden Ergebnissen für die bestimmungsgemäßen und vorhersehbar nichtbestimmungsgemäßen Betriebszustände definiert. Gefährdungsmerkmale wie unerwarteter Anlauf in den verschiedenen Betriebszuständen (manueller Betrieb, Externe Ansteuerung, etc.) und Lebenszyklen (Einrichten, Betreiben, Service, …) wurden besonders hervorgehoben.
Durch den Vergleich der Testergebnisse mit der Entwicklungsdokumentation und der Betriebsanleitung wurden Schwächen in der Dokumentation erkannt und behoben.

Ergebnis
Durch das systematische Testen konnten nicht nur Dokumentationspflichten erfüllt sondern auch Verbesserungspotenziale an der Anlage und im Entwicklungsprozess insgesamt aufgezeigt werden.
(Scan&Sort GmbH)

Aufgabenstellung 2
Erstellen eines Dokumentationskonzepts für die Zulassung einer medizinisch genutzten Software.

Durchführung
Mit der Dokumentation musste insbesondere dargelegt werden, dass alle Produktmerkmale hinsichtlich ihrer Risiken bewertet und gegen die Anforderungen getestet wurden. Das Konzept sah vor, funktionale Einheiten in der Dokumentation mit sog. Requirement-Keys zu versehen. Mit der Verknüpfungsmatrix habe ich die Beziehung zwischen Spezifikation <–> Gefährdungsbeurteilung <–> SW-Designdokument <–> Bedienkonzept <–> Testfall mit Testvorschrift <–> Bedienhandbuch dargestellt und nachgewiesen, dass die Anforderungen zu jeder Funktion erfüllt werden.

Ergebnis
Die Verwendung der Requirement-Keys hat zu einer Präzisierung des Pflichtenhefts und zu einer verbesserten Testung geführt. Einige Verbesserungen im Bedienkonzept konnten frühzeitig erkannt und umgesetzt werden. Die gesamte Dokumentation einschließlich der Bedienanleitung wurde aus Sicht der Produkthaftung verbessert.

(Energy-Lab Technologies GmbH)

Auch wenn die Dokumentationsanforderungen i.d.R. nicht so hoch sind, die Systematik in etwas abgespeckter Form ist auch bei kleineren Projekten sinnvoll. Sie zwingt dazu, Anforderungen in einer eindeutigen und vor allem testbaren Form zu formulieren. Oder anders herum: Wenn festgestellt wird, dass Anforderungen nicht präzise formuliert werden können, ist das Grundkonzept noch nicht rund. Der etwas höhere Aufwand in der Anforderungsphase zahlt sich in der Realisierung und im Test aus.