Der gesamte Prototyp wurde mit Java entwickelt. Dazu wurde Eclipse6 zusammen mit dem visual Editor Plugin7 verwendet. Das Plugin ermöglicht ein Zusammenbauen der Oberfläche und stellt die momentane Oberfläche parallel zum Programmieren dar. Dadurch wurde das Entwickeln des User Interfaces erheblich erleichtert, da nicht mehr alles manuell durch Code geschrieben wurde.

Nach dem Entwickeln der use cases sind folgende Anforderungen an den zu entwickelnden Prototyp entstanden.

• REQ:1. der Prototyp muss aus folgenden Softwarekomponenten bestehen:
  • Anforderungsliste
  • Templateeditor
  • Listeneditor
  • Anforderungseditor
• REQ:2. Der Prototyp muss eine Userverwaltung ermöglichen.
• REQ:3. Der Prototyp muss dabei zwischen drei verschiedenen Usern unterscheiden können:
  • Requirements Engineer
  • Projektadministrator
  • globaler Administrator

• REQ:4. Der Prototyp muss die Möglichkeit bieten neue Anforderungslisten zu erstellen.
• REQ:5. Der Prototyp muss die Möglichkeit bieten Anforderungslisten zu bearbeiten.
• REQ:6. Wenn keine Anforderungsliste vorhanden ist, muss der Requirements Engineer eine leere neue Liste erstellen können.
• REQ:7. Wenn eine Anforderungsliste vorliegt, soll der Requirements Engineer diese bearbeiten können.
• REQ:8. Der Requirements Engineer muss neue Anforderungen hinzufügen können.
• REQ:9. Der Requirements Engineer muss Anforderungen löschen können.
• REQ:10. Der Requirements Engineer muss die Struktur der Anforderungsliste verändern können.
• REQ:11. Der Requirements Engineer muss neue Überschriften hinzufügen können.
• REQ:12. Der Requirements Engineer sollte Blöcke der Anforderungsliste löschen können.
• REQ:13. Der Requirements Engineer sollte Blöcke der Anforderungsliste verschieben können.
• REQ:14. Der Requirements Engineer muss Anforderungslisten vom Dateisystem laden können.
• REQ:15. Der Requirements Engineer muss Anforderungslisten speichern können.

• REQ:16. Der globale Administrator muss neue Templates zu der Templateliste hinzufügen können.
• REQ:17. Der globale Administrator muss vorhandene Templates bearbeiten können.
• REQ:18. Der globale Administrator muss vorhandene Templates löschen können.
• REQ:19. Der globale Administrator muss globale Listen bearbeiten können.
• REQ:20. Der Templateeditor muss eine Möglichkeiten bieten vorhandene Templates schnell zu finden und anzuzeigen.
• REQ:21. Der globale Administrator sollte neue Templates von vorhandenen Templates ableiten können.
• REQ:22. Ableitungen sollten in den Templatelisten gespeichert werden können.
• REQ:23. Der globale Administrator muss im Editor für die Template-Metasprache neue Templates eingeben können.
• REQ:24. Der Editor für Template-Metasprache sollte die eingegebenen Templates validieren.
• REQ:25. Der Editor für Template-Metasprache sollte die abgeleiteten Templates bzw. das Template von dem abgeleitet wurde anzeigen.

• REQ:26. Der Projektadministrator muss Parameterlisten importieren können.
• REQ:27. Der Projektadministrator muss Signallisten importieren können.
• REQ:28. Der Projektadministrator muss vorhandene Listen bearbeiten können.
• REQ:29. Wenn eine Liste geöffnet ist, muss der Projektadministrator diese bearbeiten können.
• REQ:30. Der Projektadministrator muss manuell neue Elemente hinzufügen können.
• REQ:31. Der Projektadministrator muss Elemente aus der Liste entfernen können.
• REQ:32. Der Projektadministrator muss eine existierende Liste laden können.
• REQ:33. Der Projektadministrator muss eine Liste speichern können.

