Mit Satzmustern von textuellenAnforderungen zu ModellenIm Bereich der eingebetteten Systeme, beispielsweise im Automobilsektor, wird heutzutage immer mehr auf eine modellbasierteEntwicklung gesetzt. Die Anforderungen an die zu entwickelnden Systeme werden dagegen aus juristischen Gründen und zweckseiner guten Verständlichkeit nach wie vor rein textuell formuliert. Ein Prosatext lässt sich allerdings wegen der Fülle vonFormulierungsmöglichkeiten nicht automatisiert verarbeiten. Dies führt dazu, dass die Qualitätsanalyse der Anforderungen undder Übergang von textuellen Anforderungen zu Systemmodellen auf manuelle Weise erfolgen müssen. Dies kostet Zeit und istfehleranfällig. In diesem Beitrag wird ein Ansatz vorgestellt, mit dem Anforderungen auf Basis von Satzmustern weiterhin textuell,aber gleichzeitig auch automatisiert verarbeitbar formuliert werden können.

Aus dem Modell der Systemarchitekturentstehen somit im weiteren Designprozessdedizierte Software-, Hardware- oder rege-lungstechnische Entwicklungsmodelle. Ausden Modellen wird der Programmcode ent-sprechend des MDE-Ansatzes (Model-

Architektur des Gesamtsystems ohne eineFestlegung, welche Funktionen durchSoftware, Hardware oder Regelungs -technik realisiert werden. Dies wird ineinem nächsten Schritt mit dem Erfah -rungswissen der Entwickler entschieden.

Die Entwicklung voneingebetteten Systemenim AutomobilsektorAbbildung 1 zeigt einen Überblick über diefrühen Prozesse zur Entwicklung von einge-betteten Systemen nach dem Prozess bewer -tungsmodell Automotive SPICE [ASIG10]für Entwicklungsprojekte in der Auto -mobilindustrie. Demnach erheben Auto -mobil hersteller (Original EquipmentManufacturers – OEMs) Kundenanfor -derungen und stellen diese ihren Zulieferernin Form von Lastenheften zur Verfügung(Prozess ENG.1). Der Zulieferer analysiertmit seiner Expertise die größtenteils textuel-len Anforderungen, um beispielsweise vageund unvollständige Anfor derungen zu identi-fizieren. Um konkretere Systemanfor derun -gen in Form eines Pflich tenhefts zu erstellen,präzisiert und vervollständigt der Zulieferernach dieser Analy se phase die Anforderungendes Lastenhefts und reichert sie umLösungsinformationen an (Prozess ENG.2).

Basierend auf den Anforderungen desPflichtenhefts wird ein Entwicklungsmodellfür die Systemarchitektur (z. B. in derSystems Modeling Language – SysML[OMG08]) erstellt (Prozess ENG.3). DasModell dient als Grundlage für die weitereEntwicklung. Es beschreibt zunächst die

der au tor

Jörg Holtmann

(E-Mail: jholtmann@s-lab.upb.de)ist wissenschaftlicher Mitarbeiter beim Software Quality Lab (s-lab) und in der mit dem Heinz-Nixdorf-Institut (HNI) assoziierten Fachgruppe Softwaretechnik der Universität Paderborn.

1 www.objektspektrum.de

fachartikel

Abb. 1: Entwicklungsprozesse für eingebettete Systeme der Automobilindustrie nachAutomotive SPICE.

Driven Engineering) soweit wie möglichmittels Generatoren automatisiert erstellt.

Aber nicht nur die Systemarchitekturberuht auf den Anforderungen des Pflich -tenheftes, sondern auch weitere Modelle,wie z. B. Testmodelle, nutzen die Systeman -for derungen.

