Einführung
Warum sollten Systemanforderungen dokumentiert werden? In der Regel haben Sie bereits Kundenanforderungen, warum also Zeit und Mühe investieren, um zusätzliche Systemanforderungen zu dokumentieren? Egal um welches Projekt es geht: Es ist immer wichtig, die vereinbarten Ergebnisse pünktlich, budgetgerecht und in der vom Kunden geforderten Qualität zu liefern. Wenn ein Zulieferer die Systemanforderungen nicht dokumentiert, könnten bestimmte Funktionalitäten übersehen oder die Erwartungen der Kunden falsch interpretiert werden. Das wiederum führt zu mehr Aufwand, Kosten und Verzögerungen. Unter Umständen übersehen Zulieferer wesentliche Aspekte des Systems, die für die Funktionalität oder nicht-funktionalen Aspekte des Systems wichtig sind. In diesem Fall können dann Fehlstarts oder sogar zusätzliche Entwicklungszyklen die Folge sein.
Im Folgenden sind die wichtigsten Aspekte der System-Anforderungsanalyse in Automotive SPICE aufgeführt.
-
Systemanforderungen und Struktur. Ein wichtiger Grund für die Dokumentation von Systemanforderungen ist, dass Sie mehr als nur die Erwartungen Ihrer Kunden berücksichtigen müssen. Die meisten Systeme müssen Standards, Normen und andere Vorschriften erfüllen, was die Anzahl der Anforderungen erhöht. Deshalb werden sie im Prozess als Stakeholderanforderungen beschrieben. Für Dokumentationszwecke ist es hilfreich, die Stakeholderanforderungen den Systemanforderungen zuzuordnen, die eine interne Sicht des Systems widerspiegeln. Die Systemanforderungen bilden wiederum die Basis für den System-Qualifizierungstest und alle nachfolgenden Prozesse, z. B. die Systemarchitektur.
Die Systemanforderungen beschreiben das System als Black-Box. Hier geht es um das „Was“ – also was soll das System tun (nicht wie soll es etwas tun). Wenn wir zum Beispiel ein elektronisches Steuergerät (ECU) entwickeln, haben die Systemanforderungen folgende Aufgabe:
- Sie beschreiben, welche Signale an den Pins des Steckverbinders ankommen, was das System mit diesen Signalen tun soll und welche Ausgangssignale wir an den Pins des Steckverbinders anlegen.
- Bei diesem Ansatz werden die Anforderungen außerdem so strukturiert, dass sie für die interne Organisation Sinn ergeben und die Verteilung auf verschiedene Bereiche unterstützen.
- So wird sichergestellt, dass jede Organisationseinheit weiß, welche Anforderungen für sie relevant sind. Das können beispielsweise Attribute zur Klassifizierung der Anforderungen nach ISO 26262 sein, oder eine funktionale Struktur zur Unterstützung der Verteilung auf Funktionsgruppen usw.
In der Regel wird das Anforderungsmanagement durch geeignete Tools wie z. B. eine Anforderungsdatenbank unterstützt.
- Personal für diesen Prozess. Es kann schwierig sein, Mitarbeiter zu finden, die das erforderliche Fachwissen zur Definition der Systemanforderungen mitbringen. Der Grund dafür: Systemingenieure müssen Multitalente sein und sich in verschiedenen Disziplinen auskennen. Um etwa ein mechatronisches System wie eine Servolenkung zu entwickeln, muss der Ingenieur ein tiefes Verständnis für Mechanik, Elektronik und Softwareentwicklung haben. Es ist fast unmöglich, eine Person zu finden, die über dieses Wissen verfügt. Alternativ können Unternehmen ein bereichsübergreifendes Team bilden, das die Systemanforderungen gemeinsam definiert.
- Die Analyse der Anforderungen. Wie der Name schon sagt, geht es bei diesem Prozess auch darum, die Anforderungen zu analysieren,und zwar auf Machbarkeit bzw. Risiko – zwei eng verbundene Aspekte. Wenn man nicht bewertet hat, ob eine Anforderung machbar ist, besteht ein inhärentes Risiko, da die Suche nach einer Lösung möglicherweise lange dauert oder es überhaupt keine Lösung gibt. Ein weiteres zu analysierendes Thema ist die Testbarkeit. Sie kann durch die Unterstützung der Tester gewährleistet werden. Tester werden häufig auch mit der Überprüfung der Anforderungen betraut. Die Analyse sollte auch die technischen Auswirkungen abdecken, einschließlich der Beurteilung von Abhängigkeiten zwischen Anforderungen.
Nehmen wir etwa die Schließfunktion einer Fensterhebersteuerung: Für die Schließfunktion muss die Fensterscheibe nach oben gleiten, bis das Fenster geschlossen ist. Demgegenüber steht der Einklemmschutz, eine Sicherheitsfunktion, die verhindern soll, dass Finger beim Schließen des Fensters eingeklemmt werden.Zwischen diesen Anforderungen besteht eine offensichtliche gegenseitige Abhängigkeit und technische Implikation. Diese sollten bei der Analyse berücksichtigt werden.
Abschließend sollte die Analyse auch wirtschaftliche Aspekte der Anforderungen abdecken. Deshalb sollten die Auswirkungen der Umsetzung der verschiedenen Anforderungen auf die Kosten und den Zeitplan untersucht werden. Nun kann man sagen, dass man all das nicht in der Anforderungsdatenbank dokumentieren kann.
- Aber wir erinnern uns: In Automotive SPICE wird nicht vorgeschrieben, wo Sie was zu dokumentieren haben.
Beispielsweise können Sie den ersten Teil der Analyse (Machbarkeit und Risiken) in der Anforderungsdatenbank hinterlegen, die technischen Auswirkungen in den verknüpften Änderungsanträgen, und die Auswirkungen auf Kosten und Zeitplan in Ihrem Projektmanagementtool.
-
Der Aufwand für Traceability und Konsistenz. Mit diesem Prozess muss auch die Traceability und Konsistenz zwischen Systemanforderungen und Stakeholderanforderungen sichergestellt werden.
Der Zweck der Traceability besteht in der Unterstützung von:
- Konsistenzprüfungen, d. h. der Überprüfung auf Vollständigkeit und Korrektheit der Systemanforderungen
- Der Auswirkungsanalyse (Impactanalyse) bei Änderungsanträgen oder Mängeln
- Der Berichterstattung über die Stakeholdererwartungen
Der zweite Teil dieses Aspekts betrifft die Konsistenz.
Konsistenz bedeutet, dass Sie die Vollständigkeit und Richtigkeit Ihrer Systemanforderungen gegenüber den Stakeholderanforderungen sicherstellen müssen. Da dieser Prozess den Einstieg in die Entwicklung darstellt, sollten Sie sicherstellen, dass die Systemanforderungen die Stakeholderanforderungen korrekt abdecken. Es ist wichtig, diesen Review nicht zu überspringen.
Nach Automotive SPICE dient die System-Anforderungsanalyse dazu, die definierten Anforderungen der Stakeholder in eine Reihe von Systemanforderungen zu übersetzen, um den Systementwurf zu unterstützen.
Best Practices (BP1): Legen Sie die Systemanforderungen fest. Nutzen Sie die Stakeholderanforderungen und Änderungen der Anforderungen, um die erforderlichen Funktionen und Fähigkeiten des Systems zu bestimmen. Spezifizieren Sie funktionale und nicht-funktionale Systemanforderungen in einer System-Anforderungsspezifikation.
- Anmerkung 1: Applikationsparameter, die Funktionen und Fähigkeiten beeinflussen, sind Teil der Systemanforderungen.
- Anmerkung 2: Bei Änderungen der Stakeholderanforderungen gilt SUP.10.
BP2: Strukturieren Sie die Systemanforderungen. Strukturieren Sie die Systemanforderungen in der System-Anforderungsspezifikation wie folgt:
- Gruppierung in projektrelevante Cluster
- Sortierung in eine für das Projekt logische Reihenfolge
- Kategorisierung nach projektrelevanten Kriterien
- Priorisierung nach den Stakeholderanforderungen
- Anmerkung 3: Die Priorisierung beinhaltet in der Regel die Zuordnung funktionaler Inhalte zu geplanten Releases.
BP3: Analysieren Sie die Systemanforderungen. Analysieren Sie die spezifizierten Systemanforderungen einschließlich ihrer Abhängigkeiten, um die Korrektheit, technische Durchführbarkeit und Verifizierbarkeit zu verifizieren und die Risikoidentifizierung zu unterstützen. Analysieren Sie die Auswirkungen auf die Kosten, den Zeitplan und die technischen Auswirkungen.
- Anmerkung 4: Durch die Analyse der Auswirkungen auf die Kosten und den Zeitplan können die Schätzungen für das Projekt angepasst werden.
BP4: Analysieren Sie die Auswirkungen auf die Betriebsumgebung. Ermitteln Sie die Schnittstellen zwischen dem spezifizierten System und anderen Elementen der Betriebsumgebung. Analysieren Sie die Auswirkungen, die die Systemanforderungen auf diese Schnittstellen und die Betriebsumgebung haben werden.
BP5: Entwickeln Sie Verifizierungskriterien. Entwickeln Sie für jede Systemanforderung Verifizierungskriterien, die die qualitativen und quantitativen Maßnahmen zur Verifizierung einer Anforderung definieren.
- Anmerkung 5: Verifizierungskriterien zeigen, dass eine Anforderung innerhalb der vereinbarten Grenzen verifiziert werden kann.Sie dienen in der Regel als Input für die Entwicklung von Systemtestfällen oder anderen Verifizierungsmaßnahmen, die die Einhaltung der Systemanforderungen sicherstellen.
- Anmerkung 6: Verifizierungen, die nicht durch Tests abgedeckt werden können, werden durch SUP.2 abgedeckt.
BP6: Stellen Sie eine bidirektionale Traceability sicher. Stellen Sie eine bidirektionale Traceability zwischen den Stakeholderanforderungen und den Systemanforderungen her.
- Anmerkung 7: Die bidirektionale Traceability unterstützt Abdeckungs-, Konsistenz- und Auswirkungsanalysen.
BP7: Verifizieren Sie die Konsistenz zwischen den Stakeholder- und den Systemanforderungen.
- Anmerkung 8: Die Konsistenz wird durch eine bidirektionale Traceability unterstützt und kann durch Reviewprotokolle nachgewiesen werden.
BP8: Kommunizieren Sie die vereinbarten Systemanforderungen und etwaige Aktualisierungen an alle Beteiligten.
Arbeitsergebnisse
- Kommunikationsaufzeichnung
- Reviewaufzeichnung
- Änderungsaufzeichnung
- Traceabilityaufzeichnung
- Analysebericht
- Schnittstellen-Anforderungsspezifikation
- System-Anforderungsspezifikation
- Verifizierungskriterien
Welchen Nutzen bietet die System-Anforderungsanalyse?
Die System-Anforderungsanalyse bildet die Basis für die Entwicklung des gesamten Produkts. Probleme, die in dieser Phase auftreten, können zu unnötigen und ungeplanten Kosten sowie zu Terminabweichungen im weiteren Verlauf des Entwicklungslebenszyklus führen. Sind die Systemanforderungen jedoch vollständig beschrieben, eindeutig und gut strukturiert, bilden sie eine solide Grundlage für eine effiziente Entwicklung und einen funktionierenden Systemtest.
Was beinhaltet die System-Anforderungsanalyse?
- Die funktionalen und nicht-funktionalen Anforderungen an das System werden unter Berücksichtigung des Inputs aller internen und externen Stakeholder festgelegt (BP1).
- Alle Systemanforderungen werden auf technische Durchführbarkeit, Testbarkeit, Risiken, Auswirkungen auf die Betriebsumgebung und Abhängigkeiten geprüft. Sie werden in einer logischen Reihenfolge entsprechend den Bedürfnissen des Projekts strukturiert (BP2, BP3, BP4).
Input für die System-Anforderungsspezifikation
- Für jede Anforderung werden Verifizierungskriterien entwickelt, die angeben, wie die Anforderung zu verifizieren ist (BP5).
- Die Anforderungen werden priorisiert, strukturiert und den Releases zugeordnet (BP2).
- Es wird eine konsistente bidirektionale Traceability zwischen den System- und den Stakeholderanforderungen hergestellt (BP6, BP7).
- Die Systemanforderungen und deren Aktualisierungen werden vereinbart und allen Stakeholdern mitgeteilt (BP8).
Überlegungen zu gängigen Herausforderungen
- Bei den Systemanforderungen sollte es sich nicht um eine Kopie der Kundenanforderungen handeln.
- Stattdessen sollten die Systemanforderungen aus den Kundenanforderungen abgeleitet und detailliert ausgearbeitet werden.
- Die Anzahl der Systemanforderungen ist in der Regel deutlich größer als die der entsprechenden Kundenanforderungen.
- Bei der Ableitung der Systemanforderungen ist ein rekursiver Ansatz sinnvoll, da sich bei der Entwicklung der Systemarchitektur häufig zusätzliche Anforderungen oder Einschränkungen für das System ergeben.
- Für ein umfassendes und gemeinsames Verständnis können Gespräche mit dem Kunden über die Spezifikation der Systemanforderungen sehr hilfreich sein. Dieser Austausch findet in der Regel in Form von gemeinsamen Workshops statt. Die Ergebnisse dieser Workshops sollten dokumentiert und auf die entsprechenden Anforderungen zurückgeführt werden.
- Im Falle einer bestehenden Produktplattform müssen im Projekt die Kundenanforderungen ermittelt werden, die bereits durch die Plattform erfüllt werden, sowie das Delta, das durch das Kundenprojekt abgedeckt werden muss.
- Nicht-funktionale Anforderungen (z. B. Prozessanforderungen, Qualitätsanforderungen) werden oft vernachlässigt.
- Es sollte auch interne Systemanforderungen geben, die auf eigenem Wissen und Erfahrung basieren und nicht von Kundenanforderungen abgeleitet sind.
- Kunden ändern ihre Anforderungen gelegentlich und überlassen es dem Zulieferer, die genauen Änderungen zu ermitteln. Dadurch entstehen dem Zulieferer erhebliche Zusatzkosten und Verzögerungen.
- Traceability allein reicht nicht aus – zusätzlich muss Konsistenz nachgewiesen werden. Mit Konsistenzprüfungen (durch Reviews) muss verifiziert werden, dass die Systemanforderungen eine korrekte Interpretation der Kundenanforderungen sind und dass Traceability und Links korrekt und vollständig sind.
- Die Unabhängigkeit der Systemanforderungen von denen der Stakeholder hat den zusätzlichen Vorteil, dass sie in einer Sprache und in einem Kontext formuliert sind, mit denen der Zulieferer vertraut ist. So können Mitarbeiter zwischen einzelnen Projekten einfacher gewechselt werden.
- Kunden haben oftmals Anforderungsspezifikationen, die viele ihrer Produkte abdecken, und es ist sehr mühsam herauszufinden, ob eine Anforderung für ein aktuelles Projekt relevant ist. Unterstützungsteams können diese Analyse durchführen und so den Mehraufwand in den Projekten reduzieren.
Erfahren Sie mehr über Automotive SPICE
Wenn Sie mehr über Automotive SPICE® erfahren möchten, besuchen Sie unsere Automotive SPICE-Schulungen.
Über den Autor
Bhaskar Vanamali ist seit fast 20 Jahren im Bereich Prozessverbesserung tätig und ehemaliger Sekretär des Arbeitskreises 13 des VDA QMC.
Er ist Principal Assessor und Trainer für Automotive SPICE® und hat bereits über 140 Assessments durchgeführt und mehr als 250 Assessoren ausgebildet.
Mehr zu dem Thema
Automotive SPICE®: Ressourcenleitfaden zur System-Anforderungsanalyse SYS.2