Im ersten Teil des Artikels der Artikelserie “Requirement Fundamentals” möchte ich nochmal grundsätzlich auf einige Begriffe und Definitionen eingehen, die im weiteren verwendet werden. Im zweiten Teil dieses Artikels sollen nochmals die Hauptaktivitäten des Requirment Engineerings und Managements zusammengetragen werden. Des weiteren sollen im 3. Teil die Beziehung der Rolle eines RE/RM zum Projektmanagement sowie zur Software und Hardware Entwicklung erläutert werden.
Grundsätzlich gibt es einmal die Bereiche des “Requirement Managements” ( RM) und des “Requirement Engineerings” (RE). Was beinhalten die 2 Disziplinen nun?
Begriffe und Definitionen
1. Eine Gegenüberstellung des RE und des RM
Oft wird viel diskutiert, ob nun das Requirement Management ein Teilgebiet des Requirement Engineering ist oder umgekehrt. Ich denke eine Unterordnung der einen oder der anderen Disziplin jeweils ist zweitrangig. Wichtig ist, das beide Disziplinen gleichwertig in Ihrer Priorität behandelt werden müssen. Vielmehr ist der Unterschied in der Bezeichnung das Tätigkeitsfeld der entstsprechenden Person in seiner Rolle eben als Requirement Manager oder als Requirement Engineer. Oft bedient sogar bei kleinen bis mittleren Projekten ein und die selbe Person beide Rollen. Bei größeren Systemen, die entwicklet werden sollen, kann eine Person dann beide Rollen nicht mehr übernehmen, ja selbst für das Requirement Engineering müssen dann unter Umständen weitere Personen jeweils für ein Teil- oder Subsystem die entsprechnede RE Rolle übernehmen. Doch dazu mehr in einem der folgenden Artikel.
2. Die Disziplin des Requirement Management
Im deutschen Sprachgebrauch wird das Requirement Management auch als “Anforderungesmanagement” bezeichnet. Das RM ist ein Teilgebiet der Business-Analyse bzw. eine Teilaufgabe der Verwaltung von vorhandenen Anforderungen eines oder mehrerer Stakeholder für die effiziente und fehlerarme Entwicklung komplexer Systeme.
Die Anforderungsverwaltung beinhaltet Maßnahmen zur Steuerung und Kontrolle der erhobenen Anforderungen. Ebenfalls ist das Änderungsmanagement also das Überwachen von sich ändernden Anforderungen ein weiteres Teilgebiet des RM. Die gefundenen Anforderungen müssen natürlich in den System umgesetzt also implementiert werden. Entsprechend ist ein Umsetzumgsmanagement also eine Überwachung der Realisierung von Anforderungen eine weitere Teilaufgabe. Die Aufgabe des Reguirement Managers trägt den Erkenntnissen aus der Vergangenheit Rechnung, dass Probleme mit Anforderungen meistens aus mangelndem Management eben dieser resultieren. Es ist zu beachten, dass alleine das Aufstellen von Anforderungen nicht genügt, sondern für die Realisierung eines Produktes oder Systems der Prozess eines Anforderungsmanagements benötigt wird. Das Anforderungsmanagement dient also auch dazu vorhandene Anforderungen zu priorisieren, welches als eine Teilaufgabe des Risikomanagments gesehen werden kann.
In einem technischen System und seiner Subsysteme gibt es eine Vielzahl von Anforderungen und Randbedingungen zur Umsetzung von Anforderungen. Anforderungen beziehen sich auch immer auf einen bestimmten Aspekt also z.B. auf das System (Systemanforderungen) oder auf die Softwarefunktionen (Softwareanforderungen). Selbst Aspekte der mechanischen und elektischen Beschaffenheit müssen oft mit einfließen (Hardwareanforderungen). Da diese Anforderungen sich auf auf verschiedenen Ebenen einer Umsetzung befinden ist es oft der Fall, dass sich z.B. Softwareanforderungen von Systemanforderungen ableiten. Da viele Anforderungen unterienander in einer Beziehung stehen müssen diese mittels eines Rückverfolgbarkeitsmanagement verwaltet werden. Auch Testfälle, die Anforderungen validieren, müssen dann in die Rückverfolgbarkeit (Traceability) mit eingeschlossen werden. Eine Klassifizierung von Anforderungen als solche sowie die Zuordnung einer entsprechenden Bearbeitungs- oder Ableitungsebene wird des weiteren durch eine Anforderungsattributierung erreicht.
Zusammenfassend ist das Ziel des Anforderungsmanagement ein gemeinsames Verständnis über ein zu entwickelndes System zwischen Auftragnehmer und Auftraggeber zu jeder Zeit der Projektphasen. Es müssen also wie oben angegeben Prozesse definiert und implementiert werden, die während des gesamten Projektverlaufs eine konsistente gemeinsame Grundlage von schriftlichen Dokumenten und Unterlagen sicherstellen. Dazu sind zusammenfassend folgende Prozesse des RM sicherzustellen:
- Requirement Change Management (Änderungsmanagement)
- Requirement Realization Management (Realisierungsmanagement)
- Requirement Priorizitation (Risikomanagement)
- Requirement Attributization (Anforderungsattributierung)
- Requirement Traceability Managemernt (Rückverfolgbarkeitsmanagement)
3. Die Disziplin des Requirement Engineering
Im deutschen Sprachgebrauch wird das Requirement Engineering auch als “Anforderungserhebung” bzw, auch als “Anforderungsdefinition” bezeichnet. Das RE ist ein Teilgebiet der Business-Analyse bzw. eine Teilaufgabe der schriftlichen Erstellung von gewünschtem funktionalen Verhalten eines Systems oder einer Software durch oder für einen oder mehrerer Stakeholder. Zu den Zielen des RE gehört, dass ein gemeinsames Verständnis über ein zu entwickelndes System zwischen Auftragnehmer und Auftraggeber zu erreichen ist. Entsprechend reicht eben nicht nur eine mündliche Vereinbarung von Anforderungen sonderen als vertragliche Basis für eine korrekte Umsetzung ist eben eine schriftliche Dokumentation von Anforderungen erforderlich. Ziel einer Anforderungsspezifikation (u. a. Lastenheft, Pflichtenheft, Fachkonzept, …) ist es immer, die Anforderungen so zu formulieren, dass zwischen dem Auftraggeber (Stakeholder) und Auftragnehmer (Supplier) ein gemeinsames Verständnis über das zu entwickelnde System geschaffen wird. Es müssen durch den Stakeholder entsprechend als erstes Anforderungen erhoben werden (Elicitation), die dann durch den Supplier hinsichtlich der Realisierbarkeit einer Anforderungsanalyse unterzogen werden müssen. Durch den Supplier müssen desweiteren diese Anforderungen weiter granularisiert bzw. verfeinert werden so dass durch die entwickelnden Disziplinen eine Realisierung ermöglicht wird. Aufgabe ist es also durch ein Herunterbrechen der Anforderungen auf die entsprechenden Disziplinen der Entwicklung (Software- und/oder Hardwareentwicklung) eine Abgrenzung der Anforderungen für die entsprechenden Bereiche vorzunehmen, da nicht jede Disziplin im vollen Umfang alle Anforderungen erfassen und bewerten kann. Um das bei natürlicher Sprache zu erreichen, sollten Regeln in der Dokumentation eingehalten werden. Dazu werde ich später einen eigenen Artikel verfassen. Ein Autor einer Spezifikation also der Requirement Engineer sollte sich an diese Regeln halten, um die Qualität der Anforderungen zu verbessern. Entsprechend gibt es dazu am Markt Requirement Engineering Werkzeuge (z.B: DOORS von IBM) die den Author dabei unterstützen können. Zur Anforderungsdefinition gehören weiterhin Qualitätskriterien wie Eindeutigkeit, Verständlichkeit, Widerspruchsfreiheit, Vollständigkeit, Nachweisbarkeit und Testbarkeit. Nur anforderungen die im Verständniss korrekt bzw. gültig sind können auch validiert werden. Entsprechend muss eine Überprüfung der Anforderungen hinsichtlich der Korrekthheit durchgeführt werden (Verification).
Zum Requirement Engineering gehört aber nicht nur die Anforderungsdefinition, sondern es müssen parallel dazu Kriterien beschrieben werden, wie diese Eigenschaften (Akzeptanzkriterien) überprüft werden können. Dies wird durch eine Anforderungsvalidierung (Requirements Validation) erreicht. Diese oft auch als Testfälle bezeichneten Kriterien dienen nicht nur der Qualitätssicherung des Produktes, sondern tragen ganz wesentlich zur Qualität der Anforderungen selbst bei, da das Beistellen eines Akzeptanzkriteriums zu einer sofortigen inhaltlichen Überprüfung der Anforderung zwingt. Es ist dabei zu beachten, dass das Formulieren eines Akzeptanzkriteriums (Testfalls) immer durch eine weitere Person also nicht durch den Author der Anforderung erfolgen sollte.
Zusammenfassend ist das Ziel der Anforderungserhebung und -definition ein gemeinsames Verständnis über ein zu entwickelndes System zwischen Auftragnehmer und Auftraggeber durch eine schriftliche Dokumentation von Anforderungen. Dazu sind zusammenfassend folgende Kriterien des RE zu berücksichtigen:
- Requirement Elicitation (Anforderungserhebung)
- Requirement Analysis (Anforderungsanalyse hinsichtlich Realisierbarkeit)
- Requirement Documentation (Anforderungsdokumentation)
- Requirement Verification (Überprüfung der Korrektheit der Anforderungen)
- Requirement Validation (Definition von Akzeptanzkriterien)
Anzumerken sei noch, dass das Anforderungsmanagement zu den elementaren Prozessen der Software- und System-Reifegrad-Modelle CMMI und ISO/IEC 15504 (SPICE) sowie zum Standard “ISO/IEC 12207″ ISO/IEC 12207 gehört.
Hauptaktivitäten des RE und RM
Rolle des RE/RM in der HW+SW Entwicklung
In meiner bisherigen Erfahrung wird in aktuellen Projekten dem Requirement Engineering und Requirement Management nicht die Wichtigkeit zugeschrieben, die für eine erfolgreiche Umsetzung eines Projektes benötigt wird. Oft wird die Rolle des Requirement Managers”nebenbei” durch einen System- oder Softwareverantwortlichen oder schlimmer noch durch einen Projektleiter übernommen. Damit konkurieren automatisch die unterschiedlichen Rollen, wenn diese einer Person zugeordnet werden. Auch habe ich oft erlebt, dass die Anforderungen durch den Entwickler geschrieben werden. Was dabei rauskommt sind in den meisten Fällen Produktbeschreibungen, wie bestimmte Funktionen in der Software umgesetzt wurden. Oft konkurieren hier wieder ebenfalls die Rolle des Entwicklers und die Rolle des Requirement Engineers. Was bei einem engen Terminplan der Realisierung als Dokumentation von Anforderungen herauskommt, kann sich jetzt jeder ausmalen. Zuerst wird die Software umgesetzt und dann wird nachdokumentiert. Das hat nichts mehr mit einem Requirement Engineering zu tun, von einer qualitativ hochwertigen Umsetzung des Projektes ganz zu schweigen. In einem Projekt ist eine klare Rollenverteilung essentiell wichtig, um konkurierende Prozesse innerhalb einer Person welche die Rollen beinhalten zu vermeiden.
Der Requirement Manager und Requirement Engineer bildet im Umfeld der Anforderungen an das Produkt oder Systems das Interface zum Stakeholder, genauso wie der Projektmanager im kommerziellen Umfeld sowie der Technische Projektleiter im Umfeld der technischen Planung das Interface zum Kunden hält. Entsprechnd sollten alle 3 Rollen kurze Kommunikationswege haben also im besten Fall sollte der Requirement Engineer/Manager Projektleiter und Projektmanager sich “gegenübersitzen”. Der Requirement Engineer/Manager definiert die Anforderungen also das “WAS” und der Architekt bzw. Entwickler definiert anhand der Anforderung die Realisierung dieser also das “WIE”.
Zusammenfassend sind folgende wichtig Punkte für eine erfolgreiche Projektdurchführung zu beachten:
- Definition der Rolle des Requirement Engineer/Manager im Umfeld der System- und Softwareentwicklung
- Definition der Rolle des RE/RM im Umeld des Projektmanagements sowie Definition der anteiligen Arbeitsaufgaben eins Projektleiters im Requirement Engineering and Management Process
- Abgrenzung des RE/RM von der eigentlichen Entwicklung also der Realisierung des Produktes bzw. der Software zur Vermeidung der Rollenkonkurenz