Nichtfunktionale Anforderungen testen, ein Widerspruch?

In der Praxis gibt es immer wieder Diskussionen darüber, was funktionale und was nicht funktionale Anforderungen an ein System sind.

Könnte eine geeignete Strukturierung der Anforderungen nach den richtigen Themen die Diskussion überflüssig machen?
Wie wird der Nachweis erbracht, dass alle Anforderungen erfüllt sind? 

In diesem Blogbeitrag beschreiben wir einen möglichen Lösungsansatz. 

Anforderungen und deren Verifizierung 

Traditionell wurden Anforderungen in funktionale Anforderungen und den Rest (nicht funktionale Anforderungen) eingeteilt. Diese Klassierung hält sich hartnäckig obwohl neuere Normen wie [ISO/IEC 25010:2011] “System and software quality models” den Begriff “nicht funktional” nicht verwenden.

Unter Zeitdruck verleitet die traditionelle Aufteilung dazu nur die “Funktion” zu realisieren und den “Rest” auf später zu verschieben.

Der Effekt könnte sein, dass das System/Produkt im Markt nicht den gewünschten Erfolg liefert. 

Bild 1: Traditionelle Aufteilung der Anforderungen in zwei Hauptklassen

Für eine Machbarkeitsstudie kann es genügen, nur die minimalen funktionalen Anforderungen zu erfüllen (Stichwort MVP:  “Minimum Viable Product”).

Damit ein System/Produkt seinen Zweck nachhaltig leistet, sind weitere Anforderungen zu formulieren, zu realisieren und nachzuweisen. 
 
Wir empfehlen Anforderungen in viele Themenbereiche einzuteilen und gleichzeitig die geeignete Verifizierungsmethode zuordnen.

Einen Vorschlag der Themenbereiche ist in Bild 2 dargestellt, weitere können in den folgenden  Normen entnommen werden. 

• [ISO/IEC/IEEE 29148:2018] «Systems and software engineering —Life cycle processes — Requirements engineering»
• [ISO/IEC 25010:2011] “System and software quality models”
• [Capturing Architectural Requirements, FURPS+ :2005] 
   
  
  

Neben dem klassischen «Testen» existieren noch weitere Verifizierungsmethoden.

Die Norm [ISO/IEC/IEEE 29148:2018] beschreibt vier Standardüberprüfungsmethoden, um den objektiven Nachweis zu erbringen, dass die Anforderungen erfüllt wurden: 

• Inspektion 
• Analyse oder Simulation
• Demonstration
• Prüfung (Test/Messung)
  
  

Der Vorteil einer solche Aufteilung und direkten Zuteilung der Verifizierungsmethode liegt darin, dass die Anforderungen systematisch pro Themenbereich erfasst werden und dadurch das Risiko sinkt etwas zu vergessen.

Auch sind die Tests und Nachweise einfacher planbar und durchführbar, da bereits die richtigen Methoden formuliert sind. 

Bild 2: Anforderungen nach Themen und Zuordnung Verifizierungs-Methode

Notiz 1: Human and Organisational Factors (HOF), umfassen unter anderem Anforderungen ans Design des HMI wie Haptik, usw.
Eine gute Übersicht über die HOF-Themen liefert [ERA-HOF] und [RailHOF-Design]. 

Tipps zur Umsetzung

• Gruppiere Anforderungen in mehrere Themen, lege die Verifizierungsmethode bereits beim Schreiben der Anforderung fest.
• Verwende das Wort «Nicht funktionale Anforderung» nicht.
• Überlege bereits beim Schreiben der Anforderungen, ob die Verifizierung machbar ist. 

Fazit

Sind «nicht funktionale Anforderungen» testbar?

Ja, dazu sind aber zwei Punkte zu berücksichtigen:

Einerseits sollten Anforderungen nach dem entsprechenden Thema wie «Performance», «Interface», «physikalische Eigenschaften», usw. strukturiert werden und nicht nur in die Kategorien «funktional» / «nicht funktional».

Andererseits sollte für die jeweiligen Kategorien die verschiedenen Verifizierungsmöglichkeiten betrachtet, abgewogen und die geeignetste definiert werden.

Mit einer solchen Strukturierung und systematischem Vorgehen gelingt es dann auch scheinbar nicht testbare Anforderungen zu verifizieren und ein Produkt mit der gewünschten Qualität zu realisieren. 
 
CSA Engineering verfügt über fundierte Kenntnisse im Requirements Engineering/Test Engineering und ist in der Lage, die jeweils geeigneten Methoden für ein Projekt auszuwählen und anzuwenden.

Durch eine optimale Abstimmung mit den Verifizierungsmethoden kann von Beginn an eine solide Grundlage für das Projekt geschaffen werden. 
 
Gerne unterstützen wir Sie bei Ihrem Projekt. Zögern Sie nicht, uns zu kontaktieren. 

Jetzt Kontakt aufnehmen >

Quellen und Referenzen 

• [ISO/IEC/IEEE 29148:2018] «Systems and software engineering —Life cycle processes — Requirements engineering» 
• [ISO/IEC 25010:2011] “Systems and software engineering – Systmes and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models”
• [ERA-HOF] Human and Organisational Factors (HOF) | European Union Agency for Railways, abgerufen am 10.03.2025
• [RailHOF-Design] HOF in Design Archives - RailHOF , abgerufen am 10.03.2025
• [Capturing Architectural Requirements, FURPS+], IBM, Peter Eeles, 2005, abgerufen aus web.archive.com am 13.03.2025
• Von der Idee zum Produkt: Requirements Engineering gibt die Richtung vor  - CSA.ch, Blog Beitrag Daniel Niggli, 20. Aug. 2024