Anforderungsstrukturierung

Anforderungsstrukturierung ist Teil des Requirements Engineerings (RE). Ziel des RE ist es die Wünsche des Kunden so in Anforderungsspezifikationen umzusetzen, dass das Endergebnis mit den Erwartungen des Kunden übereinstimmt. Die Anforderungsstrukturierung befasst sich dabei, wie der Name bereits sagt, mit der Ordnung und Strukturierung der Anforderungen. Ihre Bedeutung nimmt dabei mit der Komplexität des Projektes zu. In der heutigen Zeit gibt es einen ganzen Katalog voll von Erwartungen und Anforderungen, die das Projekt erfüllen muss. Hierbei kann man leicht den Überblick verlieren, wenn man vorher keine geeignete Struktur festgelegt hat. Die Anforderungen müssen übersichtlich geordnet sein, sodass man schnell das Gesuchte finden kann.
Welche Methoden bzw. Modelle man hierfür anwenden kann wird im folgenden Artikel erläutert.

Ziele, Stakeholder, Randbedingungen

Bevor die Anforderungen strukturiert werden können müssen erst einmal die Ziele der Stakeholder gesammelt werden. Ziele sind Anforderungen mit hohem Abstraktionsniveau und unterliegen den zuvor angedeuteten Kriterien der Anforderungen. Um diese ermitteln zu können sollte man sich vorher einen Überblick über bestehende Stakeholder zu beschaffen.

Hierzu wäre das Aufstellen einer Liste der bestehenden Stakeholder hilfreich. Um diese zu erstellen sollten zuerst alle bekannten größeren Stakeholder gesammelt werden. Um anschließend niemanden zu vergessen, werden die bereits gesammelten befragt. Hierbei geht es um das Umfeld in dem sich die betreffende Person bewegt, da hier weitere Stakeholder zu finden sind. Später werden für die einzelnen Stakeholdergruppen Repräsentanten ausgewählt und diese genauer zu befragen oder zu einer Diskussion einzuladen. Bei dem Auswählen der Personen ist es wichtig, darauf zu achten, dass diese sowohl ein Verständnis des Marktes aufweisen, wie auch dieses Verständnis kommunizieren können. Stakeholder werden dann mit ihrer Rolle, Beschreibung, Vertreter, Verfügbarkeit, Wissensgebiet und Begründung in einer Tabelle erfasst.[1] 

Gruppierung der Anforderungen

Wurden die Anforderungen gesammelt müssen sie im nächsten Schritt einzelnen Gruppen zugeordnet werden. Je größer und komplexer das Projekt ist, desto mehr unterschiedliche Anforderungen gibt es. Um hierbei nicht den Überblick zu verlieren, werden die Anforderungen in Gruppen eingeteilt. Hierbei gibt es keine festgelegten Gruppen. Die Gruppen variieren je nach Projekt.

Die 3 wichtigsten und häufigsten sind die Gruppierung nach:

- Art
- Ebene
- Priorität

Die Gruppierung nach Art erhöht wesentlich die Lesbarkeit der Anforderungen. Sie hilft dem RE-Management schnell die Anforderungen zu finden, die es gerade benötigt. Eine mögliche Einteilung wäre z.B. nach Funktionalität, Technik oder Qualität. Bei einem Handy könnte dies bedeuten, dass bei den technischen Anforderungen es um Merkmale wie die Auflösung des Displays geht. Funktionale Anforderungen würden sich eher darauf beziehen, wie das Handy benutzt werden soll z.B Tastatur oder Touchpad. Die Qualität hingegen würde sich mit Punkten wie die fehlerfreie Ausführung der Aufgaben befassen oder die Überprüfung des Netzempfangs durch diverse Tests. So kann sich jede Lesergruppe auf die Anforderungen konzentrieren die sie interessieren, indem sie die anderen heraus filtert.

