Das Lastenheft aus dem Betrieb heraus: was der Auftraggeber beschreibt, bevor Software entsteht

Das Lastenheft hält den Bedarf in der Sprache des Betriebs fest

Ein Lastenheft ist die schriftliche Beschreibung, mit der ein Betrieb vor der Beauftragung festhält, welche Arbeit eine künftige Software in seinem Alltag erledigen soll, wer mit ihr arbeitet und unter welchen Bedingungen das geschieht. Gelesen wird es vom Auftragnehmer, der darauf sein Angebot aufbaut. Seine Erwiderung schreibt er in ein zweites Dokument, das Pflichtenheft. Darin erklärt er, wie er die Anwendung bauen will und was genau er liefert.

Aus dieser Arbeitsteilung folgt die Sprache des Lastenhefts. Es beschreibt Vorgänge mit den Worten, die im Betrieb verwendet werden: Auftrag, Kommission, Aufmaß, Rückmeldung, Freigabe. Diese Worte tragen in jedem Betrieb eine eigene Bedeutung. Ein „Auftrag“ kann im einen Haus die unterschriebene Bestellung des Kunden meinen, im anderen den internen Arbeitsauftrag an die Werkstatt. Liest ein Entwickler das Wort mit seiner eigenen Bedeutung, baut er etwas, das zur Beschreibung passt und zum Betrieb nicht.

Technische Begriffe braucht das Lastenheft nur dort, wo sie im Betrieb bereits feststehen, etwa der Name eines vorhandenen Programms, an das angeschlossen werden soll. Alles Übrige bleibt Sache des Auftragnehmers. Damit bleibt das Dokument für die Personen lesbar, die seinen Inhalt bestätigen müssen: die Fachabteilung und die Geschäftsführung.

Ein Ablauf wird vom Auslöser bis zum Ergebnis beschrieben

Ein Ablauf ist eine Folge von Arbeitsschritten, die durch ein bestimmtes Ereignis beginnt und mit einem Ergebnis endet, das sich prüfen lässt. Diese beiden Enden geben der Beschreibung ihren Rahmen. Ohne sie wird aus der Ablaufbeschreibung eine Sammlung von Wünschen, bei der unklar bleibt, wann die Software tätig wird und woran erkennbar ist, dass sie fertig ist.

1. Der Auslöser legt fest, wann der Ablauf beginnt

Am Anfang steht das Ereignis, das den Vorgang in Gang setzt: Eine Anfrage geht ein, ein Wartungstermin wird fällig, eine Lieferung trifft im Lager ein, ein Mitarbeiter meldet einen Schaden. Das Lastenheft nennt dieses Ereignis und sagt, auf welchem Weg es den Betrieb heute erreicht: per Telefon, über ein Formular, als Papierbeleg oder aus einem anderen Programm.

2. Jeder Schritt nennt Eingang, Tätigkeit und Ergebnis

Zwischen Auslöser und Ende beschreibt das Lastenheft jeden Schritt mit drei Angaben. Welche Information liegt vor, wenn der Schritt beginnt. Was geschieht mit ihr, also was wird geprüft, ergänzt, berechnet oder entschieden. Und was liegt vor, wenn der Schritt abgeschlossen ist. Wer einen Schritt so beschreibt, merkt sofort, wo eine Information fehlt oder an zwei Stellen erfasst wird.

3. Das Ende ist ein Ergebnis, das jemand prüfen kann

Der Ablauf endet mit einem Zustand, den eine dritte Person feststellen kann: Das Angebot ist versandt, die Rechnung ist gebucht, die Prüfung ist dokumentiert und dem Kunden zugestellt. An genau diesem Zustand misst der Betrieb bei der Abnahme, ob die Software ihren Zweck erfüllt. Je genauer er benannt ist, desto eindeutiger fällt diese Prüfung aus.

Beschrieben wird der Ablauf, wie er heute tatsächlich läuft, mit allen Behelfen: dem Zettel am Bildschirm, der zweiten Tabellendatei, dem Rückruf beim Kollegen, weil eine Angabe im Programm fehlt. Genau diese Behelfe zeigen, wo die neue Software Arbeit abnehmen soll. Den gewünschten künftigen Ablauf hält das Lastenheft daneben fest, getrennt vom heutigen, damit sichtbar bleibt, was sich ändern soll.

