Freitag, 13. Juni 2014

Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Nachdem wir im letzten Post verschiedene Szenariotypen untersucht haben, können wir nun Qualitätsanforderungen ermitteln. In der Literatur finden wir folgende Definitionen für diese Art der Anforderungen. "Eine Qualitätsanforderung definiert eine qualitative Eigenschaft des gesamten Systems, einer Systemkomponente oder einer Funktion." [S.16, POHL08] "Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird." [IREB11] Die ISO/IEC 9126 spezifiziert folgende Kategorien zur Softwarequalität: Portierbarkeit, Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Wartbarkeit. Diese Kategorien sind in weitere Subkategorien unterteilt. Die Benutzbarkeit z.B. in Verständlichkeit, Erlernbarkeit, Bedienbarkeit und Attraktivität.



Mit diesen Kategorien stehen uns eine Reihe von Qualitätsmerkmalen zur Verfügung, anhand derer wir Qualitätsanforderungen finden können. Bevor wir jedoch Qualitätsanforderungen definieren, gehen wir mehrere Schritte zurück und definieren Qualitätsziele. Im Post Die Analyse des Problemraums führt zum Zielmodell haben wir den Aufbau unseres Zielmodells beschrieben. Der Zielbaum wird spätestens mit Hilfe dieser Checkliste von Qualitätsmerkmalen mit Qualitätszielen angereichert. Jedoch besteht durchaus die Möglichkeit, Qualitätsziele schon im Verlauf der Bildung von User Stories oder bei der Definition von Use Cases zu finden und zu dokumentieren.

Folgendes kleines Beispiel soll einen möglichen Weg aufzeigen, wie wir vorgehen können. Wir sehen uns die Checkliste der Qualitätsmerkmale an und bedenken für jedes Merkmal, ob es umzusetzende Qualitätsziele gibt. Für das Qualitätsmerkmal Funktionalität gibt es beispielsweise das Untermerkmal Sicherheit. Dafür kann das Ziel aufgestellt werden, das bestimmte Benutzerrollen nur bestimmte Funktionalitäten der Anwendung ausführen dürfen. Im weiteren Vorgehen können wir nun Szenarien für dieses Ziel entwickeln, um uns den Qualitätsanforderungen zu nähern.

Im letzten Post haben wir die einzelnen Szenariotypen aufgeschlüsselt. Wir durchdenken positive Szenarien, negative Szenarien, Missbrauchsszenarien in Bezug auf das beschriebene Qualitätsziel. Diese Szenarien stehen auch zu User Stories in Beziehung. Die entstehenden Szenarien können wir allerdings nicht zu Use Cases zusammenfassen, wie wir es mit Haup-, Alternativ- und Ausnahmeszenarien getan haben. Sie beschreiben eben keine funktionalen Zusammenhänge, für die die Klammer des Use Cases passt. Szenarien, die wir in Bezug auf Qualitätsziele entwickeln, fassen wir mit Hilfe der Qualitätsmerkmale zusammen. Wie für einen Use Case, legen wir auch für ein umzusetzendes Qualitätsmerkmal ein Objekt in unserem Modell an. Im folgenden Bild habe ich versucht diese Zusammenhänge sichtbar zu machen.



Auch [ZÖR12] ordnet seine gefundenen Qualitätsszenarien Qualitätsmerkmalen zu. Er stellt sich dabei die Frage: "Muss ein Qualitätsszenario genau einem Qualitätsmerkmal zugeordnet werden können?" [S.51, ZÖR12] Woraufhin er die folgende Antwort gibt: "Im Regelfall ist das so. Wenn Sie zwei oder mehr Qualitätsmerkmale mit einem Szenario adressieren, versuchen Sie, es geeignet zu zerlegen, um für die abgeleiteten Szenarien klare Zuordnungen zu finden." [S.51, ZÖR12] Nur in absoluten Ausnahmefällen ist er der Meinung mehrfache Zuordnungen zu Qualitätsmerkmalen zuzulassen.

Die Menge der angelegten Qualitätsmerkmale ergibt unseren systemrelevanten Qualitätsbaum. Einen Qualitätsbaum kann man sehr gut mit Hilfe eines Mind-Mapping-Tools darstellen. Die einzelnen Szenarien können so Blätter dieses Baumes werden. Dieser Qualitätsbaum spielt beim Entwurf der Softwarearchitektur und bei der Bewertung der Architektur eine große Rolle. Dazu kommen wir jedoch später.



