Anforderungen an Individualsoftware definieren: Wie genau muss es sein?
Oktober 31, 2026 | by Silvan Erlenbach
«Die Anforderungen haben wir im Kopf.» Diesen Satz hören wir in fast jedem Erstgespräch. Wer Anforderungen an Individualsoftware definieren will, muss sie aus den Köpfen auf ein Papier bringen, bevor jemand eine Offerte schreibt. Sonst vergleicht man später Angebote, die gar nicht dasselbe versprechen.
Auf einen Blick
- Gute Anforderungen beschreiben, was die Software für wen leisten muss und woran man das prüft, nicht wie sie gebaut wird. Eine blosse Funktionsliste genügt nicht.
- Vier Bausteine tragen jedes Anforderungsdokument: Ziel, fachliche Anforderungen, technische Rahmenbedingungen und Abnahmekriterien.
- Die richtige Genauigkeit ist erreicht, wenn ein Entwickler ohne Rückfrage versteht, was gebraucht wird, und die Fachseite das Dokument noch liest.
- Die Fachseite liefert den Inhalt, eine Person mit Projekterfahrung strukturiert ihn. Wer nur die Entwicklerseite schreiben lässt, bekommt Anforderungen, die zur Lösung passen statt zum Problem.
Ein Muster aus der Praxis, bewusst ohne Namen: Ein Gewerbebetrieb im Thurgau wollte die Auftragsverwaltung aus einer gewachsenen Excel-Landschaft lösen. Die Anforderungsliste bestand aus Stichworten wie «Kundenverwaltung» und «Auswertungen». Mehrere Anbieter reichten Offerten ein, die sich im Preis deutlich unterschieden. Alle lagen richtig, denn jeder hatte unter den Stichworten etwas anderes verstanden.
Dieses Muster begegnet uns häufig. Es hat selten mit Nachlässigkeit zu tun, sondern damit, dass Fachleute ihren Alltag so gut kennen, dass sie das Selbstverständliche nicht mehr aufschreiben.
Anforderungen an Individualsoftware definieren: womit man anfängt
Der häufigste Fehler passiert im ersten Satz. Anforderungen werden als Lösung formuliert: «Wir brauchen ein Dashboard mit Filtern.» Besser ist das Problem dahinter: «Die Disposition muss morgens in einer Minute sehen, welche Aufträge diese Woche kritisch sind.» Aus dem zweiten Satz kann ein Entwickler mehrere Lösungen ableiten, aus dem ersten nur eine.
Wer Individualsoftware bestellt, kauft Spielraum. Dieser Spielraum ist nur dann ein Vorteil, wenn klar ist, wofür er genutzt werden soll. Für den Einstieg hilft es, die Anforderungen pro Hauptablauf zu sammeln, etwa «Auftrag erfassen», «Auftrag disponieren» und «Auftrag abrechnen», und nicht pro Bildschirm oder Funktion.
Wie man Software-Anforderungen grundsätzlich erhebt, zeigt unser Angebot zum Thema Anforderungen an Software definieren. Hier geht es darum, wie genau das Ergebnis sein muss.
Die vier Bausteine eines Anforderungsdokuments
Wenn Anforderungen unübersichtlich werden, liegt es meist daran, dass vier verschiedene Dinge in einer Liste vermischt sind. Sie auseinanderzuhalten, schafft schnell Ordnung.
Die Abnahmekriterien sind der unterschätzte Teil. Sie zwingen dazu, Wörter wie «schnell», «übersichtlich» oder «einfach» durch etwas Prüfbares zu ersetzen. Aus «Die Suche muss schnell sein» wird zum Beispiel «Eine Suche über den gesamten Auftragsbestand liefert ein Ergebnis, ohne dass die Sachbearbeitung merklich warten muss, getestet mit einem realistischen Datenbestand.»
Wie genau ist genau genug?
Zu wenig Detail führt zu Interpretationsspielraum, zu viel Detail zu einem Dokument, das niemand pflegt. Eine Faustregel aus unserer Projektpraxis: Detaillieren Sie dort, wo ein Irrtum teuer wäre, und bleiben Sie grob, wo sich Korrekturen später günstig machen lassen.
Teuer sind Irrtümer bei Geschäftsregeln (etwa Berechnungen, Fristen, Freigaben), bei Schnittstellen und bei Daten, die übernommen werden müssen. Günstig sind sie bei der Anordnung von Feldern oder der genauen Beschriftung. Beides kann in einem Prototyp oder in einer ersten Version angepasst werden.
Hilfreich ist eine einfache Dreiteilung: Was ist zwingend (Muss), was wünschenswert (Soll), was eine Option (Kann)? Entscheidend ist, dass nicht alles ein Muss ist. Wenn jede Zeile gleich wichtig ist, lässt sich am Ende nicht mehr entscheiden, was bei knappem Budget wegfällt.
Wer liefert, wer schreibt, wer entscheidet
Die Fachseite kennt den Ablauf, aber selten die Sprache, in der Entwickler ihn brauchen. Die Entwicklerseite kennt die Technik, aber nicht die Sonderfälle der Sachbearbeitung. Zwischen beiden braucht es jemanden, der übersetzt und strukturiert.
Bewährt hat sich, den Ist-Ablauf vorher einmal sauber aufzunehmen. Eine kurze Prozessanalyse deckt oft schon auf, dass zwei Abteilungen denselben Vorgang unterschiedlich erledigen. Solche Unterschiede sollten vor dem Pflichtenheft geklärt sein, nicht danach.
In der Praxis funktionieren zwei bis drei Workshops mit den Menschen, die den Ablauf täglich erledigen, besser als ein Fragebogen. Ein Beispiel aus einer Gemeinde in der Zentralschweiz: Erst im Gespräch mit der Einwohnerkontrolle zeigte sich, dass ein Sonderfall bei Wohnsitzwechseln den halben Ablauf bestimmt. In der schriftlichen Vorbereitung war er nirgends aufgetaucht.
Wer das Gespräch moderiert und das Ergebnis festhält, ist oft eine Projektleitung mit fachlicher Erfahrung. Die Verantwortung für die Inhalte bleibt aber bei der Fachseite. Das Bundesamt für Statistik weist aus, dass die grosse Mehrheit der Schweizer Unternehmen Kleinstunternehmen sind (Bundesamt für Statistik). Dort gibt es meist keine eigene IT-Abteilung, die Anforderungen schreibt, die Fachperson muss es also selbst tun, am besten mit etwas Begleitung.
Woran Anforderungen häufig scheitern
- Lösung statt Problem. Wer eine konkrete Bedienung vorschreibt, verbaut sich bessere Lösungen und zahlt oft für Umwege.
- Alles ist ein Muss. Ohne Gewichtung kann niemand priorisieren, und der Anbieter rechnet vorsichtshalber hoch.
- Die Sonderfälle fehlen. Der Normalfall ist leicht zu beschreiben. Aufwand und Streit entstehen bei den Ausnahmen, die nur wenige Personen im Haus kennen.
- Betrieb und Wartung vergessen. Wer betreut die Software nach der Einführung, wer pflegt Benutzerrechte, wer macht Updates? Diese Fragen gehören in die Anforderungen und nicht erst in die Betriebsübergabe.
- Datenübernahme unterschätzt. Altdaten sind selten so sauber, wie es die Fachseite annimmt. Was übernommen werden muss, gehört mit Umfang und Qualität in das Dokument.
Was mit den Anforderungen danach passiert
Das fertige Dokument ist keine Ablage, sondern die Grundlage für mehrere Schritte. Es wird zur Offertanfrage, zum Massstab beim Vergleich von Angeboten und später zur Basis der Abnahme. Bei Vorhaben der öffentlichen Hand fliesst es zudem in die Ausschreibungsunterlagen ein.
Unsicher ist oft, ob vorab ein Prototyp sinnvoll ist. Wenn eine zentrale Annahme zur Bedienung oder Technik offen bleibt, lohnt er sich fast immer. Bei klaren, stabilen Abläufen genügt in der Regel ein gutes Dokument.
Wenn Sie Anforderungen strukturieren möchten und dafür eine Aussensicht brauchen, erreichen Sie uns unter +41 77 491 77 94 oder per E-Mail an info@tprojects.ch. Das Erstgespräch ist kostenlos.
Verwandte Themen
Software entwickeln lassen Kosten: Was ein Budget wirklich bestimmt, Fachapplikation entwickeln lassen: Was die Fachseite vorher liefern muss, Individualsoftware entwickeln lassen oder Standard kaufen? Eine Entscheidungshilfe, Vor dem grossen Budget: Software Prototyp erstellen lassen, Wenn Excel zur Fachanwendung wird: Excel ablösen durch Software
Über den Autor
FAQ
Was gehört in die Anforderungen an eine Individualsoftware?
Vier Dinge: das Ziel der Software, die fachlichen Abläufe samt Sonderfällen, die technischen Rahmenbedingungen wie Schnittstellen, Datenschutz und Betrieb sowie Abnahmekriterien, an denen sich jede wichtige Anforderung prüfen lässt. Eine Funktionsliste allein genügt nicht, weil sie nichts darüber sagt, wozu die Funktion dient.
Wie lang sollte ein Anforderungsdokument sein?
So lang, dass ein Entwickler ohne Rückfrage versteht, was gebraucht wird, und so kurz, dass die Fachseite es noch liest. Für ein überschaubares Vorhaben sind das in unserer Projektpraxis oft wenige Seiten pro Hauptablauf. Entscheidend ist die Prüfbarkeit, nicht der Umfang.
Wer schreibt die Anforderungen: Fachseite, IT oder externe Stelle?
Inhaltlich liefert die Fachseite, weil sie den Ablauf kennt. Formulieren und strukturieren hilft eine Person mit Projekterfahrung, oft eine interne oder externe Projektleitung, die das Dokument führt, ohne den Inhalt zu besitzen. Die Entwicklerseite sollte mitlesen, aber nicht allein schreiben, sonst entstehen Anforderungen, die zur Lösung passen statt zum Problem.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft beschreibt, was der Auftraggeber braucht. Das Pflichtenheft hält fest, wie der Anbieter es umsetzen will. Bei Software für die öffentliche Hand beginnt der Weg meist mit dem Lastenheft, das in eine IT Beschaffung einfliesst; das Pflichtenheft entsteht danach gemeinsam mit dem gewählten Anbieter.
Können sich Anforderungen während der Entwicklung ändern?
Ja, und das ist normal. Wichtig ist, dass Änderungen bewusst und sichtbar entschieden werden: Was kommt dazu, was fällt weg, was verschiebt sich? Wer das im Rahmen einer breiteren Digitalisierung früh regelt, vermeidet, dass Zusatzwünsche still das Budget aufzehren.
Wann braucht es dafür externe Unterstützung?
Wenn niemand im Haus Erfahrung mit Anforderungsarbeit hat, wenn mehrere Abteilungen unterschiedliche Vorstellungen haben oder wenn die Anforderungen als Grundlage für eine Ausschreibung dienen. Eine neutrale Person moderiert dann die Workshops und schreibt das Ergebnis so auf, dass es auch Dritte verstehen. Für die Einordnung im Gesamtvorhaben hilft die PMO Beratung.
RELATED POSTS
View all
Projektleitung ERP-Einführung ad interim: Wann externe Führung den Unterschied macht
Juni 21, 2026 | by Selina Tannenried
Vor dem grossen Budget: Software Prototyp erstellen lassen
Oktober 29, 2026 | by Selina Tannenried
Externe Projektleitung Ostschweiz: Wann sie KMU wirklich entlastet
August 11, 2026 | by Selina Tannenried