Monat: Juli 2022

Der Grundgedanke von nachvollziehbaren Anforderungen ist wirklich cool: Sie können eine Anforderung sowohl von oben nach unten von ihrer Erstellung bis zu ihrer Implementierung als auch von unten nach oben von ihrer Implementierung bis zu ihrem Ursprung verfolgen. In den meisten Lehrbüchern finden Sie gut aussehende Diagramme und Tabellen, die zeigen, wie Anforderungen mit anderen Anforderungen und Testfällen verknüpft sind. Leider haben diese Diagramme und Tabellen wenig mit der täglichen Praxis zu tun.
Systemanforderungen folgen den Prinzipien der Systemtechnik. Nehmen wir das Beispiel einer Wasserstraßenschleuse. Auf der Systemebene wird es eine Anforderung geben, die besagt, dass die Schleuse es Booten ermöglichen soll, den Kanal flussaufwärts und flussabwärts zu durchfahren. Wie können wir diese Anforderung erfüllen, wenn wir noch nicht wissen, wie wir das Problem lösen sollen, oder in der Anforderungssprache: wie wir diese Anforderung erfüllen können?
In der Praxis sehen wir eine große Vielfalt an Lösungen, vom großartigen schottischen Falkirk Wheel (einem echten Schiffshebewerk) bis zu den niederländischen Schleusen in Eefde. Zwei völlig unterschiedliche Lösungen für dasselbe Problem. Was ist also mit der Rückverfolgbarkeit unserer Systemanforderung zu tun?
Im Falle von Eefde besteht eine Schleuse aus zwei Toren und einer Kammer. Jede Komponente hat ihre eigenen Fähigkeiten, aber keine der Komponenten kann die Systemanforderung allein erfüllen. Deshalb brauchen wir die Designentscheidungen als Ankerpunkt im Anforderungsfluss (top-down, Anforderung zu Designentscheidung zu Anforderung) und in der Rückverfolgung (bottom-up). Durch das Design verstehen wir, dass der Wasserstand in der Kammer dem Wasserstand am geöffneten Tor entspricht, wenn wir eines der Tore öffnen. Anschließend können die Boote durch das geöffnete Tor in die Kammer fahren. Eine der so genannten abgeleiteten Anforderungen an das Tor-Teilsystem ist daher, dass es geöffnet und geschlossen werden kann.

[Courseinstructor heading=“‚Warum haben wir diese Anforderung und warum hat sie diesen Wert?'“

Die Fragen, die wir beantworten müssen und für die wir die Bottom-up-Spuren benötigen, sind: Warum haben wir diese Anforderung und warum hat sie diesen Wert? Die Antworten können nur durch Rückverfolgungen von den Anforderungen auf der Subsystemebene zu den Designentscheidungen eine Ebene höher gefunden werden, in unserem Fall die Systemebene der Wasserstraßenschleuse.
Systemingenieure müssen sich auch mit Ressourcenbudgets wie Masse, Volumen, Energie, Betriebsraum und Materialkosten befassen. All diese gehen als Einzelanforderungen in die Anforderungsspezifikation auf der Systemebene ein, werden aber nie an die Subsysteme weitergegeben, ohne dass sie im Zusammenhang analysiert werden, ein Design erstellt wird, das alle Vor- und Nachteile berücksichtigt, und schließlich entschieden wird, welche Lösung diese Systemanforderungen am besten erfüllt.
In der Realität gibt es viele Abhängigkeiten zwischen, in diesem Fall, den Anforderungen an die Ressourceneigenschaften. Vor allem in der Automobilindustrie sind Masse und Materialkosten zwei Fahrzeugeigenschaften, die stark miteinander verwoben sind. Auf der Systemebene wird das Gesamtbudget für die Masse festgelegt: Das Fahrzeug soll weniger als 1.500 kg wiegen, und das gilt auch für das Budget für die Materialkosten: Die Gesamtkosten für Materialien sollen 7.000 Euro nicht überschreiten. Dann wird für den Fall, dass schwierige Entscheidungen getroffen werden müssen, eine Priorität festgelegt, z.B. ist weniger Gewicht wichtiger als Materialkosten.
Der Entwurf versucht, dafür eine Lösung zu finden und weist Budgets für Masse und Materialkosten zu, wobei diese Anforderungen ausbalanciert werden und gleichzeitig bestimmte Fähigkeiten der Teilsysteme vorausgesetzt werden, die zu diesen Budgets beitragen. Wenn schließlich eine Entscheidung für eine Lösung getroffen wird, werden Teile des Massen- und Materialkostenbudgets den Subsystemen zugewiesen.
Wenn Sie für eines dieser Subsysteme verantwortlich sind und ein Massenbudget von 100 kg erhalten, wo würden Sie nach Antworten auf die Fragen suchen: Warum habe ich ein Massenbudget und warum sind es 100 kg?

Können wir objektiv sagen, dass eine Anforderung von guter Qualität ist? Was wäre der Maßstab für gut? Gibt es so etwas wie ‚gut genug‘? Die meisten Antworten auf diese Fragen finden sich in der Arbeit von Philip Crosby, William Edwards Deming und Joseph Juran. Diese drei Qualitätsgurus sind nicht mehr unter uns, aber ihre Ideen sind nach wie vor eine große Inspirationsquelle.

Da Anforderungen das Ergebnis eines Requirements-Engineering-Prozesses sind, erscheint es logisch zu prüfen, ob eine Anforderung die Ziele des Prozesses erfüllt. Erstens wurden die Bedürfnisse der Stakeholder ermittelt, und zweitens ist eine korrekte und vollständige Übertragung der Stakeholder-Bedürfnisse bis zur Dekompositionsebene gewährleistet, auf der die Anforderungen in Hardware- oder Softwarekomponenten umgesetzt werden können. Ich werde mich hier auf das zweite Ziel konzentrieren.

Es wird zwischen intrinsischer und extrinsischer Anforderungsqualität unterschieden. Intrinsisch bedeutet, dass die Qualität der Anforderung durch die Art und Weise bestimmt wird, wie sie dokumentiert oder dem Leser präsentiert wird – die Syntax der Anforderung. Diese kann entweder rein textlich sein oder mit Bildern, Tabellen und mehr verschönert werden. Die Prüfung kann theoretisch auch von Personen oder Anwendungen durchgeführt werden, die sich nicht mit dem Thema auskennen. Sie müssen nicht verstehen, worum es in der Anforderung geht, sondern nur sehen, ob sie gegen die Regeln für das Schreiben von Anforderungen verstößt. Deming spricht von „Stolz auf die eigene Leistung“ und „gut formulierten Anforderungen“. Im Laufe der letzten 10-15 Jahre sind die Software-Tools zur Unterstützung dieser Qualitätsprüfungen immer weiter entwickelt worden. In Tools wie QVScribe sind Checklisten wie die Writing Requirements Guideline des International Council on Systems Engineering (Incose) vollständig eingebettet und intrinsische Qualitätsprüfungen sind vollständig automatisiert (einschließlich verschiedener Anforderungsvorlagen wie EARS und IREB).

Beachten Sie, dass die intrinsische Qualität nur ein Drittel der Gesamtqualität der Anforderungen abdeckt. Aber die Prüfungen der intrinsischen Qualität haben einen Wert. Wenn sie durchgeführt werden und Korrekturen vorgenommen werden, bevor die Anforderungen von Fachexperten und relevanten Stakeholdern überprüft werden, können diese Tools Zeit sparen und tatsächlich dazu beitragen, die Qualität der Anforderungen zu verbessern.

Aber Tools helfen Ihnen nicht dabei, herauszufinden, ob Ihre Anforderungen für die vorgesehene Zielgruppe sinnvoll sind. An dieser Stelle kommt die extrinsische Qualität von Anforderungen ins Spiel. Sie gilt in zwei Richtungen: zurück zu den Interessenvertretern, die eine bestimmte Funktion des zu entwickelnden Produkts oder eine Produkteigenschaft oder ein Verhalten gefordert haben (die Ausgangszielgruppe), und vorwärts zu den Empfängern der Anforderung (die Zielgruppe).

Betrachten wir die folgende Anforderung: „Die Reaktionszeit des Systems muss weniger als oder gleich 0,5 ms betragen.“ Diese Anforderung wird höchstwahrscheinlich die automatischen Qualitätsprüfungen mit Bravour bestehen. In der Praxis wird sie oft wie folgt formuliert: „Reaktionsfähigkeit des Systems: ≤ 0,5 ms.“ Würden Sie sagen, dass diese Anforderungen von gleicher Qualität sind? Aus syntaktischer Sicht wird die erste Anforderung eine höhere Punktzahl erhalten, da sie eine Anweisung enthält. Aber erst wenn wir die betreffenden Interessengruppen fragen, wissen wir, ob die beabsichtigte Bedeutung korrekt übersetzt wurde.

[Courseinstructor heading=“‚equirements engineers need to have checked and judged their requirements.'“

Qualität ist Konformität mit den Anforderungen, sagt Crosby. Haben wir als Anforderungsingenieure oder Unternehmensanalysten die Bedürfnisse der Interessengruppen korrekt in eine Systemanforderung umgesetzt? Diese Frage kann nur von den Interessengruppen beantwortet werden, die den ursprünglichen Bedarf geäußert haben. Anforderungsingenieure müssen also ihre Anforderungen prüfen und beurteilen lassen – eine Tätigkeit, die als schwierig empfunden wird.

Angenommen, der Kunde sagt, dass der Ingenieur die Anfrage nicht verstanden hat? Oder dass er das Thema völlig verfehlt hat? Ein solches Feedback ist nicht immer angenehm und das veranlasst einen Anforderungsingenieur, diese Konfrontationen zu vermeiden. Er wählt oft den sicheren Weg, indem er jemanden aus dem Projekt kontaktiert, der den Kunden oder Stakeholder vertritt.

Das ist keine kluge Einstellung. Wir wollen sichergehen, dass wir die Bedürfnisse des Stakeholders verstanden und sie korrekt und vollständig in Anforderungen umgesetzt haben. Deshalb gibt es keinen anderen Weg, als diese schwierigen Fragen direkt zu stellen.

Qualität ist Eignung für den Zweck, sagt Juran. Die Anforderungen müssen ausreichend Informationen und Details enthalten, damit die Designer Lösungen entwickeln können. Von den Anforderungen wird erwartet, dass sie quantifiziert werden, damit Tester ihre erfolgreiche Umsetzung überprüfen und validieren können. Kurz gesagt, sie müssen klar, eindeutig und aussagekräftig sein und genügend Details für diejenigen enthalten, die die Anforderungen als Input für ihre Arbeit erhalten.

Ich habe schon Fälle erlebt, in denen es keine Anforderungsdokumentation zwischen einem OEM und einem seiner Zulieferer gab. Es gab nur eine mündliche Vereinbarung. Obwohl diese Situation in manchen Kulturen als inakzeptabel gilt, wurden die Ziele des Requirements Engineering Prozesses erreicht. Der Lieferant liefert das Bauteil nun schon seit über zwölf Jahren in gleichbleibender Qualität zur Zufriedenheit des Kunden.

Was würden Sie in solchen Situationen tun? Wie sehen Sie die Qualität der Anforderungen in Ihrem Unternehmen? Wie würden Sie mit Anforderungen von Interessengruppen wie „Ich möchte, dass die nächste Version des Autos energieeffizienter ist“ umgehen? Ich würde mich freuen, von Ihnen zu hören, zu lernen und es weiterzugeben.

Eine Frage, die in fast allen meinen Seminaren zum Thema Systemanforderungen auftaucht, ist: Wie können wir sicherstellen, dass unsere Anforderungsspezifikation vollständig ist? Das ist eine berechtigte Frage. Fehlende Anforderungen bedeuten in der Regel fehlende Fähigkeiten der Produkte, die wir entwickeln. Das hat Folgen für den Erfolg dieser Produkte. Entweder sind die Benutzer eines Produkts enttäuscht, weil sie etwas erwartet haben, das nicht geliefert wurde, oder das Produkt ist im Vergleich zu anderen Produkten mit ähnlichen Funktionen nicht wettbewerbsfähig genug.

Die Praxis zeigt, dass Anforderungsspezifikationen nur selten vollständig sind. Es ist nur sehr schwierig, sie vollständig zu machen und zu halten. Glücklicherweise haben wir in den letzten Jahrzehnten einige Techniken und Methoden gelernt, die uns bei unserem Streben nach Vollständigkeit helfen können.

Zunächst einmal funktionieren Vorlagen und Checklisten wirklich. Sie stammen aus den frühen Tagen der Technik und helfen uns, die offensichtlichen Anforderungen nicht zu vergessen. Heute gibt es Hilfe im Überfluss. Das Internet ist übersät mit Checklisten, die sich speziell auf Anforderungen beziehen.

Sie müssen auch selbst etwas nachforschen: Finden Sie alle Stakeholder, die einen potenziellen Einfluss auf den Erfolg des Produkts haben. Wenn Sie die Stakeholder vergessen, bedeutet das oft, dass Sie auch deren Bedürfnisse und Erwartungen an die Fähigkeiten des Produkts nicht erfassen werden. Das ist ein Rezept für Misserfolg. Natürlich müssen Sie Ihre Stakeholder befragen und herausfordern, um herauszufinden, was ihre wirklichen Bedürfnisse sind. Es hilft auch, diese Bedürfnisse explizit zu machen. Laden Sie nicht die Feuerwehr ein, wenn Sie einen neu gebauten Tunnel in Betrieb nehmen, nur um dann festzustellen, dass Sie möglicherweise einige wesentliche Sicherheitsmaßnahmen übersehen haben. Sie müssen die Feuerwehrleute schon in den frühen Phasen der Anforderungserhebung einbeziehen.

Stellen Sie sicher, dass Sie das zu entwickelnde Produkt aus verschiedenen Perspektiven betrachten. Betrachten Sie es mit den Augen der tatsächlichen Nutzer, Eigentümer und Investoren. Beziehen Sie die Interessengruppen ein, die auch die negativen Auswirkungen zu spüren bekommen. Diese Perspektiven lassen sich manchmal am besten in einem Betriebskonzept, User Stories, Anwendungsfällen und Szenarien beschreiben.

Machen Sie sich klar, dass der Schritt der Anforderungserhebung (bei dem Sie die Interessengruppen und ihre Bedürfnisse ermitteln) auf jeder Zerlegungsebene Ihrer Produktarchitektur für jedes Systemelement stattfindet! Auf jeder Ebene finden Sie neue Stakeholder, die für das jeweilige Systemelement auf dieser Ebene spezifisch sind. Denken Sie an Software-Codierungsstandards in einem multidisziplinären Produkt.

Analysieren Sie die Bedürfnisse auf strukturierte Weise. Das bedeutet, dass Sie zwischen der Hauptfunktion eines Produkts und seinen Unterfunktionen, zwischen einer Funktion, ihren Eigenschaften und ihren Designeinschränkungen unterscheiden müssen. Letztendlich müssen Sie ein Gleichgewicht zwischen den Anforderungen an die Leistung und die Ressourceneigenschaften der Funktionen finden.

Wenn wir einen Pkw als Beispiel nehmen und sagen, dass „Personen transportieren“ seine Hauptfunktion ist, müssen wir ausdrücken und quantifizieren, wie gut wir Personen transportieren müssen: wie komfortabel, wie zuverlässig, wie viele Personen, wie sicher? Dies sind Beispiele für Leistungseigenschaften (oder Qualitäten) einer Funktion. Sie werden mit den Ressourceneigenschaften abgeglichen, z. B.: wie viel Energie darf diese Leistung kosten, wie viel Materialkosten, wie viel Lärm? Während bei der Analyse die Funktionen, Eigenschaften und Einschränkungen identifiziert werden, werden bei der Anforderungsspezifikation die Eigenschaften quantifiziert.

Diese Methode ist Teil der strukturierten Anforderungsanalyse und eine der effektivsten Methoden, um die so genannten Emerging Properties zu entdecken – Eigenschaften, die von keinem Stakeholder gefordert wurden, aber einen spezifischen Produktaspekt darstellen, der sich aus den bei der Entwicklung getroffenen Entscheidungen ergibt. Wenn Sie sich zum Beispiel für einen Verbrennungsmotor entscheiden, ergeben sich als neue Eigenschaften die Geräuschentwicklung und die Emission giftiger Gase. Einige dieser neuen Eigenschaften können plötzlich sehr wichtig werden, nachdem sie lange Zeit außer Acht gelassen wurden, wie wir bei den NOx-Emissionen gesehen haben. Der Punkt ist, dass Sie, sobald eine Designentscheidung getroffen wurde, die Konsequenzen (gut, schlecht und hässlich) betrachten sollten, um zu sehen, ob neue Anforderungen geschaffen werden sollten, um die entstehenden Eigenschaften zu verwalten.

Im Laufe der Jahre haben sich die Namen der Produktentwicklungsabteilungen ziemlich verändert, insbesondere die der Gruppen, die für das Schreiben der Anforderungen auf Produkt- (oder System-) Ebene verantwortlich sind. Von der Produktdefinition über die Systementwicklung sehen wir jetzt Gruppen (manchmal Abteilungen), die so benannt sind, dass klar ist, wofür sie stehen, wie „Produkteigenschaften und Kundenfunktionen“. Auch der Titel von Hansjörg Maier von Porsche sagt alles: „Leiter Produkt-Eigenschaften und Kunden-Funktionen.“ Damit wird deutlich, worauf es bei dem Produkt ankommt, sowohl bei der Funktionalität als auch bei den Eigenschaften, und was das Produkt von der Konkurrenz abhebt.