Das Formulieren der Qualitätsanforderungen geschieht im Team unter Teilnahme der relevanten Stakeholder. Der Auftraggeber hat eine wesentliche Rolle zu spielen, beim Entscheiden über die Qualitätsanforderungen der von ihm geforderten Software. Der Auftragnehmer hat eine wichtige Rolle bei der Beratung in Bezug auf diese Anforderungen. Qualitätsanforderungen sind nicht so offensichtlich zu erkennen, wie funktionale Anforderungen. Aus Sicht des Auftraggebers sollte eine Anwendung sicher sein. Tiefer gehende Erkenntnisse zu diesem Anspruch sollten Teil der Diskussion und Aufklärung über die Bedeutung und den Aufwand von Qualitätsanforderungen zwischen Auftraggeber und Auftragnehmer sein.

In Bezug auf die Qualitätsszenarien und die Qualitätsmerkmale werden die Qualitätsanforderungen als natürliche Sätze definiert. Das oben erwähnte Beispiel der Benutzerrollen, die immer nur ganz bestimmte Funktionalitäten ausführen dürfen, führt dazu, dass wir Rollen definieren und Funktionalitäten, die diese Rollen ausführen dürfen. Weiterhin wird definiert, was geschieht, wenn Benutzer auf Funktionalitäten zugreifen wollen, die sie nicht ausführen dürfen.

Die gefundenen Qualitätsanforderungen sind wesentliche Grundlage für den Entwurf einer guten Softwarearchitektur. An dieser Stelle zeigt sich, ob wir einen gelungenen Übergang vom Requirements Engineering zur Architektur gestalten können. Beide Aufgaben sind, meiner Meinung nach, in einem Team zu erledigen. Das Trennen führt zu Kommunikationsverlusten, die einer systematischen Softwareentwicklung im Wege steht. Wie wichtig die Überlegungen zu Qualitätsanforderungen sind beschreibt auch [STARKE11]. "Qualitätsmerkmale müssen Entwurfsziele sein. Treffen Sie Entscheidungen zur Erreichung solcher Ziele bewusst und frühzeitig. Qualität entsteht nicht von selbst, sondern muss konstruiert werden!" [S.57, STARK11]

Im Sinne des Posts Ein Objekt-Aufgaben-Modell für das Requirements Engineering haben wir zum jetzigen Zeitpunkt eine ganze Reihe von Objekten gefunden. Nicht jedes Objekt sollte dabei mit einer Aufgabe in Beziehung stehen. Im Sinne der Planung eines Sprints werden eine Reihe von User Stories beauftragt und müssen somit auch eine Aufgaben erhalten. Diese Aufgabe kann als erfüllt angesehen werden, wenn wir das gesamte Anforderungsgerüst, bestehend aus Zielen, Randbedingungen, Use Cases mit Szenarien und lösungsorientierten Anforderungen sowie Qualitätsmerkmale mit Szenarien und Qualitätsanforderungen in Bezug auf die beauftragte User Story fertiggestellt haben.

  • [IREB11] Klaus Pohl, Chris Rupp: "Basiswissen Requirements Engineering", 3.korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2011
  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [STARKE11] Gernot Starke: "Effektive Software-Architekturen", 5. überarbeitete Auflage, Carl Hanser Verlag, München, 2011
  • [ZÖR12] Stefan Zörner: "Softwarearchitekturen dokumentieren und kommunizieren", Carl Hanser Verlag München, 2012


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Ich finde Ihre Darstellung mit den Zielen sehr interessant. Wenn man es schafft, diese Ziele im ganzen Projektteam und auch über Firmenengrenzen hinweg glasklar zu kommunizieren, dann hat man aus meiner Sicht einen extrem wichtigen Grundstein für solide Softwareentwicklung gelegt.

    AntwortenLöschen
  2. Schöner Post, das erinnert mich ein wenig an das Story Mapping was Fabian Schiller mal skizziert hatte und ich dann weitergeführt habe: http://www.agile-is-limit.de/tag/story-mapping/

    AntwortenLöschen