Die Gruppierung nach Ebene findet sich oft in komplexen IT-Projekten. Jede Ebene steht für einen anderen detailierungsgrad der Anforderungen. Ebene 0 bedeutet, dass die Anforderungen nur sehr grob umrissen wurden. Die Ebene 4 hingegen enthält genaue Beschreibungen der Anforderungen. Für das Beispiel des Handys würde dies bedeuten, dass auf Stufe 0 nur formuliert ist, dass ein günstiges, optisch ansprechend designtes Handy entwickelt werden soll, mit dem Ziel auch in Afrika neue Märkte zu erschließen. Auf Stufe 4 hingegen wird genau beschrieben, wie eine Bluetooth Schnittstelle eingebaut werden soll, wie die Kamera optimiert werden kann bzw. welche Einstellungen die Kamera besitzen muss. Auf diese Weise ist es jedem möglich sich den Einblick zu verschaffen, den er gerade möchte, sowohl grob wie auch detailliert. Das Verständnis zwischen den Schnittstellen wird hierbei verbessert.

Die Gruppierung nach Priorität soll eine zielgerichtete Entwicklung ermöglichen. Es soll herausgefunden werden, welche der Anforderungen als am wichtigsten gelten bzw. welche innerhalb einer bestimmten Frist fertig gestellt sein müssen. Dies geschieht durch eine Bewertung durch das Team. Mögliche Bewertungsstufen wären notwendig, gewünscht und optional. Die Bewertung kann z.B in einem Workshop erfolgen, indem die Teilnehmer eine gewisse Anzahl an Punkten unter den Anforderungen aufteilen. Die Anforderungen mit der höchsten Punktzahl sind dann die, die es zu priorisieren gilt. Ein umfangreicheres Modell hierzu wäre beispielweise das Kanomodell.[2] 

Eine weitere oft verwendete Darstellung ist die Zielprioritätenmatrix. Anhand des Bildes sieht man, dass die Merkmale des Projektes wie "Abschlusstermin" auf der linken vertikalen und die Priorisierung auf der horizontalen Achse der Matrix aufgetragen sind. Das Entwicklungsteam legt anhand der Matrix fest, welches Merkmal sie als am wichtigsten erachtet bzw. welches am unwichtigsten. Bei dem angegebenem Beispiel, wäre die Einhaltung des Abschlusstermin dem Team am wichtigsten. Hingegen legen sie weniger Wert auf eine Veränderbarkeit. Ist die Matrix fertig ausgefüllt kann man sich mit ihrer Hilfe einen schnellen Überblick über die wichtigsten Ziele des Projektes machen.

Würde man jetzt die Anforderungen auf Grundlage dieser Matrix strukturieren, würden alle Anforderungen, die den Abschlusstermin beeinflussen, an erster Stelle kommen. Anforderungen, die sich mit einer Veränderbarkeit befassen würden zunächst entfallen um sich ganz auf die Einhaltung des Termins konzentrieren zu können. Somit hilft die Zielprioritätenmatrix einen schnellen Überblick über die Ziele zu bekommen, die dem Projektteam am wichtigsten sind.

Attach:=Zielprioritätenmatrix.png Δ

UML

UML (Unified Modeling Language) ist eine graphische Modellierungssprache die oft verwendet wird zur Spezifikation, Konstruktion und Dokumentation von Softwareteilen und anderen Systemen. Im Sinne einer Sprache definiert UML dabei Bezeichner für die meisten bei einer Modellierung wichtigen Begriffe und legt mögliche Beziehungen zwischen diesen Begriffen fest. Ein häufig verwendetes Modell sind Use-Cases.

Sie beschrieben, dass gewünschte Externe Verhalten eines Systems aus Sicht des Anwenders. Use-Cases werden dabei vor allem in der Softwareentwicklung eingesetzt. Es gibt allerdings auch Business-Use-Cases mit denen auch allgemeine geschäftliche Abläufe dargestellt werden. Da sie aus der Sicht des Anwenders geschrieben sind, sind sie leicht zu verstehen. Sie umfassen allerdings keine detaillierte Beschreibung eines Prozesses.

