|
In meinem zweiten Beitrag "Ein Kundenauftrag muss richtig verstanden werden" hatte ich die sechs Phasen des fundamentalen Requirements Engineering Prozesses vorgestellt (REP). In diesem Zusammenhang wurden auch verschiedene Requirements-Ermittlungstechniken erwähnt.
Wir wollen uns jetzt der ersten Phase des fundamentalen REP widmen und gehen schrittweise zur Erstellung eines Dokuments "Anforderungsspezifikation" über – dem finalen Ergebnis der Requirements-Ermittlung. Es wird auch der Begriff "Pflichtenheft" verwendet.
Informationsquellen für die Requirements identifizieren
Sie erinnern sich bestimmt an die grafische Darstellung des fundamentalen REP aus meinem zweiten Beitrag, die sowohl die Chronologie einzelner Phasen, als auch ihre Rückkopplungen übersichtlich darstellt. Wir werden immer wieder auf die Zusammenhänge einzelner Phasen zurückkommen. Die erste Phase befasst sich mit der Identifikation der Informationsquellen für die Requirements (Anforderungen).
Die wichtigsten drei Informationsquellen, die identifiziert werden müssen, sind:
@ Stakeholder (Interessengruppen) – die wichtigste Informationsquelle für den REP
@ Unterlagen und Dokumentationen – diese sind idealerweise in der eigenen technischen Dokumentation vorhanden
@ Produktive Systeme (aber auch Altsysteme), die als Orakel dienen
Stakeholder sind auf die eine oder die andere Art in den Prozess des Requirements Engineering involviert und üben auf ihn durch ihre Wünsche und Bedürfnisse einen wesentlichen Einfluss aus. Dazu gehören Auftraggeber, Entwickler, Endbenutzer, Softwaretester, Softwarearchitekten, Datawarehouse-Spezialisten etc.
Zwischen den Stakeholdern, ihren Wünschen und Bedürfnissen gibt es große Unterschiede, die sich auf die Ermittlung der Requirements bedeutend auswirken. In der Einleitung des ersten Kapitels Requirements Engineering wurden bereits Interessenskonflikte erwähnt und das Erfordernis, diese durch die Vermittlung von Requirements Engineering konstruktiv zu lösen.
Der Auftraggeber als Informationsquelle formuliert in einem ersten Schritt sein Bedürfnis nach dem System in eigenen Worten. Durch die gezielte Fragestellung seitens Projektleitung, Requirements Engineer, Entwickler und idealerweise auch Softwaretester, werden die Anforderungen ermittelt und vervollständigt. Die Prozesse werden nachvollzogen und User Cases durchgespielt; so wird die Anforderungsspezifikation inkrementell aufgebaut und immer weiter ergänzt bis zur Vervollständigung. Die fertiggestellte Anforderungsspezifikation wird sowohl durch Auftraggeber als auch durch den Requirements Engineer, Softwaretester und Entwickler validiert.
Die Unterlagen und Benutzerhandbücher der Systeme (alt und neu) wie auch Normen, Standards, Gesetzestexte, Organisationshandbücher etc. können eine gute Informationsquelle darstellen. Die Systeme in der produktiven Umgebung, ob alt oder neu, sind genauso eine wertvolle Informationsquelle.
Tipp aus der Praxis! Die alte gute Checkliste aller Stakeholder hilft enorm! Diese sollte nicht erst mit der Ermittlung der Anforderungen begonnen werden, sondern bereits bei der Identifizierung der Infoquellen erstellt werden! Spätestens zu diesem Zeitpunkt sollte sie vollständig sein. Dabei kann für die Checklistenerstellung die Topdown-Methode angewendet werden; es wird bei der Identifizierung der Stakeholder ganz oben beim Topmanagement begonnen bis hin zu den untersten Organisationsebenen. Sollte es passieren, dass viel zu viele Stakeholder identifiziert wurden, empfiehlt sich eine Selektion und eine Priorisierung nach dem Wichtigkeitsgrad. Dabei sollte unbedingt darauf geachtet werden, dass die Selektion nicht auf die Personen gerichtet wird, sondern auf die Funktionalität selbst.
Die Praxis hat unzählige Male gezeigt, dass der schlimmste Fehler immer wieder passiert: Es werden nämlich bewusst manche Stakeholder viel zu leichtsinnig ausgeschlossen. Selbst wenn die von ihnen angeforderten Funktionalitäten weniger relevant sind, müssen diese Stakeholder unbedingt in das Projekt involviert werden. Glauben Sie mir, das erspart viel Geld, Mühe, Diskussionen, Nerven und sogar latente (versteckte) raffinierte Sabotageakte!
Zwischen dem Requirements Engineer und den einzelnen Stakeholdern sollte ein freundschaftliches Verhältnis aufgebaut werden, um eine produktive Beziehung entstehen zu lassen, was unter Umständen schwierig sein kann. Die Frage, die sich hier stellt und gleichzeitig die größte Hürde darstellt: "Wie wichtig sieht sich der einzelne Stakeholder?" Der Requirements Engineer hat es nicht leicht, sich in jedes Fachgebiet einarbeiten zu müssen, um dieses verständlich zu dokumentieren und den Stakeholdern zu präsentieren.
Nachdem wir in meinem zweiten Beitrag verschiedene Ermittlungstechniken für Requirements kennengelernt haben, wollen wir bereits hier die Qualität der Anforderungsspezifikation erwähnen und ihre direkte Abhängigkeit von den qualitativen Informationsquellen. Das Dokument "Anforderungsspezifikation" ist eine Zusammenfassung aller einzelnen Anforderungen.
Lesen Sie auch den ersten Beitrag von Mag. Anja Kribernegg "Am Anfang gibt es einen Kundenauftrag".
Anforderungsspezifikationen sollen nach dem Standard IEEE 830 folgende Qualitätsmerkmale aufweisen:
"@ Korrektheit – Correctness of Requirements: Die einzelnen Anforderungen beschreiben adäquat jene funktionale und nichtfunktionale Eigenschaften der Software, die der Kunde braucht.
@ Eindeutigkeit – Unambiguity of Requirements: Eine Anforderungsspezifikation darf nicht mehrfach interpretierbar sein, sonst wissen die Entwickler nicht, wie sie diese verstehen sollen. Eine subjektive Interpretation wäre die Folge, die aber oft eine Fehlinterpretation ist und unbedingt zu vermeiden ist.
@ Vollständigkeit – Completeness of Requirements: Eine Anforderungsspezifikation ist vollständig, wenn sie alle Kundenwünsche und Bedürfnisse betreffend der zu entwickelnden Software beinhaltet.
@ Konsistenz bzw. Widerspruchsfreiheit – Consistency of Requirements: Damit eine Anforderungsspezifikation korrekt realisiert werden kann, darf sie keine Widersprüche beinhalten.
@ Priorisierung – Priority of Requirements: Die einzelnen Anforderungen werden priorisiert, das heißt, nach Wichtigkeit bzw. Stabilität angeordnet (gewichtet).
@ Verifizierbarkeit bzw. Prüfbarkeit – Verifiability of Requirements: Die einzelnen Anforderungen sollen verifizierbar sein. Es wird geprüft, ob diese richtig funktionieren bzw. ihre gewünschten Eigenschaften richtig implementiert wurden.
@ Änderbarkeit – Changeability of Requirements: Es soll möglich sein, die einzelnen Anforderungen ändern zu können, sollte dies erforderlich werden, ohne dass das Dokument "Anforderungsspezifikation" zur Gänze neu geschrieben werden muss.
@ Verfolgbarkeit – Traceability of Requirements: Zwischen den einzelnen Anforderungen und den dazugehörigen Testfällen muss es eine Rückkopplung geben, um nachvollziehen zu können, welche Testfälle welche Anforderungen abdecken."
(Quelle: Standard IEEE 830)
© "Der fundamentale Requirements Engineering Prozess": Textbeitrag von Mag. Anja Kribernegg, Wien. Die Autorin war lange in der IT-Branche im Finanzsektor tätig. Softwareentwicklung und -testen sind ihre Hauptgebiete. Bildnachweis: Internet (Illustration), CC0 (Public Domain Lizenz).
Archive:
Jahrgänge:
2022 |
2021 |
2020 |
2019 |
2018 |
2017 |
2016 |
2015 |
2014 |
2013 |
2012 |
2011 |
2010 |
2009
Themen:
Rezensionen |
Krimi Thriller |
Ratgeber |
Sagen Legenden |
Fantasy Mythologie
Noch mehr Bücher lesen (Werbung):
Fantasy & Science Fiction
| Krimis & Thriller
| Ratgeber
| Reise & Abenteuer
Sie schreiben anspruchsvolle Romane und Erzählungen? Wir suchen neue Autorinnen und Autoren. Melden Sie sich!
Wenn Sie die Informationen auf diesen Seiten interessant fanden, freuen wir uns über einen Förderbeitrag. Empfehlen Sie uns auch gerne in Ihren Netzwerken. Herzlichen Dank!
Sitemap Impressum Datenschutz RSS Feed