Jede Rolle im Ablauf bekommt eine Bezeichnung und eine Aufgabe

Eine Rolle ist eine Aufgabe innerhalb des Ablaufs, die eine oder mehrere Personen übernehmen, etwa Auftragsannahme, Disposition, Monteur, Prüfer oder Freigabe durch die Leitung. Das Lastenheft beschreibt Rollen unabhängig von den Namen der Personen, die sie heute ausfüllen. So bleibt die Beschreibung gültig, wenn jemand ausscheidet, eine Vertretung einspringt oder eine Person zwei Rollen zugleich innehat.

Zu jeder Rolle gehören vier Angaben. Erstens, welche Informationen sie sehen muss, um ihre Arbeit zu erledigen. Zweitens, welche Angaben sie selbst erfasst oder ändert. Drittens, welche Entscheidungen bei ihr liegen, einschließlich der Grenzen, ab denen eine zweite Person zustimmen muss. Viertens, an wen sie den Vorgang übergibt, wenn ihr Schritt abgeschlossen ist.

Rollen außerhalb des Betriebs gehören ebenfalls ins Lastenheft: Kunden, die einen Auftrag verfolgen oder Unterlagen abrufen, Lieferanten, die eine Bestätigung abgeben, Außendienstmitarbeiter, die unterwegs auf ein Gerät angewiesen sind. Für jede dieser Gruppen ändert sich, was die Software leisten muss, vom Zugang über die Bedienung bis zur Frage, welche Daten sichtbar sein dürfen. Wie aus den Rollen später ein Rechtemodell mit Freigabegrenzen und Vertretungen entsteht, behandelt der Beitrag Rollen in der Geschäftssoftware.

Mengen und Spitzenzeiten legen die Auslegung der Software fest

Ein Mengengerüst ist die Aufstellung, wie viele Vorgänge, Datensätze und gleichzeitig arbeitende Personen die Software im Alltag und in Spitzenzeiten bewältigen muss. Der Auftragnehmer leitet daraus ab, wie er Datenhaltung, Suche und Verarbeitung auslegt. Eine Anwendung für wenige Vorgänge am Tag wird anders gebaut als eine, die in der Hochsaison ein Vielfaches davon verarbeitet.

In ein Mengengerüst gehören diese Angaben:

• Vorgänge je Zeiteinheit. Wie viele Aufträge, Prüfungen oder Anfragen laufen an einem üblichen Tag und an einem besonders starken Tag durch den beschriebenen Ablauf.
• Bestand an Datensätzen. Wie viele Kunden, Artikel, Objekte oder Verträge die Software verwalten soll, einschließlich des Altbestands, der aus dem bisherigen Programm übernommen wird.
• Gleichzeitige Nutzung. Wie viele Personen zur selben Zeit mit der Software arbeiten, und zu welchen Tageszeiten sich das ballt.
• Wiederkehrende Spitzen. Monatsende, Saisonbeginn, Inventur, Jahresabschluss: Zeiträume, in denen sich Vorgänge häufen und die Software trotzdem zügig antworten muss.
• Erwartete Entwicklung. Mit welchem Wachstum der Betrieb in den Jahren rechnet, für die die Software geplant wird, etwa durch einen neuen Standort oder eine zusätzliche Leistung.

Die Zahlen stammen aus den eigenen Unterlagen des Betriebs: aus dem bisherigen Programm, aus den Auftragsbüchern des Vorjahres, aus der Zeiterfassung. Ein gezählter Wert aus dem letzten Jahr ist verlässlicher als eine Schätzung im Gespräch, weil die Schätzung meist den durchschnittlichen Tag beschreibt und die Spitze unterschlägt.

Ausnahmen gehören mit ihrer Häufigkeit ins Lastenheft

Eine Ausnahme ist jeder Fall, in dem ein Vorgang vom beschriebenen Regelablauf abweicht: Der Kunde bestellt um, die Ware kommt in Teilen, ein Messwert liegt außerhalb der Grenze, eine Pflichtangabe fehlt, ein Eilauftrag überholt die Reihenfolge. In der Beschreibung des Regelablaufs tauchen solche Fälle selten auf, weil die Beteiligten sie längst als Teil der täglichen Arbeit erledigen und gar nicht mehr als Abweichung wahrnehmen. Für die Software sind sie entscheidend, denn jede Ausnahme braucht einen Weg, den das Programm kennt.

