|
In meinem ersten Beitrag "Am Anfang gibt es einen Kundenauftrag" wurde der Beruf des Requirements Engineers in den Mittelpunkt gesetzt.
Es wurde über die erforderlichen Fähigkeiten und Fertigkeiten gesprochen, die einen guten Requirements Engineer bzw. Engineerin ausmachen. Wir begannen unseren gemeinsamen Weg in die Welt des Requirements Engineering mit der Formulierung der Anforderungen und der Erstellung einer Anforderungsspezifikation (auch Pflichtenheft genannt).
Setzen wir unseren Weg mit der Definition einer Anforderung fort. Es war mir schon immer ein Anliegen, die Verwendung der Standarddefinitionen nach ISTQB und IREB voranzutreiben, damit alle Beteiligten halbwegs das Gleiche unter einem Begriff verstehen und, um zu vermeiden, dass jeder die Begriffe nach eigenem Ermessen verwendet, wodurch bei der Ermittlung der Anforderungen gewaltige Kommunikationsprobleme entstehen können.
Der Standard IEEE 610 definiert ein Requirement bzw. eine Anforderung als "eine vom Benutzer benötigte Eigenschaft oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, einen Standard, eine Spezifikation oder ein anderes formales Dokument zu erfüllen." (1)
"Wir könnten die Auseinandersetzung mit der Thematik Requirements Engineering mit dem folgenden Satz einleiten: "Es lag ein Projektauftrag vor. Wir haben ein Meeting zum Projektstart mit den IT-Experten, Fachexperten, dem Auftraggeber und dem Management einberufen, es kamen aber die Menschen!" Da wir alle tatsächlich nur Menschen sind, weisen wir sowohl die Stärken als auch die Schwächen auf, die sich insbesondere in dieser sensiblen Aufgabe widerspiegeln." (2)
Die Anforderungsphase geht einem Softwareentwicklungsprojekt voraus und stellt sozusagen den ersten Schritt, der unabdingbar ist, damit ein Projekt aufgesetzt werden kann. Unter der Anforderungsphase wird standardmäßig "eine Phase im Softwarelebenszyklus verstanden, in der die Anforderungen eines Softwareprodukts ermittelt, definiert und dokumentiert werden". (3)
Requirements Engineering kann als Anforderungstechnik definiert werden. Es wird systematisch und quantitativ vorgegangen, um die Kundenbedürfnisse zu verstehen, zu beschreiben und zu verwalten. Das heißt, wir verwenden die Anforderungstechnik, um die Kundenwünsche möglichst genau zu ermitteln.
Bevor ich Ihnen verschiedene Ermittlungstechniken vorstelle, möchte ich durch praktische Beispiele auf zwei Probleme aufmerksam machen:
1. Probleme bei der Zusammenfassung aller Anforderungen in eine Anforderungsspezifikation
2. Probleme bei der Abstimmung der Anforderungen
Tipp aus der Praxis! Angst vor großen Dokumenten: Ich staunte nicht schlecht, als ich in einem IT-Projekt für die Entwicklung eines neuen Produkts in einer Bankzentrale mit diesem Problem konfrontiert wurde. Ich gebe zu, es hat ein wenig gedauert, bis mein Gehirn bereit war, diese Tatsache wahrzunehmen und zu verarbeiten. Danach konnte ich anfangen, über die Lösungsvorschläge nachzugrübeln. In der IT-Branche ist eine Anforderungsspezifikation (Business Requirements) nun mal ein umfangreiches Dokument, das durchaus zersplittert werden kann, wodurch aber schon die Gefahr der Inkonsistenz entsteht. Das heißt, wird eine Anforderungsspezifikation partiell von verschiedenen Experten erstellt (was sinnvoll sein kann), muss gleichzeitig für die Aktualisierung gesorgt werden, damit alle Projektmitglieder über den gleichen Stand der Informationen verfügen: besser gesagt, über eine gemeinsame Informationsquelle, die immer am neusten Stand ist und sich jeder danach richten kann.
In meinem Fall lehnte der betreffende Business Analyst alle meine Vorschläge, sich lediglich in der Anforderungsspezifikation um sein Kapitel zu kümmern, kategorisch ab. Ich scheiterte kläglich, indem ich zu erklären versuchte, dass ich zwar keine Angst vor langen Dokumenten habe, dennoch nicht immer alles durchlese (zeitabhängig), sondern mich auf den mir zugewiesenen Geschäftsbereich kümmere und die einzelnen Requirements ermittle. Fachlich fühle ich mich sicherer, weil ich weiß, dass ich auf die aktuellste Informationsquelle zugreife wie meine Kolleginnen und dadurch die peinlichen und kostspieligen Inkonsistenzen vermeide. Reaktion: Finsterer Blick von dem korpulenten Kollegen und roter Kopf sagten mehr als tausend Worte, obwohl er sich auch verbal kaum zurückhielt, um seine Ängste und sein Ärgernis zu demonstrieren.
Tipp aus der Praxis! Trotz des geschilderten Szenarios, sollte bedacht werden, wie viel Zeit und Geld die detaillierten Abstimmungen in Anspruch nehmen. Die Abstimmungsfrequenz ist in so einer Situation eine viel höhere, als die üblichen Abstimmungen der Zwischenergebnisse und beansprucht somit die Ressourcen, die anderweitig sinnvoller genutzt werden könnten. Steht kein Anforderungs-Managementtool zur Verfügung, kann im Intranet problemlos ein Ordner für die Anforderungsspezifikation angelegt werden, auf den alle Projektmitglieder gleichzeitig zugreifen und arbeiten können. Jeder kann sich auf das eigene Kapitel konzentrieren; dennoch ist eine Dokumentaktualisierung jederzeit mit ein Paar Klicks verfügbar. Eine Änderungshistorie befindet sich immer am Anfang des Dokuments noch vor dem Inhaltsverzeichnis und beinhaltet den Autorennamen, das Datum und die Kurzbeschreibung einer Änderung als Link: Durch einen Klick darauf springt man im Dokument an jene Stelle, wo die Änderungen eingefügt wurden. Somit ist jedes Projektmitglied auf dem neuesten Wissensstand. Sind die Änderungen für die eigenen Aufgaben irrelevant, brauchen sie nicht weiter beachtet zu werden.
Wenn Sie zu jenen Glückspilzen gehören, die sich ein Anforderungs-Managementtool leisten können, dann sind Sie auf der sicheren Seite. So ein Tool wurde speziell entwickelt, um bei der Erfassung, Kommentierung und Verwaltung der Anforderungen zu unterstützen. Es ermöglicht die Rückverfolgbarkeit über die Anforderungsstufen bis ins Änderungsmanagement der Anforderungen. Einige Anforderungsmanagementwerkzeuge erlauben statische Analysen (z. B. Konsistenzprüfungen und die Aufdeckung der Abweichung von definierten Anforderungsregeln).? (4)
Weshalb ist es so wichtig, dass gerade in dieser Anforderungsphase möglichst viele Fehler sowohl vermieden als auch gefunden werden? Weil die Fehlerbehebung in dieser Phase am günstigsten ist; andererseits entstehen gerade hier viele Fehler wegen Missverständnissen in der Kommunikation!
Die folgende Grafik soll uns das Kostenverhalten im Softwareentwicklungsprozess verdeutlichen. "Sie steigen kontinuierlich über alle Teststufen bis hin zum Produktionsbetrieb der Software. Je länger Fehlerzustände im Code verbleiben, desto teurer ist ihre Behebung. Sie verursachen selbst oft weitere Fehlerzustände im Code." (5)
Ich versprach Ihnen, die Techniken für die Erstellung der Anforderungen zu erklären. Ich komme gleich dazu. Damit alles verständlicher wird, möchte ich Ihnen den selbstentworfenen fundamentalen Requirements Engineering Prozess vorstellen. (6)
Der fundamentale Requirements Engineering Prozess (7)
Es existiert der fundamentale Testprozess nach ISTQB und ich dachte mir, warum soll jemand nicht auch einen fundamentalen Prozess für Requirements Engineering definieren, damit auch in der Anforderungsphase mit der Zeit Standards geschaffen und somit weltweit die Arbeit einheitlich gestaltet werden kann.
"Das fundamentale besteht aus sechs Requirements- bzw. Anforderungsphasen (Hauptaufgaben):
@ Informationsquellen für die Requirements identifizieren
@ System abgrenzen und Systemkontext determinieren
@ Requirements ermitteln
@ Requirements dokumentieren
@ Requirements abstimmen
@ Requirements bzw. das Dokument Anforderungsspezifikation abnehmen und verwalten
Die Grafik oben veranschaulicht das Fundamentale des Requirements Engineering Prozesses und zeigt die Zusammenhänge der einzelnen Prozessphasen auf. In der Abstimmungsphase kommt es oft zur Feststellung der Abweichungen vor. Es kann sich um die missverstandenen, falsch interpretierten Anforderungen handeln oder um die Feststellung, dass Anforderungen komplett fehlen. Welche Unstimmigkeiten und Abweichungen es auch gibt, in dieser Phase werden sie beseitigt. Die fehlenden Requirements werden nachträglich ermittelt und dokumentiert. Das heißt, es ist eine Rückkehr zu einer oder mehreren vorherigen Phasen des fundamentalen Requirements Prozesses erforderlich, um die Abweichungen zu beseitigen." (8)
Die versprochenen Ermittlungstechniken sind in der Phase drei beinhaltet. Folgende Requirementsermittlungstechniken basierend auf Kano haben sich im Requirements Engineering etabliert:
1. Befragungstechniken
2. Kreativitätstechniken
3. Dokumentenorientierte Techniken
4. Beobachtungstechniken
5. Unterstützende Techniken (9)
Mini Glossar
Anforderungsbasierter Test: Ein Test, der auf den Anforderungen basiert. Aus ihnen werden die Testziele und Testbedingungen abgeleitet. Dazu gehören Tests, die einzelne Funktionen tätigen oder solche, die nicht funktionalen Eigenschaften wie Zuverlässigkeit oder Benutzbarkeit untersuchen. (10)
Analytisches Testen: Testen, das auf einer systematischen Analyse von z. B. Produktrisiken oder Anforderungen basiert. (11)
Ein Projekt ist "eine einmalige Menge von abgestimmten und gelenkten Tätigkeiten mit Anfangs- und Endterminen. Es wird durchgeführt, um ein Ziel zu erreichen, das spezifische Anforderungen erfüllt, wobei Zeit-, Kosten- und Ressourcenbeschränkungen eingeschlossen sind. [ISO 9000]" (12)
Qualitätskosten: "Die gesamten Kosten, die durch Qualitätssicherungsaktivitäten und durch Fehlerwirkungen entstehen. Sie werden oft in Kosten der Fehlervorbeugung, der -ermittlung, der internen Fehlerwirkungen und den externen Fehlerwirkungen aufgeteilt." (13)
Der dritte Kolumnenbeitrag von Mag. Anja Kribernegg behandelt das Thema "Der fundamentale Requirements Engineering Prozess".
Quellen:
1: Quelle: Standard IEEE 610
2: Kribernegg, A.: Software – Test it Profession@lly!, S. 91, Stand März 2014
3: Kribernegg, A.: Software – Test it Profession@lly!, S. 91, Stand März 2014
4: Quelle: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 3
5: Kribernegg, A.: Software – Test it Profession@lly!, S. 90, Stand März 2014
6: Anmerkung! Es ist ein Vorschlag der Buchautorin offiziell einen fundamentalen RE Prozess zu etablieren
7: Kribernegg, A.: Software – Test it Profession@lly!, S. 98, Stand März 2014
8: Kribernegg, A.: Software – Test it Profession@lly!, S. 98, Stand März 2014
9: Kribernegg, A.: Software – Test it Profession@lly!, S. 105, Stand März 2014
10: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 3
11: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 3
12: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 40
13: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 42
© Textbeitrag sowie zwei Abbildungen zu "Ein Kundenauftrag muss richtig verstanden werden": Mag. Anja Kribernegg, Wien. Die Autorin war lange in der IT-Branche im Finanzsektor tätig. Softwareentwicklung und -testen sind ihre Hauptgebiete. Bildnachweis oben: 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