Anforderungen richtig erheben

Von Redaktion techport.ai, IT-Beratung · Zuletzt aktualisiert am 21. August 2026

Der teuerste Satz in IT-Projekten lautet: So haben wir uns das nicht vorgestellt. Er fällt regelmäßig im Test, also an der Stelle, an der Änderungen am meisten kosten. Die Ursache liegt fast nie darin, dass jemand schlecht gearbeitet hätte. Sie liegt darin, dass Anforderungen als Sammlung von Wünschen erhoben wurden statt als Beschreibung dessen, was am Ende funktionieren muss.

Eine gute Anforderung ist prüfbar. Man kann feststellen, ob sie erfüllt ist, ohne über Absichten zu diskutieren. Das klingt selbstverständlich und ist in der Praxis der Unterschied zwischen einem Projekt mit Abnahme und einem Projekt mit Nachverhandlung.

Woran Sie es merken

Anforderungen stehen als Stichworte in einer Tabelle, jeder Punkt ist wichtig.
Im Test kommen Fragen auf, die im Workshop schon gestellt wurden.
Der Anbieter sagt, das sei nicht beauftragt gewesen, und beide Seiten haben recht.
Es gibt keine Person, die im Zweifel entscheidet, was gilt.

Warum das passiert

Anforderungen werden meist von den Menschen erhoben, die den Prozess täglich machen, und die beschreiben ihn so, wie er heute läuft, einschließlich der Umwege, die aus Einschränkungen des alten Systems entstanden sind. Gleichzeitig fehlt die Übersetzung in eine Form, die ein Anbieter prüfen und ein Entwickler umsetzen kann. Dazu kommt die verständliche Neigung, alles aufzuschreiben, was jemals gewünscht wurde, weil niemand die Verantwortung für eine Streichung übernehmen will.

So gehen wir vor

Prozess vor Funktion. Wir beginnen mit dem Ablauf, nicht mit einer Funktionsliste: Wer macht was, in welcher Reihenfolge, mit welchen Informationen, und wo entstehen heute Wartezeiten und Fehler. Aus diesem Ablauf leiten wir ab, was ein System können muss.
Anforderungen prüfbar formulieren. Wir schreiben jede Anforderung so, dass ihre Erfüllung feststellbar ist, mit Auslöser, erwartetem Ergebnis und Sonderfällen. Dazu kommen die nichtfunktionalen Punkte, die später am häufigsten für Streit sorgen: Antwortzeiten, Mengengerüste, Berechtigungen, Protokollierung, Verfügbarkeit.
Priorisieren und entscheiden lassen. Wir gewichten nach Muss, Soll und Kann, und zwar mit einer benannten Person je Fachbereich, die diese Entscheidung treffen darf. Ohne diese Rolle wird jede Anforderung zum Muss und die Priorisierung wertlos.
Änderungen geordnet zulassen. Wir richten ein einfaches Verfahren ein, mit dem neue Anforderungen im laufenden Projekt bewertet, mit Aufwand versehen und bewusst entschieden werden. Nicht jede Änderung ist schlecht, aber jede Änderung muss sichtbar sein.

Was Sie davon haben

Angebote, die vergleichbar sind, weil alle dieselbe Grundlage haben.
Eine Abnahme, die auf Kriterien beruht statt auf Eindrücken.
Weniger Nachverhandlungen, weil weniger offen bleibt.

Aus unseren Projekten

Wenn wir Anforderungen aus dem Prozess ableiten statt aus einer Sammlung von Wünschen, fällt regelmäßig ein erheblicher Teil der ursprünglichen Punkte weg. Der häufigste Grund: Sie beschreiben Umwege, die es nur gibt, weil das alte System etwas nicht konnte. Der zweithäufigste: Sie sind Sonderfälle, die einmal im Jahr auftreten und für die eine manuelle Lösung günstiger ist als eine dauerhafte Funktion. Diese Streichungen sind unangenehm, solange sie als Verzicht wahrgenommen werden, und einfach, sobald der Aufwand je Anforderung sichtbar wird.

Häufige Fragen

Wie detailliert müssen Anforderungen sein?

So detailliert, dass ein Anbieter ein verbindliches Angebot abgeben und ein Tester die Erfüllung prüfen kann. Bei Standardsoftware genügt meist die Ebene des Ablaufs mit den relevanten Sonderfällen. Bei Eigenentwicklung braucht es zusätzlich Feld- und Regelebene, weil dort niemand einen Standard als Rückfallebene hat.

Wer sollte die Anforderungen verantworten?

Eine Person aus dem Fachbereich, die den Prozess kennt und entscheiden darf, unterstützt von jemandem, der die Formulierung prüfbar macht. Wenn die IT allein die Anforderungen schreibt, werden sie technisch. Wenn der Fachbereich sie allein schreibt, bleiben sie unprüfbar. Beide Rollen zusammen führen zu einem Dokument, mit dem man arbeiten kann.

Sprechen wir über Anforderungen richtig erheben

Im Erstgespräch klären wir in dreißig Minuten, wo bei Ihnen der größte Hebel liegt und ob wir die Richtigen dafür sind.

Erstgespräch vereinbaren Unsere Software

Weiterführend

Entwickeln und beschaffenSoftware auswählen und einführenWie eine Softwareauswahl gelingt: Anforderungen aus Prozessen ableiten, Anbieter mit eigenem Drehbuch vergleichbar machen, Verträge prüfen, Migration planen und die Nutzung sichern.Einführen und verändernIT-Projekte, die liefernWarum IT-Projekte im Mittelstand scheitern und was hilft: Rollen besetzen, Umfang begrenzen, Entscheidungen dokumentieren, Risiken früh benennen und den Abschluss an Nutzung koppeln.Entwickeln und beschaffenIndividualentwicklung richtig einsetzenWann Eigenentwicklung dem Standard überlegen ist, wie Sie Abhängigkeit von Einzelpersonen vermeiden, Qualität sichern, Quellcode und Rechte sichern und den Betrieb langfristig tragen.WissenIT-GlossarBegriffe aus IT, Software und Sicherheit, kurz erklärt.WissenIT-Reifegrad-CheckIn zehn Minuten wissen, wo Ihre IT steht.

Zurück zum Feld Entwickeln und beschaffen