Lexikon

Planguage – Spezifikation nicht-funktionaler Anforderungen

Nicht-funktionale Softwareeigenschaften sind mindestens so wichtig wie die funktionalen, mitunter sind sie sogar wettbewerbsentscheidend. Ihre Spezifikation macht jedoch besondere Schwierigkeiten, so dass sie oft nicht ausreichend und geeignet berücksichtigt werden. Dieser Beitrag beschreibt die Ursache und stellt mit Planguage von Tom Gilb [1] eine Methode vor, die helfen soll, das Problem zu lösen.

Nicht-funktionale Anforderungen - Was macht sie so besonders?

Typischerweise werden Anforderungen unterteilt in funktionale Anforderungen und Anforderungen, die keine Funktion repräsentieren und deshalb nicht-funktional genannt werden. Sie stellen einen besonderen Anforderungstyp dar:

  • Nicht-funktionale Anforderungen werden häufig erst erfahrbar und test- und messbar, wenn das Gesamtsystem steht.
  • Nicht-funktionale Anforderungen beeinflussen sich gegenseitig und hängen voneinander ab. Beispielsweise macht ein höheres Maß an Softwaresicherheit zusätzliche Sicherheitsvorkehrungen erforderlich, die wiederum die Antwortzeiten verlängern können.
  • Nicht-funktionale Anforderungen sind typischerweise schwieriger zu implementieren und zu gewährleisten.

Das größte Problem jedoch ist, dass nicht-funktionale Anforderungen während der Spezifikation stärker vernachlässigt werden. Aus Zeitmangel oder weil sie zu einem frühen Zeitpunkt schwieriger zu spezifizieren sind, werden sie übersehen oder sogar bewusst nur vage formuliert. Fehler, die in einer frühen Phase der Systementwicklung gemacht und erst in späteren Phasen behoben werden (wenn es dafür eigentlich schon zu spät ist), sorgen aber für einen Summationseffekt, bei dem sich die Fehler fortpflanzen und potenzieren [2, S. 1] [3, S. 14]. Das bedeutet, dass die Integration nicht-funktionaler Anforderungen zu einem späteren Projektzeitpunkt deutlich zeitintensiver und teurer ist [4, S. 68]. Der unzureichende Umgang mit nicht-funktionalen Anforderungen stellt deshalb aus Projektsicht eines der größten Risiken dar. Die Frage liegt nahe, ob es nicht geeignete Methoden und Vorgehensweisen gibt, damit umzugehen und die Risiken zu vermeiden. Ein Blick in die Literatur zeigt, dass es keine einheitliche, allgemein akzeptierte Definition für nicht-funktionale Anforderungen gibt, wie es für Funktionen der Fall ist. Je nach Autor wird der Begriff unterschiedlich besetzt, so definiert der Begriff

  • Eigenschaften und Einschränkungen (Antón [5], Jacobson, Booch and 
    Rumbaugh [6])
  • nur Einschränkungen (Kotonya and Sommerville [7])
  •  nur Verhaltenseigenschaften (Ncube [8])
  • Eigenschaften oder Qualitäten (Robertson and Robertson [9]).

Eine gute Zusammenfassung unterschiedlichster Definitionen findet sich bei M. Glinz [10]. Sie zeigt unter anderem, dass in den Standards IEEE 610.12 (Glossary of software engineering terminology) und IEEE 830-1998 (Recommended Practice for Software Requirements Specifications) der Begriff gar nicht definiert ist.

Auch eine allgemein akzeptierte Sammlung von Attributen oder Kategorien, die nicht-funktionale Anforderungen repräsentieren, gibt es nicht. Je nach Autor werden damit die unterschiedlichsten Aspekte adressiert: Antwortverhalten, Zuverlässigkeit, Benutzbarkeit, Testbarkeit, Wartbarkeit, Kompatibilität, Vorgaben bzgl. Einsatz von Entwicklungs-werkzeugen und Bibliotheken, Qualität, rechtlich-vertragliche Belange oder wirtschaftliche und gesetzliche Einschränkungen. Der Bezugspunkt spielt dabei ebenfalls eine Rolle. Einige nicht-funktionale Anforderungen wirken lokal auf einen Anwendungsfall, andere eher systemglobal als Art Rahmenbedingung, wie z. B. das Look & Feel (vgl. [9, S. 174]). Wie breit das Spektrum ist, zeigt ein Blick auf die Norm DIN EN ISO 66272, dessen Begriff der Dienstqualität von einigen Autoren unter anderem stellvertretend für nicht-funktionale Eigenschaften referenziert wird (Abb. 1).

