Freitag, 4. Dezember 2009
Thema: Analyse
Die Art und Weise der Dokumentation von Anforderungen hat Einfluss auf die Analyse der Anforderungen. Meine Erfahrung ist, dass eine geeignete Dokumentationsmethodik die Analyse unterstützen kann.
Ich habe die folgenden Erfahrungen mit diesen Dokumentationsmethoden gemacht:
Sammlung von Requirements a la "Das System muss ...", strukturiert nach Thema der Anforderung
Keine Unterstützung für die Analyse, da die Anforderungen keine Beziehung zueinander haben.
Ein weiterer Nachteil ist die schwere Lesbarkeit. Der Leser muss die Anforderungen in seinem eigenen mentalen Modell zusammen setzen.
Geeignet für sehr formale Rahmenbedingungen, da einzelne Anforderungen referenziert / abgenommen / etc. werden können.
Mein Tipp: Hierarchische Übersichtsabschnitte um den Zusammenhang und das Big Picture der Anforderungen zu bekommen.
Use-Case-Modellierung (in Text-Szenarien oder als Aktivitätsdiagramm)
Use-Cases erleichtern, sicherzustellen, dass das System dem Anwender ermöglicht, sein Ziel zu erreichen. Ausnahmen und Fehlerfälle können methodisch ermittelt werden.
Meine Lieblings-Dokumentation für alle Benutzerinteraktionen, insbesondere wegen der Zielorientierung.
Ein Nachteil ist die hohe Freiheit beim Dokumentieren. Use-Cases können auf unterschiedlicher Ebene modelliert werden - was bewusst geschehen muss.
Geeignet insbesondere für Systeme mit Benutzerinteraktion.
Mein Tipp: Ein gutes Buch zum Thema besorgen.
UML-Modell (insb. Zustandsdiagramme / Klassendiagramme)
OOA-Modelle unterstützen, das System vollständig zu analysieren inkl. aller Ausnahmen. Es fällt leicht, alle Systemaspekte auf einer Abstraktionsebene zu analysieren.
Großer Nachteil ist die hohe Einstiegshürde zum Lesen und Interpretieren der OO-Modelle. Der Leser benötigt Grundverständnis der (technischen) Sprache UML.
Geeignet falls alle Leser UML verstehen oder als Hilfsmittel für den Analytiker, Vollständigkeit zu erreichen.
Mein Tipp: Mit anderen Methoden mischen, ggf. Redundanz in Kauf nehmen zugunsten der leichteren Lesbarkeit.
Ich habe die folgenden Erfahrungen mit diesen Dokumentationsmethoden gemacht:
Sammlung von Requirements a la "Das System muss ...", strukturiert nach Thema der Anforderung
Keine Unterstützung für die Analyse, da die Anforderungen keine Beziehung zueinander haben.
Ein weiterer Nachteil ist die schwere Lesbarkeit. Der Leser muss die Anforderungen in seinem eigenen mentalen Modell zusammen setzen.
Geeignet für sehr formale Rahmenbedingungen, da einzelne Anforderungen referenziert / abgenommen / etc. werden können.
Mein Tipp: Hierarchische Übersichtsabschnitte um den Zusammenhang und das Big Picture der Anforderungen zu bekommen.
Use-Case-Modellierung (in Text-Szenarien oder als Aktivitätsdiagramm)
Use-Cases erleichtern, sicherzustellen, dass das System dem Anwender ermöglicht, sein Ziel zu erreichen. Ausnahmen und Fehlerfälle können methodisch ermittelt werden.
Meine Lieblings-Dokumentation für alle Benutzerinteraktionen, insbesondere wegen der Zielorientierung.
Ein Nachteil ist die hohe Freiheit beim Dokumentieren. Use-Cases können auf unterschiedlicher Ebene modelliert werden - was bewusst geschehen muss.
Geeignet insbesondere für Systeme mit Benutzerinteraktion.
Mein Tipp: Ein gutes Buch zum Thema besorgen.
UML-Modell (insb. Zustandsdiagramme / Klassendiagramme)
OOA-Modelle unterstützen, das System vollständig zu analysieren inkl. aller Ausnahmen. Es fällt leicht, alle Systemaspekte auf einer Abstraktionsebene zu analysieren.
Großer Nachteil ist die hohe Einstiegshürde zum Lesen und Interpretieren der OO-Modelle. Der Leser benötigt Grundverständnis der (technischen) Sprache UML.
Geeignet falls alle Leser UML verstehen oder als Hilfsmittel für den Analytiker, Vollständigkeit zu erreichen.
Mein Tipp: Mit anderen Methoden mischen, ggf. Redundanz in Kauf nehmen zugunsten der leichteren Lesbarkeit.
... kommentieren