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

Ich hatte lange überlegt, mit welchem Thema ich in der Kategorie Fundamentals einen Blog starten sollte. Da fiel mir ein Requirements Workshop ein, den wir Anfang diesen Jahres in unserer RE-Abteilung durchgeführt hatten. Dabei war mir aufgefallen, dass jeder unserer 12 Requirement Ingenieure eine unterschiedliche Herangehensweise zur Erstellung von Anforderungen hatte. Das gab mir zu denken, denn trotz aller RE-Prozessvorgaben und BU-internen Methodiken und Regularien konnte sich dennoch nicht ein gemeinsames Vorgehen etablieren. Was konnte die Ursache dafür sein? Nun, es sind zum einen der unterschiedliche Kenntnisstand und Level der Erfahrung der Requirement Ingenieure und natürlich die spezifischen Besonderheiten eines jeden Projektes.  Kann man also gar keine Gemeinsamkeiten  zur “richtigen” Heransgehensweise für die Arbeit eines RE finden? Doch, man kann! Als wichtig erachte ich hier die gemeinsamen Grundlagen, welche für ein praktisches Requirement Engineering von jedem RE verinnerlicht werden sollten.

In der folgenden Serie von 10 Artikeln werde ich nochmals die Grundlagen des System- und Requirement Engineering erläutern.  Als Material werde ich erarbeitete Unterlagen zum genannten Requirement Workshop heranziehen und entsprechende Praxis-erfahrungen mit einfließen lassen. Desweiteren werde ich an passender Stelle erlerntes Wissen aus dem Workshop zur Erlangung des “CPRE” Zertifikates zusammenfassend hinzufügen. (Bezüglich des CPRE Zertifikats siehe dazu weitere Informationen unter der Website der SOPHISTen)

Practical Requirement Engineering – Übersicht der Artikel

Jede Woche werde ich ein konkretes Thema aufgreifen und einen Artikel der der folgenden Themengebiete veröffentlichen:

• Die Disziplin des Requirement Engineering, seine grundsätzliche Klassifizierung von Requirement Engineering Aktivitäten und die Beziehung des RE/RM zum Projektmanagement sowie zur Software und Hardware Entwicklung (zum Artikel…)
   
• Das Erkennen des Requirement Typs und seine korrekte Verwendung bezogen auf den System- und SW-Requirement Engineering Prozesses mittels eines praktischen Ansatzes (zum Artikel…)
   
• Das Schreiben, Systematisieren und Dokumentieren von Anforderungen durch entsprechende Klassifizierung von Anforderungen hinsichtlich ihrer Perspektive und  Anforderungsebenen (Levels) (zum Artikel…) 
  1. User-Perspective (Use Cases)
  2. System-Perspective (Functional Behavior)
  3. Structure Perspective (Static Description)
      
• Eine Gegenüberstellung von textueller und grafischer Notation von Anforderungen hinsichtlich ihrer Einsatzgrenzen sowie eine praktische Einführung in die Modellierung von Anforderungen (zum Artikel…)
   
• Die Kriterien guter Anforderungen, eine Einführung des “Sentence Pattern Approach” sowie eine Übersicht zur Einteilung der Verbindlichkeit von Anforderungen und entsprechend ihre Kennzeichnung (zum Artikel…)
   
• Writing Styles von Anforderungen mit einer Gegenüberstellung von “Good” and Bad” Requirements, praktischen Beispielen aus der Automotive Welt sowie eine Übersicht der Don’ts and Do’s beim Schreiben von Anforderungen (zum Artikel…)
   
• Das Erstellen einer geeigneten Dokumentenstruktur – Anforderungen an die Struktur von System Anforderungen, Architektur Anforderungen sowie Software und Hardware Anforderungen (zum Artikel…)
   
• Gutes Requirement Management durch eine geeignete Kategorisierung, Priorisierung und Verfolgung von Anforderungen mittels der Definition einer geeigneten Attributisierung von Anforderungen – Was is mindestens nötig? (zum Artikel…)
   
