Automotive SPICE® SWE.1: Software-Anforderungsanalyse

Warum sollten Softwareanforderungen dokumentiert werden? In der Regel haben Sie bereits System- oder Kundenanforderungen, warum also Zeit und Mühe investieren, um zusätzliche Softwareanforderungen 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 Sie Ihre Softwareanforderungen nicht dokumentieren, könnten Sie bestimmte Funktionalitäten übersehen oder die Erwartungen Ihrer Kunden falsch interpretieren. Das wiederum führt zu mehr Aufwand, Kosten und Verzögerungen. Unter Umständen übersehen Sie wesentliche Aspekte Ihrer Software, die für die Funktionalität oder die nicht-funktionalen Aspekte Ihrer Software wichtig sind. In diesem Fall können dann Fehlstarts oder sogar zusätzliche Entwicklungszyklen die Folge sein.

Dieser Prozess ist eng mit der System-Anforderungsanalyse (SYS.2), dem System-Architekturentwurf (SYS.3), dem Software-Architekturentwurf (SWE.2) und dem Software-Qualifizierungstest (SWE.6) verknüpft. Auch das Projektmanagement (MAN.3) und das Konfigurationsmanagement (SUP.8) haben aufgrund des Releasemanagements, des Fehlermanagements (SUP.9) und des Änderungsmanagements (SUP.10) starke Abhängigkeiten. Diese Abhängigkeiten bestehen, da in Tests identifizierte Mängel behoben und Fehlerbehebungen und Änderungsanträge z. B. in Regressionstests berücksichtigt werden müssen.

Im Folgenden sind die wichtigsten Aspekte der Software-Anforderungsanalyse in Automotive SPICE® aufgeführt.

• Berücksichtigen Sie nicht nur die Kundenanforderungen. Die Dokumentation von Softwareanforderungen ist deshalb so wichtig, weil Sie mehr als nur die Erwartungen Ihrer Kunden berücksichtigen müssen. Die Software muss Standards, Normen und andere Vorschriften erfüllen – was zu zusätzlichen Anforderungen führt.Für Dokumentationszwecke ist es hilfreich, die Systemanforderungen oder – im Falle der Softwareentwicklung – die Anforderungen der Kunden und anderer Stakeholder den Softwareanforderungen zuzuordnen, die eine interne Sicht der Software widerspiegeln. Die Softwareanforderungen bilden wiederum die Basis für den Software-Qualifizierungstest und alle nachfolgenden Prozesse, z. B. die Softwarearchitektur.

  Die Softwareanforderungen beschreiben die Software als „Black Box“: „Was“ soll die Software tun, nicht „Wie“ sie etwas tun soll. Die Softwareanforderungen beschreiben zum Beispiel, was die Signale, die an den Pins des Mikrocontrollers ankommen, bedeuten sollen, was die Software mit diesen Signalen machen soll und welche Ausgangssignale wir an den Pins des Mikrocontrollers anlegen.

  Die Softwareanforderungen beschreiben die Software als „Black Box“: „Was“ soll die Software tun, nicht „Wie“ sie etwas tun soll. Die Softwareanforderungen beschreiben zum Beispiel, was die Signale, die an den Pins des Mikrocontrollers ankommen, bedeuten sollen, was die Software mit diesen Signalen machen soll und welche Ausgangssignale wir an den Pins des Mikrocontrollers anlegen.

  Bei diesem Ansatz werden die Anforderungen außerdem so strukturiert, dass sie für die interne Organisation Sinn ergeben und die Verteilung der Anforderungen auf verschiedene Interessensbereiche unterstützen. So weiß jede Organisationseinheit, 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.

• Analysieren und verstehen Sie die Auswirkungen Ihrer Anforderungen. Ein weiterer Aspekt dieses Prozesses ist, wie der Name schon sagt, die Analyse der Anforderungen. Die Anforderungen sollten auf Machbarkeit bzw. Risiko analysiert werden – zwei eng verbundene Aspekte. Wenn Sie sich über die Machbarkeit einer Anforderung nicht sicher sind, besteht ein inhärentes Risiko, da die Suche nach einer Lösung möglicherweise lange dauert oder es überhaupt keine Lösung gibt. Hier besteht auch ein enger Zusammenhang zu den Schätzungen, die im Rahmen des Projektmanagements (insbesondere MAN.3.BP5) durchgeführt werden müssen. Ein weiteres zu analysierendes Thema ist die Testbarkeit. Natürlich können die Tester diese analysieren und die Anforderungen überprüfen. Darüber hinaus sollte die Analyse auch die technischen Auswirkungen abdecken, einschließlich der Beurteilung von Abhängigkeiten zwischen Anforderungen.

  Ein Beispiel hierzu findet sich im Video zur System-Anforderungsanalyse (SYS.2).

  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.