Über Anwendungsfalldiagramme wird das Themengebiet grob geteilt. Ein Beispiel wäre die entwicklung einer Software für einen Geldautomaten.[3]  Die erste Handlung des Anwenders wäre das Einführen der Magnetkarte. Dies ist jedoch nicht die eigentliche Essenz der Aktivität. Die Bank möchte eine Möglichkeit, wie Kunden schnell und sicher an ihr Geld kommen können. Heute ist dies über eine Magnetkarte gewährleistet in ein paar Jahren vielleicht über Stimmenerkennung. Worauf es ankommt: es muss eine Möglichkeit da sein, den Anwender zu identifizieren. Der eigentliche Kern der Aktivität wäre damit die Identifizierung des Kunden.
Sind alle Aktivitäten auf ihre Essenzen reduziert, sofern dies möglich ist, gestaltet sich das Anwendungsfalldiagramm wesentlich übersichtlicher. Die Details können später über Use-Case-Spezifikationen noch näher erläutert werden.

Die Vorteile eines Use-Case ist, dass es recht leicht zu verstehen ist, da es aus Anwendersicht geschrieben wird. Für Funktionale Anforderungen, lässt sich hier vorab eine gute Grundstruktur finden. An seine Grenzen stößt es hingegen bei nicht-funktionalen Anforderungen sowie bei sehr komplexen Systemen. Oft reicht ein Use-Case nicht aus, sodass mehrere erstellt werden müssen. Das Problem hierbei ist, dass es dazu kommen kann, dass man zu viele oder zu wenige hat bzw. man zu wenig auf die Kernessenz reduziert oder zu viel. Die richtige Mischung aus beiden ist hier der effizienteste Weg. Es ist jedoch oft nicht leicht zu erkennen, wie dieser in der jeweiligen Situation aussieht. [4] 

Use-CaseDiagramm-Multimediasystem [5] 

Lasten- und Pflichtenheft

Das Lastenheft enthält alle Anforderungen, die der Kunde an den Auftragnehmer stellt. Aus diesen Anforderungen erstellt der Auftragnehmer dann sein Pflichtenheft, indem er festlegt und beschreibt, wie die vom Kunden geforderten Anforderungen umgesetzt werden sollen. In ihm sind dann auch sämtliche Spielregeln enthalten, an die sich der Auftragnehmer halten muss. Dies kann ebenfalls bei der Strukturierung der Anforderungen hinzugezogen werden. Das bedeutet, man Strukturiert die Anforderungen so, wie man das Pflichtenheft strukturiert hat. Das bedeutet, wenn Anfangs beim Entwickeln eines Handys das Display behandelt wurde, dann sind die Anforderungen die das Display betreffen auch an erster Stelle der Anforderungen. Zum erstmaligen Sammeln und als erster Entwurf eines Pflichtenheftes kann zudem eine Mind-Map erstellt werden, aus der dann später das endgültige Pflichtenheft abgeleitet werden kann.

Lastenheft

Zusammenfassend lässt sich sagen, dass es keine feste Regel gibt, welche der genannten Methoden für ein Projekt angewendet werden sollen. Die Auswahl der Methode sollte immer anhand des Projektes geschehen. Es muss bei der Auswahl berücksichtigt werden, dass Anforderungsstrukturierung, wie auch das gesamte RE je nach der vorhandenen Komplexität sehr kostenintensiv werden kann. Ist das nötige Know-how der Methoden jedoch vorhanden und findet man für das anstehende Projekt die passende Mischung erhöht eine gute Anforderungsstrukturierung die Erfolgschancen des gesamten Projektes.

 

Quellennachweise

1.  vgl. Chris Rupp:Requirements- Engineering und -Management, München Wien 2004, Carl Hanser Verlag,(S.115-130) [↑]

2.  vgl. Chris Rupp:Requirements- Engineering und -Management, München Wien 2004, Carl hanser Verlag,(S.139-152) [↑]

3.  vgl. Chris Rupp:Requirements- Engineering und -Management, München Wien 2004, Carl Hanser Verlag,(S.162) [↑]

4.  vgl. Chris Rupp: Requirements-Engineering und -Management, München Wien 2004, Carl Hanser Verlag,(S.161-166) [↑]

5.  vgl. http://de.wikipedia.org/wiki/Anwendungsfalldiagramm Autor:Gubaer stand:20:06.2012 [↑]