Planguage, der Ansatz von Tom Gilb

Mit seiner Methode des „Competitive Engineering“ will Tom Gilb dazu beitragen, die kritischen Erfolgsfaktoren zu beherrschen und sicherzustellen, dass Systeme erstellt werden, die im Wettbewerb bestehen. Im Mittelpunkt steht dabei Planguage (ausgesprochen wie englisch „language“ mit der Anfangssilbe „plan“ statt „lan“). Planguage steht für Planning Language und bezeichnet zugleich eine formelle Spezifizierungssprache und eine Sammlung von Methoden und Prozessen für das System Engineering. Planguage zählt zu den Spezifikationstechniken, die versuchen die natürlichsprachliche Spezifikation durch zusätzliche Aspekte zu verfeinern. Für die Spezifikation stehen ein umfangreiches Glossar (von A wie „And“ (als logischer Operator), bis W wie „Wish“ (gewünschter Zielparameter)), ein Set von Parametern (zum Beispiel steht „< -- >“ für „fuzzy“ und markiert einen noch nicht ausreichend klar spezifizierten Begriff oder Abschnitt der Spezifikation) und einige Icons zur Vereinfachung bereit.

Diese Mittel helfen bei der Strukturierung, mit dem Ziel eigenständige, klar abgegrenzte Einzelanforderungen hervorzubringen, um diese individuell betrachten und managen zu können. Mit Hilfe dieser Technik werden innerhalb von Planguage sowohl Anforderungen, als auch Designkonzepte, als auch Projektpläne erstellt. Bevor wir auf die nicht-funktionalen Anforderungen eingehen können, muss zunächst dargestellt werden, wie bei Gilb [1, S. 48] die Einflussfaktoren und Eigenschaften („System-Attribute“) eines Systems in Zusammenhang stehen.

Jedes System stellt dabei unter einschränkenden Rahmenbedingungen (Conditions), mit bestimmten gegebenen Mitteln (Resources), auf Basis spezifischer Designkonzepte (Design/Architecture), Funktionen mit einer individuellen Leistungsqualität (Performance) bereit. Anders ausgedrückt wird ein System nach den folgenden Gesichtspunkten unterteilt: WOMIT (Ressource), WAS (Function), WIE (Design), WIE GUT (Performance), und WAS IST ZU BEACHTEN (Condition). Gilb teilt sämtliche System-Attribute in diese fünf Gruppen und gibt für jede einen Prozess und ein Vorgehen zu ihrer Spezifikation an.

Die Grundidee: Nicht-Funktionale Anforderungen sind Performance Requirements

Gilb selbst benutzt den Begriff „nicht-funktionale Anforderung“ nicht, er spricht von Performance. Diese steht bei Planguage für Systemleistungen, die definieren wie gut ein System ist, wie es die Außenwelt beeinflusst und wie es von den Stakeholdern wahrgenommen wird. Performance ist der Output im Sinne von Leistung, im Gegensatz zu Ressourcen, die den Input darstellen. Performance ist die Art und Weise WIE GUT das System Funktionen ausführt, dem Nutzer zur Verfügung stellt und WIE GUT das System vom Nutzer unmittelbar wahrgenommen wird.

