Wie detailliert soll ich Anforderungen beschreiben?

/in , /von

In Pflichtenheften für komplexe Systeme ergibt es mit Sicherheit keinen Sinn, die letzten Controller-PINs oder den Variablennamen im Quellcode zu beschreiben.  Wichtig ist, dass ich das, was ich konzeptionell erwarte, z.B. ein Geschwindigkeitssignal in einer gewissen Auflösung in einem gewissen Wertebereich, beschreibe.  Wie das Software-Team das unten auf deren Ebene in seine Spezifikation und in seine Lösung umsetzt und dass da irgendwelche Coding-Styleguides berücksichtigt werden usw. usw., das werde ich oben auf Systemebene schon gar nicht beschreiben.

Das tue ich schlicht aus dem Grund, dass ich dem Team auch einen Lösungsraum bereithalte, mit dem es arbeiten kann. Das macht es gerade dann besonders schwierig, und das ist häufig auch meine Erfahrung, wenn Kunden versuchen, im Pseudocode im Lastenheft Funktionen zu beschreiben. Dann bin ich auf der Systemebene immer gefordert, davon wieder zu abstrahieren, um klar zu verstehen, was will der Kunde eigentlich will. In der Regel nehme ich dann SysML, um ein Verhalten als Diagramm darzustellen. Ein Pseudocode im Lastenheft geht nämlich schon fast bis zu Variablennamen herunter. Damit ist es a) schwer verständlich und b) schränkt es den Lösungsraum auf 0 ein.

Das mag zwar ganz nett sein, aber wir haben immer bei komplexen Systemen das Problem, dass wir zwischen verschiedenen Lösungsmöglichkeiten abwägen müssen. Wenn ich keinen Handlungsspielraum mehr habe, werde ich an der Stelle dermaßen fixiert, dass ich möglicherweise das gesamte System überhaupt nicht lösungs- und zielorientiert umsetzen kann. Bei all diesen Spezifikationen gilt für einen pragmatischen Einsatz: Je einfacher ein System und je weniger Anforderungen vorhanden sind, desto weniger müssen Sie sich mit komplexen Spezifikationsstrukturen herumschlagen.
Bei manchen reicht aus meiner Erfahrung heraus die Architekturspezifikation (SAS) völlig aus. Man soll in Verbindung mit dem System Footprint auf der Lastenheftebene (= Kundenebene = „Wünsch-dir-was“ des Kunden oder Produktmanagements) einfach pragmatisch bleiben.

Wichtig: Weglassen heißt nicht komplett weglassen, sondern nur, das, was sie mit Sinn und Verstand als nutzlos nicht brauchen. Aber definitiv lassen sie nicht diese gesamte Ebene weg, sonst kommen sie in Situationen, dass sie nachher nicht mehr nachvollziehen können, was sie da eigentlich wollten, und der Kunde nicht das Gewünschte bekommt.

Was ist ein Pflichtenheft?

/in , /von

Wie immer gibt es wunderschöne Normen, und gemäß der DIN 69901-5 enthält das Lastenheft “die vom Auftraggeber festgelegte Gesamtheit der Anforderung an die Lieferung und Leistungen eines Auftragnehmers innerhalb eines Auftrags”. So kann man es bezeichnen. Ich würde einfach das Ganze mal ein bisschen pragmatischer sehen: Das Lastenheft beschreibt in der Regel, womit und wofür etwas gemacht werden soll. Mit anderen Worten, es ist am Ende des Tages das „Wünsch-dir-was“ des Kunden aus seiner Sicht.

Aber auch über das Pflichtenheft sagt die DIN 69901-5 etwas: “die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes”.  Schön, oder einfacher gesagt, das Pflichtenheft beschreibt, wie und womit etwas realisiert wird. Das ist dann die Antwort auf das Lastenheft des Kunden. Er schreibt sein Wünsch-dir-was, und im Pflichtenheft schreibe ich, wie ich das Problem verstanden habe und was ich davon umsetzen kann.

Ich habe ja einigen Episoden schon darüber referiert. Mir gefallen aus der heutigen Sicht die Begriffe „Lastenheft“ und „Pflichtenheft“ nicht mehr. Sie sind aus meiner Sicht zu allgemein. Wir müssen es gerade bei komplexeren Projekten detaillierter und differenzierter sehen. Und gerade beim Thema Systempflichtenhefte gibt es eben zwei Dokumente, die zusammen das Bild eines Pflichtenhefts ergeben. Auf der einen Seite das Dokument Systemanforderungsspezifikation (SRS), also die Beschreibung des Problembereichs. Das Ziel dieses Dokuments ist, die definierten Kundenanforderungen in einen Satz von technischen Systemanforderungen zu übertragen, die das System begleiten.

Dann gibt es noch ein zweites Dokument, die Systemarchitekturspezifikation (SAS). Das ist eigentlich der Lösungsbereich. Hier beschreibe ich, wie ich die Lösung entwerfen will, denn hier entstehen nochmals andere Anforderungen. Nicht alle Systemanforderungen werde ich erfassen, sondern ich muss mir auch auf der Architekturseite Gedanken über die Vollständigkeit der Anforderung machen. Das Ziel dieses Dokumentes ist die Identifikation, welche Anforderungen, welche Komponenten dann welchen Elementen des Systems zugeordnet werden müssen.

Diese beiden Dokumente sind zusammen ist eigentlich das, was im allgemeinen Sprachgebrauch Pflichtenheft genannt wird. Als Systemingenieur rede ich natürlich auch von dem Systempflichtenheft oder Systemspezifikationen, das heißt, beide Dokumente sind konzeptionell gehalten.

Aus der Praxis für die Praxis

 

Stapel mit Heften und DokumentenBjörn Schorre

Lastenheft vs. Pflichtenheft – Die verschiedenen Ebenen von Spezifikationen

/in , /von

Wie können Projekte pragmatisch mit Lastenheft und Pflichtenheft umgehen? Ein Thema, das zurzeit eine Menge Leute beschäftigt und bei dem wir einige Zusammenhänge besprechen müssen, um später die Umsetzung besser zu verstehen.

Ein Aspekt, der in diesem ganzen Zusammenhang mit Lastenheften und Pflichtenheften mitspielt: Es gibt Spezifikationen auf verschiedenen Ebenen. Ich erkläre ganz bewusst ein paar neue Begriffe, weil Lastenheft und Pflichtenheft aus meiner Sicht heraus alte Begriffe sind und damit zu allgemein für diese Herausforderung. Weiterlesen