Sonntag, 24. November 2013

Themen müssen einer Systemkontextanalyse unterzogen werden.

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.


Wie im letzten Post angedeutet, wird für ein Themenobjekt, wenn es denn finalisiert und beauftragt wurde, vom Product Owner für den Requirements Engineer eine Aufgabe erzeugt (create). Diese Aufgabe beinhaltet die Untersuchung des Systemkontextes in Bezug auf das entsprechende Themenobjekt. Die Grundlagen der Systemkontextanalyse habe ich in einer kleinen Artikelreihe bereits beschrieben. Die ersten beiden Post dieser Reihe klären die Grundfragen: Was ist der Systemkontext? und Warum und wie sollte der Systemkontext erfasst werden?. Im Post Welche Arten von Kontextobjekten gibt es? werden die zu findenden Kontextobjekte aufgezählt. Außerdem habe ich zusätzlich ein Modell zur Visualisierung von Stakeholdern und deren Beziehungen vorgestellt. (Kontextaspekt Stakeholder., Nutzerrollen, Personas und extreme Charaktere., Organisationsstrukturen.) In den nächsten Monaten werde ich auch für die anderen Kontextobjektarten Modelle bzw. Dokumentationsformen vorschlagen.



Trotz dieser kleinen Artikelreihe möchte ich hier nochmals kurz den Sinn einer Systemkontextuntersuchung beschreiben. In Bezug auf das zu erschaffende System wird das Umfeld auf Kontextobjekte hin untersucht, die das Problem erhellen und/oder Anforderungsquellen sind. Solche Kontextobjekte sind beispielsweise Stakeholder, Dokumente, Altsysteme und Prozesse. Die Systemkontextuntersuchung ist wichtig für das Verstehen des Systems in seiner Umgebung. In welche Prozesse ist das System eingebettet? Wer muss mit dem System arbeiten? Welche Prozesse lassen sich automatisieren? Welche Prozesse lassen sich optimieren? Nachdem diese, und einige mehr, Fragen beantwortet sind, kann man viel bessere Anforderungen definieren. Diese Tätigkeit gelingt jetzt mit dem Hintergrundwissen des Warum und Wozu. Die Systemkontextanalyse dient auch einer vertiefenden Problemanalyse.

Der Requirements Engineer muss mit dem erforderlichen theoretischen Wissen über die Systemkontextanalyse ausgestattet sein, bevor er die vom Product Owner gestellte Aufgabe angeht. In Bezug auf das Thema, welches im Themenobjekt definiert wurde, untersucht der Requirements Engineer nun die Systemumgebung des zu erstellenden Systems. Eine der wichtigsten Aufgaben dabei ist das Auffinden von Anforderungsquellen. Glücklicherweise verfügen wir bereits über Anhaltspunkte, wo diese zu finden sind. Da wir das Melden von mehr oder weniger strukturierten Ideen zulassen und diese den Themenobjekten zugeordnet wurden, liegen uns auch die Namen der Ideengeber vor. Diese sind automatisch unsere ersten Ansprechpartner für das weitere Auffinden von Anforderungsquellen.

Auf diese Art und Weise finden wir Personen, die uns Auskunft geben können über weitere Personen, Prozesse, Ereignisse und Dokumente, die im Umfeld des Systems zu diesem Thema liegen. Jedes gefundene Ding, jede gefundene Person wird zu einem Kontextobjekt. Das Kontextobjekt wird vom Requirements Engineer erzeugt (create). Damit haben wir unser zweites Objekt im Gesamtmodell gefunden. Die Kontextobjekte bekommen einen Verbindung zum Themenobjekt. Wie schon erwähnt ist unser Vorgehen iterativ und inkrementell. Das heißt, wir bauen Stück für Stück unseren Systemkontext zusammen. Mit jedem Themenobjekt wird das abgebildete Modell des Systemkontextes größer und genauer. Früher gefundene Kontextobjekte können jedoch in späteren Iterationen auch Verwendung finden. Damit kann der Requirements Engineer nicht nur mit der Analyse der Ideen beginnen, die dem Themenobjekt zugeordnet wurden, sondern er kann auch die bereits angelegten Kontextobjekte durchforsten, inwieweit diese auch in diesem thematisch eingegrenzten Systemkontext eine Rolle spielen. Somit kann ein Kontextobjekt mehrere Beziehungen zu Themenobjekten haben.



