Donnerstag, 27. Juni 2013

Requirements Engineering – erst einmal die Anforderungen definieren

Praktisches Beispiel 1.2

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Die gefundene Liste der Annahmen über Anforderungen, die in der Altsoftware verwirklicht wurden, werden jetzt im Team zu wirklichen Anforderungen gemacht. Die Aktivität des Requirements Engineering sollte keine Einzelkämpfertätigkeit sein. In einer Teamsitzung wird der Vollständigkeitsgrad der Anforderungen direkt proportional zu den anwesenden Teammitgliedern sein. Hat das Team auch noch einen positiven Teambildungsprozess durchlaufen, wird das Ergebnis unschlagbar.



Ich präferiere ein Ziel-User Story-Anforderungsmodell. Die Gründe dafür werde ich in anderen Posts unter der Themengruppe Gute Software benötigt gute fachliche Anforderungen beschreiben. Das Projekt des Kommandozeilentools ist nicht so umfangreich, dass es wirklich viel bringt, in diesem Post Ziele und User Stories definieren zu müssen. Natürlich müsste das geschehen, um ein wirklich geschlossenes Anforderungsmodell zu erreichen. Da wir ein Refactoring eines relativ kleinen Codeschnippels betrachten, werden wir nur die Anforderungsanalyse durchführen.

Am Anfang der Teamsitzung zum Requirements Engineering legen wir das Ziel des Meetings und die Dokumentationsform fest. Das Ziel ist es, für das Kommandozeilentool BestellGenerator eine umfangreiche Sammlung von fachlichen Anforderungen mit Hilfe der UML und beschreibenden Textes zu finden.

Wir unterscheiden für fachliche Anforderungen drei Perspektiven: die Strukturperspektive, die Funktionsperspektive und die Verhaltensperspektive. Die Strukturperspektive nähert sich dem Problem über die Datensicht. Dazu verwenden wir das Klassendiagramm der UML. Die Funktionsperspektive betrachtet Aktivitäten und somit eignet sich das Aktivitätsdiagramm. Die Verhaltensperspektive untersucht die Zustände und wir benutzen deshalb das Zustandsdiagramm.

Zwischen diesen drei Modellen springen wir hin und her. Im Laufe des Meetings finden wir die folgenden Diagramme. Natürlich kann man auch andere Lösungen finden.

Aus dem Klassendiagramm können wir die folgenden Anforderungen herauslesen.



  1. Der Generator wird mit Startbedingungen gestartet.
    1. Der Generator hat zum Startzeitpunkt genau eine Startoption
      1. Der Generator kann mit der Einstellung CALCULATION gestartet werden. Dann wird eine Berechnung der Bestellungen pro Monat und Kunde durchgeführt.
      2. Der Generator kann mit der Einstellung FORECAST gestartet werden. Dann wird eine Vorhersage der Bestellungen pro Monat und Kunde durchgeführt.
      3. Der Generator kann mit der Einstellung USAGE gestartet werden. Dann wird dem Benutzer gezeigt, wie das Kommandozeilentool zu benutzen ist.
  2. Der Generator hat zum Startzeitpunkt genau eine Monatsangabe oder keine Monatsangabe
    1. Die Monatsangabe besteht aus einer vierstelligen Jahresangabe und einer zweistelligen Monatsangabe.
    2. Im Falle der Berechnung wird diese vom 1. des betreffenden Monats 0 Uhr bis heute 0 Uhr durchgeführt. Die Monatsangabe muss also in der Vergangenheit liegen.
    3. Im Falle der Vorhersage wird von heute 0 Uhr bis zum Ende des betreffenden Monats 24 Uhr gerechnet.
    4. Im Falle der Usage hat die Monatsangabe keine Bedeutung.
  3. Der Generator hat zum Startzeitpunkt genau eine Kundenangabe oder keine Kundenangabe.
    1. Die Kundenangabe besteht aus der Kundennummer des jeweiligen Kunden.
    2. Die Kundennummer ist immer eine ganze positive Zahl.


Bei einem Sprung in das Zustandsdiagramm fallen uns erneut Anforderungen auf.



Die Notation mit der Notiz soll besagen, dass bei einem erneuten Setzen des Forecast oder der Calculation immer eine Usage ausgelöst wird.

  1. Wenn der Zustand USAGE, FORECAST oder CALCULATION bereits gesetzt wurde, wird bei einem erneuten Versuch immer der Zustand USAGE gesetzt.
  2. Wenn im Zustand FORECAST das Datum nicht in der Zukunft liegt, wird auf den Zustand USAGE umgesetzt.
  3. Wenn im Zustand CALCULATION das Datum nicht in der Vergangenheit liegt, wird auf den Zustand USAGE umgesetzt.


Beim Aktivitätsdiagramm sind wir bei einer sehr einfachen Variante geblieben. Trotzdem wird die Reihenfolge von Parsen und Starten klar. Meist muss man eben bei 80 % aufhören. Der Rest zieht das Ganze nur in die Länge.



Im nächsten Post dieses Beispiel werde ich mich ein wenig mit Architektur beschäftigen.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen