In den vergangenen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. Sie wissen jetzt, wie Sie die richtigen fachlichen Prozesse mitsamt den dafür notwendigen fachlichen Daten ermitteln und kommunizieren, Sie kennen User Stories, Abläufe und Features. Ihre Anwendung kann jetzt (beispielsweise) Kinokarten verkaufen. Aber da war doch noch was: Die Zahlungen der Kinokarten sollen gegen unbefugte Zugriffe geschützt und vor allen Dingen nicht abstreitbar erfolgen (Stichwort: IT-Sicherheit). Außerdem muss der gesamte Bezahlvorgang in weniger als dreißig Sekunden abgeschlossen sein (Stichwort: Performance) und natürlich niemals ausfallen (Stichwort: Zuverlässigkeit). Diesen schwierigen Themen wenden wir uns in den nächsten Folgen zu – den Qualitätsanforderungen.

Mehr als „gut“ oder „schlecht“

Kleine Vorbemerkung: Wir sprechen hier von „Produktqualität“ und meinen damit die Qualität unserer (Software-)Systeme. Das Thema „Prozessqualität“ lassen wir an dieser Stelle außen vor.

Qualität ist ein vielschichtiges Biest – wählen wir ein Beispiel aus dem realen Leben. Sie trinken gerne Tee und laden ein paar Leute zu einer Teeverkostung ein. Sie möchten gerne „hohe Qualität“ ausschenken – aber was ist das genau? Die einen mögen Grüntee aus Japan, blassgrün in der Tasse, bevorzugen den zweiten (mit 75 Grad Celsius Wassertemperatur) oder gar dritten Aufguss (über 80 Grad) – natürlich ungesüßt. Andere bevorzugen die chinesische Variante mit Jasmin, natürlich im ersten Aufguss. Die nächsten hätten gerne Schwarztee in der arabisch/türkischen Variante, schön lange gekocht und mit viel Zucker serviert. Unsere britischen Kollegen haben ihre eigene Meinung und trinken nordindischen Assam-Schwarztee mit etwas Milch. Und dann waren noch diejenigen, die den spätabendgeeigneten Kräutertee bevorzugen. Ach ja, eine Kollegin hätte gerne Bio und schadstoffarm.

Sie sehen: schon in einem einfachen Beispiel spielen, neben der (funktionalen) Anforderung „wir wollen Tee trinken“, noch weitere Eigenschaften des betroffenen Produkts eine große Rolle: Geschmack (subjektiv), Farbe, Temperatur, Zubereitungsdauer, Zusatzstoffe (Zucker, Aromen), Herkunftsland und so weiter. Manche dieser Eigenschaften nehmen wir implizit an (und hoffen, dass in der EU käufliche Teesorten geltende Schadstoffobergrenzen einhalten).

Wie soll das erst mit dem viel komplexeren Thema Software sein, bei der es eine Vielzahl möglicher weiterer Eigenschaften außer der reinen Funktionalität geben kann? Wo aber ebenfalls eine größere Zahl möglicher Stakeholder explizite und implizite Wünsche an die (Qualitäts-)Eigenschaften von Systemen haben?

Trauerspiel Praxis

In unserer Praxis realer Entwicklungsprojekte – in verschiedenen Branchen – gibt es einen gemeinsamen Nenner, nämlich den traurigen Stand (fehlender) expliziter Qualitätsanforderungen. Wir haben recht selten erlebt, dass es eine konsistente...