Es werden drei Arten von Performance unterschieden:

  1. Quality: Definiert WIE GUT das System arbeiten soll. Der Begriff ist hier im weitesten Sinne zu verstehen. Er beinhaltet alles, was nicht zu den anderen Arten gehört.
  2. Resource Savings: Definiert WIE VIEL eingespart werden soll, im Vergleich zu einem anderen System oder einem anderen Vergleichswert. Dies kann zum Beispiel die Reduzierung der Kosten für bestimmte Transaktionen oder die Verkürzung der Durchlaufzeit einer bestimmten Aufgabe sein.
  3. Workload Capacity: Definiert WIE VIEL Leistung das System erbringt. Mit diesen Anforderungen sind unter anderem Kapazität und Durchsatz gemeint. Dazu zählt zum Beispiel die Durchschnittsgeschwindigkeit für das Ausführen einer bestimmten Funktion, die Speicherkapazität oder die vom System unterstützte Höchstzahl parallel arbeitender Anwender.

Performance-Attribute zählen zu den skalaren Attributen, ihre konkrete Ausprägung kann einen von mehreren möglichen Werten annehmen und wird durch Messung bestimmt. Im Gegensatz dazu stehen die binären Attribute, die nur einen von zwei Werten annehmen können, nämlich in Bezug auf die Anforderungen „erfüllt“ oder „nicht erfüllt“. Funktionale Anforderungen sind binär.

Spezifikation von skalaren Attributen

Bei der Spezifikation von skalaren Attributen sind die folgenden beiden Aspekte am wichtigsten:

  1. Die Sicherstellung der Mess- und Testbarkeit
  2. Die Festlegung von Erfolg und Misserfolg

Die Mess- und Testbarkeit wird dadurch sichergestellt, dass die Messmethode und der Maßstab zum Spezifikationszeitpunkt bereits festgelegt werden. Es werden Zielwerte und mögliche Einschränkungen definiert, anhand deren Erreichung Erfolg und Misserfolg der Umsetzung gemessen werden kann. Dabei ist es zulässig nicht genau einen Wert festzulegen, sondern im Sinne der Skalarität einen zulässigen Wertebereich. Damit klar ist, wie skalare Attribute spezifiziert werden, liefert Planguage ein Regelwerk (Rules.SR) und ein dazugehöriges Spezifikationstemplate, das im Kern die Spezifikation folgender Elemente vorsieht:

  • Tag: Eindeutiger Name der Anforderung
  • Definition: Genaue Beschreibung der Anforderung.
  • Scale: Maßeinheit, in der die Anforderung gemessen wird (bei Antwortzeiten zum Beispiel Sekunden). 
  • Meter: Messmethode (zum Beispiel Lasttest oder Nutzerbefragung).
  • Benchmark: Vergleichswerte zur Orientierung (zum Beispiel aus Vorgänger- oder Konkurrenzsystemen)
  • Target: Vorgabe der Anforderung, das angestrebte Ziel
  • Constraint: Zulässige Grenze der Anforderung nach unten oder oben

Eine beliebte nicht-funktionale Anforderung ist die der Wartbarkeit. Hier ein vereinfachtes Beispiel, wie mit Planguage die Spezifikation dafür aussehen könnte:

  • Tag: Wartbarkeit
  • Definition: Die Leichtigkeit, mit der ein System verändert oder erweitert werden kann.
  • Scale: Stunden
  • Meter: Durchschnittliche Dauer für die Behebung eines Fehlers. Gemessen wird vom Beginn der Behebung bis zu dessen Lösung.
  • Target: 2 Stunden
  • Constraint: 4 Stunden

Das obige Beispiel lässt sich sicherlich noch weiter ausbauen und dadurch verbessern. Es soll jedoch vereinfacht zeigen, dass bei einer nicht-funktionale Anforderung erstens klar sein muss, was alle Beteiligten darunter verstehen und zweitens wie sie operationalisiert wird.

Der Nutzen für die Praxis

Alles in allem ist Planguage ein höchst formalisiertes Vorgehensmodell. Das Glossar in der Fassung von [1] ist sehr umfangreich (ca. 115 Seiten und weit über 180 Konzepte). Der Einarbeitungsaufwand ist damit eher hoch und setzt gute analytische Fähigkeiten voraus. Der Aufwand dürfte für einige Leser zu hoch sein [11]. Die gesamte Spezifikation nach Planguage zu notieren, wird zudem ohne entsprechende Tools schnell unübersichtlich.

