© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Req4Arcs

Qualität fällt nicht vom Himmel

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.

Peter Hruschka


Mehr als „gut“ oder „schlecht“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 PraxisAber zwei gute Nachrichten gibt es. Erstens: Sie können leicht Abhilfe schaffen (d. h., so schwer ist das Thema in Wirklichkeit gar nicht), und zweitens haben eine Menge schlauer Leute vor Ihnen dieses Thema ziemlich gründlich aufgearbeitet (sprich: Es gibt mit ISO-25010 einen nützlichen Standard, siehe [1] und Abb. 1).Qualitätsanforderungen sind ArchitekturtreiberAn dieser Stelle hören wir schon Ihren inneren Protest: „Ja, aber das kann ich doch im Vorfeld noch gar nicht wissen.“ Wir möchten auf keinen Fall zurück zu Wasserfall und Vorabspezifikation, sondern zu einem intelligenten, angemessenen und vor allem expliziten Umgang mit Qualitätsanforderungen. Das bedeutet insbesondere, Qualitätsanforderungen bereits zusammen mit funktionalen Anforderungen zu bearbeiten, und nicht auf „irgendwann später“ zu ...

Java Magazin
Kolumne: Req4Arcs

Qualität fällt nicht vom Himmel

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.

Peter Hruschka


Mehr als „gut“ oder „schlecht“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 PraxisAber zwei gute Nachrichten gibt es. Erstens: Sie können leicht Abhilfe schaffen (d. h., so schwer ist das Thema in Wirklichkeit gar nicht), und zweitens haben eine Menge schlauer Leute vor Ihnen dieses Thema ziemlich gründlich aufgearbeitet (sprich: Es gibt mit ISO-25010 einen nützlichen Standard, siehe [1] und Abb. 1).Qualitätsanforderungen sind ArchitekturtreiberAn dieser Stelle hören wir schon Ihren inneren Protest: „Ja, aber das kann ich doch im Vorfeld noch gar nicht wissen.“ Wir möchten auf keinen Fall zurück zu Wasserfall und Vorabspezifikation, sondern zu einem intelligenten, angemessenen und vor allem expliziten Umgang mit Qualitätsanforderungen. Das bedeutet insbesondere, Qualitätsanforderungen bereits zusammen mit funktionalen Anforderungen zu bearbeiten, und nicht auf „irgendwann später“ zu ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang