Viele Lastenhefte und Pflichtenhefte unterscheiden funktionale Anforderungen und nicht-funktionale Anforderungen. Funktionale Anforderungen sind Anforderungen mit Bezug zur Zweckbestimmung des Produkts. Zu den nicht-funktionale Anforderungen zählen Anforderungen wie die Zuverlässigkeit und das Zeitverhalten.
Dieser Artikel hilft mit Beispielen, beide Anforderungstypen zu unterscheiden, und erläutert die Auswirkung auf deren Dokumentation.
1. Unterscheidung von funktionalen und nicht-funktionale Anforderungen
Diese Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen stammt noch aus Zeiten der ISO 9126 (die inzwischen abgelöst wurde durch die ISO 25010):
Die Trennung zwischen den beiden Typen an Anforderungen findet sich v.a. bei stand-alone Software.
a) Funktionale Anforderungen
Funktionale Anforderungen haben meist einen direkten Bezug zur Zweckbestimmung des Produkts. Sie sind spezifisch für dieses Produkt. Beispiele für diesen Typ an Anforderungen sind:
- Die Software muss den Body-Mass-Index basierend auf einer gegebenen Formel auf eine Nachkommastelle genau berechnen.
- Die Software muss vor Arzneimitteln warnen, für die eine Kontraindikation oder Wechselwirkung vorliegt.
b) Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen sind meist unspezifisch für ein Produkt. Beispiele sind:
- Zeitverhalten: Das System muss innerhalb von 10 ms das Ergebnis berechnet haben.
- Ressourcenverbrauch: Das System kann 15.000 Transaktionen pro Sekunde bearbeiten ohne, dass die CPU zu mehr als 50% ausgelastet ist.
- Robustheit: Das System kann 4 Wochen im Dauerbetrieb ohne ein Neustarten betrieben werden.
- IT-Sicherheit: Die Software blockiert nach drei Fehlversuchen die Anmeldung für 30 Sekunden.
Probleme mit funktionalen und nicht-funktionalen Anforderungen
a) Schwierige Unterscheidung
Die Unterscheidung ist oft nicht trivial: Wo würden Sie die Fähigkeit eines Systems, Fehleingaben zu erkennen subsumieren?
- Unter Gebrauchstauglichkeit? Eines der Prinzipien der Gebrauchstauglichkeit gemäß ISO 9241 ist die Fehlertoleranz.
- Unter Zuverlässigkeit? Die ISO 9126 zählt die Fehlertoleranz explizit dazu.
- Unter Funktionalität? Schließlich ist es eine Funktion des System Fehleingabe zu erkennen und darauf zu reagieren.
Auch lässt sich trefflich darüber streiten, ob die Interoperabilität wirklich keine funktionale Anforderung ist. Wie sollte sich denn die Funktionalität eines Systems außer über die UI denn sonst erfahren lassen?
Fazit: Eine Unterscheidung zwischen den beiden Anforderungstypen ist meist überflüssig. Die Software Requirements Specification muss aber sicherstellen, dass beide Typen spezifiziert sind.
Die Nachfolge-Norm ISO 25010 betrachtet zwei Aspekte nicht mehr als funktionale Anforderungen:
Lesen Sie hier mehr zur ISO 25010 und zur ISO 9126.
b) Aufteilung der Dokumentation
Manche Hersteller teilen die Anforderungen nach Typen auf verschiedene Dokumente auf:
- Die Produktmanager spezifizieren die funktionalen Anforderungen,
- die Entwickler die nicht-funktionalen.
Das Johner Institut rät von dieser Aufteilung ab. Damit laufen Hersteller in Gefahr, zusammengehörige Aspekte zu trennen und nicht-zusammengehörige Aspekte in einem Dokument zu beschreiben. Das führt zu regulatorischen Problemen u.a. mit der Freigabe und der Traceability.
Beachten Sie, dass die Wartbarkeit der einzige Ast der ISO 25010 ist, der nicht zu den System-Anforderungen zählt. Er ist ein Aspekt der Architektur.
In ein Lastenheft sollte Stakeholder-Anforderungen beschreiben, ein Pflichtenheft die Systemanforderungen. Letztere können Sie sehr gut mit der ISO 9126 bzw. der ISO 25010 auf Vollständigkeit prüfen.
c) Struktur der Dokumente
Die IEC 62304 hat in den Ausgaben 2005 und 2015 die Strukturierung nach der Taxonomie der ISO 9126 bzw. der ISO 25010 übernommen. Eine Software Requirements Specification danach zu strukturieren ist nicht sinnvoll.
Das Johner Institut empfiehlt dieses Dokument nach Schnittstellentyp aufzuteilen.
Der Auditgarant zeigt in Videos, wie Sie Schritt für Schritt die Anforderungen schnell, systematisch und normenkonform dokumentieren können. Er stellt dafür vollständige Templates bereit und nimmt so einen großen Teil der Arbeit ab.
Änderungshistorie
- 2023-04-18: Redaktionelle Änderungen, Hinweis auf die IEC 62304 mit aufgenommen, fehlende Links ergänzt
- 2018-05-13: Erste Version des Artikels erstellt
Steht die ISO25010 mit ihrer genauen Spezifikation für Studenten kostenlos zur Verfügung?
Nein, Sie könnten es höchstens über die Hochschulbibliothek versuchen…
Hallo,
Wie sehen Sie eine Marktrelevanz für ein zertifiziertes Software Testtool?
Testing-Tools halte ich immer für wichtig. Mit dem Begriff der Zertifizierung müssen wir vorsichtig hantieren.
Alles, was nicht unter dem Dach der DaKKS zertifiziert ist, ist für MP-Hersteller nur bedingt hilfreich.