Dieser Beitrag erläutert die Konzepte von Data Mart und Data Vault und stellt den Zusammenhang der... » weiterlesen
Zum Meilenstein XY sind die dokumentierten Anforderungen fällig… Änderungen werden nicht mehr berücksichtigt.
Gibt es für Anforderungen tatsächlich einen Redaktionsschluss?
Die Wahrheit:
Softwareprojekte sind keinesfalls „soft“ also leichtgewichtig, sondern eine kontinuierliche Herausforderung. Anforderungen verändern sich kurzfristig und laufend.
Für die erfolgreiche Projektumsetzung benötigt man ein umfangreiches Verständnis darüber, was letztendlich erreicht werden soll. Doch in vielen Fällen kann das Team nicht vollständig im Kopf haben oder vorab exakt dokumentieren, welche Anforderungen sich an die geplante Software ergeben.
Wenn wir nun von Requirements Engineering sprechen, beleuchten wir eine Disziplin zur systematischen Ermittlung, Dokumentation, Abbildung und dem Management von Anforderungen.
Es geht hierbei nicht um das Ansammeln und Dokumentieren von Anforderungen, sondern um deren Ziele, ihre Struktur und Abhängigkeiten besser zu verstehen. Auf dieser Grundlage ergibt sich eine leichtere Kommunikation im Team und mit den ermittelten Stakeholdern.
Requirements Engineering ist eine Kompetenz um zielgerichteter zu handeln und die Werte für die Nutzer:innen zu realisieren. Die Verifikation der Kernhypothesen, welche die Software in Funktion und Qualität ausmachen.
Und ja, Agilität und Requirements Engineering sind Gegensätze, die sich durchaus anziehen. Haben Sie das gewusst?
- Um User Stories zu finden, die zu erwartungskonformen und wertschöpfenden Lösungen führen, bietet das Requirements Engineering geeignete Mittel. Die Analyse der Stakeholder, ihrer Ziele und Anforderungen.
- Das Agile Manifest (https://agilemanifesto.org/iso/de/manifesto.html) wertet funktionierende Software höher als Dokumentation. "Dokumentieren Sie nur so viel wie nötig, jedoch so wenig wie möglich." Was nicht bedeutet, dass Dokumentation als nutzlos erachtet wird, sondern lediglich das Spezifikationsdokument im Umfang verkürzt.
- Änderungen der Anforderungen sind immer willkommen – wie in den agilen Prinzipien formuliert. Denn Rahmenbedingungen wechseln, Stakeholder lernen dazu, der Bedarf ändert sich. Anpassungen sollten direkt und rasch in die Entwicklung einfließen. Schnelles Feedback ist entscheidend!
Agile Softwareentwicklung und agiles Requirements Engineering sind ganzheitlich zu betrachten. Diese Kombination ist keine neue Erfindung, sondern basiert auf einer sinnvollen Mischung von klassischen und agilen Methoden.
Die iterative Vorgehensweise schafft einen gleich langen Rhythmus und das Projekt gliedert sich in feste Zeitabschnitte. Jeweils zum Ende eines Sprints erweitert sich das Etappenziel (das Inkrement) schrittweise auf den Lieferumfang.
Es macht Sinn, dass auch das Entwicklungsteam die Grundprinzipien des Requirements Engineering und das gewünschte Projektziel versteht. Die Lösung muss ebenso klar sein, wie das Problem. Schwächen sollen ohne Schwierigkeiten erkannt werden und die schnelle Reaktion darauf ein Selbstläufer sein.
Statisch vs. Dynamisch:
Zahlreiche Softwareprojekte basieren auf einer statischen Umsetzung, wonach es schwierig ist flexibel auf Änderungen während der Entwicklung einzugehen. Daraus resultiert die Unterbindung von schnellen Reaktionszeiten. Kunden sind vor allem in der anfänglichen Projektphase eingebunden.
Ein deutlicher Unterschied zeigt sich in einem dynamischen Ablauf. Die Entwicklung ist in den Kreislauf eingebunden, darüber hinaus sind auch direkte Sprünge möglich. Die Priorisierung der Anforderungen erfolgt so weit, wie dies für die weitere Einschätzung nötig ist. Kunden begleiten den Prozess über den gesamten Zyklus hinweg.
Doch was passiert, wenn man auf Requirements Engineering verzichtet?
- Das System erlangt keine Akzeptanz, aufgrund fehlender Befragung und Einbindung der Anwender:innen.
- Die Entwicklung erfolgt aufgrund von Vermutungen, wonach sich automatisch Fehler einschleichen.
- Die Projektlaufzeit erhöht sich um ein Vielfaches, da fehlende Anforderungsdokumentation die Abstimmungen zwischen den Abteilungen erschweren.
- Das Projekt scheitert, weil das System sich wegen fehlender oder mangelhafter Anforderungen nicht schnell genug umsetzen lässt.
Jedes Software-Projekt weist eigene Rahmenbedingungen und Charakteristiken auf. Sie sind an zielführenden Erhebungstechniken interessiert? Wir unterstützen Sie dabei, Risiken abzudecken und freuen uns auf Ihre Kontaktaufnahme.