Freitag, 7. Februar 2014

Die Analyse des Problemraums führt zum Zielmodell.

These: 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.

Eine Software wird oft entwickelt, weil ein Problem gelöst werden soll. Prozesse werden automatisiert, menschliche Tätigkeiten werden durch den Prozessor ersetzt und Aktenschränke verschwinden auf Festplatten. Damit die Entwicklung weiß, was von diesen Dingen wirklich umgesetzt werden soll, muss zuerst eine Problemanalyse durchgeführt werden. Erste Schritte einer Problemanalyse wurden bereits in der Systemkontextanalyse durchgeführt. Dort wurde der Schwerpunkt auf das Verstehen des Systemumfeldes gelegt, aber es wurden auch Prozesse analysiert und vor allem optimiert. Das Optimieren eines Prozesses ist jedoch nur möglich, wenn man eine IST-Analyse durchgeführt hat und nachfolgend eine Schwachstellenanalyse. Die Schwachstellenanalyse hat Probleme aufgedeckt, die in der Optimierung des Prozesses abgestellt wurden.

Ein wichtiger Schritt im Requirements Engineering ist also das Aufdecken von Problemen. Diese Probleme werden innerhalb der IST-Analyse des Systemkontextes entdeckt und beschrieben. Probleme können in Form eines Baumes dargestellt werden. Durch eine Top-Down-Analyse kann man die Probleme immer weiter verfeinern. Bei der Verfeinerung spielen zwei Abhängigkeiten eine Rolle.
  1. Probleme verursachen weitere Probleme und
  2. Probleme bestehen aus Problemen.
Die Aufzeichnung des Problemraumes ist Voraussetzung für das Entwickeln einer Zielvorstellung. Auch in der Aufzeichnung von Ideen verstecken sich Probleme. Hinter jeder Idee verbirgt sich eine vermeintliche Lösung für ein Problem.



Jedes Problem wird nun durch ein Ziel gelöst. Bevor wir jedoch den Zusammenhang zwischen Problem und Ziel betrachten, wollen wir die sogenannten Randbedingungen diskutieren. Die Randbedingungen bzw. die Restriktionen ermitteln wir in einer sogenannten Restriktionsanalyse. Diese Art der Analyse führen wir vor der Zielanalyse durch. Das geschieht, weil Restriktionen bzw. Randbedingungen unseren Lösungsraum einschränken. Anhand der Restriktionsanalyse können wir die Durchführbarkeit von Zielen wesentlich besser bewerten und brauchen bestimmte Irrwege gar nicht erst zu gehen.

Unter Kenntnis der Randbedingungen können wir nun Ziele finden, welche die Probleme lösen. Ein Ziel, welches kein bestehendes Problem löst, ist kein Ziel. Auch Ziele werden in einer Hierarchie abgebildet. Die zweite Ebene klassifiziert Ziele in Projektziele, Geschäftsziele, technologische Ziele und Fachziele. In [DIR11] werden vier Wissenslücken aufgeführt, die für ein Softwareprojekt geschlossen werden müssen: Markt, Domäne, Prozesse/Experience und Technologie. Die Ziele für die Domäne und die Prozesse/Experience finden sich unter den Fachzielen. Die Ziele für die Technologie unter den technologischen Zielen und die Ziele in Bezug auf den Markt unter den Geschäftszielen. Das Softwareprojekt und seine Führung ist ein eigenständiges Problem, dass ebenso Ziele benötigt, eben die Projektziele. In allen vier Sparten gibt es Probleme, die durch Ziele gelöst werden sollen und deren Lösungsraum eventuell durch Restriktionen eingeschränkt sind.

Im obigen Text haben wir also drei Analyseformen beschrieben, die im Zusammenhang gesehen werden müssen: Problem-, Restriktions- und Zielanalyse. Jede dieser Analyseformen befruchtet die Ergebnisse der anderen beiden Analysearten. Wieder ist ein Kreislauf entstanden, in dem sich sowohl die Probleme, die Ziele und auch die Randbedingungen in immer verfeinerter Form darstellen.

In der Zielanalyse fertigen wir ein Zielmodell an. Das Ziel ist in unserem Objekt-Aufgaben-Modell ein Objekt. Die Bearbeitungsaufgabe für das Themenobjekt führte uns im letzten Artikel zu User-Story-Objekten. Die Bearbeitungsaufgaben von User-Story-Objekten, unter Beachtung der Kontextobjekte, führt uns nun zu Zielobjekten. Weitere Objekte in diesem Arbeitsgang sind Problemobjekte und Randbedingungen. Problemobjekte und Zielobjekte werden jeweils für sich betrachtet in Bäumen angeordnet. Zwischen Problemobjekten und Zielobjekten muss die Assoziation "löst" stehen. Zielobjekte ohne diese Beziehungen können gelöscht werden. Zwischen Zielobjekten und Randbedingungen heißt die Assoziation "schränkt ein". Diese Assoziation ist natürlich nur vorhanden, wenn es wirklich eine Randbedingung gibt.



