Ergebnisse der Anforderungsanalyse auswerten
Vielleicht haben Sie die kleinen Filme in meinem letzten Beitrag zum neuen objectiF Requirements Modeller angesehen und dabei gedacht: „Grafische Modellierung von Stakeholdern, Zielen, Anforderungen und Testfällen schön und gut. Aber wie behält man den Überblick, wenn man es in der Praxis nicht mit fünf oder zehn, sondern einigen hundert oder tausend Elementen eines Typs zu tun hat?“ Wenn Sie in-Step kennen, werden Sie diese Frage vermutlich so stellen: „Gibt es in dem neuen Werkzeug denn nicht so etwas ähnliches wie benutzerdefinierte, gefilterte Sichten?“ Klar gibt es das. Bevor ich Ihnen weitere Modellierungsfunktionen des objectiF Requirements Modeller vorstelle, machen wir – wenn Sie Lust haben – einen Ausflug: Ich zeige Ihnen an einem einfachen Beispiel, wie Sie alle Elemente, die Sie erstellt haben,
- nach selbstdefinierte Kriterien – wir sagen, durch Abfragen – selektieren,
- als (geschachtelte) Listen anzeigen,
- in den Listen filtern und
- in den Listen editieren.
Abfragen sind ein sehr mächtiges Instrument im objectiF Requirements Modeller. Jede Abfrage, die Sie definieren, wird gespeichert. Wann immer Sie sie erneut aufrufen, zeigt sie Ihnen den aktuellen Stand der Daten an. Abfragen können Sie darüber hinaus z. B. im Pflichten- oder Lastenheft verwenden, um ihre Ergebnisse aktuell und vollständig ohne große Mühe zu dokumentieren.
Auswertungen erstellen
Heute verlassen wir also den eingeschlagenen Pfad und machen einen Abstecher zum Thema Auswertungen erstellen.
Das zweistufige Konzept der Abfragen
Rein technisch sind die Ergebnisse, die Sie mit dem objectiF Requirements Modeller erstellen, in „guten Händen“: Weil das Tool die Zusammenarbeit in größeren Teams unterstützen soll, werden alle Ergebnisse in einer SQL-Datenbank verwaltet. Wir werden Microsoft SQL-Server und Oracle unterstützen.
Sie wissen: Für komplexere Datenbankabfragen muss man das Datenbankschema kennen. Als Requirements Engineer wollen Sie sich aber sicher nicht mit den Details des Datenbankschemas eines Tools beschäftigen. Deshalb haben wir ein zweistufiges Konzept für Abfragen realisiert:
Wir unterscheiden zwischen Abfragetypen und Abfragen.
- Abfragetypen sind so etwas wie Vorlagen. Sie werden von einem Tool-Administrator angelegt. Sorry, einer muss dann doch in den sauren Apfel beißen und sich mit den wesentlichen Elementen (sprich: Entity-Typen) des Datenbankschemas vertraut machen. Aber keine Sorge: Auch der Administrator muss nicht bei null anfangen. Grundlegende Abfragetypen bringt das Werkzeug mit.
- Aus einem Abfragetyp erstellen Sie als Anwender nach Bedarf konkrete Abfragen. Das ist ganz einfach: Sie wählen für einen Elementtyp mit ein paar Klicks die Eigenschaften aus, die Sie auf dem Bildschirm sehen möchten. Sie brauchen zum Beispiel eine Liste aller Stakeholder mit Namen und Kontaktdaten. Ihr Kollege hätte dagegen gern eine Übersicht aller Stakeholder mit Priorität. Sie beide verwenden denselben Abfragetyp Stakeholderabfrage, machen daraus aber durch Auswahl der Eigenschaften Name und Kontakt beziehungsweise Name und Priorität ihre eigenen Abfragen. Zusätzlich können Sie auch noch Filterkriterien definieren.
Tun wir’s doch einfach:
Abfragetypen und Abfragen – ein Beispiel
Schlüpfen wir zunächst in die Rolle des Administrators und bleiben wir bei dem eben genannten Beispiel: Der Administrator will einen Abfragetyp vorbereiten, mit dem die Anwender später die Stakeholder auswerten können. Der Abfragetyp bekommt den Namen Stakeholderabfrage. Dann wird der Entity-Typ festgelegt, der ausgewertet werden soll. Das ist – klar – Stakeholder. Schon ist der – zugegeben – sehr einfache Abfragetyp fertig. Schauen Sie:
Haben Sie im Dialog zum Anlegen eines Abfragetyps die Liste „Auswählbare Entities“ gesehen? Damit hat es Folgendes auf sich: Im Datenbankschema steht der Entity-Typ Stakeholder mit anderen Entity-Typen in N:1-Beziehungen. Wenn der Administrator den Anwendern die Möglichkeit geben will, in ihren Abfragen später auch Eigenschaften dieser anderen Entity-Typen auszuwerten, dann muss er die entsprechenden Entity-Typen in dieser Liste markieren. Der Anwender sieht später einfach eine Menge von Eigenschaften, in der er diejenigen markieren kann, die er abfragen möchte. Mit dem ganzen „Beziehungskram“ muss sich der Anwender also nicht abgeben.
Aber was muss der Anwender denn jetzt noch tun? Übernehmen wir einmal die Rolle des Anwenders und legen eine eigene Abfrage an. Die Abfrage bekommt einen Namen. Sie soll Stakeholderliste heißen. Dann wählen wir den Abfragetyp aus, auf dem die Abfrage basieren soll. Wir nehmen die eben definierte Stakeholderabfrage. Und zum Schluss bestimmen wir die Eigenschaften des Stakeholders, die anzeigt werden sollen. „Live“ sieht das so aus:
Was haben wir uns da zusammengeklickt? Schauen wir mal nach:
Natürlich können Sie – wie Sie eben gesehen haben – in der Ergebnisliste die Anordnung der Spalten ändern, die Sortierung festlegen und Eigenschaftswerte editieren. Änderungen der Eigenschaftswerte werden nicht nur sofort in der Datenbank gespeichert. Sind die Werte auch in Diagrammen sichtbar, werden die Änderungen automatisch auch dort wirksam.
Nehmen wir jetzt an, Sie sind nur an den Stakeholdern interessiert, die im Projekt konstruktiv mitwirken wollen, d. h. deren Motivation nicht gerade gering ist. Um diese zu finden, filtern Sie die Stakeholderliste. Wie das geht, sehen Sie hier:
Übrigens: Sie können natürlich nicht nur flache, sondern auch hierarchische Listen erzeugen, wie Sie es an diesem einfachen Beispiel der Stakeholder mit ihren Zielen sehen:
Performance-optimiert
Ich habe hier nur extrem einfache Beispiele mit winzigen Ergebnismengen verwendet, um Ihnen das Prinzip der Abfragetypen und Abfragen mit Filtern zu veranschaulichen. Aber mit diesem Mitteln können Sie gerade in großen Mengen zum Beispiel von Anforderungen sehr schnell für Orientierung sorgen. Wir haben bei der Entwicklung der Abfrage-Funktionen die Erfahrungen von in-Step einfließen lassen und ein besonderes Augenmerk auf die Performance gelegt.
Übrigens: Aus den Menüs und den Dialogen, die Sie in den Filmen gesehen haben, werden noch eine ganze Reihe von Einträgen verschwinden, die für Sie als Anwender nicht von Bedeutung sind. Wie Sie wissen: wir bauen noch.
Und deshalb gibt es auch noch mehr über den objectiF Requirements Modeller zu berichten. Fortsetzung folgt.
Diskutieren Sie mit und hinterlassen Sie einen Kommentar.