In Pflichtenheften für komplexe Systeme macht es mit Sicherheit keinen Sinn den letzten Controller-PIN oder den Variablennamen im Quellcode zu beschreiben, sondern nur, was ich konzeptionell erwarte, sprich, ich erwarte ein Geschwindigkeitssignal in einer gewissen Auflösung in einem gewissen Wertebereich, und damit hat es sich dann. Wie der Softwerker das unten auf seiner Ebene in seiner Spezifikation und in seine Lösung umsetzt und dass er da irgendwelche Coding-Styleguides berücksichtigt usw. usw., das werde ich oben auf Systemebene schon gar nicht beschreiben.

Das tue ich schlicht aus dem Grund, dass ich ihm auch einen Lösungsraum bereit halte, mit dem er 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 a) ist er schwer verständlich und b) schränkt er 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.

Aus der Praxis eines Troubleshooters