Das zentrale Modell ist das Zielmodell. "Ein Ziel ist die intentionale Beschreibung eines charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprozesses." [S.91, POHL08] Eine Intention beschreibt dabei die Absicht des zu entwickelnden Merkmals. Das oberste Ziel ist die Vision. Diese Vision unterliegt einem Verfeinerungsprozess. Aus Oberzielen werden Unterziele abgeleitet. Das kann mit Hilfe von Und-Dekomposition oder Oder-Dekomposition geschehen. Den folgenden Teil dieses Artikels übernehme ich aus meiner Diplomarbeit, die ich im Rahmen meines Fernstudiums 2009 abschloss. [BAU09] Die folgenden Zeilen erläutern, wie ein Zielmodell aufzubauen ist und welche Modellelemente dabei beachtet werden müssen.

Bei einer Und-Dekomposition werden aus einem Ziel Z die Teilziele Z1 bis Zn (n => 2) abgeleitet. Alle Teilziele müssen für die Erfüllung des Oberziels Z erfüllt werden.

Bei einer Oder-Dekomposition werden aus einem Ziel Z die Teilziele Z1 bis Zn (n => 2) abgeleitet. Es muss mindestens ein Teilziel erfüllt werden, damit das Oberziel Z erfüllt wird.

Zwischen Zielen können Abhängigkeiten bestehen. [POHL08] nennt die Zielunterstützung, die Zielbehinderung, den Zielkonflikt und die Zieläquivalenz.

Im Folgenden werden die Abhängigkeiten definiert.

Die Zielunterstützung: "Ein Ziel Z1 unterstützt ein Ziel Z2, wenn die Erfüllung von Z1 zur Erfüllung von Z2 beiträgt." [S.92, POHL08]

Die Zielbehinderung: "Ein Ziel Z2 behindert ein Ziel Z1, wenn die Erfüllung von Z2 die Erfüllung von Z1 erschwert." [S93, POHL08]

Der Zielkonflikt: "Zwischen einem Ziel Z1 und einem Ziel Z2 besteht ein Zielkonflikt, wenn (1) die Erfüllung von Z1 die Erfüllung des Ziels Z2 ausschließt und (2) die Erfüllung von Z2 die Erfüllung des Ziels Z1 ausschließt." [S.94, POHL08]

Die Zieläquivalenz: "Zwischen zwei Zielen Z1 und Z2 besteht eine Zieläquivalenz, wenn (1) die Erfüllung des Ziels Z1 die Erfüllung des Ziels Z2 bedingt und (2) die Erfüllung des Ziels Z2 die Erfüllung des Ziels Z1 bedingt." [S.94, POHL08]

Zur Darstellung der Ziele wird ein Und-Oder-Baum verwendet. Und-Oder-Bäume sind Graphen. Die Knoten stellen die Ziele dar und die Kanten verbinden Oberziele mit Teilzielen. Mit Und-Oder-Bäumen kann sowohl die Und-Dekomposition und die Oder-Dekomposition von Zielen dargestellt werden.




Außerdem können so genannte Benötigt-Beziehungen und Konfliktär-Beziehungen dargestellt werden.

Eine Benötigt-Beziehung drückt aus, dass ein Ziel die Erfüllung eines anderen Ziels benötigt, damit es erfüllt werden kann. Damit wäre die Abhängigkeit der Zielunterstützung beschrieben. Ist diese Abhängigkeit beidseitig wird eine Zieläquivalenz beschrieben.



Eine Konfliktär-Beziehung drückt aus, dass die Erfüllung eines Zieles verhindert, dass ein anderes Ziel erfüllt werden kann. Damit wird die Abhängigkeit des Zielkonflikts ausgedrückt.



Im Folgenden wird ein Beispiel für einen Und-Oder-Baum dargestellt.



Damit endet der Auszug aus der Diplomarbeit und auch der heutige Post. In jedem Prozessschritt lösen wir wichtige Aufgaben auf dem Weg ein sinnvolles System zu bauen. Wir versuchen nicht einfach irgendetwas umzusetzen, sondern uns genau zu überlegen WAS wir umsetzen wollen.

  • [BAU09] Ralf Baumann: "Entwicklung eines Arbeitsablaufes für die Entwicklung von Anforderungen an eine Software durch den Auftraggeber.", Diplomarbeit an der FH Trier, 2009
  • [DIR11] : Jörg Dirbach, Markus Flückiger, Stefan Lentz: "Software entwickeln mit Verstand", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2011
  • [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