Serie „Requirements Engineering für KMU“ – Teil 3 Requirements Engineering – Nicht-funktionale Anforderungen

Von Stefan Lange und Moises Lorenzo-Leon* 5 min Lesedauer

Anbieter zum Thema

Sie haben sich bereits mit den Grundlagen des Requirements Engineering befasst und wissen, über welche Funktionalitäten oder welche Struktur ihr System verfügen soll. Aber wie lassen sich Anforderungen erfassen, die sich nicht auf eine spezielle Funktion beziehen, wie etwa Qualitäts- oder Leistungsmerkmale?

Leistung, Zuverlässigkeit, Sicherheit: Es gibt viele Anforderungen, die nicht mit speziellen Funktionen verbunden, aber doch von essentieller Bedeutung für ein System sind.(Bild:  frei lizenziert /  Pixabay)
Leistung, Zuverlässigkeit, Sicherheit: Es gibt viele Anforderungen, die nicht mit speziellen Funktionen verbunden, aber doch von essentieller Bedeutung für ein System sind.
(Bild: frei lizenziert / Pixabay)

Im Mittelpunkt dieser Serie steht die Frage, warum gründliches Requirements-Engineering insbesondere für kleinere und mittlere Unternehmen in der Elektronikindustrie eine entscheidende Rolle spielt, welche typischen Fragenstellungen dabei auftreten können und wie sie zu lösen sind. In den ersten beiden Teilen beschäftigten wir uns mit den Grundlagen wie der Begriffsdefinition sowie den verschiedenen Abstraktionsebenen von Anforderungen. Heute stehen Anforderungen im Mittelpunkt, die sich nicht direkt auf die Funktionalität, sondern auf die Qualität beziehen. Die Begriffe „nicht-funktionale“ bzw. Qualitätsanforderungen sind beide in der einschlägigen Literatur verbreitet und beschreiben eine ganze Reihe unterschiedlicher Bereiche.

Qualitätsanforderungen stellen nach wie vor eine Herausforderung für viele Projektteams dar. Insbesondere mehrdeutige Begriffe wie „einfach“, „schnell“, „zuverlässig“, „sicher“, „skalierbar“, „effizient“, „robust“, etc. führen häufig zu unterschiedlichen Interpretationen und Missverständnissen zwischen den Projektbeteiligten und den Entwicklungsteams. Verfehlte Erwartungen, Nacharbeiten, Zeitverzug und andere Probleme sind die Folge.

In der Praxis neigen Stakeholder dazu, Qualitätsanforderungen zu übergehen, da sie diese als selbstverständlich betrachten. Wenn es um Faktoren wie Benutzerfreundlichkeit, Zuverlässigkeit oder Verfügbarkeit geht, kann es jedoch sinnvoll sein, ein Qualitätsmodell als Leitfaden zu verwenden. Umfassende Beispiele hierfür sind in der Literatur und in Normen wie z. B. IEC 25010 zu finden. In jedem Fall ist es wichtig, genau zu definieren, was unter dem jeweiligen Begriff konkret zu verstehen ist.

In der Literatur werden mehrere Gruppen von nichtfunktionalen Anforderungen definiert. Es folgt eine komprimierte, geeignete Auswahl für typische elektronische Industrieprojekte und Umgebungen.

Performance (Leistung)

Der Begriff bezieht sich darauf, in welchem Umfang, wie gut und unter welchen Bedingungen eine Funktion oder Aufgabe zu erfüllen ist. Es handelt sich um messbare Anforderungen an die Systemleistung, die einzeln überprüfbar sind. Dabei ist zu beachten, dass mit einer Funktion, einer funktionalen Anforderung oder einer Aufgabe mehr als eine Leistungsanforderung verbunden sein kann.

Diese Leistungsanforderungen beziehen sich u.a. auf:

  • Zeit (z. B. für die Durchführung einer Aufgabe oder die Reaktion auf externe Ereignisse)
  • Umfang (z. B. die erforderliche Datenbankgröße)
  • Häufigkeit (z. B. für die Berechnung einer Funktion oder den Empfang von Sensorsignalen)
  • Durchsatz (z. B. die Datenübertragungs- oder Transaktionsraten)
  • Ressourcenverbrauch (z. B. bezüglich CPU, Speicher, Bandbreite, Batterie)

Benutzerfreundlichkeit

Dieser Begriff beschreibt die Eigenschaften eines Systems hinsichtlich der Anforderungen an messbare Effektivität, Effizienz und anderer Zufriedenheitskriterien aus Sicht des Benutzers.

