Bereits heute stellen Entwicklungsprojekte aufgrund ihrer immer größeren Komplexität hohe Anforderungen an die Requirements- und Testspezifikationen. Eine wesentliche Rolle spielt dabei die Traceability zwischen Kunden-, System- und Softwareanforderung beziehungsweise dem Detailed Design und von da in die jeweiligen Testspezifikationen, sowie zu den dazwischenliegenden Architekturschichten.

In den etablierten Prozessbeschreibungen wie dem V-Modell oder Automotive Spice ist die Traceability als Rückverfolgbarkeit definiert, welche oft durch „einfaches“ Verlinken zwischen den Spezifikationen realisiert wird. Dadurch wird ein struktureller Zusammenhang sichergestellt. Das „Stille-Post“-Problem, also die Frage, ob zwei verlinkte Anforderungen/Testspezifikationen inhaltlich denselben Sachverhalt beschreiben, findet hierbei keine Berücksichtigung. Konsistenz muss durch fehleranfällige Reviews nachgewiesen werden.

Bei der heutigen Dynamik von Entwicklungsprojekten reagieren klassische Entwicklungsprojekte zudem recht träge. Speziell die Umsetzung einer Anforderung in den entsprechenden Testfall ist schon bei minimalen Änderungen oft zu langsam oder benötigt zu viele Ressourcen, um dem dynamischen Entwicklungsumfeld gerecht zu werden. Dies führt zur Diskrepanz zwischen Softwareimplementierung und den zugehörigen Testfällen.

Die Einführung einer wohldefinierten „Requirements Specification Language“ (zum Beispiel TTCN-3), die sowohl in der Implementierungs- als auch in der Testphase Anwendung findet, lässt sich nutzen, um die Spezifikationen auf inhaltliche Konsistenz zu prüfen. Jedoch weist schon eine IEEE-Spezifikation auf Probleme beim Erlernen und Verstehen einer solchen Sprache hin: „One disadvantage in the use of such languages is the length of time required to learn them. Also, many nontechnical users find them unintelligible.”

Piro – Phrase in, requirement out

Requirements

Bild 1: Vergleich einer konventionellen und einer Keyword-Driven Specification. Piro Systems Engineering

Dagegen kombiniert die formale Sprache „Piro“ (Phrase in, requirement out) etablierte Syntax-Regeln mit einem innovativen Ansatz für die Semantik von Spezifikationen – ohne deren Lesbarkeit zu verschlechtern.

Grundlegend für Piro ist das in der ISO-29119 Part5 beschriebene Verfahren des „Keyword-Driven Testing“ (Bild 1). Piro erweitert dieses Konzept um einen allgemeingültigen Realisierungsvorschlag für die Schlüsselwörter, welche in Piro als Phrasen bezeichnet werden. Ein objektorientierter Ansatz verhilft dabei zu Eindeutigkeit und macht die Begrifflichkeiten verständlicher.

Mithilfe dieser Phrasen lassen sich unter anderem Systemzustände, Signale aber auch Tätigkeiten und Abfolgen von Handlungen leicht und eindeutig beschreiben. Der Ansatz wurde dahingehend optimiert, dass Piro nicht nur zur Erstellung von Testspezifikationen, sondern bereits bei der Anforderungsspezifikation genutzt werden kann. Auch hier lag der Fokus auf der Lesbarkeit beziehungsweise einfachen Anwendbarkeit für den Benutzer. Piro lässt sich ohne größere Schulungsmaßnahmen oder spezielles Expertenwissen direkt und effizient anwenden.

Syntax und Semantik

Piro unterscheidet sich gegenüber anderen formalen Sprachen dadurch, dass der Wortschatz nicht eingeschränkt ist und durch jeden Benutzer selbst erweitert werden kann. Dadurch wird Piro zu einer lebendigen Sprache, die sich ständig selbst weiterentwickelt und verbessert.

Eine Datenbank im Hintergrund lässt sich mit beliebigen Keywords inklusive der entsprechenden Übersetzung in die jeweiligen Domains befüllen. Solche Domains können beispielsweise „Fahreranweisungen“, „HiL-/SIL-Prüfskripte“, „Signaldefinitionen“, „Zustände“ und vieles mehr sein.

Neben dem eigentlichen Keyword besteht eine Piro-Phrase aus den folgenden optionalen Komponenten:

  • Klasse (zum Beispiel Zustand, Kodierung, Parameter….)
  • System (zum Beispiel Steuergerät xyz, Fahrzeug…)
  • Argument (zum Beispiel der Wert einer Variable)

Damit ergibt sich die maximale Ausbaustufe einer Piro-Phrase wie folgt:

Class::System::KeyWord[Argument]

Ein gewünschter Lenkwinkel, der als Kodierwert vorgehalten werden soll, lässt sich beispielsweise wie folgt beschreiben: Coding::EPS::SteerAngleThreshold[20°] .

Der Klasse selber können nun auch Eigenschaften mitgegeben beziehungsweise spezifiziert werden. Das System EPS etwa beschreibt dabei, dass es sich um eine Kodierung innerhalb des EPS-Steuergerätes (Electrical Power Steering) handelt und definiert das Schlüsselwort damit eindeutig.

Das während der Spezifikationsphase entstandene Repositorium lässt sich einfach über Projektteams, Abteilungen und externe Kooperationspartner zusammen mit der eigentlichen Spezifikation verteilen. Piro versteht sich als Metamodell, sodass die konkrete Syntax und Semantik an die individuellen Bedürfnisse des Projektes angepasst werden kann.

Seite 1 von 3123