• REQ:34. Der Requirements Engineer muss eine Anforderung erstellen können.
• REQ:35. Der Requirements Engineer muss Templates lokalisieren können.
• REQ:36. Der Requirements Engineer muss Templates auswählen können.
• REQ:37. Der Requirements Engineer muss das Template zur Anforderung vervollständigen können.
• REQ:38. Der Requirements Engineer muss die erstellten Anforderungen zur Anforderungsliste hinzufügen können.

In diesem Kapitel werden die use cases aus Kapitel 4.2 mit Hilfe von Screenshots beschrieben. Dabei finden nur die Erwähnung, die letztendlich implementiert wurden. Alle anderen wären durch einen deutlichen Mehraufwand zwar implementierbar gewesen, jedoch stellen sie keinen notwendigen Aspekt zur Darstellung der Methode dar.

Für das erstellen einer neuen Anforderungsliste muss das Tool gestartet werden, sodass eine neue, leere Anforderungsliste vorliegt.

Abbildung 23: Ansicht einer leeren Anforderungsliste

Diese kann nun bearbeitet werden8. Anschließend kann die fertige Liste durch das Klicken auf “Anforderungslisten” und danach auf den Unterpunkt “Datei speichern” gespeichert werden.

Abbildung 24: Navigation um eine Anforderungsliste zu speichern

Danach öffnet sich der gewohnte “Datei speichern Dialog”, wo man seinen Speicherort, sowie den Namen der Datei angibt. Somit wurde eine neue Anforderungsliste erstellt und gespeichert.

Damit eine Anforderungsliste bearbeitet werden kann muss erst einmal eine vorhanden sein. Dies geschieht entweder beim Starten des Tools, denn dann liegt eine neue, leere Anforderungsliste vor oder aber durch das Laden einer Anforderungsliste. Um eine Anforderungsliste zu laden muss auf die Schaltfläche “Anforderungsliste” gedrückt werden und danach auf den Unterpunkt “Datei öffnen”.

Abbildung 25: Navigation um eine Anforderungsliste zu laden

Dadurch öffnet sich der übliche “Datei öffnen Dialog” und man kann die gewünschte Datei laden.

Für das Bearbeiten der Anforderungsliste gibt es nun verschiedene Möglichkeiten. Dazu gehören das Verändern der Struktur der Anforderungsliste, das Hinzufügen von Anforderungen zu der Liste und das entfernen von Anforderungen von der Liste. Diese drei werden in den folgenden Abschnitten exakter beschrieben. Der use case eine Anforderung zu ändern wurde nicht implementiert, da dieses durch das Löschen und Hinzufügen realisiert werden kann.

Das ändern der Struktur beinhaltet das Hinzufügen von neuen Überschriften und Unterüberschriften. Neue Überschriften werden durch das Klicken des Buttons “Heading hinzufügen” realisiert. Nun muss noch der gewünschte Text der Überschrift eingegeben werden. Die Schriftgröße der Überschrift wird je nach Hierarchiestufe angepasst. Der Explorer im linken Bereich fängt ebenfalls an sich mit aufzubauen.

Abbildung 26: Anforderungsliste mit Hauptüberschriften

Damit jetzt unter Punkt 1. Unterüberschrift 1.1 entsteht muss zunächst die Überschrift zu der eine neue Unterüberschrift hinzugefügt werden soll markiert werden. Anschließend erfolgt ein Klick auf den Button “Subheading hinzufügen” und die Unterüberschrift 1.1 erscheint und benötigt noch einen eingegebenen Text.

Abbildung 27: Anforderungsliste mit Haupt- und Unterüberschriften

Das Löschen einer Überschrift oder Unterüberschrift verändert ebenfalls die Struktur der Anforderungsliste. Um eine Überschrift zu löschen muss diese vorher selektiert werden und danach durch Klicken des Buttons “Zeile entfernen” gelöscht werden.

Abbildung 28: Darstellung der Anforderungsliste nach dem Entfernen einer Zeile

Das Verschieben von Blöcken um die Struktur zu ändern ist zwar möglich, nur wird die Indexierung noch nicht mit angepasst.

Als Vorbedingung für den use case muss gelten, dass die entsprechenden Listen bereits mit Werten gefüllt wurden, damit die Variablen überhaupt ersetzt werden können.