• Stellen Sie Traceability und Konsistenz sicher.Zu diesem Prozess gehört auch die Nachverfolgbarkeit, die so genannte Traceability, zwischen Ihren Softwareanforderungen, den Systemanforderungen und der Systemarchitektur.

  In Automotive SPICE® wird jedoch ausdrücklich darauf hingewiesen, dass eine Redundanz nicht erforderlich ist. Sie können entscheiden, ob sie eine Traceability zu den Systemanforderungen, zur Systemarchitektur oder zu einer Kombination der beiden bevorzugen. Entscheidend ist, welcher Ansatz Ihre Entwicklung am besten unterstützt, nicht welcher Ansatz für Sie am einfachsten ist.

  Die Traceability kann durch Hyperlinks wie DOORS, durch spezifische Traceability-Tools wie Rectify, durch Traceability-Matrizen oder durch andere verwaltbare Mittel hergestellt werden, die von Ihrer Toollandschaft unterstützt werden.

  Zweck der Traceability besteht in der Unterstützung von:

  • Konsistenzprüfungen, d. h. der Überprüfung auf Vollständigkeit und Korrektheit der Softwareanforderung
  • Der Auswirkungsanalyse (Impactanalyse) bei Änderungsanträgen oder Mängeln
  • Der Berichterstattung über den Stand der Umsetzung

  Ein weiterer Aspekt ist die Konsistenz.

  Konsistenz bedeutet, dass Sie die Vollständigkeit und Richtigkeit Ihrer Softwareanforderungen gegenüber den Systemanforderungen bzw. Ihrer Systemarchitektur nachweisen.

  Dies kann nur durch einen Review erfolgen.

  Wird dieser Review ausgelassen, kann das zu unvollständigen oder fehlerhaften Softwareanforderungen führen. Im schlimmsten Fall bleiben Mängel auch im Software-Qualifizierungstest unbemerkt, da dieser Test anhand Ihrer Softwareanforderungen durchgeführt wird. Bei fehlerhaften Softwareanforderungen zeigt Ihr Test möglicherweise kein falsches Verhalten. Überspringen Sie diesen Review nicht.

Tutorial zur Software-Anforderungsanalyse für Fortgeschrittene

Welchen Nutzen bietet die Software-Anforderungsanalyse?

Die Softwareanforderungen für die softwarebezogenen Elemente und ihre Schnittstellen in der Systemarchitektur sind vollständig analysiert und dokumentiert. Sie bilden die Grundlage für die eigentliche Softwareentwicklung.

Was beinhaltet die Software-Anforderungsanalyse?

• Die funktionalen und nicht-funktionalen Anforderungen an die Software werden unter Berücksichtigung der Systemanforderungen und der Systemarchitektur ermittelt (BP1).
• Alle Softwareanforderungen 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).
• 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 Softwareanforderungen, den Systemanforderungen und der Systemarchitektur hergestellt (BP6, BP7).
• Die Softwareanforderungen und deren Aktualisierungen werden vereinbart und allen Stakeholdern mitgeteilt (BP8).

Quellen für die Ermittlung von Softwareanforderungen

Erfahrungen, Probleme und Tipps

• In vielen Fällen sind die Kundenanforderungen so detailliert, dass sie unverändert oder mit geringfügigen Änderungen als Softwareanforderungen verwendet werden können. Allerdings muss eine Analyse durchgeführt werden, um festzustellen, ob es Auswirkungen auf das System gibt. Die vollständige Abdeckung der Kundenanforderungen und die Traceability zu den Kundenanforderungen müssen ebenfalls nachgewiesen werden.
• Bei einem reinen Softwareprodukt sind die Kundenanforderungen direkt mit den Softwareanforderungen verknüpft, da in diesem Fall keine Systemanforderungen erforderlich sind.
• Hinsichtlich der Traceability zwischen Softwareanforderungen und Systemanforderungen sowie zwischen Softwareanforderungen und Systemarchitektur ist keine Redundanz erforderlich. Es kommt auf das Projekt an, für welche Umsetzung man sich entscheidet.
• Wenn das Projekt plattformbasiert ist, können die Softwareanforderungen der Plattform übernommen werden. Die Plattformanforderungen sollten jedoch sorgfältig analysiert werden, um sicherzustellen, dass sie für die neuen Projektanforderungen relevant und genau sind.
• Traceability allein reicht nicht aus – zusätzlich muss Konsistenz nachgewiesen werden. Mit Konsistenzprüfungen (durch Reviews) muss verifiziert werden, dass die Softwareanforderungen eine korrekte Interpretation der Systemanforderungen sind und dass Traceability und Links korrekt und vollständig sind.
• In manchen Systemen umfassen die Funktionen zwei oder mehr Disziplinen, etwa Hardware und Software. Es ist wichtig klarzustellen, welcher Teil der Funktion durch die Softwareanforderungen abgedeckt wird.
• Bei softwarelastigen Systemen können sich die Anforderungen auf System- und Softwareebene überschneiden, aber sie sollten niemals identisch sein.

Vertiefen Sie Ihr Wissen über Automotive SPICE® 

Sie interessieren sich für Automotive SPICE®? Dann sind unsere Automotive SPICE® Schulungen genau das Richtige für Sie!

Ü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

Ressourcenleitfaden zur Software-Anforderungsanalyse (SWE.1)

Dienstleistungen für Automotive SPICE und Erweiterungen