Das Lastenheft hält zu jeder Ausnahme drei Angaben fest: wie oft sie vorkommt, wie der Betrieb sie heute behandelt und wer darüber entscheidet. Die Häufigkeit bestimmt, wie die Software mit der Ausnahme umgeht.

• Häufige Ausnahmen bekommen einen eigenen, geführten Weg in der Software, mit den Feldern und Entscheidungen, die dieser Fall verlangt.
• Seltene Ausnahmen dürfen von Hand bearbeitet werden. Die Software kennzeichnet den Fall, übergibt ihn an eine zuständige Person und hält fest, wie er erledigt wurde.

Diese Unterscheidung schützt das Vorhaben vor zwei Fehlentwicklungen. Wird jede denkbare Ausnahme als eigener Programmweg bestellt, wächst der Umfang, ohne dass der Alltag spürbar leichter wird. Fehlt der Umgang mit seltenen Fällen ganz, landen sie wieder in der Tabellendatei neben der neuen Software, und das alte Nebeneinander entsteht von vorn.

Der Betrieb beschreibt Schnittstellen über die Daten, die wandern

Eine Schnittstelle ist die Verbindung, über die zwei Programme Daten austauschen, ohne dass jemand sie abschreibt oder von Hand überträgt. Aus Sicht des Betriebs zählt dabei, welche Daten zwischen welchen Programmen wandern und wozu. Diese Sicht kann nur der Betrieb liefern, und sie gehört ins Lastenheft.

Für jede gewünschte Verbindung nennt das Lastenheft das vorhandene Programm, etwa die Warenwirtschaft, die Buchhaltung oder die Zeiterfassung, und die Daten, die fließen sollen: Kundenstamm, Artikel, Aufträge, gebuchte Stunden. Es sagt, in welchem Programm die maßgebliche Fassung einer Angabe liegt, wenn beide Seiten sie führen. Und es beschreibt, wie der Austausch heute geschieht, ob über eine exportierte Datei, über erneutes Eintippen oder über eine Rückfrage per Telefon.

Wie aktuell die übertragenen Daten sein müssen, gehört ebenfalls hierher, und zwar in Worten des Alltags: „Der Disponent muss den Lagerbestand vor der Zusage sehen“ sagt mehr über den Bedarf als eine technische Taktangabe. Welche weiteren Fragen eine Schnittstelle technisch aufwirft, vom Umgang mit Fehlern bis zur Überwachung im Betrieb, stellt der Beitrag Schnittstellen zwischen zwei Systemen zusammen.

Fachabteilung und Geschäftsführung liefern verschiedene Teile

Ein Lastenheft speist sich aus zwei Quellen im Betrieb, und das Dokument braucht beide. Die Fachabteilung kennt die Arbeit, die Geschäftsführung kennt den Rahmen, in dem sie sich verändern soll. Fehlt eine der beiden Stimmen, beschreibt das Dokument entweder einen Ablauf ohne Ziel oder ein Ziel ohne Bezug zur täglichen Arbeit.

Die Fachabteilung liefert Abläufe, Fälle und Zahlen

Aus der Fachabteilung kommen die Ablaufbeschreibungen, die Ausnahmen mit ihrer Häufigkeit, die Mengen aus den eigenen Unterlagen und die Begriffsliste. Gemeint sind ausdrücklich auch die Personen, die den Vorgang täglich ausführen. Wer eine Maske täglich bedient, kennt die Stelle, an der heute ein Feld fehlt und deshalb ein Zettel geschrieben wird.

Die Geschäftsführung legt Ziel, Umfang und Rahmen fest

Die Geschäftsführung bestimmt, was sich durch die Software ändern soll und woran der Betrieb das nach der Einführung erkennt. Sie entscheidet, welche Abläufe zum Vorhaben gehören und welche später folgen, und sie legt die Reihenfolge fest, wenn nicht alles gleichzeitig kommen kann. Zum Rahmen gehören der Termin, an dem die Software benötigt wird, der Budgetrahmen, die Frage, wem der Quellcode gehört, und die internen Vorgaben zum Umgang mit Daten.

Eine Person führt die Beiträge zusammen

