Werkzeugunterstützung Traceability zwischen Anforderungen und Design

Brauchbare Traceability-Information zwischen den Phasen Anforderungen und Design zu kommunizieren und zu nutzen gestaltet sich häufig schwierig. Die MBtech Group hat in Kooperation mit der Hochschule Regensburg und der Professur für Medieninformatik der Universität Regensburg das Traceability-Werkzeug PROVEtech:R2A (R2A) entwickelt, das versucht, eine adäquate Lösung für diesen Übergang bereitzustellen.

Anbieter zum Thema

MicroConsult Academy GmbH

E.E.P.D. Electronic Equipment Produktion & Distribution GmbH

RECOM Power GmbH

Akkodis

Anforderungs-Traceability wird als wichtiger Faktor bei der Entwicklung von sicherheitskritischen Systemen wahrgenommen [SP08]. Die Gewinnung von Informationen zur Traceability stellt sich besonders im Übergang zwischen Anforderungen und Design als schwierig dar da, anders als bisherige Ansätze suggerieren, die auf einfacher Verlinkung aufbauen, dieser Übergang nicht linear ist, sondern einen kreativen Transferprozess von einer Problemstellung zur Lösung darstellt, in dem die getroffenen Entscheidungen das Fundament bilden [TKT+07].

Die MBtech Group hat in Kooperation mit dem Kompetenzzentrum Software Engineering der Hochschule Regensburg und der Professur für Medieninformatik der Universität Regensburg das Traceability-Werkzeug PROVEtech:R2A (R2A) entwickelt, das versucht, eine adäquate Lösung für diesen Übergang bereitzustellen. Die nachfolgenden Kapitel beschreiben drei Probleme, die beim Übergang zwischen Anforderungen und Design die Etablierung der Traceability erschweren, und zeigen die Lösungsstrategien von R2A.

Design als eine Kette von Entscheidungen

Der Weg von Anforderungen zum Design ist geprägt durch eine Abfolge von Entscheidungen, die Lösungsraum immer weiter einengen. Dieser Umstand führt dazu, dass Design nicht nur von den Anforderungen, sondern zumeist in höherem Maße von den schon zuvor getroffenen Entscheidungen abhängt. Diese Beobachtung führt zu folgenden zwei Problemen:

• Entscheidungen und ihre Auswirkungen müssen im Projekt an andere Designer, Entwickler und Tester kommuniziert werden.
• Spätere Anforderungsänderungen beeinflussen nicht nur das Design, sondern können auch dazu führen, frühere Entscheidungen erneut prüfen und ggf. revidieren zu müssen, was wiederum auch Auswirkungen auf das Design haben kann.

Das Entwicklungstool R2A bietet derzeit zwei verschiedene Entscheidungsmechanismen, um Entscheidungen in ihren Beziehung zu Anforderungen als auch zum Design dokumentieren zu können.

Embedded-Projekte sind häufig dadurch geprägt, dass Ressourcen wie RAM, ROM oder EEPROM nur begrenzt verfügbar sind. R2A bietet die Möglichkeit, mittels eines hierarchischen Designs eingeschränkte Ressourcen im Sinne eines Budgets zu verwalten und solche Festlegungen einzelnen Designelementen als „neue Anforderungen“ zuzuweisen. Dazu wurde für das Tool das Konzept eines BudgetedResourceConstraint (BRC)eingeführt. Bild 1 zeigt wie eine RAM-Ressource von 1500 Bytes auf die SW-Architektur einer Lichtsteuerung verteilt wird.

Die so einem Designelement zugewiesenen BRCs gelten als weitere einzuhaltende Anforderungen und können entsprechend weiterverarbeitet werden. Abb. 2 zeigt wie ein anderer für das detaillierte Design Moduls Light_hdl zuständiger Designer eine BRC von 250 Bytes auf sein detaillierteres Design aufteilen kann. Weitere Informationen zu diesem Mechanismus finden sich in [TWT+08].

Ein zweiter Mechanismus hilft, Konflikte und deren Lösung festzuhalten. Abb. 3 zeigt eine Situation, in der eine Anforderung („All 16 light ...“) in einem Konflikt mit dem PWM-Modul (Pulsweitenmodulation, PWM) steht, da die Hardware (HW) nur 12 PWM-Kanäle bietet. Als Lösung ergibt sich eine „neue Anforderung“ an das PWM-Modul. Diese „Anforderung“ stammt nicht aus den Kundenanforderungen, sondern aus der Designentscheidung und wird im Kontext des Tools R2A als DesignConstraint (DC) bezeichnet.

Mit den DCs hat der Designer die Möglichkeit, die Konsequenzen seiner Entscheidung an andere Designer zu kommunizieren. In diesem Beispiel wurde der neue DC dem PWM-Modul zugewiesen. Der für das detaillierte Design des PWM-Moduls zuständige Designer sieht in Zukunft diesen DC als ebenfalls zu erfüllende Anforderung, vgl. dazu detaillierter [TKT+07].

(ID:283059)