Ein Lastenheft, mit dem Ihr Softwareprojekt konkret wird.
Ein gutes Lastenheft erklärt, welches Problem gelöst werden soll, welche Anforderungen verbindlich sind und woran Sie das Ergebnis prüfen. Dafür brauchen Sie zuerst Wissen über Ihren Arbeitsalltag, keine fertige technische Architektur.
Lastenheft und Pflichtenheft: Zweck und Umsetzung unterscheiden
Im Lastenheft beschreibt der Auftraggeber die benötigten Ergebnisse und Rahmenbedingungen. Das Pflichtenheft konkretisiert anschließend die geplante Umsetzung. Beide Dokumente müssen zueinander passen; ihre Bezeichnung allein sagt jedoch wenig über die Qualität der Anforderungen aus.
Für ein erstes Gespräch ist ein vollständiges Dokument nicht nötig. Bei mehreren beteiligten Abteilungen oder einem Angebotsvergleich hilft eine gemeinsame schriftliche Grundlage, unterschiedliche Erwartungen sichtbar zu machen. Die folgende Struktur ist eine praktische Arbeitshilfe, keine starre Pflicht für jedes Projekt.
Diese Inhalte sollten Ihre Anforderungen abdecken
- Ausgangslage und Ziel: Welcher konkrete Engpass besteht, und was soll sich für welche Beteiligten ändern?
- Prozessgrenzen: Wo beginnt und endet der betrachtete Ablauf? Was gehört ausdrücklich nicht zur ersten Ausbaustufe?
- Nutzer und Rollen: Wer liest, bearbeitet, genehmigt, administriert oder arbeitet vertretungsweise?
- Anwendungsfälle: Beschreiben Sie typische Vorgänge und wichtige Ausnahmen mit Eingang, Bearbeitung und Ergebnis.
- Daten und Systeme: Welche Informationen werden benötigt, welches System führt sie und welche Zugänge sind vorhanden?
- Betrieb und Schutzbedarf: Wann wird die Anwendung benötigt, welche Daten verarbeitet sie und wer unterstützt bei Störungen?
- Einführung und Abnahme: Wer liefert Testdaten, wer prüft Ergebnisse und welche Voraussetzungen gelten für den Start?
Aus einem Wunsch eine prüfbare Anforderung machen
„Die Software soll benutzerfreundlich sein“ ist ein nachvollziehbarer Wunsch, aber noch kein prüfbarer Umfang. Beschreiben Sie stattdessen, welche Aufgabe die betreffende Rolle mit welchen Informationen erledigen soll. Ergänzen Sie ein beobachtbares Ergebnis und die wichtigen Fehlerfälle.
| Bestandteil | Konkretes Beispiel |
|---|---|
| Kennung und Priorität | AF-01, Muss-Anforderung der ersten Ausbaustufe |
| Ausgangssituation | Eine Sachbearbeiterin hat einen Auftrag mit allen Pflichtangaben erfasst. |
| Gewünschtes Verhalten | Aufträge mit einer abweichenden Kondition werden einer berechtigten Person zur Freigabe vorgelegt. |
| Erwartetes Ergebnis | Die Entscheidung und der Bearbeitungsstand sind am Auftrag erkennbar. |
| Negativtest | Ein Nutzer ohne Freigaberecht kann die Entscheidung auch über einen direkten Aufruf nicht ausführen. |
| Offene Frage | Welche Konditionen gelten als Abweichung, und wer übernimmt bei Abwesenheit? |
Prioritäten und offene Fragen getrennt führen
Nicht jede sinnvolle Idee muss in die erste Version. Kennzeichnen Sie Anforderungen als unverzichtbar, sinnvoll für den ersten Umfang oder später zu prüfen. Jede unverzichtbare Anforderung braucht eine fachliche Begründung. Das erleichtert die Diskussion, wenn Budget oder Termin einen kleineren Start erfordern.
Unbekannte Schnittstellen, unklare Datenqualität oder nicht entschiedene Freigaberegeln gehören in eine Liste offener Punkte. Weisen Sie für jeden Punkt einen Ansprechpartner und einen Klärungstermin zu. Eine unbestätigte Annahme sollte nicht unbemerkt zur zugesagten Funktion werden.
Schnittstellen so beschreiben, dass sie kalkulierbar werden
Nennen Sie Systeme und Versionen, betroffene Datenobjekte, Übertragungsrichtung und benötigte Aktualität. Ergänzen Sie, wer Dokumentation und Testzugänge bereitstellen kann. Beschreiben Sie außerdem, was passieren soll, wenn Daten fehlen oder eine Übertragung fehlschlägt.
Sie müssen dafür kein API-Konzept entwerfen. Die fachliche Aussage „Ein freigegebener Auftrag wird genau einmal im ERP angelegt; das Ergebnis bleibt nachvollziehbar“ ist für den Einstieg hilfreicher als eine vorschnell festgelegte Technologie.
Den Umfang vor dem Angebotsvergleich gemeinsam durchgehen
Lassen Sie Fachbereich, IT und Projektverantwortliche denselben typischen Vorgang prüfen. Stimmen Anfang, Ende, Rollen und Ausnahmefälle überein? Sind Migration, Tests und Einführung als eigene Aufgaben enthalten? Kann die spätere Betreuung mit den beschriebenen Anforderungen arbeiten?
Für den Vergleich sollten Anbieter fehlende Informationen, Abhängigkeiten und Ausschlüsse ausdrücklich benennen. Ein vollständig klingendes Angebot ist wenig wert, wenn die wichtigsten Annahmen ungeprüft bleiben. Die Vorlage hilft Ihnen, diese Fragen früh zu ordnen; wir können das Anforderungsbild anschließend gemeinsam schärfen.