Zwischen beiden Quellen braucht es eine benannte Person, die das Lastenheft zusammenführt. Sie sammelt die Beiträge, legt Widersprüche offen, holt Entscheidungen der Geschäftsführung ein und ist für den Auftragnehmer der Ansprechpartner. Ohne diese Zuständigkeit bleiben Widersprüche zwischen Abteilungen im Dokument stehen, und der Auftragnehmer entscheidet sie beim Programmieren nach eigenem Ermessen.

Ein Lastenheft darf benannte offene Fragen enthalten

Ein Lastenheft wird vor der Beauftragung geschrieben, und zu diesem Zeitpunkt lässt sich nicht jede Frage beantworten. Manche Antworten ergeben sich erst, wenn die Beteiligten mit ersten Bildschirmen arbeiten. Eine offene Frage ist unbedenklich, solange sie im Dokument steht, mit der Person, die sie klärt, und mit dem Zeitpunkt, bis zu dem die Antwort vorliegen muss.

Offen bleiben dürfen zum Beispiel diese Punkte:

• die Gestaltung der Bildschirme und die Reihenfolge der Felder
• der genaue Umgang mit seltenen Ausnahmen, die von Hand bearbeitet werden
• der Inhalt späterer Ausbaustufen, die nach dem ersten Betrieb geplant werden
• Auswertungen, deren Bedarf sich erst mit echten Daten zeigt

Vor der Beauftragung feststehen müssen die Punkte, nach denen der Auftragnehmer Aufwand und Lösung bemisst: das Ziel des Vorhabens, die Abläufe, die zum Umfang gehören, die beteiligten Rollen, das Mengengerüst in seiner Größenordnung und für jede Datenart das Programm, in dem ihre maßgebliche Fassung liegt. Bleibt einer dieser Punkte offen, kann kein Anbieter ein belastbares Angebot abgeben, und Angebote verschiedener Anbieter lassen sich nicht vergleichen.

Abnahmekriterien entstehen aus den beschriebenen Fällen

Ein Abnahmekriterium ist eine prüfbare Bedingung, an der Auftraggeber und Auftragnehmer gemeinsam feststellen, ob die gelieferte Software eine beschriebene Anforderung erfüllt. Bei der Abnahme prüft der Betrieb die Software gegen diese Bedingungen und gibt sie frei. Die Kriterien lassen sich am leichtesten formulieren, wenn das Lastenheft die Fälle bereits enthält, an denen geprüft wird.

Jeder beschriebene Ablauf liefert einen Prüffall mit drei Teilen: der Ausgangslage vor dem ersten Schritt, der Handlung der zuständigen Rolle und dem Ergebnis, das am Ende vorliegen muss. Aus den übrigen Abschnitten des Lastenhefts folgen weitere Prüffälle.

1. Ausnahmen werden zu eigenen Prüffällen. Jede häufige Ausnahme bekommt einen Fall, der ihren Weg durch die Software prüft. Bei seltenen Ausnahmen wird geprüft, ob die Software den Fall kennzeichnet und an die zuständige Person übergibt.
2. Rollen ergeben Prüfungen der Rechte. Für jede Rolle wird geprüft, dass sie sieht und ändert, was ihre Aufgabe verlangt, und dass Freigaben oberhalb ihrer Grenze bei der zweiten Person landen.
3. Das Mengengerüst ergibt eine Prüfung unter Last. Die Software wird mit dem Datenbestand und der Zahl gleichzeitiger Personen geprüft, die das Lastenheft für die Spitzenzeit nennt.
4. Schnittstellen ergeben Prüfungen des Datenflusses. Ein Auftrag, der in der neuen Software angelegt wird, muss im angeschlossenen Programm mit den beschriebenen Angaben ankommen, und umgekehrt.

Ob eine Bedingung als Kriterium taugt, zeigt ein einfacher Test: Zwei Kollegen prüfen getrennt und notieren dasselbe Ergebnis. Den Wunsch nach einer schnellen Suche bewertet dagegen jeder nach eigenem Empfinden. Messbar wird er, sobald der Betrieb angibt, wonach gesucht wird und wie lange es höchstens dauern darf, bis die Treffer erscheinen. Die Zeitangabe selbst stammt aus dem Arbeitsalltag: Sie richtet sich danach, wie lange ein Kunde am Telefon auf die Auskunft warten kann.