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 auf einen Blick.
Die wichtigsten Punkte für Ihre Entscheidung: wann es passt, wie wir vorgehen und worauf wir achten.
- 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.
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
Wann es passt — und wann nicht.
Wir empfehlen den Weg, der zum Vorhaben passt — auch wenn das ein Standardprodukt ist.
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.
Entscheidungen, bevor Code entsteht.
Nicht was die Technik kann, sondern warum wir sie so einsetzen.
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.
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.
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.
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.
Risiken, die wir früh erkennen.
Was in Systemen dieser Art typischerweise schiefgeht — und wie wir es vermeiden, bevor es in Produktion sichtbar wird.
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.
- Abwägung
- 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.
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.
- Abwägung
- Kosten: Zeit der Fachanwender, die im Tagesgeschäft fehlt. Anders, wenn: der Ablauf neu entsteht und es noch keine gelebte Praxis gibt.
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.
- Abwägung
- 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.
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.
- Abwägung
- Kosten: Aufwand bei den Verantwortlichen der Bestandssysteme, bevor die Umsetzung feststeht. Anders, wenn: das Vorhaben eigenständig ist und keine bestehenden Systeme berührt.
Fragen, die wir vor der Umsetzung klären.
Ihre Antworten prägen die Architektur stärker als die Wahl der Werkzeuge.
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 Folge
- 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.
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 Folge
- Wir beziehen beide Gruppen ein und leiten Rollen, Rechte und nichtfunktionale Anforderungen daraus ab.
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 Folge
- Deckt ein Standardprodukt den Bedarf, empfehlen wir es. Individuell gebaut wird der Teil, der das Unternehmen tatsächlich unterscheidet.
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 Folge
- Wir erstellen eine Schnittstellen- und Datenübersicht und bewerten jede Anbindung nach Risiko, bevor ein Aufwand genannt wird.
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 Folge
- Wir schneiden den ersten Umfang entlang eines vollständigen Ablaufs und ordnen die folgenden Phasen danach.
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 Folge
- Jede offene Entscheidung erhält einen Verantwortlichen und einen Zeitpunkt; der Aufwandskorridor benennt die Annahme, die sie bis dahin ersetzt.
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.
Abwägung · 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.
Abwägung · 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.
Abwägung · 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.
Abwägung · 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.
Abwägung · 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.
Abwägung · 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.
Vom ersten Gespräch bis zum laufenden System.
Jedes Projekt folgt denselben vier Schritten. Zwischenstände sehen und prüfen Sie unterwegs, nicht erst am Ende.
- 01
Verstehen und Anforderungen klären
Im ersten Gespräch mit der Geschäftsführung geht es um Ihr Vorhaben, Ihre Abläufe und die vorhandenen Systeme. Danach halten wir Ziele und Anforderungen schriftlich fest und sagen offen, ob eine individuelle Entwicklung sinnvoll ist.
- 02
Lösung und Architektur planen
Wir schlagen eine technische Lösung vor, legen Umfang und Reihenfolge der Umsetzung fest und dokumentieren die tragenden Entscheidungen mit ihrer Begründung.
- 03
Entwickeln und gemeinsam prüfen
Wir entwickeln in Etappen, mit Tests und Code-Reviews. Zwischenstände stellen wir regelmäßig vor, damit Sie früh prüfen und Prioritäten anpassen können.
- 04
In Betrieb nehmen und weiter betreuen
Nach dem Start übernehmen wir im vereinbarten Umfang Wartung, Updates, Überwachung und Weiterentwicklung. Der projektspezifische Quellcode und die Dokumentation gehen an Sie über.
Was Sie am Ende in der Hand haben.
Ein dokumentiertes Zielbild mit überprüfbaren Kriterien
Ein priorisierter Scope mit klarer Muss-/Kann-Abgrenzung
Eine Übersicht über Prozesse, Rollen und Verantwortlichkeiten
Ein Anforderungskatalog mit Abnahmekriterien
Eine Übersicht über Schnittstellen, Datenquellen und Bestandssysteme
Eine Risiko- und Abhängigkeitsanalyse mit offenen Entscheidungen
Eine Grundlage für die Wahl: Individualsoftware, Standardsoftware oder Abbruch
Umsetzungsphasen und Aufwandskorridor als Grundlage für Architektur und Umsetzung
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.
Verwandte Themen.
Leitfäden, Entscheidungen, Leistungen und Arbeiten, die mit dieser Seite zusammenhängen.
Verwandte Konzepte
Sprechen wir über Ihr Vorhaben.
Beschreiben Sie kurz Ihr Vorhaben. Das erste Gespräch führen Sie direkt mit der Geschäftsführung.