Schritt 1: Wählen der Anforderungsklasse

Der Requirement Engineer öffnet den Anforderungseditor durch Klicken der Schaltfläche “Anforderungslisten” und dort den Unterpunkt “Anforderungen hinzufügen”.

Als nächstes muss gewählt werden zu welcher Kategorie die entstehende Anforderung gehören soll. Dabei sollen die Beispiele als kleine Hilfe dienen, wenn man sich nicht ganz sicher ist, wo die Anforderung nun einzuordnen ist..

Die Kategorien sind als Buttons implementiert und durch das Klicken der entsprechenden Kategorie gelangt man zum nächsten Schritt.

Abbildung 29: Darstellung der Kategorie von Anforderungen innerhalb des Prototypen

Schritt 2: Wähle das Template.

Der Requirements Engineer wählt das Template entsprechend der Anforderung aus. Dabei hat er die Möglichkeit ein Basistemplate zu verwenden oder aber eines seiner Eigenen. Diese müssen vorher gespeichert worden sein.

Durch das Klicken des Templates gelangt man zum nächsten Schritt. Durch Klicken des Buttons „Previous“ zum vorherigen Schritt.

Weiterhin wird für einen solchen Fall der Bauplan abgespeichert. Dadurch wird es ermöglicht, durch eine Edit Funktion, die nicht vollendete Anforderung an der Stelle fortzusetzen, wo der Vorgang unterbrochen wurde.

Abbildung 30: Darstellung der Templates in der gewählten Kategorie

Schritt 3a: Anpassen des Templates

In diesem Schritt muss der Requirements Engineer sein Template anpassen. Das heißt er wählt die optionalen Teile aus, die enthalten sein sollen, sowie Einschränkungen oder Erweiterungen für die Variablen. Zusätzlich erfolgt dazu das Befüllen der Variablen. Zu den Buttons kommt zusätzlich ein Button Save Template hinzu, welcher ermöglicht das Template, so wie es momentan ist, als selbst erstelltes Template unter dem gewählten Basistemplate abzuspeichern. Weiterhin wird noch ein Button “Save Requirement” eingefügt. Dieser speichert die Anforderung in jetzigen Zustand ab und beendet den Editor. Gibt es noch Variablen, die keine Werte enthalten wird dies in der Anforderung explizit mit einem “to do” gekennzeichnet. So wird zum Beispiel aus <value> → <value to do>. Somit weiß ein anderer Requirements Engineer, dass diese Anforderung noch nicht vollständig ist.

Abbildung 31: Darstellung der Erweiterung von Teilen zum Beispiel Conditions

Schritt 3b: Befüllen der Variablen durch Typenauswahl

Der Requirements Engineer muss nun die Variablen anklicken und befüllen.

Abbildung 32: Darstellung der Befüllung von Variablen

Schritt 3c: Befüllen der Variablen durch Zahlenwerte

Es besteht die Möglichkeit nicht nur vordefinierte Werte hinzuzufügen, sondern auch einzelne Zahlenwerte mit Einheiten. Dafür wird in dem Textfeld der Zahlenwert eingegeben und die gewünsche Einheit selektiert. Zum Übernehmen muss dies mit “OK” bestätigt werden. Wurde keine Einheit ausgewählt wird nur der Zahlenwert eingefügt.

Abbildung 33: Darstellung der Werte beim Anklicken der Variablen "nonvolatile"

Abbildung 34: Editor zum Hinzufügen von Konstanten

Damit ein neues Template hinzugefügt werden kann, muss der Templateeditor geöffnet werden. Dazu muss in der Menüleiste der Punkt Templates und dort der Unterpunkt Templateeditor angeklickt werden.

Abbildung 35: Darstellung zum Starten des Templateeditors

Es öffnet sich ein Fenster, welches die Struktur der Templates als Explorer darstellt.

Möchte man nun ein neues Template hinzufügen, muss erst der Ordner oder das Template markiert sein, unter welchem das neue Template eingefügt werden soll. Anschließend kann das gewünschte Template unter Einhaltung der Templatemetasprache im Textfeld eingegeben werden. Durch Klicken des Buttons „Template hinzufügen“ wird das neue Template unter dem markierten Ordner/Template hinzugefügt. Es ist nicht möglich neue Anforderungsklassen hinzuzufügen.

