|
Damit etwas Neues zustande kommt, benötigt es einen Impuls! Diesen gibt in der Welt der Softwareentwicklung meistens der Kunde mit seinem Auftrag. Dabei spielt es keine Rolle, ob es sich um einen internen oder einen externen Kunden handelt, denn es kommt auf das Gleiche hinaus: den Wunsch des Kunden, für ihn eine neue Software zu entwickeln, eine bestehende durch neue Funktionen zu erweitern, oder ein System zu analysieren, um festzustellen, ob dies nicht bereits am Ende seines Software-Lebenszyklus angelangt ist.
Am Anfang steht also der Kundenauftrag. Alle Stakeholder (d. h. Interessengruppen), aber auch das Unternehmensmanagement wollen im Idealfall wissen, wie schnell und leicht oder schwer das eigene System an die höheren Kundenanfragen angepasst werden könnte. Wie schwierig ist eine Veränderung der Systemgröße bzw. Systemaufstockung (Skalierbarkeit), um es ganz einfach zu formulieren.
Um es simpel auszudrücken: Es geht um die Ermittlung des Wachstumspotenzials des Systems, um die Fähigkeit der Software erweitert zu werden, das heißt zu wachsen. Zu diesem Zweck wird durch die Tests der Schwellenwert ermittelt, der einen Erweiterungsbedarf indiziert. Skalierbarkeitstests zeigen auch, was skaliert werden muss. Wird, zum Beispiel, der Arbeitsspeicher RAM verdoppelt oder sollen weitere Prozessoren angeschafft werden?
Die Kreativität und die sich daraus ergebenden Ideen für eine neue Software – ob App oder Großsystem – stellen einen weiteren Impulsgeber dar.
Als nächster Schritt gilt es, das Gewünschte genau zu artikulieren. Das heißt, der Informationssender (Kunde) und der Informationsempfänger (Entwickler), müssen auf der gleichen Wellenlänge sein. Dies ist meistens gar kein Thema, wenn es sich um die eigenen Ideen handelt, denn diese reifen in unserem Unterbewusstsein, kommen in unserem Bewusstsein zum Vorschein – anschließend aufs Papier und ans Tageslicht!
Handelt es sich aber um einen Wunsch, der einem fremden Gehirn entsprungen ist, gestaltet sich dieser Prozess der Wunschformulierung etwas schwieriger!
Somit sind wir beim Requirements Engineering angelangt: einem Bereich, der mit dem Softwaretesten und der Entwicklung eng verbunden ist. Requirements Engineers sind jene Spezies in der Praxis, die versuchen, den Spagat zwischen den Wünschen und der (IT-)Realität zu schaffen! Sie werden oft auch Business Analysten genannt. Der "Requirements Engineer bzw. Anforderungsingenieur stellt das Bindeglied zwischen der Entwicklung und den Stakeholdern dar und spielt eine Schlüsselrolle." (1)
In den letzten Jahren hat sich der Beruf Requirements Engineer stark etabliert, ähnlich wie jener des Softwaretesters. Diese beiden Berufe können nach Standards zertifiziert werden, wodurch eine weltweit einheitliche Ausbildung gewährleistet wird. Das IREB – International Requirements Engineering Board – bestimmt die Standards und regelt die Ausbildung und die Zertifizierung der Requirements Engineers. Das ISTQB – International Software Testing Qualification Board – hingegen bestimmt die Standards und regelt die Ausbildung und die Zertifizierung der Softwaretester.
Jetzt werden Sie denken, wir haben uns von dem Thema Softwaretesten hin zum Requirements Engineering entfernt. Dem Einwand stimme ich voll und ganz zu, möchte aber argumentieren, dass wir bei der Softwareentwicklung und dem darauf folgenden Softwaretesten die gesamte IT-Landschaft miteinbeziehen müssen, um professionelle Ergebnisse liefern zu können. Von diesen hängt die Qualität der Software ab.
Über welche Fähigkeiten und Fertigkeiten muss ein Requirements Engineer bzw. eine Engineerin verfügen, um die Anforderungen an eine Software so zu formulieren, dass die zu entwickelnde Software als valide bezeichnet werden kann? Unter Validierung wird das Prüfen verstanden, ob das Richtige programmiert wurde. Verifizierung dagegen prüft, ob richtig entwickelt wurde.
Die Anforderungsspezifikation ist ein Dokument, das alle einzelnen Anforderungen umfasst und der Software genau "sagt", wie sie sich verhalten soll und was es alles können muss.
"@ Analytisches Denken: Für diese Rolle als Eigenschaft unerlässlich! Ein(e) Requirements Engineerin muss in der Lage sein, die komplizierte, manchmal auch unbekannte Sachverhalte, kognitiv schnell zu verstehen, zu erfassen und zu analysieren. Die unterschiedliche Ausdrucksweise der Stakeholder erschwert diese Aufgabe erheblich.
@ Empathie: Die Fähigkeit, sich in die anderen Menschen bzw. Stakeholder zu versetzen, um besser zu verstehen, wie sie sich fühlen, was sie wünschen und brauchen, ist die zentrale Voraussetzung.
@ Kommunikationsfähigkeit: Hohe verbale und nonverbale kommunikative Fähigkeiten sind erforderlich. Ein Mensch kommuniziert nicht nur durch die natürliche, sondern auch körperliche Sprache. Missverständnisse können dadurch entstehen. Aus dem Gesagten müssen Informationen eruiert werden. Gut zuhören können, rechtzeitig Fragen stellen, wenn die Aussagen unklar oder mehrdeutig sind – das ist der Erfolgsschlüssel.
@ Konfliktlösungsfähigkeit: Die Vermittlerrolle ist unentbehrlich, wenn es zu heftigen Diskussionen zwischen den Stakeholdern kommt. Jeder versucht, seine Wünsche und Vorstellungen durchzusetzen, so dass Konflikte unvermeidbar sind.
@ Moderationsfähigkeit: In den Projektmeetings werden verschiedene Meinungen geäußert. Der Meinungsaustausch zwischen den Stakeholdern muss geschickt gesteuert werden und gleichzeitig jedem Projektmitglied die Meinungsäußerung ermöglichen.
@ Selbstbewusstsein: Oft genug wird der/die Requirements Engineerin kritisiert und verbal attackiert; insbesondere, wenn der Wissensstand der Stakeholder große Unterschiede aufweist und es deshalb zu Verständlichkeitsproblemen der Materie kommt. Nur, wie sagt man einem Auftraggeber, dass er doch über das Thema weniger weiß als er glaubt? Wie macht man ihm klar, dass die Wünsche eines und die Realität etwas anderes sind? Das erfordert manchmal ganz schön viel Mut und eine ordentliche Portion an Selbstbewusstsein.
@ Überzeugungsfähigkeit: Der/die Requirements Engineerin muss die Erfüllung der Kundenanforderungen durchsetzen können. Professionell erstellte Präsentation und überzeugtes Auftreten schaffen die Authentizität und vermitteln Seriosität. Schließlich soll das ganze Vorhaben auch budgetiert werden. Niemand gibt Geld für etwas aus, wovon er nicht überzeugt ist." (2)
Nicht umsonst ist diese Tätigkeit so anspruchsvoll. Es gilt, mit unterschiedlichsten Menschen, oft anderen Kulturen und Denkweisen zurechtzukommen und einen gemeinsamen Nenner zu finden.
Selbst bei vorhandenen aufgezählten Fähigkeiten stellt sich die Frage: Wie holt man aus dem Auftraggeber heraus, was er wirklich will, und was genau er oder sie von der zukünftigen Software erwartet?
Tipp aus der Praxis! Die größte Gefahr bei der Requirements-Ermittlung stellt das implizite Wissen jener Stakeholder dar, die aus den unterschiedlichen Fachbereichen kommen. Ein großes Problem in dem IT-Alltag bei den Softwareentwicklungsprojekten ist, dass die gerade erwähnten Akteure es für selbstverständlich halten, dass ihr implizites Wissen durch die anderen Stakeholder "irgendwie" richtig wahrgenommen bzw. erraten werden kann. Die Lösung stellen die vorher fachlich gut vorbereiteten Kommunikationsexperten. Sie schaffen es durch die richtige Fragestellungstechnik, dieses Wissen aus den Stakeholdern herauszuholen. Solche Experten – ob als projektbezogene externe Projektberater oder als eigene Angestellte – kann sich aber nicht jedes Unternehmen leisten. (3)
Softwarelebenszyklus wird wie folgt definiert: "Der Zeitraum, der bei der Konzeption eines Softwareprodukts beginnt und dann endet, wenn die Software nicht mehr für die Nutzung verfügbar ist. Der Softwarelebenszyklus enthält üblicherweise eine Konzeptionsphase, Anforderungsphase, Entwurfsphase, Implementierungsphase, Testphase, Installationsphase, Betriebs- und Wartungsphase, und manchmal eine Außerbetriebnahme. Bemerkung: Diese Phasen können sich überlappen oder iterativ durchgeführt werden." (4)
Skalierbarkeit bzw. Scalability ist "die Fähigkeit eines Softwareprodukts, so aufgerüstet zu werden, dass es eine erhöhte Last verkraftet. [nach Gerrard]" (5)
Anforderung wird folgendermaßen definiert: "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. [Nach IEEE 610]" (6)
Validierung bedeutet Prüfen, ob das Richtige entwickelt wurde: ob die Kundenanforderungen umgesetzt wurden.
Verifizierung bedeutet Prüfen, ob eine Software korrekt, also genau so programmiert wurde, wie es vom Kunden angefordert wurde.
Im zweiten Kolumnenbeitrag geht die Autorin Mag. Anja Kribernegg auf die einzelnen Requirements-Ermittlungstechniken ein.
Quellen:
1: Kribernegg, A.: Software – Test it Profession@lly!, S. 91, Stand März 2014
2: IREB Foundation Level Version 2.1, 15. Juni 2012, S. 7
3: Kribernegg, A.: Software – Test it Profession@lly!, S. 106, Stand März 2014
4: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 50
5: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 48
6: ISTQB/GTB Standardglossar der Testbegriffe 2013, S. 3
© "Im Blickpunkt: Der Beruf des Requirements Engineers – Am Anfang gibt es einen Kundenauftrag". Ein Beitrag 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