AKARA Launchpad

Jede Software beginnt mit derselben Frage: Was genau soll gebaut werden?

Requirements Engineering ist das systematische Erheben, Dokumentieren und Validieren von Anforderungen. Dies ist die kritischste Phase jeder Softwareentwicklung. Studien zeigen seit Jahrzehnten: Die teuersten Fehler entstehen nicht beim Programmieren, sondern wenn Anforderungen unvollständig, widersprüchlich oder falsch verstanden sind.

Der klassische Prozess sieht so aus: Eine Woche Workshop mit Stakeholdern, Whiteboards voller Post-its, Design-Thinking-Sessions, Protokolle, die niemand liest, und am Ende ein 40-seitiges Pflichtenheft, das bereits veraltet ist, wenn es fertig wird.

Was daran wirklich schwer ist

Das Problem ist nicht der Aufwand, sondern die Unsicherheit. Kunden wissen oft nicht, was sie wollen. Sie können Probleme beschreiben, aber keine Lösungen spezifizieren. Ein Stakeholder sagt: "Wir brauchen ein Dashboard", meint aber drei verschiedene Dinge je nachdem, ob man den CEO, den Vertriebsleiter oder den Entwickler fragt.

Klassisches Requirements Engineering versucht diese Unsicherheit durch Gespräche aufzulösen. Das funktioniert, aber es dauert Wochen, kostet 10.000 bis 50.000 Euro an Beratungsleistung und das Ergebnis ist ein Dokument, das der Kunde nicht anfassen kann. Kein Prototyp. Kein klickbares Interface. Nur Text.

Die Alternative "einfach mal loslegen und schauen, was passiert" ist teurer. Jede Iteration, die auf falschen Annahmen basiert, kostet ein Vielfaches dessen, was eine gute Spezifikation gekostet hätte.

Das Dilemma für Dienstleister

Für eine Softwareagentur wie AKARA Solutions ist das ein betriebswirtschaftliches Problem. Investiert man eine Woche in Workshops bevor eine Zeile Code geschrieben wird, sinkt die Marge. Überspringt man die Anforderungsanalyse, steigt das Risiko von Fehlentwicklung. Beide Optionen skalieren nicht.

Was fehlt: Ein Weg, Kunden innerhalb von Minuten mit einem haptischen, testbaren Ergebnis zu konfrontieren nicht mit einem Dokument, sondern mit einem funktionierenden Prototypen. Nicht um das Gespräch zu ersetzen, sondern um es auf ein anderes Niveau zu heben: weg von "Was meinen Sie damit?" hin zu "Klicken Sie hier — ist es das was Sie brauchen?"

Beispiel: Die Designphase des Apollo-Programms

In der Anforderungserhebung gibt es ein grundlegendes Problem, das sich hartnäckig durch Projekte jeder Größenordnung zieht: Die Annahme, dass eine vollständige, formal korrekte Spezifikation ausreicht, um sicherzustellen, dass das Richtige gebaut wird. Eine Episode aus dem Apollo-Programm illustriert, warum das nicht stimmt und was stattdessen funktioniert.

Während der Designphase der Apollo-Kapsel arbeiteten Ingenieure an der Spezifikation der Sichtfenster. Die Anforderungen lagen in der Form vor, die man erwarten würde: Maße, Positionskoordinaten, Materialstärke, Toleranzen, thermische Belastungswerte. Jede Zeile war technisch korrekt, geprüft und freigegeben.

Ein Ingenieur entschied sich, die Spezifikation auf einem anderen Weg zu validieren. Er baute aus Pappe einen simplen Mockup der Kapselwand mit dem Fensterausschnitt in exakt den spezifizierten Maßen und an der vorgesehenen Position. Dann bat er die Astronauten, sich hineinzusetzen.

Das Ergebnis war eindeutig: Das Sichtfeld reichte nicht aus. Für Andockmanöver, visuelle Lagekontrolle und Navigation fehlte der Überblick. Die Astronauten konnten sofort zeigen, wo die Probleme lagen. Etwas, das ihnen beim Lesen der Spezifikation nicht möglich gewesen war. Position, Größe und Winkel der Fenster mussten grundlegend überarbeitet werden.