Probleme natürlich-sprachlicher AnforderungenDas Pflichtenheft dient im Allgemeinen alsvertragliche Grundlage für alle beteiligtenStakeholder. Um eine leicht prüfbare, juri-stisch vertretbare und dokumentorientierteForm zu erreichen und den Lernaufwandfür spezifische Modellierungssprachen füralle beteiligten Stakeholder zu minimieren,werden die Systemanforderungen in natür-licher Sprache verfasst.

Der Einsatz von in Prosa verfasstenAnforderungen führt allerdings zu diversenProblemen. Der Grund dafür ist, dass freie,natürliche Sprache mehrdeutig und nicht for-mal ist und sich somit nicht automatisiertverarbeiten lässt. Daher müssen alle nachfol-genden, auf den Anforderungen basierendenSchritte manuell ausgeführt und auch diespäteren Modelle manuell erstellt werden,was Zeit kostet und fehleranfällig ist. Diekonkreten Probleme sind folgende:

1. Anforderungen sollen unter anderemeindeutig, vollständig und wider-spruchsfrei sein [IEEE98]. Diese inhalt-liche Konsistenz kann bei der Vielzahlder Anforderungen nur noch schwer-lich manuell erreicht werden.

2. Die Informationen der textuellen An -forderungen müssen für die Erstellungeines initialen Modells lediglich in eineandere Notation gebracht werden, waswiederum manuell geschieht. Davonsind sowohl Entwicklungs- als auchTestmodelle betroffen.

3. Aktuell eingesetzte RE- und MDE-Tools, wie IBM Rational DOORS[DOORS] und Rhapsody [RHAPSO-DY], verfügen über die technischenMöglichkeiten, Abhängigkeiten zwi-schen Anforderungen und Modellen zuerstellen und zu pflegen. Dies erfolgtdurch die Erstellung von Traceability-Links zwischen Anforderungsobjektenund Modellelementen. Die Erstellungund Pflege der Links bedeutet bei dergroßen Anzahl von Anforderungeneinen hohen Aufwand.

4. Im Projektverlauf ändern sich Anfor -derungen mehrfach. Des Weiteren wer-

den die Modelle nach ihrer Erstellung umweitere Informationen ergänzt. Nach wievor sind allerdings starke inhaltlicheÜberlappungen zwischen den textuellenAnforderungen und den Modellen vor-handen. Die Konsistenz der ursprüng-lichen und evtl. geänderten Anforderun -gen zu den verfeinerten Modellen musssichergestellt werden. Dies kann derzeitnur manuell erfolgen und erfordert einenhohen Arbeits aufwand.

5. Zum einen werden bei der System -anforderungsanalyse (Prozess ENG.2)bereits Modelle eingesetzt, zum anderenergeben sich in Entwicklungs- undTestmodellen Änderungen und Ergän -zungen, die ebenfalls Einfluss auf dieAnforderungen haben. Die Erkennt nisseund modellierten Informationen müssenins Pflichtenheft übernommen werden.Daher müssen die Modellin halte in tex-tueller Form aufbereitet werden.

Nachfolgend wird ein Konzept vorgestellt,das diese Probleme adressiert. Hierzu wer-den die textuellen Systemanforderungendes Pflichtenhefts mit Satzmustern spezifi-ziert. Sie sind weiterhin textuell formuliert,aber gleichzeitig auch formalisiert und lie-gen somit in einer automatisiert verarbeit-baren Form vor. Die hier vorgestelltenSatzmuster wurden für einen Zulieferer imAutomobilsektor entwickelt und schränkendie bei der Formulierung der Anfor derun -gen verwendete natürliche Sprache aufsinnvolle Weise ein. Dasselbe prinzipielleVorgehen ist auch in anderen Branchenanwendbar.

Satzmuster fürAnforderungenIn [KK06] wurden auf Basis der Analysevon deutschsprachigen Pflichtenhefteneines Zulieferers der AutomobilindustrieSatzmuster zur Beschreibung von eingebet-teten Systemen vorgestellt. Diese Satz -muster wurden im Rahmen der Innova -tions allianz „Software PlattformEmbed ded Systems 2020“ (SPES 2020)[SPES2020] aufgegriffen und im Hinblickauf eine objektorientierte Systementwick -lungsmethodik weiterentwickelt, um die indiesem Artikel vorgestellten, weiterführen-den Nutzungspotenziale zu erschließen.