Wenn alle gewünschten Templates hinzugefügt wurden, können die Änderungen durch Klicken des Buttons „Übernehmen“ in die Datei geschrieben werden.

Abbildung 36: Darstellung zum Hinzufügen eines Templates

Möchte man nun ein vorhandenes Template wieder entfernen, muss erst zum Templateeditor navigiert werden. Dort muss das zu entfernende Template markiert werden und durch Klicken des Buttons „Template entfernen“ wird dies aus dem Explorer gelöscht. Das endgültige Entfernen geschieht erst durch Klicken des Buttons „übernehmen“.

Abbildung 37: Darstellung zum Entfernen eines Templates

Innerhalb des Prototypen existiert keine Unterscheidung zwichen projektbezogenen Listen und globalen Listen, deshalb wurden die use cases, die die Listen betreffen zusammengefasst. Dies betrifft use case 2.4: “Globale Liste bearbeiten” und use case 2.5: Globale Liste erstellen”.

Abbildung 38: Navigation zum Listeneditor

Damit der Projektadministrator die Möglichkeit besitzt eine neue Liste zu erstellen, muss er zum erforderlichen Editor navigieren. Dafür muss das Menü Listen und dort der Unterpunkt Listen angeklickt werden.

Es erscheint folgendes Fenster:

Abbildung 39: Darstellung des Listeneditors, wenn keine Liste gewählt wurde

In diesem Fenster muss nun der Button “Neue Liste erstellen” gedrückt werden. Dadurch erscheint ein Textfenster, in welchem der Name der Datei eingegeben werden muss. Dabei muss Groß- und Kleinschreibung beachtet werden, da der Prototyp ansonsten beim Erstellen der Anforderungen die entsprechende Datei nicht finden kann. Der Name der Datei muss somit identisch mit dem Namen der Regel sein.

Abbildung 40: Darstellung des Listeneditors nach Klicken des Buttons "Neue Liste erstellen"

Anschließend erscheint die Datei in der obrigen Auswahlliste und kann bearbeitet werden.

Damit der Projektadministrator eine vorhandene Liste bearbeiten kann, muss erst einmal zum Listeneditor navigiert werden.

Im offenen Editor muss nun die Liste gewählt werden, welche bearbeitet werden soll. Wenn die gewüschte Liste angeklickt wurde, erscheinen die Werte in Form einer Tabelle. Zusätzlich erscheinen am unteren Bildrand drei neue Buttons, welche es ermöglichen die Liste zu bearbeiten.

Die Bearbeitungsmöglichkeiten sind das Hinzufügen von neuen Elementen und das Löschen von Elementen. Der “Übernehmen” Button sorgt dafür, dass die Änderungen übernommen werden.

Abbildung 41: Darstellung des Listeneditors, wenn eine Liste gewählt wurde

Die Elemente der einzelnen Variablen (Hardware, System, Failure, Test und weitere) werden als einfache Textdokumente gespeichert. Die Elemente werden durch Komma getrennt nacheinander aufgezählt.

Das Ziel ist es nicht den Text der Anforderung abzuspeichern, sondern ein Bauplan, der beinhaltet welches Template gewählt wurde, welche optionalen Teile gewählt wurden und welche Änderungen an den einzelnen Variablen vorgenommen wurden.

Dazu werden die Formalen Regeln als XML File gespeichert. Somit kann die notwendige Hierarchie, die die BNF vorgibt gut abgebildet werden und zusätzlich erhält jede Regel einen Identifikator der Form „r42“. Somit ist es möglich die einzelnen Veränderungen, die den Variablen widerfahren sind, nachzuvollziehen. Die Templatelisten werden ebenfalls als XML File abgespeichert. Einerseits damit die Hierarchie von Anforderungsklassen und ihren Templates besser dargestellt werden kann. Andererseits weil ebenfalls den Templates eigene Identifikatoren der Form „T5“ zugewiesen werden. Die Anforderungslisten werden zwecks der zahlreichen Zusatzinformationen (Identifikator, Bauplan, Kategorie, Hierarchiestufe) ebenfalls als XML File gespeichert. Außerdem ist die gesamte Hierarchie des Anforderungsdokumentes somit deutlich ersichtlicher.

