Modellen bzw. als Erweiterungen gängiger Modellierungsansätze dokumentiert werden.
Der Requirements Engineer sollte sicherstellen, dass die Qualitätsanforderungen möglichst objektiv an dem entwickelten System überprüfbar sind. Dies erfordert in der Regel, dass die geforderten Qualitäten durch quantitative Angaben konkretisiert werden. Beispielsweise könnte eine Qualitätsanforderung in Bezug auf die geforderte Leistung des Systems festlegen, dass die Abarbeitung einer Anfrage auf keinen Fall mehr als 4 Sekunden in Anspruch nehmen darf. Qualitätsanforderungen können hierbei durch zusätzliche funktionale Anforderungen konkretisiert werden. Oder eine Qualitätsanforderung bezüglich der Sicherheit des Systems kann durch die Forderung nach der Verschlüsselung der Ausgabedaten präzisiert und verfeinert werden. Die geforderte Verschlüsselung der Ausgabedaten stellt dabei eine funktionale Anforderung dar, die die geforderten Sicherheitseigenschaften des Systems umsetzt.
Constraints oder Randbedingungen (auch: Rahmenbedingungen) können von den Projektbeteiligten nicht beeinflusst werden. Randbedingungen können sich sowohl auf das betrachtete System beziehen (z.B. »Das System soll durch Webservices realisiert werden«) als auch auf den Entwicklungsprozess des Systems (z.B. »Das System soll bis spätestens Mitte 2024 am Markt verfügbar sein«). Randbedingungen werden, im Gegensatz zu funktionalen Anforderungen und Qualitätsanforderungen, nicht umgesetzt, sondern schränken die Umsetzungsmöglichkeiten, d.h. den Lösungsraum im Entwicklungsprozess, ein.
Definition 1–6: Randbedingung (Constraint)
Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.
Übersetzt aus [IREB-Glossar 2020]
Eine Randbedingung ist also in der Regel eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.
Exkurs: Randbedingungen (Constraints)
Um Randbedingungen näher zu betrachten und zu unterscheiden, existieren verschiedene Klassifikationen. In [Robertson und Robertson 2012] werden Randbedingungen in technische Einschränkungen und Einschränkungen des Entwicklungsprozesses unterschieden.
Des Weiteren können Randbedingungen auch im Hinblick auf ihren Ursprung unterschieden werden. So existieren beispielsweise:
Einschränkungen aufgrund des kulturellen Umfelds
Rechtliche Rahmenbedingungen
Organisatorische Einschränkungen
Einschränkungen aufgrund der physikalisch technischen Umgebung des zu entwickelnden Systems
Rahmenbedingungen, die sich aus dem definierten Vorgehen im Projekt ergeben
Eine derartige Strukturierung von Randbedingungen hilft beim Erheben von Anforderungen, aber auch bei ihrer Verwaltung.
Kernfakten 1–1: Requirements Engineering – Was
1.2 Requirements Engineering – Warum?
Problemverständnis schärfen und Testfälle ableiten
Requirements Engineering trägt dazu bei, dass eine Problemstellung früher und besser verstanden wird. Dies ermöglicht es, die Kosten bei einem späteren Aufdecken von Fehlern zu minimieren. Außerdem legen gute Anforderungen die Grundlage, um nachzuweisen, dass das System die Anforderungen wie gewünscht realisiert. Hierzu werden direkt aus den Anforderungen Testfälle gewonnen, die es ermöglichen, Defekte im System aufzudecken.
Anforderungen zur Projektplanung und Kostenschätzung
Anforderungen leisten daneben einen nicht zu unterschätzenden Beitrag zur Projektplanung. Wie wir später sehen werden, erlauben explizit dokumentierte Anforderungen eine Priorisierung und damit eine Projektplanung vorzunehmen. Anhand dieser Priorisierungen und Planungsdokumente lassen sich dann, basierend auf dem zu erwartenden Aufwand für die Umsetzung der Anforderungen, die Kosten der einzelnen Arbeitspakete und damit des gesamten Entwicklungsprojekts besser schätzen.
Zusammengefasst bietet Requirements Engineering laut [IREB-Lehrplan 2020] einen Mehrwert bei der Entwicklung und Weiterentwicklung eines Systems, indem:
das Risiko, ein falsches System zu entwickeln, verringert wird;
ein besseres Verständnis des Problems erzeugt wird;
die Grundlage für die Schätzung von Entwicklungsaufwand und Kosten gelegt wird;
die Voraussetzung für das Testen des Systems geschaffen wird.
Symptome und Gründe für fehlerhafte Anforderungen
Symptome für mangelhaftes Requirements Engineering sind ebenso zahlreich wie ihre Ursachen. Häufig fehlen Anforderungen oder sie sind unklar formuliert. Wenn beispielsweise die Anforderungen nicht genau den Kundenwunsch widerspiegeln oder die Anforderungen zu ungenau beschrieben und damit verschiedenartig interpretierbar sind, kann dies zur Folge haben, dass das erstellte System nicht den Erwartungen der Auftraggeber bzw. Nutzer entspricht.
Der häufigste Grund für fehlerhafte Anforderungen ist die falsche Annahme der Stakeholder, dass vieles selbstverständlich ist und nicht explizit genannt werden muss. Es entstehen Kommunikationsprobleme zwischen den Beteiligten, die oft aus unterschiedlichem Erfahrungs- bzw. Wissenstand resultieren. Erschwerend kommt hinzu, dass besonders der Auftraggeber in vielen Fällen kurzfristige Ergebnisse in Form eines produktiven Systems erhalten möchte.
Zusammengefasst sind die typischsten Ursachen für mangelhaftes Requirements Engineering laut [IREB-Lehrplan 2020]:
Direkt mit der Entwicklung des Systems zu beginnen, ohne eine ausreichende Verständnisgrundlage geschaffen zu haben.
Kommunikationsprobleme zwischen den beteiligten Parteien (siehe Exkurs)
Die Annahme, dass die Anforderungen selbstverständlich sind und keiner weiteren Erläuterung bedürfen bzw. gar nicht erst erfasst werden müssen.
Unzureichende Ausbildung und Fähigkeiten des Requirements Engineer
Exkurs: Kommunikationsprobleme
Anforderungen müssen kommuniziert werden. In den meisten Fällen bedient man sich hierbei eines allen Kommunikationspartnern zugänglichen, regelgeleiteten Mediums – der Sprache.
Damit die Übertragung von Informationen von einem Individuum zu einem anderen funktioniert, wird ein gemeinsamer Code benötigt. Der Sender verschlüsselt seine Botschaft, die der Empfänger dann wieder entschlüsseln muss. Ein solcher gemeinsamer Code ist Menschen gegeben, die die gleiche natürliche Sprache (z.B. Deutsch) sprechen, den gleichen kulturellen Hintergrund haben und auf ähnliche Erfahrungen zurückgreifen können. Je ähnlicher der kulturelle und Bildungshintergrund, das Fachgebiet und der Arbeitsalltag sind, umso besser klappt der Austausch von Informationen. Da dies häufig unter den Stakeholdern nicht gegeben ist, ist es sinnvoll, sich zunächst auf eine gemeinsame Sprache und deren Verwendung zu einigen. Das kann z. B. der Einsatz eines Glossars (siehe Abschnitt 3.5) sein, in dem alle wichtigen Begriffe erläutert werden, oder die Einigung auf eine formalere Beschreibungssprache, z. B. die Unified Modeling Language (UML) der OMG (siehe Abschnitt 3.4).
Ein weiterer Faktor ist die Art des Kommunikationsmediums.