Im Bereich der funktionalen Sicherheit, insbesondere bei der Entwicklung von elektronischen Steuerungen und Steuergeräten, ist die Traceability oder Nachvollziehbarkeit von Anforderungen entscheidend. Im V-Modell steht Traceability für die Beziehung zwischen verschiedenen Entwicklungsphasen, beginnend von der Anforderungsdefinition bis hin zur Validierung und Verifikation der entwickelten Lösung.
Traceability ist nicht nur ein Schlüsselbegriff für Anforderungen, sondern steht stellvertretend für ein Anforderungsmanagement, bei dem die technische Planung und Umsetzung während aller Prozessphasen verfolgt werden können. Damit gewährt die Dokumentation und das Management von Anforderungen sichere, zeitgerechte, kostengünstige und effiziente Produkte.
Jeder Schritt im Entwicklungsprozess basiert auf einem vorhergehenden Schritt und damit auf vorher festgelegten Anforderungen. Dies beginnt bei den Kundenanforderungen und reicht bis zu den konkreten Modulspezifikationen. Zwischen diesen Ebenen haben wir:
Es muss immer klar sein, wie sich eine höherrangige Anforderung in den untergeordneten Spezifikationen niederschlägt und welche Designentscheidungen oder zusätzlichen Anforderungen daraus resultieren. Dies stellt sicher, dass jeder Schritt, jede Änderung oder jedes neue Designelement klar auf eine ursprüngliche Anforderung zurückzuführen ist.
Die korrekte Rückverfolgbarkeit von Anforderungen kann Entwicklungsaufwände für Anforderungsmanager und Entwickler sparen. Insbesondere folgende Vorteile der Anforderungsrückverfolgbarkeit sind offenliegend:
Sicherstellung, dass Endlieferungen den anfänglichen Geschäftsanforderungen entsprechen: Die vorwärts gerichtete Rückverfolgbarkeit ermöglicht es dem Analysten sicherzustellen, dass Geschäftsanforderungen tatsächlich an die Anforderungen gebunden sind und dass diese Anforderungen an Lieferungen gebunden sind. Umgekehrt stellt die rückwärts gerichtete Rückverfolgbarkeit sicher, dass bei einer entwickelten Produktfunktion, die niemand in Auftrag gegeben oder autorisiert hat, festgestellt werden kann, ob es sich tatsächlich um eine unnötige Ergänzung handelt oder ob sie tatsächlich an eine Anforderung (und entsprechenden Geschäftsbedarf) gebunden ist.
Vermeidung von Zeit- und Ressourcenverschwendung durch redundante Analyse von Anforderungen: Wenn Anforderungen einmal fixiert wurden und darunter kaskadierte Anforderungen geändert werden, müssen die fixierten Anforderungen nicht geändert werden. Dies vermeidet unnötige Überarbeitungen und stellt sicher, dass einmal festgelegte Geschäftsanforderungen stabil bleiben, auch wenn technische oder untergeordnete Anforderungen angepasst werden.
Einhaltung etablierter Industriestandards: Die Rückverfolgbarkeit ist ein Schlüsselelement in vielen anerkannten Industriestandards für Softwareentwicklung, einschließlich CMMI und ISO 9001:2000. Insbesondere aber im Kontext funktionaler Sicherheit ist sie unverzichtbar.
Vereinfachte Auswirkungsanalyse: Mit der Rückverfolgbarkeit von Anforderungen ist eine intelligente Auswirkungsanalyse möglich; wenn ein Stakeholder eine Anforderung während der Entwicklung oder des Tests ändern möchte, ermöglichen rückverfolgbare Links zu Geschäftsanforderungen und anderen Anforderungen einem Analysten oder Projektmanager, den vollen Einfluss der gewünschten Änderung zu berichten.
Die Rückverfolgbarkeit von Anforderungen im Entwicklungszyklus bildet daher nicht nur eine Brücke zwischen Geschäftsanforderungen und technischer Umsetzung, sondern dient auch als Sicherheitsnetz, um sicherzustellen, dass Projekte effizient und zielführend umgesetzt werden.
Die Auswirkungs- und Einflussanalyse von technischen Änderungen sowie vollständig umgesetzten Sicherheitsanforderungen ist grundsätzlich nur mit Unterstützung von strukturierten Datenbanken möglich. Tools wie Polarion unterstützen einerseits die Vollständigkeitsanalyse von Anforderung bis Implementierung sowie Test und Validierung. Andererseits wird durch sog. Suspects die Auswirkungsanalyse von geänderten Anforderungen gefördert.
Analyse von Auswirkungen und Coverage über Traceability in Polarion
Traceability sollte immer auch entwickelte Work Items wie umfassen. Es bietet sich daher an, Module entsprechend zu tracen. Ausgehend von einem Beispiel soll gezeigt werden wie mit einem Tool wie Polarion ein Link auf ein Requirement zu linken ist. Angenehm ist dabei die Kombination aus Polarion und doxygen-Syntax, die zusätzlich Entwicklerdokumentation ermöglicht.
Ein einfaches Beispiel für eine Anforderung im EARS-Pattern:
EL-115
* Trigger: When in idle state
* Precondition: and the gateway CAN status request is 0xE0
* Actor: the ECU shall
* Action: respond with
* Object: status code 0x0
Ein entsprechender Code-Snippit wird durch das @wi.implements -Attribut mit der ursprünglichen Anforderung verknüpft und ist ab dann transparent für eine Auswirkungsanalyse.
/**
* @brief Respond with status code 0x0 when conditions are met.
*
* This function checks the ECU state and CAN status request and
* responds accordingly based on the EARS pattern.
*
* @return int Status code to respond with.
* @wi.implements elibrary/EL-115:1
* check and respond function for CAN gateway statuses. */
int checkAndRespond() {
if (ECU_STATE == IDLE && CAN_STATUS_REQUEST == 0xE0) {
return 0x0;
}
// ... other conditions and responses ...
}
Die Rückverfolgbarkeit von Anforderungen im Entwicklungszyklus bildet daher nicht nur eine Brücke zwischen Geschäftsanforderungen und technischer Umsetzung, sondern dient auch als Sicherheitsnetz, um sicherzustellen, dass Projekte effizient und zielführend umgesetzt werden. Die Praxis zeigt jedoch, dass dies mithilfe von Datenbanken und dedizierten Anwendungen ermöglicht werden muss. Das gezeigte Beispiel in Polarion stellt einen einfachen Workflow dar, mit dem einfach Anforderungen und Work Items verknüpft werden können.