Bild zu Rollen im RE

Die Rollen im Anforderungsmanagement

/in ,

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

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.

Wie detailliert soll ich Anforderungen beschreiben?

/in ,

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 ,

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 ,

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

Warum? Eine Frage nach dem Sinn …

/in

Als Freiberufler und Podcaster bin ich im Mai 2014 auf den Podcast „Erfolg mit Leidenschaft“ von Markus Cerenak gestoßen. Nach meinem Feedback zu einer Episode hat Markus mich angemailt und mich gefragt „Warum schreibst du deinen Blog? Warum möchtest du Leser unterstützen? Warum ist deine Leidenschaft DEINE Leidenschaft? Warum?“

Ich fand diese Frage sehr anregend. Gerade als Business Podcaster halte ich diese Frage für unglaublich wichtig. Denn diese Frage klärt für mich und auch für dich als Teil der Community, was mich im Innersten antreibt, meinen Podcast zu senden.

So bin ich seinem Aufruf gefolgt und habe für den ZukunftsArchitekten und für den lifestyle:entrepreneur diese Frage näher beleuchtet.

Warum sende ich den ZukunftsArchitekten Podcast? Warum baue ich die Systems Engineering Akademie als Plattform auf?

Mein Wissen konservieren. Ich bin seit 2000 als Mechatronikingenieur in der Automobilentwicklung unterwegs. Zunächst als Embedded Softwerker, dann als Projektleiter und Troubleshooter. Ich habe 2005 meinen angestellten Job geschmissen und bin „auf die Walz“ gegangen. Ich wollte die Welt sehen. Was lag näher, als meine Erfahrung zu nutzen. So habe ich als Troubleshooter internationale Entwicklungsprojekte gerettet. Mit dem Podacst habe ich die Möglichkeit, mein Wissen zu konservieren. Wenn ich mich irgendwann mal verabschiede, mein Wissen und meine Erfahrung werden für dich erhalten bleiben. So das du daraus lernen kannst.

Eine Community aufbauen und vernetzen. Systemingenieure sind bis heute noch sehr rar. So kämpfen viele noch mit ihrer Rolle und ihrer Verantwortung in den Projekten und in den Firmen. Ich merke immer wieder auf Hörertreffen, wie wichtig es für die Hörer ist, sich auszutauschen. Jenseits von Firmenpolitik und klassischen Ingenieurdogmen. Umso mehr treibt es mich an, für dich und die Hörer eine Community aufzubauen, in der du dich vernetzen und deine Erfahrungen mit anderen Systemingenieuren austauschen kannst.

Dich inspirieren und neue Sichten erschaffen. Ich habe in den Entwicklungsbereichen vieler Firmen zu viele Säue durchs Dorf treiben sehen. Viele Beratungsfirmen nutzen gerne die Trends aus, um damit Geld zu verdienen. Nicht alles war schlecht, aber vieles total gehyped. Mir geht es beim ZukunftsArchitekten darum, dir neue Einsichten zu geben und dich in deiner Rolle und deiner Berufung als Systemingenieur zu inspirieren. Damit du für dich eine eigene Meinung bilden kannst. Unabhängig von irgendwelchen aktuellen Strömungen.

Wissen unabhängig von Zeit und Ort. Viel zu oft habe ich erlebt, dass ich als Entwicklungsingenieur auf ein Problem gestoßen bin und nach einer Lösung suchte. Was war die nächstliegende Idee? Ich brauche zu einer Methode oder einem Tool eine Schulung. Aber gerade bei uns als Ingenieuren sind Schulungen oftmals zwei oder drei Tage lang. So hat zwar jedes Unternehmen ein Seminarbudget für die Weiterbildung, aber jeder Projektleiter wird sein Veto einlegen, wenn genau sein Projekt gerade in einer kritischen Phase ist. Also konnte ich die Schulungen besuchen, wenn dafür etwas Zeit war. Und wann war das? Zwischen dem Wechsel vom alten in das neue Projekt. Da hatte ich aber das Problem nicht mehr zu lösen. Also habe ich viele tolle Dinge in Seminaren gelernt. Wenn ich im neuen Projekt dann aber das Wissen brauchte, war die Schulung schon wieder sechs Monate her, und ich hatte fast alles vergessen. Deshalb ist es mein Ziel, mit der Systems Engineering Akademie und dem ZukunftsArchitekten eine webbasierte Quelle aufzubauen, die es dir ermöglicht, unabhängig von Zeit und Ort, genau dann, wenn du ein Problem lösen musst, das wesentliche Wissen abzurufen, damit du direkt dein Problem lösen kannst.