Innerhalb des Prototypen werden für die Bereithaltung der Listenvariablen, sowie für die Anforderungsliste, Listen in Form vom Javatyp Vector verwendet, die die einzelnen Tabellenspalten beinhalten. Die Anforderungsliste wird, zwecks Navigation ,zusätzlich noch in einer Baumstruktur bereitgestellt, damit der Explorer dargestellt werden kann.

Die Templatelisten werden einerseits als Parsebaum des XML Dokumentes bereitgestellt und andererseits als Baum für den Explorer zur Auswahl und zum Bearbeiten der Templates. Die Formalen Regeln sind ebenfalls als Parsebaum für die Verwendung im Prototypen bereitgestellt.

Wie bereits erwähnt wird nicht der Inhalt einer Anforderung abgespeichert, sondern der Bauplan wie diese Anforderung entstanden ist. Dabei wird gespeichert welches Template gewählt wurde, welche optionalen Teile benutzt wurden und was mit den einzelnen Variablen geschehen ist. Die Variablen sind dabei durch Semikolons getrennt, damit die einzelnen Variablen unterscheiden werden können. Der Bauplan wird letztendlich als ein zusammenhängender String dargestellt. Ein Bauplan sieht zum Beispiel folgendermaßen aus:

T4 O1:1 O2:0 O3:1 O4:1 r2 W: microcontroller; r17 W: automatically; r13 r10 W: analog input; W:default; r34 W: Terminal50; W:default;W:default;W:default;W:default;W:default;

Dabei steht T für Template, O für Optionaler Teil, r für eine Regel und W für einen Wert.

Die Schwierigkeit lag nun darin aus dem Bauplan wieder die Anforderung zu erstellen. Dabei fand JavaCC Verwendung.

JavaCC ist ein Plugin für Eclipse, welches es ermöglicht relativ einfach einen Compiler zu bauen. Dabei muss man als Entwickler die Zeichen der erwartenden Sprache definieren und in welche Reihenfolge diese auftreten. Dadurch ist es möglich einen Eingabestring zu validieren und auszuwerten.

Somit wurde der gelesene Bauplan an den Compiler weitergegeben. Da jeder Bauplan identisch aufgebaut ist, kann der Compiler den Bauplan validieren. Das heißt er überprüft, ob alle wichtigen Parameter enthalten sind, damit aus dem Bauplan eine Anforderung wird. Beim validieren speichert er die gefunden Werte in geeigneten Datenstrukturen ab. Wenn eine Anforderung fertig validiert wurde wird ein zweiter Compiler aufgerufen. Dieser bekommt das gewählte Template als Eingabestring und überprüft dieses Schritt für Schritt. Findet er dabei eine Variable, schaut er in der Datenstruktur, was mit dieser Anforderung bei ihrer Erstellung vollführt wurde und vollführt die entsprechenden Schritte. Dadurch entsteht aus dem Bauplan die vorher entwickelte Anforderung.

Da es sich lediglich um einen Prototypen handelt wurden einige Möglichkeiten innerhalb des Prototypen nicht generalisiert, sondern statisch implementiert.

Dies bedeutet das zum Beispiel innerhalb der Anforderungsliste nur Hierarchien bis zur Stufe 5 unterschieden werden. Alles was eine höhere Hierarchiestufe hat wird als 5 interpretiert.

Außerdem besteht nur die Möglichkeit Conditions einmal zu erweitern, also

Condition→Condition and Condition→Component is in mode and Component is in state

ist noch zulässig, nicht jedoch

Condition→Condition and Condition→Condition or Condition and Condition or not Condition

Diese Einschränkungen beziehen sich lediglich auf den entwickelten Prototypen. Auf die Methodik haben diese keine Auswirkungen.

• Zusammenfassung
• Einleitung
• Grundlagen
• Stand der Technik
• Variable Templates
• Usecases
• Prototypische Implementierung
• Evaluation
• Fazit