SYS.2 Systemanforderungs-Analyse

Ein wichtiger Grund für die Dokumentation der Systemanforderungen ist, dass Sie mehr als die Erwartungen Ihrer Kunden berücksichtigen müssen. Die meisten Systeme müssen Standards, Normen und andere Vorschriften erfüllen, die die Anzahl der Anforderungen erhöhen. Aus diesem Grund werden sie im Prozess als Stakeholder-Anforderungen beschrieben. Zu Dokumentationszwecken ordnen Sie die Stakeholder-Anforderungen Ihren Systemanforderungen zu, die Ihre interne Sicht des Systems widerspiegeln. Die Systemanforderungen bilden wiederum die Basis für den Systemqualifizierungstest und alle nachfolgenden Prozesse, z.B. Systemarchitektur.

Die Systemanforderungen beschreiben das System als Black-Box, das »Was«. Was soll das System tun, nicht »wie« soll es etwas tun. Wenn wir also eine elektronische Steuereinheit (eng. electronic control unit), ein ECU, entwickeln, identifizieren wir Folgendes:

• Sie beschreiben, welche Signale die Pins des Steckverbinders erreichen, was das System mit diesen Signalen tun soll und welche Ausgangssignale wir an den Pins des Steckverbinders erwarten.
• Teil dieses Ansatzes ist es auch, die Anforderungen so zu strukturieren, dass sie für die interne Organisation von Bedeutung sind und die Verteilung auf verschiedene Bereiche unterstützen.
• Dies stellt sicher, dass jede Organisationseinheit weiß, welche Anforderungen für sie relevant sind. Diese können Attribute sein, z.B. um Anforderungen gemäß ISO 26262 zu klassifizieren, es kann sich um eine funktionale Struktur handeln, die die Verteilung auf Funktionsgruppen usw. unterstützt.

In der Regel wird das Anforderungsmanagement durch geeignete Tools wie z. B. eine Anforderungsdatenbank unterstützt.

Eine Herausforderung kann darin bestehen, Mitarbeiter zu finden, die die Definition von Systemanforderungen unterstützen können. Die Herausforderung liegt darin, dass ein Systemingenieur ein Allrounder sein muss. Wenn Sie ein mechatronisches System wie die Servolenkung entwickeln möchten, muss dieser Ingenieur ein tiefes Verständnis für Mechanik, Elektronik und Softwareentwicklung haben. Dies ist fast unmöglich in einer Person zu kombinieren. Wenn Sie nicht über diese Art von Personal verfügen, könnte ein möglicher Workaround sein, ein domänenübergreifendes Team zusammenzustellen, das für die gemeinsame Definition der Systemanforderungen verantwortlich ist.

Ein weiterer Zweck dieses Prozesses ist, wie der Name schon sagt, die Analyse der Anforderungen. Die Anforderungen sollten auf Machbarkeit oder Risiko analysiert werden. Diese beiden Aspekte sind eng miteinander verbunden. Wenn Sie sich hinsichtlich der Machbarkeit einer Anforderung nicht sicher sind, besteht ein inhärentes Risiko, da die Suche nach einer Lösung möglicherweise zu viel Zeit in Anspruch nimmt oder es überhaupt keine Lösung gibt. Ein weiteres zu analysierendes Thema ist die Testbarkeit. Natürlich kann die Unterstützung der Tester genutzt werden, um dies zu gewährleisten. Oft werden die Tester gebeten, die Anforderungen zu überprüfen. Die Analyse sollte auch die technischen Auswirkungen berücksichtigen. Dies beinhaltet die Beurteilung von Abhängigkeiten zwischen Anforderungen. Ein Beispiel hierfür könnte die »Schließen«-Funktion eines Fensterheber-Steuergeräts sein. Für die Schließfunktion muss die Fensterscheibe nach oben gleiten, bis das Fenster geschlossen wird. Es gibt jedoch eine widersprechende Sicherheitsfunktion, die sogenannte »Einklemmschutz«-Funktion, die verhindern soll, dass sich Finger beim Schließen des Fensters einklemmen. Es besteht eine offensichtliche gegenseitige Abhängigkeit und technische Implikation zwischen diesen Anforderungen. Dies sollte im Rahmen der Analyse berücksichtigt werden.

Zu guter Letzt sollte die Analyse auch wirtschaftliche Aspekte der Anforderungen abdecken. Es sollte daher festgestellt werden, wie sich die Umsetzung der verschiedenen Anforderungen auf Kosten und Zeitplan auswirkt. Jetzt können Sie sagen, dass Sie all dies nicht in der Anforderungsdatenbank dokumentieren können.

Beachten Sie, dass Automotive SPICE^® nicht festlegt, wo Sie dies dokumentieren. Beispielsweise können Sie den ersten Teil der Analyse (Machbarkeit und Risiken) in der Anforderungsdatenbank, die technischen Auswirkungen auf entsprechende und verknüpfte Änderungsanforderungen sowie die Auswirkungen auf Kosten und Zeitplan in Ihren Projektmanagementtools abdecken.