Systementwicklung Nicht-funktionale Anforderungen

Bei der Entwicklung der meisten Systeme liegt der Fokus heute auf Funktionalität. Solange diese die Bedürfnisse der Nutzer erfüllt, akzeptieren diese normalerweise, wenn einige der nicht-funktionalen Anforderungen nicht vollständig umgesetzt werden konnten beziehungsweise angepasst wurden. Dies gilt jedoch nicht für Embedded Systeme. Speziell in industriellen Anwendungen wirken sich diese auf das ganze System aus.

Nicht-funktionale Anforderungen an Embedded Systeme wirken sich in der Regel auf das gesamte System auf, einschließlich der Art und Weise wie es entwickelt und gepflegt wird. Derartige Systeme müssen die Umgebung »kennen«, in der sie ausgeführt werden sollen, da diese das Produktverhalten beeinflusst. Bei der Entwicklung eingebetteter Systeme liegt heutzutage ein deutlich stärkerer Fokus auf Erkennung und Behandlung möglicher Fehler. Typische nicht-funktionale Software-Anforderungen für Embedded Systeme sind synchrone beziehungsweise nicht-synchrone Ausführung, Sicherheit und Zuverlässigkeit, knappe Ressourcen und Autonomie (keine menschliche Interaktion).

Es gibt zwei Arten nicht-funktionaler Anforderungen. »Harte« Anforderungen sind nicht verhandelbar und müssen vom System erfüllt werden, andernfalls wird es nicht abgenommen. »Weiche« Anforderungen sind mit dem Kunden verhandelbar, und die Nichterfüllung muss nicht unbedingt eine Ablehnung des Systems zur Folge haben. Bei eingebetteten Systemen sind die meisten nicht-funktionalen Anforderungen harte Anforderungen. In seltenen Fällen besteht Verhandlungsspielraum, aber zumeist eher mit anderen Systemkomponenten und nicht mit Endanwendern. Auch in diesen Fällen ist die übergeordnete Systemanforderung in der Regel eine harte Anforderung, die zu erfüllen ist.

Nehmen wir zum Beispiel die Anforderung eines Online-Beschaffungssystems, das eine Zahlung innerhalb von 30 Sekunden durchführen soll. Die Entwicklung wird sich wahrscheinlich darauf konzentrieren, die Leistungsfähigkeit der Software dahingehend zu verbessern, dass Zahlungen schnellstmöglich abgewickelt werden. Wenn während der Prüfung herauskommt, dass es trotzdem noch 35 Sekunden dauert, bis die Zahlung durchgeführt ist, so kann das für einen Benutzer durchaus akzeptabel sein. Zwar wird die Nichterfüllung dieser nicht-funktionalen Anforderung Diskussionen mit dem Kunden zur Folge haben, doch werden diese in den meisten Fällen dazu bereit sein, solange die gewünschte Funktion erfolgreich implementiert wurde.

Harte und weiche Anforderungen

Betrachten wir nun eine ähnliche Situation bei einem eingebetteten Steuerungssystem einer Rakete. Sie hat 30 Sekunden Zeit, Geländedaten zu lesen, diese Daten zu verarbeiten und den Kurs der Rakete entsprechend zu aktualisieren. Diese 30 Sekunden sind eine harte Anforderung, bei deren Erfüllung es keinen Spielraum gibt. Wenn die Bedingung nicht erfüllt ist, wird die Rakete wahrscheinlich eine notwendige Kurskorrektur verpassen und deshalb verloren gehen. Diese Gewissheit wird die Arbeit der Software-Entwickler bestimmen.

Wahrscheinlich werden sie die Funktion »automatische Kurskorrektur«, für die 30 Sekunden zur Verfügung stehen, in Detailfunktionen verschiedener Systemkomponenten herunterbrechen und jeder dieser Detailfunktionen einen Teil der Zeit zuordnen. So könnten zum Beispiel anfangs den Detailfunktionen »Geländedaten lesen«, »Geländedaten verarbeiten« und »Raketenkurs aktualisieren« jeweils 10 Sekunden zugeordnet werden. Stellt sich später heraus, dass man bei einer Detailfunktion die Zeitgrenze nicht einhalten kann, so kann zunächst zwischen den Systemkomponenten verhandelt werden, denn möglicherweise lässt sich eine Detailfunktion einer anderen Systemkomponente schneller erledigen.

Entscheidend ist am Ende nur, dass die gesamte Funktion »automatische Kurskorrektur« innerhalb von 30 Sekunden abgeschlossen ist. Eine einzige nicht-funktionale Anforderung kann sich auch auf die Art und Weise, wie ein System entwickelt und getestet wird, auswirken. Zum Beispiel veränderte die Anforderung, einen Mann binnen eines Jahrzehnts auf den Mond zu bringen (Anforderung von John F. Kennedy), seinerzeit das gesamte Raumfahrtprogramm der NASA.

Statt sich auf die Analyse zu konzentrieren, verlagerte sich der Fokus auf häufiges Ausprobieren (viel Prototyping). Auch in heutigen Embedded Systemen können sich nicht-funktionale Anforderungen auf das gesamte in der Entwicklung befindliche System auswirken. Dabei können auch Entwicklungsmethoden und mögliche Lösungsansätze erheblich eingeschränkt werden. Ändert sich eine nicht-funktionale Anforderung, gilt es herauszufinden, welche Komponenten des Systems davon betroffen sind.

Traceability von nicht-funktionalen Systemanforderungen zu den Systemkomponenten und deren detaillierten Subsystem-Anforderungen ist entscheidend, um sicherzustellen, dass alle Aspekte einer Anforderung über ihren gesamten Lebenszyklus hinweg berücksichtigt wurden. Nicht-funktionale Anforderungen sind entscheidend, um sicherzustellen, dass das eingebettete System ordnungsgemäß funktioniert. Daher ist es zwingend erforderlich, die Einhaltung nicht-funktionaler Anforderungen zu prüfen.

Testpläne sollten daher frühzeitig im Entwicklungszyklus erstellt werden, um eine vollständige und umfassende Prüfung der nicht-funktionalen Anforderungen zu gewährleisten. Nicht selten ist eine derartige Anforderung an jeden Testplan zu verlinken, um sicherzustellen, dass diese Anforderung bei jedem ausgeführten Test berücksichtigt wird.

Je größer die Anzahl der nicht-funktionalen Anforderungen, desto schwieriger und aufwändiger wird es sein, das System zu entwickeln und vollständig zu testen. Damit steigen auch Entwicklungskosten und Risiken. Die Verknüpfung nicht-funktionaler Anforderungen zu Entwicklungsartefakten und Tests führt zu einer gleichgewichtigen Konzentration auf funktionale und nicht-funktionale Anforderungen. Entwickler müssen sich der äußeren Zwänge bewusst sein, unter denen das System arbeitet. Sie müssen sich während des Entwurfs und der Entwicklung einer Lösung gleichermaßen auf funktionale und nicht-funktionale Anforderungen konzentrieren. Systemanalytiker müssen sicherstellen, dass der Analyse und Umsetzung nicht-funktionaler Anforderungen ausreichend Zeit eingeräumt wird.

Über den  Autor:

Marcia Stinson ist Senior Requirements Engineering und beratend für Visure Solutions tätig.