Ein Beispiel hierzu wäre die folgende Vorgabe: „Jede Funktion des Systems sollte maximal 3 Benutzerinteraktionen zur Ausführung haben.“. Ungenügend formulierte Anforderungen enthalten stattdessen Aussagen wie „Das System muss einfach zu erlernen und zu benutzen sein“, was zu ungenau und generisch ist.

Eine Möglichkeit besteht darin, die Anforderungen vom Kenntnisstand des Benutzers abhängig zu machen. Einige mögliche Parameter dieser Kategorie könnten wie folgt aussehen:

„Das Ziel ist, dass das System einfach einzurichten ist, da Probleme beim Setup am häufigsten Supportanfragen und Systemretouren der aktuellen Generation verursachen. Ein Neueinsteiger sollte in der Lage sein, den Vorgang innerhalb von 20 Minuten abzuschließen. Ein erfahrener Nutzer innerhalb von 5 Minuten.“

Diese Punkte liefern eine Vielzahl von Informationen in einem kompakten Format. Darüber hinaus sind sie überprüfbar und weit weniger mehrdeutig als die ursprüngliche Beschreibung. Der größte Vorteil einer präzisen formulierten Anforderung ist außerdem, dass jeder Beteiligte, der mit dieser nicht einverstanden ist, seine Meinung frühzeitig äußern kann, und somit Korrekturen noch kostengünstig und unaufwändig umgesetzt werden können.

Anpassungsfähigkeit

Dies bestimmt die mögliche Erweiterbarkeit, Wachstum oder Skalierbarkeit während der Systemlebensdauer.

Logistik

Damit werden die logistischen Bedingungen festgelegt, die für die kontinuierliche Nutzung des Systems erforderlich sind. Die damit verbundenen Anforderungen umfassen Instandhaltung (Bereitstellung von Einrichtungen, Support-Level, Betreuungspersonal, Ersatzteile, Schulung, technische Dokumentation usw.), Verpackung, Handhabung, Versand und Transport.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Embedded Software Engineering Kongress

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Zuverlässigkeit

Das Verhalten des Systems muss konsistent sein und seiner Spezifikation entsprechen.

Verfügbarkeit

Das System muss bei Bedarf für den Betrieb bereit sein. Zum Beispiel muss das System zu mindestens 99,8% seiner vorgesehenen Betriebszeit verfügbar sein.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Wartbarkeit

Hier stellt sich im Hinblick auf die Konstruktion die Frage nach den Anforderungen an die Wartbarkeit: Sollen z. B. Sicherungen gut zugänglich sein, um gegebenenfalls leicht getauscht werden zu können?

Prüfbarkeit

Hiermit wird festgelegt, inwieweit das System testfähig für Typ- und Linientests sein soll.

Safety

Kann das System Schäden an Personen oder an seiner Systemumgebung verursachen? Welche Anforderungen bestehen, um dem entgegenzuwirken?

(Cyber-)Security

Bestehen Anforderungen das System und seine Daten vor unerlaubtem Zugriff zu schützen?

Bei näherer Betrachtung gibt es also viele Parameter, die zu beachten sind, deren Bedeutung aber auch genau beschrieben werden muss, um Fehleinschätzungen zu vermeiden. Diese Vielschichtigkeit ist gerade für KMU schwer zu bewältigen, weshalb es eine gute Entscheidung sein kann, die Unterstützung eines erfahrenen Dienstleisters wie Heitec in Anspruch zu nehmen.

Im nächsten Teil unserer Serie werfen wir einen genaueren Blick auf die dritte Kategorie der Systemanforderungen: Die Randbedingungen (constraints).  (sg)

Literaturverweise

IREB (2022). Certified Professional for Requirements Engineering - Foundation Level - Handbuch (1.2.0). IREB e.V.

ISO/IEC/IEEE 29148:2018. Systems and software engineering - Life cycle processes - Requirements engineering

ISO/IEC 25010:2023. Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Product quality model

SEBOK(2025). Guide to the Systems Engineering Body of Knowledge (SEBoK). https://www.sebokwiki.org/

* Stefan Lange ist Teamleiter Systems Engineering im HEITEC Geschäftsgebiet Elektronik und Dozent für Systems Engineering an der Hochschule Augsburg.

* Moises Lorenzo-Leon ist Systemingenieur im HEITEC Geschäftsgebiet Elektronik und Certified Professional für Requirements Engineering.

(ID:50629913)