Einen schönen Tag aus Köln!

Digitalisierung im Maschinenbau? Ist Software der Wertetreiber der Zukunft?

/in

„In den nächsten fünf Jahren wird Software in unseren Produkten kein Thema sein“.

So endete im Dezember 2013 ein Gespräch mit dem Entwicklungsleiter eines großen, bekannten Technologieunternehmens. Mir blieb nur, nachdenklich den Konferenzraum zu verlassen. Die ganze Fahrt zurück nach Hause kreisten meine Gedanken um das, was da geschehen war.

Da ich schon früh meine ersten Zeilen Code geschrieben hatte und seit über 18 Jahren beruflich mit Embedded Software und komplexen Systemen zu tun habe – zunächst als Softwareingenieur, später als Systemingenieur – stellt sich für mich die Frage „Brauchen wir Embedded Software in zukünftigen Produkten?“ einfach nicht. Für mich ist das absolut selbstverständlich.

Aber dieser Entwicklungsleiter war felsenfest davon überzeugt, dass in seinem Produktsegment und auch im Markt bei den Wettbewerbern das Thema Software einfach nicht ansteht. Er sah in der Digitalisierung keine Chancen und bestand darauf, dass sein Vorsprung am Markt in den nächsten Jahren durch die exzellenten konstruktiven und technologischen Fähigkeiten seines Produktbereiches gesichert sei. Ja, Elektronik würde vielleicht noch mit dazu kommen, aber Software – nein.

Liege ich so falsch? Habe ich vielleicht eine sehr einseitige Sicht, geprägt durch meine Vergangenheit? Ich war tief verunsichert. So trieb mich seit dem fragwürdigen Tag die Frage umher: „Ist Software der Wertetreiber der Zukunft?“

Woran kann ich den Trend erkennen?

Also begab ich mich auf die Suche nach interessantem Wissen und hilfreichen Indizien, die mir diese Frage beantworten können. Aus Gesprächen bei Hörertreffen, über Twitter und durch Hörermails bekam ich mit der Zeit immer mehr Informationen, durch die sich ein Bild formte.

Ich habe bei dieser Suche zwei sehr wichtigste Impulse aus der Community erhalten:. Zum einen den Vortrag „520 Wochen Zukunft — die zweite Dekade der großen Chancen“ von Lars Thomsen, einem Zukunftsforscher aus Zürich. Zum anderen das Hörertreffen in Paderborn, bei dem ich das erste Mal mit einer Gruppe von Maschinenbauern in Kontakt kam, die in einem Spitzencluster mit dem Namen „it’s OWL“ das Thema Software im Maschinenbau in ihrer Region vorantreiben.

Das Video findet ihr unter https://www.youtube.com/watch?v=sHsPyymMZ4s.

Den Spitzencluster findet ihr unter http://www.its-owl.de.

Was ist das Ergebnis?

Das Ergebnis meiner Recherche hat am Ende meine Meinung deutlich verfestigt. Software wird der Wertetreiber der Zukunft sein. Dabei habe ich mehrere grundlegende Faktoren ausgemacht:

  • Das Mooresche Gesetz gilt immer noch. Damit verbunden ist die Verdoppelung der Leistungsfähigkeit alle 12 Monate. Anders ausgedrückt: Alle 12 Monate halbieren sich die Kosten für Hardware, die wir brauchen, um komplexe Aufgaben mit Software zu erledigen. Das beste Beispiel sind die Arduinos als kostengünstige Möglichkeit, komplexe Aufgaben zu automatisieren. Als ich 2000 als Softwareingenieur eingestiegen bin, haben wir für vergleichbare Entwicklungssysteme noch tausende von Euros ausgegeben. Heute kosten Arduinos nicht mal 100 Euro und sind sogar einfacher zu bedienen.
  • Kein Maschinenbaubereich wird unangetastet werden. Dazu gibt es genug Beweise aus der näheren Vergangenheit. Ein sehr bekanntes Beispiel ist Kodak und deren feste Überzeugung, dass die analoge Fotografie nie durch die Digitalisierung ersetzt werden kann. Heute sind sie nicht mehr da.
  • Immer mehr Funktionen und Nutzen werden ins Web übertragen. Damit wachsen Embedded- und IT-Software immer mehr zusammen. Ein Beispiel ist der Einstieg von Google und Apple in den Automobilsektor. Sehr interessant sind die reflexartigen Reaktionen der „Big Player“ der klassischen Maschinenbaubranche „Automobil“.
  • In China verlassen seit 2012 mehr Absolventen die Universitäten, als in den USA Kinder geboren werden. Und trotz der Ein-Kind-Politik wird in den nächsten Jahren China versuchen, weltweit regelrecht alle Spezialisten zu sich zu ziehen, um seinen Bedarf an Fachkräften zu stillen. Mittlerweile beginnen chinesische Unternehmen damit, ihre Entwicklungszentren nach Deutschland zu verlegen.