Die Satzmuster schränken eine natürlicheSprache so ein, dass nur noch bestimmteFormulierungen möglich sind. Konkretetextuelle Anfor derungen werden dann alsAusprägungen eines Anforde rungsmusters

formuliert. Bei spiele für Muster und kon-krete Anfor derungen sind im folgendenAbschnitt zu finden. Aktuell existieren über100 dieser Muster, die folgende Aspekteumfassen:

■ Struktur: Beschreibung des Aufbausund der Hierarchie des Gesamtsystemsund seiner Subsysteme.

■ Verhalten: Beschreibung von automa-tenbasiertem Verhalten, wobei auchZeitbeschränkungen zur Spezifikationvon Echtzeitsystemen berücksichtigtwerden.

■ Schnittstellen: Beschreibung derSchnitt stellen von Systemkompo -nenten, wobei auf in einem zentralenDatenlexikon definierte Signalgrößenreferenziert wird.

■ Funktionen: Beschreibung von Funk -tio nen, wobei ähnlich wie bei Kompo -nentenschnittstellen zu verarbeitendeund zu erzeugende Signalgrößen ausdem Datenlexikon zugeordnet werden.

Die Einschränkung der Formulierungs -möglichkeiten macht eine natürlicheSprache zu einer eingeschränkten Sprache –man spricht auch von einer kontrolliert-natürlichen Sprache oder ControlledNatural Language (CNL) – , die bei einemsorgfältigen Entwurf der Satzmuster keineMehrdeutigkeiten mehr aufweist. Dadurchlässt sie sich durch einen Algorithmus ver-arbeiten, was weitere automatisierteSchritte ermöglicht. Abbildung 2 zeigteinen Überblick über das Gesamtkonzept.Die einzelnen Schritte sind dort mit Num -mern gekennzeichnet und werden nachfol-gend erläutert.

Schritt 1: Auf der linken Seite von Abbil -dung 2 befinden sich die mithilfe derSatzmuster formulierten, textuellenSystem anforderungen des Pflichtenhefts(siehe Prozess ENG.2 in Abbildung 1). Siesind Ausprägungen oder Instanzen derjeweiligen Anforderungsmuster. ZurDefinition der Muster wird eine spezielleGrammatik verwendet. Die textuellenAnforderungen werden in Anfor -derungsobjekte umgewandelt, die in Formeiner automatisiert verarbeitbaren Objekt -struktur vorliegen. Dies geschieht mithilfeeines aus der Grammatik generiertenParsers (Text-to-Model – T2M). DieObjektstruktur ist eine Instanz einesKlassenmodells zur Beschreibung derAnforderungsinhalte. Die einzelnen, im

2Online-Themenspecial Requirements Engineering 2010

Online-Themenspecial Requirements Engineering 2010 fachartikel

hen, Anforderungen frei zu formulieren.Über die Inhalte solcher Anforderungenlassen sich durch einen Algorithmus keineAussagen treffen. Daher lassen sie sichnicht in die automatisiert verarbeitbareObjektstruktur transformieren. Allerdingsbietet die Modellierungssprache SysMLeine dedizierte Spracheinheit zur Model -lierung von natürlichsprachlichen Anfor -derungen. Indem man die frei formuliertenAnforderungen automatisiert in eine solcheForm bringt, kann man zumindest dasProblem der manuellen Etablierung vonNachverfolgbarkeit einschränken (ProblemNr. 3).

Beispielhafte Anwendung derAnforderungsmusterNachfolgend werden fünf ausgewählteSatzmuster vorgestellt, mit denen manStruk tur, Verhalten, Funktionen undFunktionsschnittstellen beschreibt. DieSyntax der Muster ist angelehnt an die derregulären Ausdrücke. Die verwendetenSymbole bedeuten Folgendes:

■ | : Auswahl einer Alternative■ [ ] : Optionaler Teil■ < > : Stelle, in der Aufzählungen oder

gewisse Freitextanteile eingesetzt wer-den können.

Als Beispiel dient ein Komfortsteuergerät,welches die Innenlichtsteuerung einesAutomobils regelt. Das Innenlicht wirdaktiviert, sobald ein Türkontakt das Öff-nen oder das Schließen einer Tür anzeigt. Indiesen Fällen wird das Innenlicht zunächsthochgedimmt, danach leuchtet es für einegewisse Zeit in voller Intensität und wirdspäter wieder heruntergedimmt (Tabelle 1).

Diese Anforderungen können nun auto-matisch in ein initiales Modell derSystemarchitektur basierend auf SysMLübertragen werden, das Ausgangspunkt fürein weiteres, manuelles Design ist. Eineentsprechende Repräsentation in SysML istin Abbildung 3 dargestellt.

Prototypische Werkzeug -unterstützungZwecks einer Evaluierung der Anwend -barkeit der Anforderungsmuster wurde einprototypischer Anforderungseditor entwik-kelt. Dieser ermöglicht eine einfache undkomfortable Formulierung der Anfor -derungen, basierend auf den Satzmustern.

Schritt 4: Die Inhalte der Modelle könnendurch die Modelltransformationen mit derObjektstruktur abgeglichen werden.Mithilfe von Codegenerierungstechniken(Model-to-Text – M2T) kann Text in Formder Anforderungsmuster aus dieser Objekt -struktur synthetisiert werden. Dadurchkönnen die im weiteren Design prozess aufModellebene hinzugefügten Informationenautomatisch auf Konsistenz mit denAnforderungen überprüft werden, indemdie zusätzlichen oder veränderten Informa -tionen von der Modell- auf die Textebenegebracht und über Versionsverwaltungs -systeme auf Veränderungen geprüft wer-den. Dies stellt eine Lösungsmöglichkeit fürProblem Nr. 4 dar. Letztendlich erlaubt diesauch, textuelle Anforderungen ausModellen der Systemanforderungsanalyseoder aus Entwicklungsmodellen zu generie-ren. Diese werden zusammen mit grafi-schen Diagrammen im Pflichtenheft zurVerfügung gestellt. Die Generierung vontextuellen Anforderungen ist eine möglicheLösung für Problem Nr. 5.

Die Qualitätsanalyse und die automati-sierte Anbindung an Modelle sind inAbbildung 2 grau dargestellt und stelleneinen Ausblick dar. Die blauen Anteiledagegen sind bereits prototypisch in Formeines Anforderungseditors implementiert(siehe Abschnitt „Prototypische Werkzeug -unterstützung“).

Da selbst bei einem sorgfältigen undumfassenden Design der Satzmuster sicher-lich nicht alle möglichen Formulierungenfür Anforderungen vorhersehbar sind,muss nach wie vor die Möglichkeit beste-

Folgenden erklärten Schritte der automati-sierten Verarbeitung der Objektstrukturadressieren die im letzten Abschnitt aufge-zeigten Probleme.

Schritt 2: Auf der aus den Anforderungenerzeugten Objektstruktur kann die Voll -ständigkeit und Konsistenz derAnforderungen mittels einer Qualitätsana -lyse automatisiert überprüft werden.Fehlende oder inkonsistente Anforderun -gen, beispielsweise fehlende Einheiten,können so zügig ermittelt werden. Dies istein Lösungsansatz für das Problem Nr. 1aus dem letzten Abschnitt.

