Anforderungsanalyse & Software Discovery
Bevor Software entsteht, klären wir Ziele, Abläufe, Anforderungen und Risiken. Daraus entsteht eine belastbare Grundlage für Scope, Architektur, Aufwand und Umsetzung — oder die begründete Empfehlung, nicht zu bauen.
Anforderungsanalyse & Software Discovery in einer Minute.
Für Entscheider: unsere Position auf einen Blick — wann es passt, wie wir es angehen, worauf wir optimieren.
- Discovery passt, wenn
- ein Vorhaben fachlich noch offen ist, mehrere Bereiche betrifft oder an Bestandssysteme angebunden wird.
- Kompakter genügt, wenn
- Ziel, Nutzer und Umfang bereits klar sind und das Vorhaben kaum Abhängigkeiten zu anderen Systemen hat.
- Typischer Anlass
- eine Idee ohne belastbaren Aufwand oder ein Ablauf, der heute in Tabellen, E-Mails und Einzelwissen lebt.
- Was wir klären
- Ziele, Nutzerrollen, tatsächliche Abläufe, Anforderungen, Daten, Schnittstellen und offene Entscheidungen.
- Typische Risiken
- die Lösung vor dem Problem, der dokumentierte statt des gelebten Prozesses und ein Scope ohne Grenze.
- Was am Ende vorliegt
- ein priorisierter, dokumentierter Scope mit Risiken, Abnahmekriterien und einem begründeten Aufwandskorridor.
- Was wir bewusst vermeiden
- Workshops als Selbstzweck, Anforderungslisten ohne Priorität und Zusagen auf ungeklärter Grundlage.
- Mögliches Ergebnis
- auch die Empfehlung für Standardsoftware, einen kleineren Zuschnitt oder den Verzicht auf das Vorhaben.
Risiken, die wir früh erkennen.
Was in Systemen dieser Art typischerweise schiefgeht — und wie wir es vermeiden, bevor es in Produktion sichtbar wird.
- 01
Die Lösung vor dem Problem
- Warum
- Ein Vorhaben beginnt mit einer fertigen Lösung im Kopf — einer App, einem Portal, einer KI-Funktion. Anforderungen werden dann so formuliert, dass sie diese Lösung bestätigen, statt das Problem zu beschreiben.
- Frühwarnzeichen
- Anforderungen nennen Oberflächen und Werkzeuge, aber kein Ziel; die Frage nach dem Nutzen wird mit einer Liste von Funktionen beantwortet.
- Wie wir es verhindern
- Wir beginnen beim Ziel und beim heutigen Ablauf und bewerten die gewünschte Lösung erst danach — gegen Standardsoftware, einen kleineren Zuschnitt und den Verzicht.
- Trade-off
- Kosten: Die ursprüngliche Idee wird geprüft, statt direkt umgesetzt zu werden. Anders, wenn: die Lösung bereits validiert ist — dann konzentrieren wir uns auf Umfang und Risiken.
- 02
Der dokumentierte statt des gelebten Prozesses
- Warum
- Prozessbeschreibungen und Handbücher zeigen, wie gearbeitet werden soll. Die tatsächliche Arbeit enthält Ausnahmen, Umwege und Nebenlisten, die nirgends stehen — und genau dort liegen die teuren Anforderungen.
- Frühwarnzeichen
- Antworten beginnen mit „eigentlich“; Tabellen und Postfächer übernehmen Schritte, die offiziell ein System erledigt; Sonderfälle kennt nur eine Person.
- Wie wir es verhindern
- Wir sprechen mit den Menschen, die die Arbeit tun, sehen uns reale Fälle an und nehmen Ausnahmen als Anforderungen auf — nicht als Randnotiz.
- Trade-off
- Kosten: Zeit der Fachanwender, die im Tagesgeschäft fehlt. Anders, wenn: der Ablauf neu entsteht und es noch keine gelebte Praxis gibt.
- 03
Scope ohne Grenze
- Warum
- Jede Anforderung ist für sich vernünftig. Ohne Priorität und Abgrenzung wächst der Umfang, bis Aufwand, Termin und Budget nicht mehr zusammenpassen.
- Frühwarnzeichen
- Alles ist Muss; es gibt keine Liste dessen, was nicht gebaut wird; neue Wünsche kommen hinzu, ohne dass ein bestehender zurücktritt.
- Wie wir es verhindern
- Muss und Kann werden getrennt, der erste Umfang wird entlang eines vollständigen Ablaufs geschnitten, und was nicht dazugehört, wird ausdrücklich festgehalten.
- Trade-off
- Kosten: sichtbarer Verzicht in der ersten Phase. Anders, wenn: der Umfang von außen fest vorgegeben ist — dann priorisieren wir die Reihenfolge statt der Menge.
- 04
Verdeckte Abhängigkeiten
- Warum
- Bestandssysteme, Datenquellen und Zuständigkeiten außerhalb des Projekts bestimmen oft Tempo und Machbarkeit. Werden sie spät entdeckt, verschieben sie Architektur, Aufwand und Zeitplan zugleich.
- Frühwarnzeichen
- Schnittstellen „gibt es“, sind aber nicht dokumentiert; die Qualität der Daten ist unbekannt; niemand kann sagen, wer ein angebundenes System verantwortet.
- Wie wir es verhindern
- Wir erfassen Daten, Schnittstellen und Verantwortliche früh, prüfen kritische Zugänge an echten Beispielen und führen Offenes als Risiko mit Termin.
- Trade-off
- Kosten: Aufwand bei den Verantwortlichen der Bestandssysteme, bevor die Umsetzung feststeht. Anders, wenn: das Vorhaben eigenständig ist und keine bestehenden Systeme berührt.
Die Fragen, die wir vor dem Code stellen.
Keine Ratschläge, sondern Entscheidungsfragen. Ihre Antworten prägen die Architektur — nicht die Werkzeuge.
- 01
Welches Problem soll gelöst werden — und woran erkennen wir, dass es gelöst ist?
- Warum das zählt
- Ohne überprüfbares Ziel lässt sich weder der Umfang priorisieren noch am Ende feststellen, ob sich das Vorhaben gelohnt hat.
- Typische Konsequenz
- Ist das Ziel unklar, klären wir es zuerst. Ist es klar, wird es zum Maßstab, an dem sich jede weitere Anforderung messen lassen muss.
- 02
Wer nutzt das System — und wer ist betroffen, ohne es zu nutzen?
- Warum das zählt
- Nutzerrollen bestimmen Oberflächen und Rechte. Mittelbar Betroffene wie Buchhaltung, Datenschutz oder Betrieb bringen Anforderungen mit, die sonst erst spät auftauchen.
- Typische Konsequenz
- Wir beziehen beide Gruppen ein und leiten Rollen, Rechte und nichtfunktionale Anforderungen daraus ab.
- 03
Muss das überhaupt individuell gebaut werden?
- Warum das zählt
- Individualsoftware lohnt dort, wo Standardsoftware den Ablauf nicht abbildet oder ihre Anpassung teurer wird als eine gezielte Entwicklung.
- Typische Konsequenz
- Deckt ein Standardprodukt den Bedarf, empfehlen wir es. Individuell gebaut wird der Teil, der das Unternehmen tatsächlich unterscheidet.
- 04
Welche Systeme und Daten sind beteiligt?
- Warum das zählt
- Integrationen und Datenübernahmen gehören zu den häufigsten Ursachen für Verzögerungen — und sie sind früh erkennbar, wenn man gezielt nach ihnen fragt.
- Typische Konsequenz
- Wir erstellen eine Schnittstellen- und Datenübersicht und bewerten jede Anbindung nach Risiko, bevor ein Aufwand genannt wird.
- 05
Was ist der kleinste Umfang, der echten Nutzen bringt?
- Warum das zählt
- Ein erster Umfang, der alles enthält, liefert spät und lernt wenig. Einer, der zu klein geschnitten ist, liefert nichts, was jemand im Alltag nutzt.
- Typische Konsequenz
- Wir schneiden den ersten Umfang entlang eines vollständigen Ablaufs und ordnen die folgenden Phasen danach.
- 06
Welche Entscheidungen sind noch offen — und bis wann müssen sie fallen?
- Warum das zählt
- Offene Entscheidungen sind am Anfang normal. Gefährlich werden sie, wenn niemand sie verantwortet und sie im Projekt stillschweigend getroffen werden.
- Typische Konsequenz
- Jede offene Entscheidung erhält einen Verantwortlichen und einen Zeitpunkt; der Aufwandskorridor benennt die Annahme, die sie bis dahin ersetzt.
Was das ist — und was dazugehört.
Anforderungsanalyse und Software Discovery sind die strukturierte Klärung eines Softwarevorhabens — meist einer Webanwendung, eines Portals oder einer Plattform — vor seiner Umsetzung: welches Problem gelöst werden soll, für wen, in welchen Abläufen, mit welchen Daten und Systemen — und welche Risiken und offenen Entscheidungen darin liegen. Batunet macht daraus eine dokumentierte Grundlage, auf der Scope, Architektur, Aufwand und Umsetzung begründet entschieden werden können.
Leistungsumfang
- Fachliche Ziele und erwarteter Geschäftsnutzen
- Stakeholder, Nutzerrollen und Verantwortlichkeiten
- Bestehende Prozesse und tatsächliche Arbeitsabläufe
- Funktionale und nichtfunktionale Anforderungen
- Muss-/Kann-Abgrenzung und Zuschnitt des ersten Umfangs
- Priorisierung und Abhängigkeiten
- Daten, Schnittstellen und Bestandssysteme
- Technische Risiken, offene Entscheidungen und Abnahmekriterien
- Umsetzungsphasen, Aufwandskorridor und Dokumentation
Entscheidungen, bevor Code entsteht.
Nicht was die Technik kann, sondern warum wir sie so einsetzen.
- 01
Das Problem vor der Lösung
Viele Vorhaben beginnen mit einer Lösung. Wir klären zuerst, welches Problem sie lösen soll und woran man erkennt, dass es gelöst ist. Erst dann lässt sich die Lösung bewerten — auch gegen Alternativen, die weniger Entwicklung erfordern.
- 02
Beobachtete Abläufe statt Soll-Prozess
Dokumentierte Prozesse beschreiben, wie gearbeitet werden soll. Wir sehen uns an, wie tatsächlich gearbeitet wird — mit Ausnahmen, Umwegen und den Tabellen neben dem System. Dort liegen die Anforderungen, die später am meisten kosten.
- 03
Ein Korridor statt einer Zahl
Am Anfang eines Vorhabens ist die Unsicherheit am größten. Wir nennen deshalb einen begründeten Aufwandskorridor mit den Annahmen, auf denen er beruht, statt einer einzelnen Zahl, die Genauigkeit nur behauptet. Jede geklärte Frage macht ihn enger.
- 04
Offene Fragen bleiben sichtbar
Nicht alles lässt sich vor Projektbeginn klären. Was offen bleibt, wird benannt, einem Verantwortlichen zugeordnet und mit dem Zeitpunkt versehen, bis zu dem es entschieden sein muss — statt stillschweigend angenommen zu werden.
So bauen wir. Die Batunet Engineering Method.
Sieben Phasen — von der ersten Frage bis zum Betrieb nach Jahren. Kein Projektprozess, sondern die Art, wie wir denken.
- 01
FrameRahmen
Das eigentliche Problem, seine Grenzen und ein messbarer Erfolg werden definiert, bevor eine Lösung erwogen wird.
- 02
ModelModellieren
Die Domäne wird modelliert und in Kontexte geschnitten — mit einer präzisen, gemeinsamen Sprache.
- 03
DecideEntscheiden
Die tragenden Entscheidungen fallen zuerst, bewusst und dokumentiert, solange Ändern noch günstig ist.
- 04
ProveBeweisen
Ein lauffähiges Skelett beweist die Architektur auf dem riskantesten Pfad — vor der Breite.
- 05
BuildBauen
Auf dem bewiesenen Skelett entsteht das System in prüfbaren, umkehrbaren Schritten — Fortschritt wöchentlich sichtbar.
- 06
HardenHärten
Fehlerfälle, Last und Sicherheit werden geprüft, nicht angenommen. Aus „läuft“ wird „hält“.
- 07
OperateBetreiben
Wir betreiben, überwachen und entwickeln weiter — und halten das System verständlich und änderbar.
Vom Entwurf bis zum Betrieb.
Das System muss nicht nur laufen, sondern im Betrieb bestehen. Jede Empfehlung mit ihren Kosten — und dem Fall, in dem wir anders entscheiden.
Ziele und Geschäftsnutzen
Wir halten fest, was sich durch die Software ändern soll: welche Arbeit entfällt, welcher Fehler nicht mehr passiert, welche Entscheidung schneller möglich wird. Überprüfbar, wo es geht; ehrlich benannt, wo nicht.
Trade-off · Kosten: Zeit mit den Fachverantwortlichen statt mit Technik. Anders, wenn: das Ziel vorgegeben und unstrittig ist — dann genügt eine kurze Bestätigung.
Rollen und Arbeitsabläufe
Wer arbeitet mit dem System, wer ist betroffen, wer entscheidet? Wir beschreiben Nutzerrollen und die tatsächlichen Abläufe — einschließlich der Ausnahmen, die im Alltag regelmäßig vorkommen.
Trade-off · Kosten: Gespräche und Beobachtung bei mehreren Beteiligten. Anders, wenn: ein einzelnes Team das System allein nutzt — dann reicht eine knappe Rollenübersicht.
Anforderungen und Abgrenzung
Funktionale Anforderungen beschreiben, was das System tut; nichtfunktionale, unter welchen Bedingungen — Last, Verfügbarkeit, Datenschutz, Nachvollziehbarkeit. Beides wird priorisiert und in Muss und Kann getrennt.
Trade-off · Kosten: Wünsche werden sichtbar zurückgestellt. Anders, wenn: der Umfang bereits verbindlich feststeht — dann prüfen wir ihn auf Lücken und Widersprüche.
Daten, Schnittstellen und Bestand
Welche Daten entstehen, woher kommen sie, welches System ist führend? Welche Systeme werden angebunden, und wie gut sind ihre Schnittstellen dokumentiert? Hier liegen die meisten verdeckten Abhängigkeiten.
Trade-off · Kosten: früher Zugang zu Bestandssystemen und ihren Verantwortlichen. Anders, wenn: das Vorhaben keine bestehenden Daten und Systeme berührt.
Risiken und Abnahmekriterien
Technische Risiken und offene Entscheidungen werden benannt und bewertet. Für jede wesentliche Anforderung halten wir fest, woran ihre Erfüllung erkannt wird — die Grundlage für Test und Abnahme.
Trade-off · Kosten: unbequeme Fragen, bevor Zusagen gemacht werden. Anders, wenn: das Risiko nachweislich gering ist — dann bleibt die Bewertung knapp.
Phasen und Aufwandskorridor
Aus priorisiertem Umfang und Abhängigkeiten entstehen grobe Umsetzungsphasen und ein Aufwandskorridor mit seinen Annahmen. Er ist die Grundlage für Budget, Architektur und die Entscheidung, ob gebaut wird.
Trade-off · Kosten: keine verbindliche Zahl vor der Klärung. Anders, wenn: Umfang und Rahmen so klar sind, dass eine belastbare Schätzung direkt möglich ist.
Worauf Sie sich verlassen können.
- 01
Ein dokumentiertes Zielbild mit überprüfbaren Kriterien
- 02
Ein priorisierter Scope mit klarer Muss-/Kann-Abgrenzung
- 03
Eine Übersicht über Prozesse, Rollen und Verantwortlichkeiten
- 04
Ein Anforderungskatalog mit Abnahmekriterien
- 05
Eine Übersicht über Schnittstellen, Datenquellen und Bestandssysteme
- 06
Eine Risiko- und Abhängigkeitsanalyse mit offenen Entscheidungen
- 07
Eine Grundlage für die Wahl: Individualsoftware, Standardsoftware oder Abbruch
- 08
Umsetzungsphasen und Aufwandskorridor als Grundlage für Architektur und Umsetzung
Wann es passt — und wann nicht.
Die ehrliche Antwort gehört zur Beratung. Wir empfehlen den Weg, der zum Problem passt.
Passt
- Ein Vorhaben ist fachlich noch nicht ausformuliert, soll aber budgetiert, geplant und belastbar entschieden werden.
- Mehrere Abteilungen, Rollen oder Standorte arbeiten mit demselben System und bringen unterschiedliche Erwartungen mit.
- Die neue Software muss sich in Bestandssysteme, bestehende Daten oder laufende Abläufe einfügen.
- Es ist offen, ob Individualsoftware, ein Standardprodukt oder eine Kombination die richtige Antwort ist.
Passt nicht
- Ein kleines, klar umrissenes Vorhaben mit bekannten Nutzern und wenigen Abhängigkeiten. Dort genügt eine kompakte Klärung zu Beginn der Umsetzung — ein eigener Discovery-Abschnitt wäre Overhead.
- Anforderungen, Umfang und Rahmenbedingungen liegen bereits belastbar dokumentiert vor. Dann prüfen wir sie auf Lücken, statt sie neu zu erheben.
- Discovery als Pflichtritual vor jedem Auftrag. Workshops ohne Entscheidung am Ende erzeugen Dokumente, aber keine Grundlage.
Arbeitsmittel & Ergebnisse
Fragen zu Anforderungsanalyse & Software Discovery
Braucht jedes Vorhaben eine Discovery?
Nein. Bei kleinen, klar definierten Vorhaben genügt eine kompakte Klärung zu Beginn der Umsetzung. Die Tiefe richtet sich nach Unklarheit, Abhängigkeiten und Risiko — nicht nach einem festen Format.
Wie lange dauert eine Anforderungsanalyse?
Das hängt von Größe und Unklarheit des Vorhabens ab. Bei einem überschaubaren Vorhaben reichen wenige Gespräche und ein kompaktes Ergebnisdokument; sind mehrere Bereiche und Bestandssysteme beteiligt, dauert die Klärung entsprechend länger. Den Rahmen legen wir vorab gemeinsam fest.
Wie belastbar ist der Aufwand danach?
Belastbarer als vorher, aber nicht beliebig genau. Sie erhalten einen Aufwandskorridor mit den Annahmen, auf denen er beruht, und den Risiken, die ihn verschieben können. Je mehr geklärt ist, desto enger wird er.
Was, wenn sich herausstellt, dass wir nicht bauen sollten?
Dann ist das ein Ergebnis, kein Scheitern. Eine begründete Empfehlung für Standardsoftware, einen kleineren Zuschnitt oder den Verzicht kostet weniger als ein Projekt auf falscher Grundlage.
Mit welchen Arbeitsmitteln arbeiten Sie — und was erhalten wir?
Mit dem, was die Klärung braucht, nicht mit einem festen Werkzeugsatz: Prozessmodelle für die tatsächlichen Abläufe, Anforderungskataloge mit Priorität, Abnahmekriterien für die wesentlichen Anforderungen und Entscheidungsprotokolle für Entschiedenes und Offenes. Die Analyse legt sich dabei weder auf eine Technologie noch auf eine bestimmte Umsetzung fest.
Setzen Sie Ihren Engineering-Weg fort.
Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.
Verwandte Konzepte
Sprechen wir über Ihr Vorhaben.
Kein Vertrieb. Ein direktes Gespräch mit der Geschäftsführung.
