Donnerstag, 19. Dezember 2013

Ein hierarchisches System von Kontextobjekten

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im letzten Artikel habe ich beschrieben, warum für Themenobjekte eine Systemkontextuntersuchung durchgeführt werden muss. Eigentlich wollte ich in diesem Post das Erstellen von User Stories beschreiben. Damit müssen wir jedoch noch einen Post warten, weil ich beim Reflektieren des Verhältnisses zwischen Kontextobjekt und inhärenten Unterobjekten Abhängigkeiten gefunden habe, die noch nicht beschrieben sind. Im Artikel Ordnung für Dokumente habe ich den Unterschied zwischen Quelldokumenten und Dokumenten, die gewonnene Informationen enthalten, beschrieben. Diese Formen der Dokumente stehen in einem engen Zusammenhang. Die gewonnene Information wird aus dem Quelldokument ermittelt.



Was meine ich nun mit inhärenten Kontextobjekten? Wenn man beispielsweise einen Stakeholder als Anforderungsquelle gefunden hat, legt man für ihn ein Kontextobjekt an. Dieses Kontextobjekt kann mit der Zeit verschiedene Assoziationen zu mehreren Themenobjekten besitzen. Schließlich kann dieser Stakeholder ein Fachexperte sein, der zu verschiedensten Fachbereichen kompetente Auskunft geben kann. Diese Auskünfte ermittelt der Requirements Engineer mit Hilfe verschiedenster Methoden. Beliebte Methoden sind das Interview oder der Fragebogen. Das Ergebnis dieser Befragungen sind ebenfalls Kontextobjekte, die dem Kontextobjekt des Stakeholders untergeordnet werden. Diese Kontextobjekte enthalten gewonnene Informationen.

Die entstandenen Kontextobjekte Interview und Fragebogen können aber ganz andere Beziehungen zu den Themenobjekten besitzen als das Kontextobjekt Stakeholder. Genauer gesagt, sie sind eine Teilmenge der Beziehungen des Stakeholders. Ein Stakeholder kann mit Hilfe verschiedenster Aussagen viele Beziehungen zu Themenobjekten aufbauen. Bestimmte Interviews beziehen sich aber nur auf einen Teilaspekt dieser Beziehungen. Die Auswertung von Interviews und Fragebögen kann durchaus wieder neue Kontextobjekte ergeben. Dabei kann man darauf achten, dass die Beziehung zum Themenobjekt eindeutig ist. Auf diese Art und Weise entsteht ein hierarchisches System von Kontextobjekten.



Folgt man der Entstehung der Hierarchie, dann ist damit eine gewisse Arbeitsweise verbunden. Das oberste Kontextobjekt ist eine Anforderungsquelle. Mit Hilfe dieser Anforderungsquelle werden Informationen ermittelt. Diese Informationen werden reflektiert und verdichtet. Das Ergebnis sollte dann abgestimmt werden. Der Sinn dieser Verdichtung ist die Konzentration auf das Wesentliche. Das Interview und den Fragebogen behalten wir als Originale. Es kann durchaus sein, dass wir während der Verdichtung wichtige Informationen übersehen haben und bei einer folgenden Iteration darauf aufmerksam werden. Der Unterschied zwischen Original und Verdichtung ist deswegen bedeutsam. Es gibt also zwei Arten der gewonnenen Information, die ungefilterte und die gefilterte Information.

Eine ähnliche Bedeutung hat der IST-Zustand der Kontextobjekte, die mehrere Zustände annehmen können. Unser Beispiel im letzten Artikel dazu war ein Prozess. Der IST-Zustand des Prozesses ist das existierende Original. Die beiden SOLL-Zustände sind in diesem Fall jedoch keine Verdichtungen der Information auf das Wesentliche. Es sind vermeintliche Verbesserungen der Ausgangssituation durch die Optimierung des Prozesses.

Im Ergebnis erzeugen wir also zwei Arten gewonnener Information, die wir in der Anforderungsermittlung weiter benutzen können:
  1. Verdichtete Information auf das Wesentliche. (Was soll umgesetzt werden.)
  2. Information über die Verbesserung der Ausgangssituation. (Was soll besser gemacht werden.)

Ein wichtiger Bestandteil der Analyse des Systemkontextes ist die Problemanalyse. Das Aufdecken von Problemen und Schwachstellen ist eine essentielle Aufgabe. Der Zustandswechsel des Kontextobjektes zum Prozess resultiert vor allem aus der Analyse von Schwachstellen, die im optimierten Prozess verschwunden sein sollten. Auch beim Ergründen des Systemkontextes durch Interviews oder Fragebögen ist die Suche nach Schwachstellen von hoher Bedeutung. Auch hier werden IST-Zustände beschrieben, die durch Ideen zu SOLL-Zuständen verbessert werden können. Von hoher Wichtigkeit ist auch das eindeutige Auseinanderhalten von IST- und SOLL-Zuständen. Es muss klar sein, wovon gerade die Rede ist.

Das Aufdecken der Probleme ist deshalb eine grundlegende Tätigkeit, weil in der Zielanalyse des Systems Ziele definiert werden, die ebendiese Probleme lösen sollen. Ein Ziel löst also ein Problem. Eine Randbedingung schränkt die Zielmöglichkeiten ein.



Die schrittweise Verbesserung unseres Verständnisses des Systemkontextes führt zu einem immer besseren Problemverständnis und damit auch zu einer höheren Lösungskompetenz. Dieses Problembewusstsein sollten sich das ganze Team und die Auftraggeber/Benutzer zusammen erarbeiten. Erst wenn brauchbare Ergebnisse der Systemkontextanalyse vorliegen, kann mit dem Beschreiben von User Stories begonnen werden. Damit werde ich im nächsten Artikel fortfahren.

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