Kreislaufwirtschaft und Systems Engineering – Nachhaltigkeit neu denken
Die Kreislaufwirtschaft ist nicht nur ein Trend, sondern eine zukunftsweisende Herangehensweise an die Entwicklung technischer Systeme und Produkte.
Ganzheitliches Denken in der Krise – Warum wir umdenken müssen
Es reicht nicht, die Ursachen oberflächlich zu betrachten. Trockenheit, Erderwärmung, Klimawandel – all das sind keine neuen Phänomene
Kfz-Neuzulassungen im ersten Halbjahr 2024 in China: 40% Verbrenner und 60% E-Autos
Der Artikel diskutiert Deutschlands Tendenz, technologische Trends zu verschlafen, am Beispiel der E-Mobilität.
Die Rollen im Anforderungsmanagement
Neben den Anforderungsdokumenten haben wir auch noch die verschiedenen Rollen bei der Erstellung von Spezifikationen.
Auf der einen Seite haben wir den Kunden, der in seinem Lastenheft ein Problem beschreibt, das er gelöst haben will. Zusätzlich haben wir die Interessensgruppen, die ebenfalls ein Problem beschreiben, das sie allgemeingültig gelöst haben wollen.
Auf der anderen Seite haben wir das Projektteam mit jemandem, der sich mit dem ganzen Thema Requirements Engineering beschäftigt und versucht, überhaupt das Problem zu begreifen. Dann gibt es jemanden, der sich mit dem ganzen Systemdesign beschäftigt. Das ist jemand, der versucht, aus den Anforderungen eine Lösung zu definieren. Und dann haben wir einen Projektmanager, der halt in diesem ganzen Kontext noch versucht, das Team zum Erfolg zu führen.
Das zusammen ist genau die Schnittstelle, und wir sehen auch da: Auf der einen Seite liegen die Lastenhefte und auf der anderen Seite die Pflichtenhefte nach der klassischen Beschreibung.
Rollen im Anforderungsmanagement
Am Ende bilden die Rollen auch die Arbeitsergebnisse ab. Ein Requirements Engineer wird also die Anforderungsspezifikation (SRS) erschaffen. Ein Systemdesigner oder ein Systemarchitekt wird die Architekturspezifikation (SAS) schreiben, und der Projektmanager beschreibt in der Regel in seinem Projekthandbuch all die nichttechnischen Anforderungen an ein System.
Je komplexer Systeme werden oder je dynamischer ihre Funktion ist, desto wichtiger wird es, sich intensiv mit diesen Dokumenten und Spezifikationen zu beschäftigen. Ein System, das einen relativ einfachen Aufbau hat und auch keine großartige Dynamik besitzt, muss nicht in aller epischer Breite sämtliche oben beschriebenen Spezifikationen besitzen, wenn eigentlich klar ist, was wichtig ist. Das bedeutet aber, sie nicht komplett wegzulassen, sondern mit Sinn und Verstand nur das, was gebraucht wird, umzusetzen.
Je komplexer ein System wird oder gar je mehr Unterlieferanten dabei sind, also je mehr Menschen auch in diesem Projekt eingebunden sind, desto wichtiger werden Spezifikationen. Denn Spezifikationen sind am Ende nichts anderes als eine Dokumentation von Wissen.
Requirements-Engineering mit Word und Excel
Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Word und Excel zu arbeiten, was nicht immer einfach ist – und weswegen ich die nächsten Beiträge diesem Thema widmen möchte.
Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.
Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.
Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe „traditionell“ – die Word- oder auch Excel-Werkzeuge.
Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.
Das Ziel dieser Episoden ist es, euch das nötige KnowHow und viele Tipps zu vermitteln, um eure Spezifikationen mit Word zu handhaben. Zunächst habe ich ein paar Begriffsklärungen und ein wenig Hintergrundwissen für Leser, die die vorangegangenen Beiträge noch nicht kennen.
Wie detailliert soll ich Anforderungen beschreiben?
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?
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
Björn SchorreLastenheft vs. Pflichtenheft – Die verschiedenen Ebenen von Spezifikationen
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
Drei Kriterien, um die Qualität eines Lastenheftes sicherzustellen
Wenn ich Projekte begleite, kommt früher oder später folgende Frage auf: „Woran erkenne ich, ob ich mit meinen Requirements fertig bin?“
Es ist immer schwierig, geistige Leistung – und Requirements sind die Ergebnisse geistiger Arbeit – zu bewerten, und gerade bei den eigenen Arbeiten tun wir uns oft schwer.
Die meisten unter uns haben diese Erfahrungen mit selbstgeschriebenen Texten gemacht: Irgendwann sehen wir unsere Fehler einfach nicht mehr. Und leider schleichen sich aus diesem Grund auch schnell Fehler in die Requirements-Dokumente ein.
Damit das nicht passiert, nutze ich in der Praxis drei einfache Checks, die mir enorm weiterhelfen:
1) Testebene
Wenn ich Requirements beschreibe, ist es meine Aufgabe als Systemingenieur, bei jedem Requirement auch für die Testebene eine Empfehlung abzugeben. Fällt es mir schwer, nur eine Ebene anzugeben, und habe ich stattdessen mehrere Möglichkeiten, die ich auswählen kann, ist das Requirement sehr wahrscheinlich nicht gut beschrieben.
Als Konsequenz ändere ich also das Requirement, formuliere es detaillierter, teile es auf, schreibe es um – bis ich sicher nur eine Testebene empfehlen kann. Das hilft gleichzeitig auch dem Testkollegen, denn so kann er seine Tests frühzeitig entwerfen und die Abdeckung nachweisen.
2) Linkabdeckung
Im zweiten Schritt nutze ich den Filter meines Requirements-Management-Werkzeuges und schaue, ob es in meinem Dokument irgendwelche Requirements gibt, die keinen Link zu übergeordneten Anforderungen besitzen. Wenn mir der Filter Einträge dieser Art anzeigt, ziehe ich diese Links nach.
Anschließend prüfe ich mit einem weiteren Filter, ob es übergeordnete Anforderungen gibt, die keinen Link zu meinem Dokument haben. Wenn mir der Filter Einträge dieser Art anzeigt, prüfe ich, ob ich noch etwas in meinem Dokument vergessen habe, und erstelle entsprechende Anforderungen auf meiner Ebene (und verlinke diese natürlich!).
3) Reviews
Ich gebe meine Arbeitsergebnisse regelmäßig anderen Kollegen mit der Bitte, mir mit einem Peer-Review ein kurzes Feedback zu geben. Anschließend arbeite ich die Ergebnisse ein und lade zu einem formalen Review.
In dieser Review-Session übernehme ich alle Auffälligkeiten in ein Review-Protokoll und gewichte gemeinsam mit den Teilnehmern die Schwere der Auffälligkeiten. Wenn ich keine „Major“-Punkte und nicht mehr als zehn „Minor“-Punkte habe, ist die Reife der Requirements nach dem aktuellen Wissensstand gut genug. Ansonsten muss ich die Auffälligkeiten entsprechend korrigieren, bis ich unter meinem Grenzwert liege.
Wo genau Eure Grenzen sind, müsst Ihr in Euren Projekten selbst ausloten – die Requirements zu beschreiben, ist für mich eine sehr gute und ausreichende Hilfe.
Das Ergebnis
Mit dieser Vorgehensweise in drei Schritten habe ich die Möglichkeit, schnell zu erkennen, ob ich mit meinen Ergebnissen wirklich eine hohe Qualität erreiche.
Um diese für ein Lastenheft sicherzustellen und eine klare Aussage dazu treffen zu können, sind also die folgenden Aspekte hilfreich:
- Habe ich Schwierigkeiten, mich für eine Testebene zu entscheiden, befinden sich meine Aussagen wahrscheinlich nicht auf der richtigen Testebene und ich muss sie verbessern.
- Wenn ich ein Requirements-Management-Werkzeug nutze, kann ich überprüfen, ob alle Anforderungen verlinkt sind.
- Indem ich Reviews mit Kollegen durchführe, kann ich sicherstellen, dass ich nichts vergessen habe.
