Der Trainer des High Tech Institute , Cees Michielsen, beleuchtet eine Handvoll Trends im Bereich System Requirements Engineering. Er bietet mehrmals im Jahr das 2-tägige Training System Requirements Engineering Improvement für das High Tech Institute an.
Bei jeder Schulung zur Verbesserung des System Requirements Engineering stellt sich die Frage: Welches ist das beste Tool zur Verwaltung unserer Anforderungen? Um diese Frage zu beantworten, müssen Sie alle Funktionen der Anforderungsmanagement-Tools kennen, einschließlich der neuesten Updates. Gleichzeitig brauchen Sie ein gutes Verständnis der Betriebsumgebung, in der Sie das Tool einsetzen wollen. Kurz gesagt: dies ist eine unmögliche Aufgabe.
Machen Sie sich keinen Stress, es gibt immer noch eine erste Unterscheidung zu treffen. Am besten tun Sie das auf der Grundlage der Art des Unternehmens, mit dem Sie arbeiten. Ein Unternehmen wie ASML muss sich nicht an internationale Sicherheitsstandards, Informationssicherheit oder FDA-Vorschriften halten. Auch Word oder Excel sind dann geeignet, um alles zu verwalten – und überraschenderweise scheint dies die bevorzugte Lösung zu sein.
Wenn es um Normen und Vorschriften geht, muss die Software Prüfpfade unterstützen. Das bedeutet, dass sie grundlegende Funktionen für das Konfigurationsmanagement bereitstellen muss, wie Versionsmanagement, Änderungsmanagement und Statusverwaltung. Es ist schon erstaunlich, aber viele Tools für das Anforderungsmanagement bieten diese grundlegenden Funktionen nicht.
Eine weitere Unterscheidung, die Sie treffen müssen, ist die Baseline. In ihrer einfachsten Form ist eine Baseline eine Momentaufnahme der Anforderungsdatenbank, die eine Teilmenge der Anforderungen enthält. Fortschrittlichere Tools bieten Workflows zur Auswahl bestimmter Anforderungen mit bestimmten Merkmalen aus der Datenbank. Eine solche Baseline kann geprüft, geändert, genehmigt und als separate Einheit im Tool freigegeben werden. Sobald sie freigegeben ist, kann der Inhalt der Baseline nicht mehr geändert werden.
In einigen Branchen, wie der Automobilindustrie, ist der Austausch von Baselines zwischen OEM und Zulieferern ein Standardverfahren (besser bekannt als Lastenheft-Pflichtenheft-Informationsaustausch ), aber auch intern ist er nützlich. Sie schaffen Ruhe und Stabilität in einem Umfeld, das für wechselnde Anforderungen durch multidisziplinäre Produktentwicklung bekannt ist.
Die Entkopplung der verschiedenen Dynamiken von den Grundlinien kann sehr effektiv sein. Dies ist auch die Grundlage für meine frühere Bemerkung über Word und Excel. Sie können mit ihrem relativ langsamen Veränderungstempo einen angemessenen Herzschlag für die Initiierung von Veränderungen in der Entwicklungsorganisation vorgeben. Zum Beispiel eine sich schnell ändernde agile Arbeitsweise mit zweiwöchentlichen Sprints und einer langen Vorlaufzeit mit vierteljährlichen Updates und jährlichen Releases.
Ein starkes Argument für die Verwendung von RM-Tools ist die Unterstützung der Rückverfolgbarkeit. Die meisten Anbieter von Tools werben damit, dass ihr Tool geeignet ist, Anforderungen mit anderen Anforderungen zu verknüpfen. Wie ich in meiner Kolumne über Rückverfolgbarkeit geschrieben habe, scheint dies in der Praxis nicht der Fall zu sein. Es wird sogar davon abgeraten.
Bei der Rückverfolgbarkeit geht es darum, die Quelle der Anforderungen zu finden. Diese Quellen sind entweder eine Anforderungsanalyse oder eine Designentscheidung auf höherer Ebene. Daher ist es wichtig, dass das Tool die Möglichkeit bietet, andere Entitäten als Anforderungen zu erstellen und in der Lage ist, spezifische Beziehungen (Trace-Links) zwischen Anforderungen und Designentscheidungen herzustellen.
Auch hier werden Sie erstaunt sein, wie viele Tools dies nicht unterstützen.
In meiner letzten Kolumne habe ich das W-Modell als Antwort auf die Notwendigkeit vorgestellt, Systemelementen Eigenschaften (wie Masse und Volumen) zuzuweisen. Sie würden erwarten, dass dies von Tool-Anbietern unterstützt wird, die ihre Tools Product Lifecycle Management (PLM) nennen, wie Siemens, IBM, Dassault, Contact Software und PTC. Leider sehen die meisten dieser PLM-Tools die ersten CAD-Zeichnungen als den Beginn des Lebenszyklus des Produkts an. Ich betone es nur: Das ist fast am Ende des Entwicklungsprozesses!
Anders ausgedrückt: diese Tools lassen die linken Beine des W-Modells (von der Geburt bis zur Pubertät) komplett aus. In den letzten Jahren haben diese PLM-Tool-Anbieter versucht, die Lücke zu füllen, indem sie Anbieter von modellbasierten System-Engineering-Tools übernommen oder Schnittstellen zu diesen angeboten haben (Enterprise Architect, Capella, No Magic) und dann den armen Kunden mit den Integrations- und Schnittstellenproblemen allein gelassen haben, während sie gleichzeitig mit veralteten Konzepten wie RFLP, einer inkompatiblen Terminologie, dem völligen Fehlen des Konzepts der Produkteigenschaften und der fehlenden Möglichkeit von Attributen zu Beziehungen zurückgelassen wurden.
Einige beliebte Anforderungsmanagement-Tools wie Doors, Polarion, Relatics, TopTeam und Jama erweitern ihre Funktionalitäten auf das Systems Engineering. Sie werden mit den Voraussetzungen konfrontiert, die aus einer SE-Perspektive erfüllt sein müssen: ordnungsgemäßes Konfigurations-, Änderungs- und Versionsmanagement, kontextübergreifende Rückverfolgbarkeit, Lebenszyklusunterstützung für Systemelemente, Baselining und mehr.
Um auf das ursprüngliche Thema des Tages zurückzukommen: Ich muss noch ein RM-Tool sehen, das nicht nur die Managementaspekte unterstützt, sondern auch die technischen Aspekte. Wie z.B. die Quantifizierung von Anforderungen mit Tags und Qualifizierern nach Gilb; die Beziehung zwischen Funktionen und Funktionseigenschaften (auch um die veraltete Trennung von funktionalen und nicht-funktionalen Anforderungen aufzuheben); wie man eigenschaftsspezifische Anforderungen schreibt; Unterstützung bei der Sicherstellung der intrinsischen Qualität von Anforderungen (Funktionalität, die von Tools wie QVScribe bereitgestellt wird); einfacher Vergleich des Systems, wie es benötigt wird, des Systems, wie es entworfen wurde und des Systems, wie es getestet wurde. Eine Anforderung ist mehr als nur eine textuelle Beschreibung.
In der Kolumne über Rückverfolgbarkeit habe ich erwähnt, dass Anforderungs-Tools bei der Beantwortung der Frage helfen können: Warum gibt es diese Anforderung und warum hat sie diesen Wert? Das PLM-Tooling kann bei der Beantwortung von Fragen helfen wie: „Wenn dieses Element im Feld ausfällt, kann mir das Tooling helfen, die Systemfunktion(en) zu finden, die von diesem ausgefallenen Element betroffen sind?