Allerdings kann für die Praxis aus Planguage der Nutzen gezogen werden, über Performance und skalare Attribute zu lernen. Eine genau festgelegte Definition und Kategorisierung nicht-funktionaler Anforderungen steht nicht im Vordergrund. Wichtiger und damit entscheidend für den Erfolg ist die quantitative Spezifizierung.

In unserem Haus, einem der größeren IT-Beratungs- und Systemintegrationsunternehmen in Deutschland, sind wir pragmatisch vorgegangen. Unser Vorgehensmodell, das laufend überarbeitet wird, um den Softwareentwicklungsprozess gezielt zu verbessern, basiert auf dem Rational Unified Process [12, S. 27] [13]. Der Bereich der nicht-funktionalen Anforderungen wurde mit Hilfe von Planguage komplett überarbeitet. Die Definition der Performance Requirements und die Kategorien Quality, Resource Savings und Workload Capacity wurden übernommen und das Template zur Spezifikation nicht-funktionaler Anforderungen entsprechend aktualisiert.

Weiterhin ist die Sicherstellung der Test- und Messbarkeit und die Festlegung von Erfolg- und Misserfolg nun fester Bestandteil der Spezifikation und der Kontrolle nicht-funktionaler Anforderungen.

Literatur

1. Gilb, T.: Competitive Engineering. 1. Aufl., ISBN 0-7506-6507-6, Elsevier Butterworth Heinemann, Amsterdam Niederlande, 2005

2. Alexander, I. F., Stevens, R.: Writing Better Requirements. 1. Aufl., ISBN 0-321-13163-0, Addison-Wesley, Boston USA, 2002

3. Chris Rupp & die SOPHISTen: Requirements-Engineering und Management. 4., aktualisierte und erw. Aufl., ISBN 3-446-40509-7, Hanser, München Deutschland, 2007

4. Ebert, C.: Systematisches Requirements Management. 1. Aufl., ISBN 3-89864-336-0, dpunkt-Verl., Heidelberg Deutschland, 2005

5. Antón, A.: Goal Identification and Refinement in the Specification of Information Systems. PhD Thesis, Georgia Institute of Technology, 1997

6. Jacobson, I., Booch, G. and Rumbaugh, J.: The Unified Software Development Process, Addison Wesley, Reading, Mass., 1999

7. Kotonya, G., Sommerville, I.: Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998

8. Ncube, C.: A Requirements Engineering Method for COTS-Based Systems Development. PhD Thesis, City University London, 2000

9. Robertson, S., Robertson, J.: Mastering the Requirements Process. ACM Press books, 2. Aufl., ISBN 978-0-321-41949-1, Addison-Wesley, Boston USA, 2006

10. Glinz, M.: On Non-Functional Requirements. 15th IEEE International Requirements Engineering Conference (RE'07), Delhi, India, 15. bis 19.12.07, www.ifi.uzh.ch/rerg/fileadmin/ downloads/publications/ papers/RE07_Glinz.pdf, 16.10.2008

11. Alexander, I.: Book Review: Competitive Engineering. 2005, i.f.alexander.users.btopenworld.com reviews/gilb.htm, 05.11.2008

12. Singvogel, R.: Wirtschaftlich und wirksam: Entwicklungsprozesse auf Basis des Eclipse Process Frameworks, Proceedings Software Engineering 2009, Peter Liggesmeyer; Gregor Engels; Jürgen Münch; Jörg Dörr; Norman Riegel (Hrsg.). Proceedings of Software Engineering 2009. Software Engineering 2009 (SE-09), March 2-6, Kaiserslautern, Germany, GI, 2009.

13. Kruchten, P.: The rational unified process. 2. Aufl., ISBN 0-201-70710-1, Addison-Wesley, Reading USA, 2001

Autor und Copyright

Torsten Emmanuel
msg systems ag,  Robert-Bürkle-Str. 1, 85737 Ismaning 
E-Mail

© 2010 Informatik Spektrum, Springer-Verlag Berlin Heidelberg