O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

55
2.6 ENG.4 Softwareanforderungsanalyse
2.6 ENG.4 Softwareanforderungsanalyse
2.6.1 Zweck
Zweck des Prozesses ist es, die Softwareanforderungen des Systems zu ermitteln.
Nachdem in ENG.3 die Systemelemente, bestehend aus Hard- und Software,
bestimmt wurden, werden ab diesem Prozess bis ENG.8 ausschließlich die Soft-
wareanteile in Form der Softwareelemente des Systems betrachtet. Die Software-
anforderungsanalyse ist der Zwischenschritt zwischen ENG.3 Systemarchitektur-
design und ENG.5 Softwaredesign. In ENG.4 werden die Anforderungen an die
Softwareelemente ermittelt. Softwareanforderungen werden in funktionale und
nicht funktionale Anforderungen unterschieden.
2.6.2 Besonderheiten in der Automobilindustrie
In der Praxis verlaufen die Übergänge der Prozesse ENG.2 bis ENG.5 meist flie-
ßend und sind iterativer und rekursiver Natur. Der Code muss neben den funkti-
onalen Anforderungen weiteren, nicht funktionalen Anforderungen genügen, die
im Rahmen der Softwareanforderungsanalyse ermittelt werden. Neben der Ein-
haltung von Codierrichtlinien, wie z.B. MISRA Rules [MISRA], werden weitere
Qualitätsanforderungen (z.B. in Form von Metriken) für den Sourcecode festge-
legt, die Qualitätseigenschaften der Software wie z.B. Analysierbarkeit, Änder-
barkeit, Stabilität und Testbarkeit positiv beeinflussen.
In letzter Zeit werden immer stärker formale Methoden zur Softwareanfor-
derungsanalyse angewendet. Eine Formalisierung der Anforderungsermittlung,
nicht nur für System-, sondern auch für die Softwareumfänge lässt sich z.B. durch
die Erstellung von Use-Case-Diagrammen erreichen. Use-Case-Diagramme sind
eine grafische und textliche Darstellung der abzubildenden Funktionalität. Als
Beschreibungssprache wird z.B. UML
33
verwendet. Diese formale Vorgehens-
weise bietet Vorteile bzgl. Eindeutigkeit, Verständlichkeit, Kommunikation von
Inhalten, Unabhängigkeit von der Implementierung, Nachvollziehbarkeit, Wie-
derverwendbarkeit, Fehlererkennung und des Nachweises der Korrektheit.
33. Unified Modeling Language; UML
TM
ist eine durch die Object Management Group (OMG)
standardisierte grafische Beschreibungsform für objektorientierte Modelle.
2 Interpretationen zur Prozessdimension
56
2.6.3 Basispraktiken
BP1: Ermittle die Softwareanforderungen. Verwende die Systemanforderungen
und die Systemarchitektur als Grundlage für die Ermittlung von funktionalen
und nicht funktionalen Softwareanforderungen. Dokumentiere die Softwarean-
forderungen in einer Softwareanforderungsspezifikation.
Anmerkung: Im Falle einer reinen Softwareentwicklung beziehen sich die
Systemanforderungen und die Systemarchitektur auf eine bestehende Betriebs-
umgebung (siehe auch Anmerkung bei BP3). In diesem Fall sollten die Kunden-
anforderungen als Grundlage für die Ermittlung der geforderten Funktionen und
Fähigkeiten der Software genutzt werden.
Funktionale und nicht funktionale Anforderungen an die Software werden ermit-
telt und den einzelnen Softwareelementen zugeordnet. Funktionale und nicht
funktionale Anforderungen an die Software können zum Teil direkt aus der Sys-
temanforderungsspezifikation übernommen werden, zum Teil bedarf es einer
inhaltlichen Transformation. Automotive SPICE fordert explizit, dass eine Soft-
wareanforderungsspezifikation (z.B. ein Softwarepflichtenheft) erstellt wird.
BP2: Analysiere die Softwareanforderungen. Analysiere die ermittelten Soft-
wareanforderungen im Hinblick auf technische Machbarkeit, Risiken und Test-
barkeit.
Anmerkung: Verifikationskriterien sollten für alle Softwareanforderungen für
die spätere Entwicklung der Softwaretestfälle definiert werden.
Anmerkung: Die Ergebnisse der Analyse können zur Kategorisierung der Anfor-
derungen genutzt werden.
Für die Analyse der Softwareanforderungen gelten die Ausführungen bei ENG.2
BP2 analog. Softwarespezifische Risiken können z.B. sein:
Hinweis für Assessoren
In vielen Projekten wird keine separate Softwareanforderungsspezifikation erstellt,
sondern alle relevanten Anforderungen (funktionale und nicht funktionale Sys-
tem- und Softwareanforderungen) sind in einem einzigen Dokument (z. B. im
Pflichtenheft) beschrieben. Der Grund ist oft, dass die Systemfunktionalität zwar
hauptsächlich durch Software bestimmt ist, aber von der Hardwarefunktionalität
nicht sinnvoll zu trennen ist. Die Bewertung dieser Basispraktik sollte dann abhän-
gig vom Projektkontext und von der Projektgröße erfolgen. Zur vollständigen
Erfüllung sollte nachgewiesen werden, dass die funktionalen und nicht funktiona-
len Anforderungen für Software eindeutig spezifiziert wurden und für den Funkti-
onsumfang angemessen sind. Das heißt, es müssen sowohl die Aspekte der Sys-
temebene als auch die der Softwareebene erkennbar sein, egal ob in einem
Dokument oder in mehreren getrennten Dokumenten.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required