Freitag, 10. Januar 2014

Praktisches Beispiel zur Kontextuntersuchung.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Am Ende des letzten praktischen Posts zum System einer Anforderungsermittlung haben wir uns damit beschäftigt, wie man für eine Softwarevision Ideen sammelt, ohne dass Ideen verloren gehen. Danach wurden die Ideen in Themen gruppiert und in einer Roadmap zu einem Fahrplan zur Erstellung eben dieser Softwarevision. Das verwendete Beispiel bezog sich auf eine Software zur Verwaltung der Stakeholder. In einer kleinen Artikelreihe habe ich die Visualisierung der Stakeholder und ihrer Beziehungen beschrieben. Am Ende des letzten Artikels lagen dann als Ergebnis des ersten praktischen Beispiels mehrere Themen vor: Projektakzeptanz, Projektbetroffenheit, Stakeholderbeziehungen, Personas, extreme Charaktere und Gruppen.



Greifen wir uns einfach das Thema "Personas" heraus und stellen wir uns vor, dieses Thema ist vom Product Owner beauftragt worden. Er hat eine Aufgabe für den Requirements Engineer erzeugt. Dieser muss nun eine Kontextanalyse für dieses Thema durchführen. Dieses Thema ist natürlich nicht losgelöst vom Gesamtkontext der Anwendung. Da wir in unserem Beispiel das Thema Personas herausgegriffen haben, sind die Themen Projektakzeptanz, Projektbetroffenheit und Stakeholderbeziehungen bereits abgearbeitet. (siehe Roadmap) Damit liegen uns Kontextobjekte vor, die wir für unsere Kontextanalyse nutzen können. Darunter sind z.B. Stakeholder, die wir zu unserem neuen Thema befragen können.

Einer der ersten Schritte der Kontextanalyse ist der Versuch, eine Kontextgrenze festzulegen. "Die Kontextgrenze separiert den relevanten Teil der Umgebung eines Systems von dem irrelevanten Teil, d.h. dem Teil, der keinen Einfluss auf die Systementwicklung hat und daher im Requirements Engineering nicht beachtet wird." [S.59,POHL08] Hierbei leistet uns die thematische Festlegung ungeahnte Hilfe. Wir wissen, wir müssen uns um Personas kümmern. Alles, was mit diesem Thema nicht in Beziehung steht, ist irrelevant. Natürlich existiert zwischen dem irrelevanten und dem relevanten Teil eine gewisse Grauzone. Bei bestimmten Kontextobjekten werden die Einen den Standpunkt vertreten, dieses Objekt gehört zum Kontext und Andere werden anderer Meinung sein. Am Ende hilft hier nur Diskussion, Abgleich der mentalen Modelle und Priorisierung.

Der erste Schritt wäre ein Grundverständnis über Personas. Eine Internetrecherche kann weiterhelfen oder Experten zu diesem Thema. Eine solche Expertin ist Frau Meseberg von der microTool GmbH. Einen Vortrag von der 21. microTOOL NutzerKonferenz zu Personas in Unternehmen finden Sie hier. An dieser Stelle möchte ich mich ausdrücklich noch einmal bei Frau Meseberg bedanken, auf diesen Artikel und das Vidio verweisen zu dürfen. Eine weitere wichtige Quelle der Erkenntnis ist die Literatur. Ich habe das Buch von Mike Cohn "User Stories" gelesen. [COHN10] In diesem setzt er sich im Zusammenhang mit User Stories auch mit dem Thema Personas auseinander. Sicherlich würden wir noch eine Vielzahl solcher Quellen finden, aber das ist natürlich nur soweit gewinnbringend, wie es uns zusätzliche Erkenntnis bringt und nicht unseren Zeitplan sprengt. Bleibt festzuhalten: Es muss ein Grundverständnis des Problems existieren. Dazu muss man das Grundlagenwissen beherrschen.

Diesen Wissen kann man sich auch erschließen, indem man Kontakt zu Domänenexperten aufnimmt. Diese verfügen über ein mentales Modell des Gegenstandes. Um den Kontext zu verstehen, ist es wichtig, dass sich der Domänenexperte zusammen mit dem Requirements Engineer, besser noch mit dem Team, gemeinsam ein mentales Modell über den Wissenszusammenhang erarbeitet. Dazu ist eine gewisse Form der gemeinsamen Kommunikation erforderlich, die ich in späteren Artikeln betrachten möchte. Am Ende der gemeinsamen Arbeit liegt uns das Modell als Kontextobjekt vor. In diesem Fall ist der Domänenexperte eine Anforderungsquelle und das erarbeitete Modell ein Kontextobjekt gewonnener Information. Eine wichtige Erkenntnis ist das Verstehen der Domäne.



Neben einem soliden Grundwissen über Personas müssen wir uns ebenso ein tiefes Verständnis der Marktsituation zum Thema erarbeiten. Gibt es bereits Produkte, die das Thema abdecken? Könnten Alternativprodukte eingesetzt werden? Wird unser Produkt überhaupt benötigt? Mit welchem Kosten-Nutzen-Verhältnis müssen wir rechnen? Eine zielgerichtete Marktanalyse ist ein wichtiger Bestandteil unserer Betrachtung des Systemkontextes. Dem Verstehen der Domäne muss also das Verstehen des Marktes zur Seite gestellt werden. Die Erarbeitung einer Marktanalyse ist genauso Entwicklungsarbeit wie das Herunterschreiben von Code und die Optimierung von Algorithmen.

Ein eventuelles Produkt würde für die Wirklichkeit entwickelt werden. In dieser Wirklichkeit arbeiten reale Menschen mit diesem Produkt. Doch bisher mussten diese Menschen auch arbeiten, ohne das neue Produkt. Bewusst oder unbewusst haben sie mit diesem Thema Umgang gehabt. Es wurden Arbeitsschritte durchgeführt. Diese Prozesse gilt es aufzunehmen. Diese Prozesse müssen analysiert und eventuell optimiert werden. Ebenso grundlegend ist also ein Verständnis der Prozesse und deren Schwierigkeiten.



Das Bild zeigt die drei wichtigen Gebiete, die verstanden und bearbeitet werden müssen. Zu allen Gebieten werden grundlegende Kontextobjekte gesammelt. [POHL08] unterscheidet dabei drei wichtige Kontextaspekte: Anforderungsquellen, Betrachtungsgegenstände und Eigenschaften und Beziehungen der Betrachtungsgegenstände. Anforderungsquellen sind z.B. Stakeholder, Dokumente und existierende Systeme. "Betrachtungsgegenstände sind Objekte im Kontext des Systems, die vom zu erstellenden System direkt berücksichtigt werden müssen." [S.67, POHL08] Ein Beispiel für einen Betrachtungsgegenstand ist z.B. der Administrator des zukünftigen Systems.

Die gefundenen Kontextobjekte erzeugen nun eine Reihe von abhängigen Kontextobjekten. Im Artikel Ein hierarchisches System von Kontextobjekten habe ich für den Prozess der Weiterverarbeitung von Kontextobjekten zwei wesentliche Schritte benannt:
  • Die Verdichtung der Information auf das Wesentliche. (Informationsessenz)
  • Die Verbesserung der Ausgangssituation. (Prozessoptimierung)


Am Ende der Systemkontextanalyse sollte uns klar sein, was der Gegenstand des Themas ist, wofür wir das System entwickeln und was das System verbessert. Sind diese grundlegenden Fragen nicht geklärt, machen wir irgendwas aus irgendeinem Grund. Die genaue Absicht bleibt jedoch ungeklärt.

  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


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