Es gibt Kontextobjekte, die drei verschiedenen Zustände besitzen können. Wird für eine Firma z.B. ein Prozess zur Rekrutierung von Personal aufgezeichnet, so bilden wir als erstes den IST-Zustand des Prozesses ab, der zum Zeitpunkt der Erfassung real durchgeführt wird. Oft ist es angebracht real existierende Prozesse zu optimieren. Der dabei erdachte Prozess bildet den SOLL-Zustand des Prozesses ab. Im Post Warum und wie sollte der Systemkontext erfasst werden? habe ich diesen Zustand auch Optimierungs-SOLL-Zustand genannt. Danach wird ein dritter Zustand hergestellt. Bestimmte Teilprozesse werden in das System verlagert und somit automatisiert. Diesen Zustand nennen wir System-SOLL-Zustand. Alle drei Zustände dieses erfassten Prozesses bilden ein Kontextobjekt. Dabei ist das Kontextobjekt des IST-Zustandes mit dem des Optimierungs-SOLL-Zustandes zu verbinden und das wiederum mit dem des System-SOLL-Zustandes.



Eine weitere Möglichkeit, die der Requirements Engineer während der Untersuchung des Systemkontextes hat, ist das Hinzufügen von Ideen zum Themenobjekt. Diese Ideen entstehen aus der Kommunikation mit den Stakeholdern, aus dem Lesen von Dokumenten, dem Beobachten von Prozessen oder anderen typischen Ermittlungstechniken des Requirements Engineering. Der Requirements Engineer sollte diese Ideen bereits strukturiert formulieren. Die neu gefundenen Ideen müssen dem Gremium vorgelegt werden, welches ich im letzten Post erwähnt hatte. Diesem Gremium gehören der Product Owner, der Requirements Engineer, ein Kundenvertreter und ein Vertreter des Entwicklerteams an. Die neu hinzugefügten Ideen müssen priorisiert werden.

Mit dem Abschluss der Kontextuntersuchung setzt der Requirements Engineer seine Aufgabe auf IMPLEMENTED. Im Gremium wird die Arbeit des Requirements Engineer bewertet. Dazu haben die Mitglieder des Gremiums natürlich Zeit sich vorzubereiten. Jedes Meeting muss, um einen Sinn zu ergeben, vorbereitet, durchgeführt und nachbereitet werden. Die Vorbereitung hat jedes einzelne Mitglied durchzuführen, genau wie es an der Sitzung teilnehmen muss. Für die Nachbereitung kann eine verantwortliche Person durch den Product Owner festgelegt werden oder er macht es selber. Wenn das Gremium die Arbeit des Requirements Engineer positiv bewertet wird die Aufgabe der Kontextuntersuchung auf REVIEWED gesetzt und ist somit abgeschlossen. Eine negative Bewertung würde die Aufgabe wieder auf OPEN setzen und der Requirements Engineer müsste nacharbeiten. In der endgültigen Bewertung würde der Product Owner die Aufgabe akzeptieren und somit den Weg für eine Weiterarbeit frei machen.

Im nächsten Schritt, der im folgenden Post beschrieben wird, geht es darum, User Stories zu erstellen.

vorheriger Post dieses Themas     folgender Post dieses Themas


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

Kommentare:

  1. Ich würde an dieser Stelle die Aussage des Posts sogar noch drastischer formulieren:

    Eine Systemkontextanalyse ist die einzige Möglichkeit, aus Sicht des Unternehmens sinnvolle Anforderungen zu definieren.

    Meine Motivation dafür ist, dass in meinen Projekten oftmals Anforderungen auf den Tische kamen, die sich im Nachhinein oft in eine der folgenden Kategorien einordnen ließen:
    - Beheben eines einmalig aufgetretenen Problems
    - Silodenken einer Abteilung
    - Messetermin oder Vertriebstermin mit einem Hersteller
    - Behinderung des Prozess- oder Informationsflusses
    - Und so weiter....

    Alle diese Fälle produzieren letztlich sinnlose Anforderungen. Ein Requirements Engineer, der nur das mitschreibt, was ihm die Fachabteilung sagt, benötigt daher Unterstützung - zum Hinterfragen der Sinnhaftigkeit einer jeden Anforderung.

    Und diese Unterstützung kann nur mit Kontextwissen sinnvoll geleistet werden.

    AntwortenLöschen
    Antworten
    1. Aus Erfahrung weiß ich, dass für die Ist-Analyse und die Definition der Requirements zuwenig Zeit und zuwenig Erfahrung des Umfelds genutzt wird. Die Herausforderung für den Requirements Manager ist es also, Kontextwissen zu sammeln um maximal 100 Prozent zu erreichen - das ist in meinen Augen utopisch. Vor allem wenn man den Zeitrahmen bedenkt, der meist extrem knapp bemessen ist. Die Sinnhaftigkeit jeder Anforderung zu hinterfragen.....nun ja. Die Sinnhaftigkeit der Anforderung muss an sich gegeben sein, denn sonst muss ich die Existenzberechtigung des Anfordernden in Frage stellen. Meist ist es doch so, dass alle Anforderungen erfüllt werden sollen....obwohl es nicht möglich ist. Ich denke jede Anforderung kann mit Was Wer warum (bis) wann wie womit beantwortet werden. Und daraus ergibt sich die Existenzberechtigung. (oder auch nicht) Kontextwissen ist ohne Frage erforderlich.

      Löschen