• Die Verifikation und Validierung von Anforderungen durch Verwendung von Test-Leveln sowie Methoden zur Verifikation und Validierung. Welcher Review past? – Eine Gegenüberstellung. (zum Artikel…)
   
• Die Anwendung von Prozess Modellen (V-Modell vs. agile Methoden, SPICE und CMMI), die Qualitskriterien der System und SW Analyse und ihre Traceability sowie ein Ansatz zur Aufwandsabschätzung des RE+RM (zum Artikel…)

Zum Abschluss möchte ich noch allen Lesern eine Grafik ans Herz legen, welche eine Übersicht über alle oben genannte Aspekte aufzeigt und schon mal eine gute Übersicht bietet. ProfessionalRequirementEngineeringOverview.pdf

Bis zum nächsten Parity Weblog…
Enrico Seidel

Copyright Hinweis:
Alle in den folgenden Artikeln vorgestellten Unterlagen unterliegen dem Urheberrecht. Eine Verwendung außerhalb der Grenzen ist ohne schriftlicher Zustimmung des Autors unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigung, Übersetzungen sowie Einspeichern und Verarbeiten in elektronischen Systemen.

English:
Hello world! Today the blog “The Parity Weblog” is online with topics related to requirements engineering. There will be each week from today on (updated Sundays always) article and updates following. Stop by occasionally and get informed about news from the world of Requirement and System Engineering…

Chears
Enrico Seidel

• Requirement Engineering & Management
• Configuration & Version Management
• Change & Release Controlling
• Project & Portfolio Management

Dazu wird eine Client–Server Lösung auf der Basis einer hochskalierbaren objekt-orientierten Datenbankstruktur entstehen, mit der die starke Vernetzung (Verlinkung) der oben genannten  Arbeitsdisziplinen und -artefakte performant gelöst werden kann.

Zielgruppe für diese Softwarelösungen sind vor allem projektbezogene Entwicklungs-abteilungen und Institutionen der Industrie in den Bereichen Automotive, Luftfahrt und Prozesstechnik.

Auf der Smart Service Collaboration Platform werden vier Basisprodukte entstehen, welche einzeln oder auch gemeinsam den kompletten technischen Engineering-Prozess auf einer gemeinsamen Platform instrumentieren können.  Weitere Produkte die auf den SSCP aufsetzen werden,  sind strategisch geplant.

Nur so viel sei schon verraten: Die Smart Service Collaboration Platform entsteht unter Benutzung modernster Software Technologien wie WPF, WCF, NoSQL etc.  auf der dotNet Plattform aufsetzend und zu 100% entwickelt in C#.

In den demnächst folgenden Blogs werden wir kontinuierlich über den Entwicklungsstand und weitere Fortschritte berichten. Sie können gespannt sein, denn wir werden mit Sicherheit hier Staub aufwirbeln…

English Version:
Beginning this year, a Smart Service Collaboration Platform (SSCP) has been started for development, which has as its goal to unite the following disciplines within a work and development platform:

• Requirement Engineering & Management
• Configuration & Version Management
• Change & Release Controlling
• Project & Portfolio Management

Therefore a Client-Server solution based on a highly scalable, object-oriented database structure has been developed to solve the strong cross-referencing (linking) of the above work disciplines and artifacts. The utilized database will strongly support to solve complex tasks and structures with best performance. As a target group for these software solutions we are focusing the use in project-based development institutions and departments of the industry in the fields automotive, aerospace and process systems.

On the Smart Service Collaboration Platform we will have 4 basic products, which separately or together can be used to orchestrate the whole engineering process on only one common platform. Further products that are setup on the SSCP are strategically planned.

Only so much is already revealed: The Smart Service Collaboration Platform is produced on the platform for dotNet using the latest software technologies such as WPF, WCF  and a NoSQL database, developed 100% in C#. 

With the next blogs we will continuously report on the state of development and progress. You may be curious, because we will certainly kick up dust here …

Keep on track…