Was ist nun die Quintessenz?

  • Ich glaube, wenn sich der klassische, konstruktionsgetriebene Maschinenbau – der mit seinen durchaus sehr anspruchsvollen Produkten unsere Wirtschaft als Hidden-Champions in der Nische prägt – sich nicht dieses Jahr mit dem Thema Software intensiv und professionell beschäftigt, werden wir im deutschen Mittelstand noch unser blaues Wunder erleben.
    Ja, ich weiß, Software ist für Maschinenbauer ein schwer zu greifendes Thema. Software können wir nicht anfassen, es gibt nicht die Möglichkeit, sie haptisch zu begreifen. Und tausende von Zeilen Quellcode auszudrucken bringt uns auch nicht mehr Erkenntnis. Software ist wie Geld. Das Papier des 100 € Scheins ist auch keine 100 € wert – wir geben ihm seinen Wert.
    Wir müssen lernen, mit Software in und um die Produkte professionell und wertschöpfend umzugehen.
  • Verbunden mit dem Thema Software, wird auch das Thema Systeme immer mehr in den Vordergrund treten. Software an sich ist nicht deterministisch, im Gegensatz zur Elektronik oder der Konstruktion. Wenn ich zu viel Spannung auf einen Kondensator gebe, gibt es schicke Rauchwölkchen. Wenn ich auf einen Hebel mit zu viel Kraft beaufschlage, wird er brechen. Das ist bei Software anders. Software erzeugt keine Rauchwölkchen und wird nicht brechen. Das Verhalten ist nicht deterministisch. Das führt dazu, dass softwaregetriebene Systeme schlicht komplexer werden.
    Die Beherrschung der Systemebene und der software erfahrene Systemingenieur als Führungskräfte werden in maschinenbau geprägten Unternehmen zukünftig der entscheidende Schlüssel für Erfolg oder Niederlage sein.
  •  China ist eine jahrtausendealte Nation, wenn nicht die älteste überhaupt. Sie hatten in den letzten paar hundert Jahren einfach nur eine „Formkrise“. Ihre Kultur, den Meister zu kopieren, ist für die westlich orientierten Unternehmen mit ihrer Patentkultur einfach nur schwer zu verstehen. Sie werden vom Meister lernen, und Software können wir nicht patentieren (was aus meiner Sicht auch keinen Sinn ergibt).
    Es führt zu einer einzigen möglichen Konsequenz – wir müssen einfach besser sein!

Brauchen wir jetzt noch den Maschinenbau? Wird der Konstrukteur und der Elektroniker überflüssig?

Software braucht ein Zuhause, und dieses Zuhause wird entweder funktional oder designgetrieben sein. 

Also wird sich die Aufgabe des Konstrukteurs genau dahin verschieben. Wir sehen das schon seit Jahren in der Automobilentwicklung. Dort geht es um Packaging (wie bekomme ich den Kram unter?), um die Bedienung (Wie kann ich die Steuerung des komplexen Systems so einfach wie möglich gestalten?) und um Design (wie kann ich mein Produkt emotionalisieren?). Eine sehr anspruchsvolle Aufgabe.

Genauso wird sich die Aufgabe des Elektronikers verschieben. Wir sehen das schon seit Jahren im Telefonbereich. Dort geht es um die Frage: Wie kann ich dem Softwerker eine optimale Plattform bereitstellen. Mit den Faktoren Bauraum (für die Konstrukteure), Umwelt (Vernetzung, EMV, ESD) und Zukunftsfähigkeit (für die nachträgliche Aktualisierung). Nicht minder anspruchsvoll!

Aber als Mechatronikingenieur glaube ich: Die heutigen Führungskräfte aus den klassischen Ingenieursdisziplinen müssen sich bewusst machen, dass schon heute die Software in ihren Produkten der Wertetreiber für ihre Kunden darstellt. Ob sie es glauben oder nicht. Denn Unternehmen, die das Thema Embedded Software gar nicht oder nur stiefmütterlich behandeln, werden einfach in den nächsten Jahren große Schwierigkeiten haben, überhaupt noch am Markt zu überleben.

Die Zukunft wird das entscheiden. 520 Freitage und wir werden uns wieder sehen.