Episode 213 – Wie ordne ich Anforderungen aus Normen richtig ein? Music. Ja, herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst.
So wirst du in dieser Episode erfahren, wie Anforderungen aus Normen richtig kategorisiert werden können und wie weit die Normenanforderungen aufgeteilt werden müssen, um sinnvoll damit umgehen zu können. Ja, einer meiner Hörer, der Maximilian Kastner, hat mich gefragt, beziehungsweise hat auf meine Umfrage geantwortet, wo ich nach den größten Herausforderungen bei Systemanforderungen und der Architektur gefragt habe.
Er schrieb mir, seine größte Herausforderung wäre die Einordnung von Requirements in die richtigen Kategorien. So ist seine Frage in zwei Teile aufgeteilt. Und zwar erstens, ist zum Beispiel aktive Entladung des Hochvoltsystems eine Einschränkung oder kann ich es als funktionale Anforderung definieren? Wird eine solche Norm, in Klammern LV123, speziell aufgedröselt oder allgemein nur auf diese verwiesen? Und der zweite Teil, inwieweit muss ich auf Systemebene DTCs definieren?
Muss ich hierfür Priorität, Verlernzähler etc. Definieren oder geschieht dies erst auf einer späteren Abstraktionsebene? Genau so, wie Maximilian seine Fragen gestellt hat, möchte ich die jetzt auch beantworten und zum einen zu dem ersten Punkt kommen. Die aktive Entladung eines Hochvoltsystems ist aus meiner Sicht, wenn ich das richtig verstanden habe, ein Anwendungsfall, den der Gesetzgeber von dem zu entwickelnden System fordert.
Daher ist es erst einmal eine Einschränkung, weil es nicht direkt mit dem Nutzen des Systems zu tun hat bzw. auf diesen einzahlt. Das könntet ihr auch nochmal nachschauen in meinem System Footprint. Aber es ist auch eine Funktion, denn das System muss irgendetwas tun Also es muss, ohne dass von außen irgendeine Aktion an dem System durchgeführt wird Egal ob durch den Benutzer oder eine Schnittstelle, muss das System irgendetwas tun Deswegen versteckt sich darin auch eine funktionale Anforderung.
Aber es steckt dort auch eine nicht-funktionale Anforderung in diesem Wunsch, denn wir müssen höchstwahrscheinlich auch die Architektur und das Design entsprechend anpassen. Was ich mir jetzt hier gerade darunter vorstellen kann, ist, dass diese Energie, die in dem System vorhanden ist, ja irgendwo hin abgeführt werden muss. Und das wird üblicherweise dann durch entsprechende Architektur- und Designentscheidungen getroffen.
Welche Anforderungen dafür wichtig sind, das sind die sogenannten nicht-funktionalen Anforderungen. Und wenn ich das jetzt richtig aufgefasst habe, was Maximilian da beschrieben hat, dann ist genau das die Frage, die er sich hier stellt. Wie soll man also da mit diesen Anforderungen umgehen? Meine Empfehlung ist, diese Anforderung als sogenannte Einschränkung aufzunehmen und entsprechend zu attributieren.
Was ich nicht machen würde, ist dafür einen eigenen Anforderungstypen zu definieren, sondern ich würde dort Attribute wählen, wo ich dann die Anforderung einkategorisieren kann in, es ist eine funktionale, es ist eine nicht funktionale oder es ist vielleicht eine einschränkende Anforderung.
Den Vorteil, den ich mir dadurch erarbeite, ich kann auch später noch sehen, dass ich diese Anforderung als eine Einschränkung erkannt habe und als eine Einschränkung in meine Systementwicklung aufgenommen habe.
Was nun im weiteren Verlauf des Systementwicklungsprozesses passieren kann, ist, dass aus dieser Einschränkung auf vielleicht sogar auf derselben Ebene, also auf der Systemebene oder auf tiefer liegenden Ebenen, wo es dann in die Domänen, in die Fachabteilungen geht, dass dort detailliertere Anforderungen werden, die eventuell andere Attribute haben, zum Beispiel funktional oder eben auch nicht funktional.
Was aber wirklich wichtig ist, ist, dass diese Anforderung auf der Systemebene hier, diese Anforderung der aktiven Entladung, frühzeitig identifiziert worden ist. Denn nur so werdet ihr in die Lage versetzt oder könnt ihr euch in die Lage versetzen, dass ihr ein umfassendes Systemdesign aufstellen könnt und wo das Systemdesign auch so robust aufgebaut ist, dass, falls dort nochmal irgendwelche Anpassungen notwendig sind, dass das recht einfach möglich ist.
Dadurch, dass ihr hoffentlich diese Anforderungen auch frühzeitig gefunden habt, ist ein erneuter Entwicklungsdurchlauf nicht unbedingt notwendig. Dadurch, dass ihr zu Anfang diese Anforderungen auch gefunden habt, werdet ihr nicht in das Risiko laufen, aufgrund von einer späteren Findung dieser Anforderung nochmal den Entwicklungsdurchlauf starten zu müssen und spart euch somit auch Zeit ein. Ja, der zweite Teil dieser Frage geht darum, ob Normen komplett aufgeschlüsselt werden sollten.
Erstmal, in den Normen stehen ganz viele Kapitel mit vielen Anforderungen, Einschränkungen und Informationen drin. Das jetzt alles abzuschreiben oder, falls möglich, in ein Requirements Management Tool zu importieren, würde einen wahnsinnig großen Aufwand mit sich bringen.
Zum einen müssten die Anforderungen, wie gesagt, abgeschrieben oder importiert werden, dann müsstet ihr hergehen, die Anforderungen alle einzeln bewerten und diese Anforderungen unter Umständen, je nachdem wie euer Prozess da gestaltet ist, in eurem eigenen Haus nochmal freigeben. Das wäre vielleicht sogar noch der langwierigste Teil, weil über jede Anforderung dann dort nochmal explizit diskutiert wird.
Welches Ziel verfolgt ihr damit oder welches große Ziel steckt dann dahinter, dass für jeden Testfall eine Anforderung im Requirements Management Tool stehen soll und zwar wirklich für jeden Testfall eine Anforderung, also eine 1 zu 1 Beziehung. Das ist oftmals die Forderung, die dann irgendwie Tester an ein solches System haben. Das ist aus meiner Sicht aber gar nicht notwendig, da eine Anforderung auch von mehreren Testfällen referenziert werden kann.
Dann stellt euch einfach nur mal vor, es gibt schon einen Haufen Testfälle bei euch im Haus, die sind schon alle erstellt worden, weil sich die Testmanager, Testteams schon mit diesen Normen beschäftigt haben und haben da viele Punkte aufgeführt, die dafür gesorgt haben, dass das System auch zugelassen werden kann. Und jetzt müsste es unter Umständen mal nachdokumentiert werden, das Ganze. Und jetzt wird gefordert, ihr müsst für jeden Testfall auch eine Anforderung dort stehen haben.
Das ist prinzipiell erst mal richtig, diese Aussage. Aber bitte auch die Kirche im Dorf lassen und einfach mal überlegen, wie kann ich das denn hinbekommen, dass jeder Testfall eine Anforderung hat. Das geht nämlich auch, indem ich einen Testfall ... Auch auf eine Anforderung verlinke, die schon einen anderen Testfall verlinkt hat. Also auch das ist durchaus möglich. Also das war jetzt nochmal ein kurzer Abstieg in, welches Ziel verfolgt ihr damit eigentlich.
Aber um jetzt von Anfang an reinzusteigen und die Normen richtig zu behandeln, empfehle ich, dass ihr die Normen, so wie ihr sie bekommt, wenigstens die als Titel zu importieren. Und jetzt kann es manchmal sein, dass es auch in diesen Dokumenten nochmal verschiedene Kapitel gibt, die entweder umgesetzt werden, gar nicht umgesetzt werden oder nur teilweise umgesetzt werden.
Und dann ergibt es Sinn, wenn man neben der Entscheidung, ich nehme nur die Referenz und den Titel des Dokumentes als Anforderung mit auf, dass man dann auch vielleicht nochmal die Hauptkapitelstruktur der Norm mit reinnimmt. Und dann hat man schon mal eine etwas feinere Zergliederung und das hilft durchaus schon mal weiter. Dann könnt ihr nämlich die Teile der Norm nutzen, die wirklich relevant sind für euer Produkt und andere können ignoriert werden, die gar nicht benötigt werden.
So, und wie könnt ihr das hinbekommen? Helfen können euch dabei die Mitarbeitenden aus der Zertifizierung, aus dem Test oder der Homologation.
Die haben nämlich ein wahnsinnig gutes Wissen und schon großes Wissen über diese Normen, weil sie das ja auch oftmals schon getestet haben, das System und das gegen diese Normen gespiegelt haben und können euch natürlich dann entsprechend helfen, ob jetzt eine Norm komplett getestet werden muss und damit also auch einfach nur das gesamte Normdokument als Anforderung referenziert wird oder ob nur Teile daraus geprüft werden müssen und so man
dann vielleicht auf einer Hauptkapitelstruktur der Norm sich reduzieren kann. Ja, die Kollegen aus diesen Bereichen der Zertifizierung, Test und Homologation haben nämlich schon oftmals, und das ist meine Erfahrung, diese ganzen Testfälle erstellt, um vorhergehende Projekte oder die vorhergehende Generation an einer Baureihe an den Markt zu bringen. Und daher könnt ihr auch gut und gerne diese Struktur der Tests als Hilfe benutzen, wie Normen in Anforderungen überführt werden können.
Der nächste Teil der Frage von Maximilian bezieht sich auf die DTCs, das sind die sogenannten Diagnostic Trouble Codes oder Fehlercodes, die für die Diagnose in Fahrzeugen benutzt werden. Und dazu wollte er wissen, inwieweit das schon auf Systemebene definiert werden muss. Da ich jetzt hier nicht ganz vom Fach bin, muss ich Annahmen bezüglich der Priorität treffen.
Ich behaupte mal, die Priorität eines DTCs besagt, welcher Fehler andere überdeckt, wenn nur ein Fehler im Fahrzeug angezeigt werden soll. Und die andere Annahme ist, oder das habe ich mir mal angelesen, der Verlernzähler. Den Begriff kannte ich jetzt auch noch nicht, aber der Verlernzähler zeigt also die Anzahl der fehlerfreien Fahrzyklen an, die erforderlich sind, bis dieser gespeicherte Fehlercode sich selbst löscht.
Also bedeutet, es können Fehler auftreten, die durch das System diagnostiziert worden sind, aber wenn der jetzt über eine längere Zeit, über mehrere Fahrzyklen oder Zündungszyklen nicht mehr aufgetreten ist, dann soll der auch wieder verschwinden. So, das kurz zu ein paar Definitionen, die hier in der Frage aufgetaucht sind. So, und die Frage war aber, wo oder wann müssen diese Diagnostic Trouble Codes festgelegt werden?
Da bin ich der Meinung, die müssen auf der Ebene festgelegt werden, wo auch der Überblick über alle anderen Teilsysteme im Fahrzeug vorhanden ist. Und das ist meistens eine der obersten, allerobersten Ebenen. Ich kenne das noch so ein bisschen aus meiner Zeit in der Automobilindustrie, dass es da ein sogenanntes Babylon-Level gibt. Der Level 0 ist die gesamte Welt und das Level 1 ist jetzt das Fahrzeug, welches sich in dieser Welt bewegt.
So, also Level 1 ist das Fahrzeug und alle Systeme, die jetzt in diesem Fahrzeug sind, werden dann darunter weiter aufgegliedert auf Level 2, 3 und 4. Vielleicht sogar noch mehr, je nachdem, was da benötigt ist. Und ja, auf der Ebene, wo man sich jetzt bewegt, zum Beispiel dem Level 1 oder vielleicht sogar dem Level 2, auf der Ebene müssen dann diese Codes für das gesamte Fahrzeug festgelegt werden.
Es wird wichtig sein, diese Fehler-Codes in einer gleichen Art und Weise zu benutzen und zu verwenden. Das soll heißen, wenn ein Fehler auftritt und dieser als kritisch eingestuft wird, dann ist damit die Auswirkung dieses Fehlers gemeint. Und wenn ein anderer Fehler auftritt und eine ähnliche Auswirkung hat, dann wird die auch als kritisch eingestuft und dieser Fehler auch entsprechend als kritisch.
Dazu im Vergleich, ein leichter oder mittelschwerer Fehler ist zwar auch nicht schön, wenn der auftritt, es kann aber sein, dass sich diese selbst wieder beheben oder beheben lassen. Dazu gibt es dann den Verlernzähler, der das wiederum definiert. Und diese Ebene, auf der die Fehlercodes festgelegt werden, das ist auch die einzige Ebene, wo die Priorität der Fehler untereinander abgewogen werden können.
Also welcher Fehler soll jetzt in dem Gesamtsystem angezeigt werden und welcher wird dann eventuell überdeckt oder wird erst an zweiter Stelle eventuell angezeigt. Ein Fehler wird üblicherweise durch ein Subsystem ausgelöst. Dieses Subsystem wird auch in der Lage sein, über seine Interna zu urteilen. Das heißt also, es kennt ja nun mal seine Abläufe, die intern durchgeführt werden und kann deswegen auch einschätzen, ob ein Fehler weiterhin existiert oder ob er irgendwann auch als behoben gilt.
Dadurch speist sich wiederum dann der Zahlenwert des Verlernzählers. Allgemein auf Systemebene kann ich dafür jetzt nicht eine Formel herausgeben, aber durch die Kenntnisse der einzelnen Systeme kann jetzt beurteilt werden, wie oft muss jetzt so ein Zyklus durchfahren werden, dass man auch mit gutem Gewissen sagen kann, okay, der Fehler ist jetzt wieder weg.
Der Systemingenieur der Ebene N, also hier vielleicht jetzt Level 1, muss also mit den verantwortlichen Entwicklenden der Ebene N plus 1, also in diesem Fall dann Level 2, darüber sprechen, welche Werte auf der Ebene N in diese Verlernzähler eingetragen werden. So, wir haben jetzt also ein bisschen überlegt, wo kommen die Fehlercodes her, wer hat Einfluss auf diese Verlernzähler und haben jetzt quasi dieses Fehlercodesystem festgelegt.
Es kann aber in jedem Subsystem auch noch andere interne Fehlercodes existieren. Also jedes Entwicklungsteam, was jetzt da irgendwo ein Subsystem zuliefert, kann intern eigene Fehlercodes aufgestellt haben, definiert haben. Nur sobald diese zu einer höheren Ebene übermittelt werden, weil dieses eigene System oder dieses Subsystem selber nicht mehr in der Lage ist, diesen Fehler zu behandeln und damit umzugehen.
Dann muss es den halt also nach oben melden und dann muss dieser Fehler in das höher liegende Fehler-Code-System eingebettet werden. Aber solange wieder Fehler und die Fehlerbehandlung intern ist, sind dort eigene Fehlercodes natürlich möglich. Die können sich ableiten von dem Übergeordneten, müssen sie aber prinzipiell nicht. Was aber dann passieren muss, ist ein entsprechendes Mapping muss vorgenommen werden.
Also ich nehme diese internen Fehlercodes als Basis für die Entscheidung zum Setzen der Fehlercodes der Ebene N und melde die dann nach oben weiter. Ja, zusammenfassend zu der heutigen Episode, meine drei Tipps. Überlege dir gut, wie tief die Anforderungen aus den Normen in das Requirements Management Tool aufgenommen werden sollen.
Sprich dazu mit den Menschen aus dem Test und der Zulassung, denn die haben das Wissen, welche Normen und entsprechenden Tests wichtig sind und welche Anforderungen, welche Granularität du dann benötigst. Und der dritte Tipp betrifft die Fehlercodes. Die müssen immer auf der Ebene definiert werden, wo Rückmeldungen aus verschiedenen Subsystemen zusammenlaufen.
Das kann auf der Ebene N sein für Fehlercodes aus der Ebene N plus 1 oder natürlich auf der Ebene N plus 1 für die Fehlercodes aus der Ebene N plus 2. 2. Brauchst du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest du meine E-Mail in den Shownotes. Klicke da drauf und kopiere sie in dein E-Mail-Programm und schicke mir eine Mail. Ich melde mich dann bei dir und wir sprechen darüber.
Das war die heutige Episode des Zukunftsarchitekten, der Systems Engineering Podcast für Macher und Entscheidende. Mein Name ist Björn Schorre und ich danke dir fürs Zuhören. Hab Spaß an dem, was du machst und vor allem auch einen hohen Wirkungsgrad. Tschüss und bis zum nächsten Mal. Music.