Zittern Ihre Knie, wenn es darum geht, nicht funktionale Anforderungen zu dokumentieren? Dann lesen Sie unbedingt weiter. Die nachfolgenden Zeilen haben eine beruhigende Wirkung.
Oft wird in der Praxis während der Phase der Anforderungsermittlung den nicht funktionalen Anforderungen zu wenig Beachtung geschenkt. Diese scheinen weniger offensichtlich und schwieriger zu dokumentieren als die funktionalen Anforderungen.
In den kommenden Zeilen finden sie daher eine praxiserprobte Möglichkeit, wie nicht funktionale Anforderungen für ein IT-System mit Planing Language (Planguage) als eine allgemein verständliche Sprache dokumentiert werden. Richtig angewendet, unterstützt die Methode die Kommunikation auf mehreren Stufen im Vorhaben. Dabei werden standardisiert die Stufen «in Spezifikation», «Design» & «Projekt» unterschieden.
In meinem Blog-Beitrag fokussiere ich mich auf die Stufe Spezifikation, genau genommen auf die Spezifikation von leistungsbezogenen Anforderungen (Englisch: Performance Requirements).
So sehen Sie Beispielhaft und Praxisnahe wie auch Sie mit ein wenig Übung die ersten Performance Requirements mit Planguage dokumentieren können.
Anforderungs-Typen
Anforderungen sind Informationslieferanten von Anspruchsgruppen für Anspruchsgruppen und werden in funktionale- und nicht funktionale Anforderungen unterteilt. Die Gesamtheit der Anforderungen (für ein IT-System) widerspiegelt das Resultat, dass mit dem IT-System erreicht werden soll.
Planguage unterstützt dahingehend, dass sie eine formalisierten Standard zur Verfügung stellt und unterscheidet entsprechend folgenden Anforderungs-Typen:
- Vision
- Funktionsbezogene Anforderungen
- Leistungsbezogene Anforderungen* (wie gut ein System sein soll)
- Qualität (wie gut ein System funktioniert)
- Ressourcenschonend (wie viele Ressourcen eingespart werden sollen)
- Arbeitskapazität (wie viel Auslastung ein System im Betrieb erwartet)
- Anforderungen an die Ressourcen
- Design Restriktionen
- Systemvoraussetzungen
*Bezogen auf die Wettbewerbsfähigkeit eines IT-Systems, sind die leistungsbezogenen Anforderungen DIE Anforderungen, denen am meisten Aufmerksamkeit gewidmet werden soll. Denn diese bilden u.a. die Grundlage für die funktionalen Anforderungen und beeinflussen die Performanz eines IT-Systems.
Sind die Performance Requirements bekannt, so sind diese u.a. in Bezug auf den Systemerfolg/-misserfolg verständlich zu dokumentieren. «Verständlich» bedeutet, dass jedes Performance Requirement mit Werten angereichert wird, die aus einem undeutlich formulierten Requirement ein unmissverständlich interpretierbares Requirement kreieren. Erreicht wird dies u.a. mit der Quantifizierung von Werten.
Ein Beispiel für quantifizierte Werte
Quantifiziert: Zwischen 6 Uhr und 22 Uhr muss das IT-System den Zugriff von bis zu 20 Benutzern gleichzeitig erlauben.
Nicht quantifiziert: Viele Benutzer müssen gleichzeitig auf das IT-System zugreifen können.
Erwartungen erkennen
Wenn in der Organisation Standards fehlen kann es schwierig sein für ein IT-System die passende Quantität zu definieren. Hierbei können Benchmarks unterstützen. Ein Vergleichsmassstab kann ein IT-System in Betrieb sein, dass dem Zielsystem ähnlich ist. Dennoch leitet sich die Basis zur Festlegung der Quantität stark von den Erwartungen der Stakeholder an das IT-System ab.
Mögliche Fragen zur Ermittlung von Erwartungen der Stakeholder
- Wie ambitioniert soll das IT-System arbeiten?
- Sollen die neusten Technologien eingesetzt werden?
- Mit welchen Risiken muss gerechnet werden?
- Mit welchen zu erwartenden Kosten ist zu rechnen?
Flughöhe bestimmen
Es stellt sich die Frage, wie detailliert ein Performance Requirement beschrieben werden soll. Dieser Detaillierungsgrad hängt u.a. von der Grösse und der Kritikalität des zu kontrollierenden Risikos ab. In der Praxis ist vor allem dieser Aspekt für den Requirements Engineer oft eine Gratwanderung. Doch müssen die Anforderungen die zu bildende Realität mit heutigem Wissensstand wiedergeben und auf Veränderungen angepasst werden können. Dabei unterstützen kann der aus agilen Methoden bekannte INVEST-Ansatz: der Aufwand pro Requirement ist geschätzt (E), das Requirement passt in den Sprint (S) und ist testbar (T).
Basis Parameter
- Tag: Eindeutiges Element, das das Requirement identifizierbar macht
- Type: Art des Requirements
- Version: Eindeutige Instanz des Requirements
- Status: Genehmigungsstufe des Requirements
- Owner: Name der für das Requirement verantwortlichen Person
- Stakeholder: Kontaktstelle für die Dokumentation des Requirements
- Gist: Kurze Beschreibung mit der Kernaussage des Requirements
- Description: Beschreibung des Requirements in der notwendigen Tiefe
- Ambition: Erwartete Leistung in Worten beschrieben
Parameter und Icons
Parameter können entweder mit einem Begriff beschrieben oder als Icon dargestellt werden:
- Source (<-...): Verweist auf die Quelle des Elements
- Source (<- ?): Verweist auf eine nicht bekannte Quelle des Elements
- Comment ("..."): Zusatzinformationen für den Leser des Requirements
- Fuzzy (<...>): Steht für unklare Elemente im Requirement, die später geklärt werden sollen
- Set Parantheses ({...}): Einzelne Elemente, die eine Gruppe bilden
- Qualifier ([...]): Erläutert nähere Informationen bezüglich Zeit, Ort und Bedingung
Skalare Parameter
- Scale of Measure: Definition des Massstabs oder der Masseinheiten
- Scale: Skala
- Messtechnik
- Meter: Metrik, die für die Messung angewendet wird
- Benchmarks: Leistung mit anderen IT-Systemen vergleichen
- Past: Erbrachte Leistung in der Vergangenheit zu einem bestimmten Zeitpunkt
- Record: Höchste erbrachte Leistung in der Vergangenheit
- Trend: Hochrechnung von erbrachter Leistung in der Vergangenheit
- Targets: Zukünftig zu erreichende Ziele
- Goal: Leistung, die Erfolg bringt
- Budget: Ziele zur Einhaltung von Ressourcen
- Stretch: Mehrerfolg und Budgeteinsparung durch Mitarbeitermotivation
- Wish: Nicht budgetierte, unrealistische Wunschziele von Stakeholdern
- Constraints: Zukünftige Restriktionen für Systemfehler und Systemüberleben
- Fail: Systemzustand, der Ausfälle vermeidet
- Survival: Minimaler Systemzustand (eine Art Minimum Viable Product), der den Totalausfall des IT-Systems verhindert
Beispiel
Untenstehend ein Beispiel eines Qualitäts Requirement, dass alle in diesem Blog-Beitrag beschriebenen Parameter und Icons beinhaltet:
Tag: Systemerreichbarkeit
Type: Leistungsbezogene Anforderung: Qualitäts Anforderung
Version: 19.09.19/11:55h
Status: Entwurf
Owner: Stefan Gisin, Consultant SwissQ
Stakeholder: Max Muster, Auftraggeber
Gist: Das IT-System hat eine sehr hohe Erreichbarkeit
Description: Die System-Benutzer mit den Benutzer-Rollen {USER_EDITOR und USER_VIEWER} haben während mindestens 363 Tagen pro Jahr uneingeschränkten Zugriff auf das IT-System. Da das IT-System <responsive> gestaltet ist, muss das IT-System während diesem Zeitraum für {Smartphones, Tablets, Laptops und Personal Computer} erreichbar sein.
Ambition: Das IT-System ist nicht mehr als 48 Stunden pro Jahr für die System-Benutzer unerreichbar. "Diese Anforderung ist ein Standard-SLA in unserer Organisation."
Scale: Zeit in Stunden pro Jahr für [System-Benutzer mit den Benutzer-Rollen: USER_EDITOR und USER_VIEWER] während der Verwendung von [Ausgabegeräten: Smartphones, Tablets, Laptops und Personal Computer].
Meter: <IT-Systemreport> für das IT-System durch den <Service-Verantwortlichen> pro {Q1, Q2, Q3 und Q4}.
Benchmark
- Past: [Webapplikation X, vor vier Jahren]: 58 Stunden <- IT-Systemreport Q4
- Record: [Webapplikation X, vor zwei Jahren]: 52 Stunden <- IT-Systemreport Q4
- Trend: [Webapplikation X, 2010 bis 2018]: 54 Stunden <- Durchschnitt der jährlichen IT-Systemreports per Q4
Targets
- Goal: [IT-Systemreport, Q4/2019]: 48 Stunden <- Stakeholder Grobanforderung
- Budget: [Deployment, Q1-Q4/2019]: 40 Stunden <- Analyse des Service-Verantwortlichen
- Stretch: [Deployment, Q1-Q4/2019]: 35 Stunden <- ?
- Wish: [IT-Systemreport, Q4/2019]: 24 Stunden <- Stakeholder Grobanforderung
Constraints
- Fail: [Deployment, Q4/2019]: 72 Stunden <- Stakeholder Grobanforderung
- Survival: [Deployment, Q4/2019]: 96 Stunden <- Analyse des Service-Verantwortlichen
Fazit
Die Dokumentation von Performance Requirements mit Planguage ermöglicht eine solide Kommunikation zwischen den Anspruchsgruppen und erhöht den Mehrwert für den Kunden. Dies auch dank des standardisierten Vorgehens, welches dazu führt das Missverständnisse vermieden und die Transparenz erhöht wird.
Damit im Alltag Planguage korrekt und effizient angewendet wird, sind Geduld, Übung und Disziplin gefragt. Die Methode bietet eine Vielzahl von Parametern und Icons zum Dokumentieren. Je nach Typ der Anforderung können die Parameter und Icons variieren. Da Planguage nicht selbsterklärend ist, sollten sich die Stakeholder, die mit Planguage dokumentierten Anforderungen in Kontakt kommen, vorab in die Terminologie eingearbeitet werden.
Meinem Blog-Beitrag habe ich das Buch von Tom Gilb (Competitive Engineering, 1. Auflage, 2005) zu Grunde gelegt und mit meiner Erfahrung aus der Praxis ergänzt. Der Blog-Beitrag vermittelt einen groben Überblick über Planguage. Für einen umfassenderen Einblick empfehle ich die vorerwähnte Lektüre zu lesen und/oder die Dokumentation des Konzepts unter https://concepts.gilb.com/Glossary zu konsultieren.