Schritt 3: Durch den Einsatz von Modell -transformationstechniken (Model-to-Model – M2M) können die Informationenaus der Objektstruktur – welche die In -formationen der Anforderungen enthält –automatisiert in ein initiales Entwick -lungsmodell (zum Beispiel auf Basis vonSysML) übertragen werden. Dies ist derStar punkt für den Entwurf der System ar -chitektur (Prozess ENG.3 in Abbildung 1).Zusätzlich ist es möglich, die Infor -mationen auch in andere Modelle – zumBeispiel Testmodelle – zu überführen.Insgesamt soll dieser Übergang zu Mo -dellen das Problem Nr. 2 bewältigen. Beider Modelltransformation werden dieInformationen gespeichert, welche Anfor -derung mit welchem Modellelement inVerbindung steht. Dadurch ergibt sichautomatisch eine Traceability zwischenAnforderungen und Entwicklungsmodell,was Problem Nr. 3 löst.

fachartikel

3 www.objektspektrum.de

Abb. 2: Automatisierter Übergang von textuellen Anforderungen zu Modellen.

Der Editor auf Basis der Entwicklungs -umgebung Eclipse [ECLIPSE] bietetFeatures wie Autovervollständigung, Syn -tax Highligh ting und eine praktische Über-

sicht des beschriebenen Systems in dersogenannten Outline View.

Abbildung 4 zeigt auf der linken SeiteAusschnitte aus dem Texteditor, in dem die

Anforderungen formuliert werden. DieAusschnitte enthalten zum Teil die vorhergenannten Anforderungen. Die Autover -voll ständigung schlägt zum einen die fixenTextfragmente der Anforderungsmustervor, zum anderen bereits definierteSystemelemente, wie zum Beispiel Sub -systeme, Funktionen oder Größen aus demDatenlexikon. Zusätzlich können die An -forderungen auch ohne Benutzung derAutovervollständigung formuliert werden.Im Falle von Fehlformulierungen wirddirekt eine Rückmeldung an den Benutzergegeben. Diese Funktionen erleichtern undbeschleunigen die Formulierung derSatzmuster und sichern auf eine konstruk-tive Weise ab, dass nur Sätze in Form derMuster und bereits definierte System -elemente benutzt werden. Auf der rechtenSeite von Abbildung 4 wird ein Ausschnittder Übersicht des beschriebenen Systemsdargestellt. Dieses ist unter anderem inSystemkomponenten, Funktionen undZustände aufgeteilt.

Zusammenfassung undAusblickDas in diesem Artikel vorgestellte Konzepterlaubt es, Anforderungen textuell, aberauch zugleich in einer automatisiert verar-beitbaren Form zu formulieren. Als Basisdafür werden Satzmuster eingesetzt, welchedie freie, natürliche Sprache einschränkenund den Anforderungsanalysten auf kon-struktive Weise bei der Formulierung unter-stützen. Die Formalisierung der Anfor -erungen ermöglicht automatisierteQuali täts analysen sowie eine schnellereund zuverlässigere Anbindung an diemodellbasierte Entwicklung. Die Ent -wicklung und Evaluierung des Ansatzeserfolgte dabei bei einem Zulieferer in derAutomobilindustrie.

4Online-Themenspecial Requirements Engineering 2010

Online-Themenspecial Requirements Engineering 2010 fachartikel

Anforderungsmuster Konkrete Anforderung

System und Subsysteme (alle): DasSystem „<System>” besteht [genau] aus fol-gende(n|m) Subsystem[en]: <Systemliste>.

Funktionalität und Funktionen: DieFunktionalität des Systems „<System>”besteht [genau] aus (folgenden Funktionen |folgender Funktion): <Funktionsliste>.

Funktionalität und Input: Das System„<System>” (verarbeitet keine | reagiert aufkeine | (verarbeitet (genau|optional|stets) |reagiert (genau|optional|stets) auf)folgende[s] ) (Größe[n] | Signal[e] |Information[en] | Einwirkung[en]) [:<Größenliste>].

Systemzustandswechsel: ((Wenn |Sobald) im | Vom) [Zustand] (Startzustand |<Ursprungszustand>) ((des Systems„<System>“ [(das Ereignis <Ereignis> eintritt |die Zeit abgelaufen ist) [und die Bedingung<Bedingung> erfüllt ist], geht es) | (geht dasSystem „<System>“)) in den [Zustand](<Zielzustand> | Endzustand) über [; ( paralleldazu | zugleich) wird [die Funktion„<Funktion>“ (gestartet | aktiviert | reaktiviert |gestartet oder reaktiviert)]]. [Dies darf [mini-mal <Min-Zeit>] [und] [maximal <Max-Zeit>]dauern.]

Zeitinvariante: Das System „<System>“darf sich [minimal <Min-Zeit>] [und] [maximal<Max-Zeit>] im [Zustand] <Zustand>aufhalten.

Das System „Innenlichtsteuerung“ bestehtaus folgenden Subsystemen: Sensor„vorne_links“, Sensor „vorne_rechts“, Sensor„Kofferraum“, Licht „innenLicht“, Dimmer „d“.

Die Funktionalität des Systems„Innenlichtsteuerung“ besteht aus folgendenFunktionen: Licht hochdimmen, Licht an,Licht abdimmen.

Das System „Dimmer“ verarbeitet folgendeGröße: Dimmdauer.

Vom Startzustand geht das System „Innen -lichtsteuerung“ in den Zustand Startup über.Dies darf maximal 100ms dauern.

Sobald im Zustand Startup des Systems„Innenlichtsteuerung“ die Zeit abgelaufen ist,geht es in den Zustand Ready über.

Das System „Innenlichtsteuerung“ darfsich maximal 200ms im Zustand Startupaufhalten.

Tabelle 1

Abb. 3: Darstellung der Anforderungsinformationen in SysML-Diagrammen.

Die Anforderungsmuster wurden inner-halb eines Serienprojekts im Kontext einerAbteilung evaluiert. Die entwickeltenAnforderungsmuster könnten auch inanderen Abteilungen angewendet unddadurch untersucht werden, ob eineKlassifizierung in abteilungsübergreifendesowie abteilungs- oder gar projektspezifi-sche Muster möglich ist. Schließlich ist zuprüfen, ob bestimmte Muster und/oder derAnsatz auch außerhalb der Automobil -industrie oder der Domäne der eingebette-ten Systeme einsetzbar sind. Letztendlichist vorgesehen, den vorgestellten Ansatz indas Vorgehensmodell COSMOD-RE[PS09] zur integrierten Entwicklung vonAnforderungen und Architektur einzubet-ten. ■

fachartikel

5 www.objektspektrum.de

Abb. 4: Screenshots des Anforderungseditors basierend auf Eclipse.

Literatur

[ASIG10] Automotive Special Interest Group (SIG). Automotive SPICE: Process Reference Model.

Release v4.5, 2010.

[DOORS] IBM Rational DOORS. http://www.ibm.com/software/awdtools/doors.

[ECLIPSE] Eclipse. http://www.eclipse.org.

[IEEE98] IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements

Specifications, 1998.

[KK06] Roland Kapeller, Stefan Krause. So natürlich wie Sprechen - Embedded Systeme model-

lieren. Design & Elektronik. Heft 08, September 2006, S. 64ff.

[OMG08] Object Management Group. SysML Specification. Version 1.1, OMG Document

Number: formal/2008-11-02, 2008. http://www.omgsysml.org.

[PS09] Klaus Pohl, Ernst Sikora. COSMOD-RE: Verzahnung des Architekturentwurfs mit dem

Requirements Engineering. OBJEKTspektrum Online Themenspecial Architekturen 2009.

[RHAPSODY] IBM Rational Rhapsody. http://www.ibm.com/software/awdtools/rhapsody.

[SPES2020] Innovationsallianz „Software Plattform Embedded Systems 2020” (SPES 2020).

http://www.spes2020.de.