The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements ... No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later.
F.P. Brooks (1987)
Die Anforderungen des Kunden an die Software sind die wichtigste Information in einem Software-Projekt. Kein großartiger Entwurf, kein eleganter Code, keine komfortable Bedienoberfläche kann das Projekt retten, wenn die Anforderungen des Kunden nicht erfasst und verstanden wurden. Um diese Anforderungen, ihre Erhebung, Dokumentation und Prüfung, geht es in diesem Kapitel.
Der Kunde, der eine Software kauft oder in Auftrag gibt, erwartet, dass sie ihm über einen gewissen Zeitraum hinweg als williger und billiger Diener zur Verfügung steht, ihm also bestimmte Leistungen erbringt, ohne von ihm umgekehrt erhebliche Leistungen (in Form von Kosten, Aufwand, Mühe, Ärger) zu fordern. Die Software soll ihm dienen, nicht umgekehrt.
Die Software-Entwickler, die diesen Diener realisieren sollen, müssen genau wissen, welche Erwartungen der Kunde hat. Dies betrifft die Funktionalität des Systems, aber auch zahlreiche nichtfunktionale Merkmale, beispielsweise die Effizienz, die Robustheit, die Portabilität. Werden die Erwartungen, die Anforderungen des Kunden, nicht vollständig und präzise erfasst, ist damit zu rechnen, dass das entwickelte Produkt die Anforderungen nicht (vollständig) erfüllt. Darum ist die vollständige und präzise Erfassung der Anforderungen die allerwichtigste technische Voraussetzung für eine erfolgreiche Software-Entwicklung. (In Abschnitt 8.1 war festgestellt worden, dass die Planung die wichtigste nichttechnische Voraussetzung ist.)
Die Spezifikation definiert die Aufgabe der Entwickler. Jede weitere konstruktive Arbeit, jede Prüfung und nicht zuletzt die Klärung aller Streitigkeiten darüber, ob das Resultat den Abmachungen entspricht, stützt sich auf die Spezifikation. Die Spezifikation ist also das zentrale Dokument der Software-Entwicklung.
Traditionell werden in einem ersten Schritt die Anforderungen gesammelt. Diesen Schritt bezeichnet man als Analyse. Anschließend wird das Material in eine Form gebracht, die als Grundlage für die weitere Arbeit dienen kann; dieser Schritt wird – wie sein Resultat – als Spezifikation bezeichnet. Das Wort ist also doppeldeutig, wir gehen auf diesen Begriff detailliert in Abschnitt 16.5.1 ein. Wo ein Missverständnis möglich scheint, sprechen wir darum von der Anfertigung der Spezifikation bzw. vom Spezifikationsdokument. Die Schritte Analyse und Spezifikation werden aber nicht immer klar getrennt. Nachdem die Spezifikation (durch Reviews, evtl. auch durch Prototypen) geprüft ist, kann man mit dem Entwurf beginnen.
Abb. 16–1 Der Weg der Anforderungen vom Klienten zum Entwickler
Abbildung 16–1 zeigt den vollständigen Ablauf: Die Anforderungen werden erhoben, in der Spezifikation formuliert, geprüft und anschließend in den Entwurf umgesetzt. Schließlich wird implementiert, auf verschiedenen Ebenen geprüft und korrigiert. Das Resultat geht zurück an den Klienten. Offensichtlich bekommt der Klient nur dann, was er will, wenn seine Anforderungen sorgfältig erhoben und unterwegs nicht verfälscht wurden. Der Entwickler ist weit von ihm entfernt, er denkt und spricht ganz anders als der Klient; er erfährt also die Wünsche des Klienten aus der Spezifikation, oder er erfährt sie nicht – und erfüllt sie auch nicht.
Die Abbildung zeigt nur zwei Rollen, die in der Realität meist noch weiter aufgeteilt sind; an der Analyse sind unterschiedliche Klienten, also Fachexperten, Benutzer, aber auch Leute, die das System später warten sollen, beteiligt, von Seiten des Software-Herstellers spezialisierte Analytiker oder Entwickler, die auch die Analyse durchführen (siehe Abschnitt 6.2.1). In einer guten Analyse werden auch die Interessen solcher Klienten erfasst, die nicht im engeren Sinne zum Kunden gehören (siehe Abschnitt 6.2.3).
Schaut man sich in der Praxis um, so stellt man überrascht fest, dass noch immer viel Software ohne (brauchbare) Spezifikation entwickelt wird. Man könnte daraus den falschen Schluss ziehen, dass die Spezifikation so wichtig nicht sein könne, scheinbar geht es ja auch ohne sie. Spricht man aber mit den Praktikern, so wird am lautesten beklagt, dass klare Vorgaben fehlen. Die folgende Liste soll den Unwilligen klar machen, was sie mit einer Entwicklung ohne Spezifikation anrichten, und die Verfechter einer systematischen Entwicklung mit Argumenten versorgen. Die Spezifikation ist notwendig für
die Abstimmung mit dem Kunden bzw. mit dem Marketing,
den Entwurf und die Implementierung,
das Benutzungshandbuch,
die Testvorbereitung,
die Abnahme,
die Wiederverwendung,
die Klärung späterer Einwände, Regressansprüche usw.,
eine spätere Re-Implementierung.
Welche Nachteile entstehen, wenn die Spezifikation fehlt?
1. Die Anforderungen bleiben ungeklärt, sie werden darum auch nicht erfüllt. Das fällt meist erst im Betrieb auf, wenn die Entwicklung abgeschlossen ist.
2. Den Entwicklern fehlt die Vorgabe, darum fragen sie »auf dem kurzen Dienstweg« Bekannte, die beim Kunden arbeiten, oder sie legen mangels Kontakten die eigenen Erfahrungen und Erwartungen zu Grunde. Beides führt zu zufälligen, undokumentierten und ungeprüften Anforderungen.
3. Die Basis für das Handbuch fehlt, es wird darum phänomenologisch, d. h. experimentell, verfasst. Ein Fachautor (technical writer) sitzt am Bildschirm, probiert das System aus und dokumentiert das Resultat als Benutzungshandbuch. Er kann also nicht sagen, wie man ein bestimmtes Ziel erreicht, sondern nur berichten, was passiert, wenn man die Menüs und Kommandos verwendet. Das ist die Karikatur eines Handbuchs.
Ein gutes Handbuch ist nichts anderes als ein umformulierter Auszug aus der Spezifikation. Einige Unternehmen verzichten auf die Spezifikation und erstellen stattdessen zu Beginn das Handbuch. Das ist nicht der Lehrbuchansatz, aber weit besser als ein Verzicht auf jegliche Vorgabe.
4. Ein systematischer Test ist ohne Spezifikation unmöglich, denn es ist nicht definiert, welche Daten das System akzeptieren muss und welche Resultate es liefern soll. Trotzdem wird scheinbar getestet. Aber in Wahrheit können die Tester nur ausprobieren, ob das System abstürzt oder Resultate liefert, die sie nicht für plausibel halten; man kann das als einen oberflächlichen Glass-Box-Test (siehe Abschnitt 19.6) bezeichnen.
5. Wenn bei der Abnahme nicht entschieden werden kann, ob das System richtig (d. h. wie in der Spezifikation verlangt) arbeitet, wird die Korrektheit zur Glaubensfrage, und Streit zwischen Hersteller und Klienten ist angesagt. Oft zeigen sich echte oder vermeintliche Fehler der Software auch erst später. Ohne Spezifikation kann diese Unterscheidung aber nicht getroffen werden. Hersteller behaupten dann gern: This is not a bug. It’s a feature!
6. Wer eine Software(-Komponente) wiederverwenden will, muss wissen, was sie leistet. Das ist in der Spezifikation dokumentiert. Durch Code-Lesen und Ausprobieren erhält man nur einen sehr schmalen Einblick, darum ist die Wiederverwendung einer nicht spezifizierten Software schwierig und riskant.
7. Wenn ein System ausgemustert und ersetzt wird, ist Abwärtskompatibilität gefordert: Der Nachfolger muss (auch) leisten, was der Vorgänger geleistet hat, und auch alle Schnittstellen unverändert bedienen. Der Nachfolger muss also die Spezifikation des Vorgängers einhalten. Dazu muss sie vorhanden sein. Ist das nicht der Fall, kann man nur durch ein aufwändiges Reverse-Engineering-Projekt versuchen, die Spezifikation aus dem vorhandenen Code wiederzugewinnen (siehe Abschnitt 23.2.1).
David Parnas hat mit seiner Gruppe ein solches Projekt dokumentiert (Heninger et al., 1978), in dem mit großem Aufwand eine relativ kleine Navigationssoftware des Kampfflugzeugs A-7E nachspezifiziert wurde, weil eine Neuimplementierung unvermeidbar war und keine Spezifikation vorlag.
Wer den Sinn einer Spezifikation anerkennt, aber keine vorweisen kann, behauptet gern, es gebe sie schon – in seinem Kopf. Das ist, wie die vorstehende Diskussion zeigt, Unsinn. Denn die beiden wichtigsten Merkmale der Spezifikation sind ihre Stabilität (und damit ihre Eignung als Kontrakt) und ihre Verteilbarkeit, die es ermöglicht, die Arbeit vieler Menschen zu harmonisieren. Nur ein Genie, das völlig allein Software für sich selbst entwickelt (und sie später auch allein wartet), kommt mit der Spezifikation im Kopf aus.
Introspection showed three main techniques that were applied beyond normal common sense: abstract data typing, strong typing, Jewish motherhood.
D. M. und O. Berry (1980)
Was meint das Ehepaar Berry mit »Jewish motherhood«? Die jüdische Mutter ist eine Stereotype der US-Literatur, bekannt dafür, dass sie ihren Kindern immer und immer und immer wieder die gleichen Fragen stellt, in vielen Varianten, bis sie sicher ist, alles erfahren zu haben, was sie wissen will (siehe »Jewish mother stereotype« in der englischen Wikipedia). Diese nagende Art zu fragen sollten alle Analytiker einüben. (Die Berrys legen Wert auf die Feststellung, dass man keine Frau und kein Jude sein und auch keine eigenen Kinder haben muss, um »Jewish motherhood« zu leben.)
Auf die Frage, was genau mit »Analyse« und »Anforderung« gemeint ist, gibt das IEEE-Glossar leider mehr als eine Antwort.
requirement — (1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
requirements analysis — (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements.
(2) The process of studying and refining system, hardware, or software requirements.
IEEE Std 610.12 (1990)
Wir entscheiden uns jeweils für die Bedeutung (1), interpretieren dabei den »user« als Klienten. Das bedeutet: Jede Anforderung kommt vom Klienten. Im Zuge der Analyse werden die Anforderungen gesammelt. Die verschiedenen Kategorien von Anforderungen werden in Abschnitt 16.4 diskutiert.
Die Analyse ist die Vorarbeit und Voraussetzung der Spezifikation; ihr Ergebnis wird auch als Lastenheft bezeichnet. Obwohl es Definitionen für diesen Begriff gibt (beispielsweise in der Norm DIN 69905, 1997), bleibt er in der Praxis unscharf, weil der Inhalt des Lastenhefts von Firma zu Firma stark variiert. Außerdem ist unklar, inwieweit das Lastenheft zur Dokumentation gehört, d. h., ob es langfristig gepflegt wird oder seine Aufgabe erfüllt ist, wenn das Pflichtenheft, die eigentliche Anforderungsspezifikation, vorliegt; da in der Praxis schon die Pflege des Pflichtenhefts große Mühe macht, raten wir, auf die Pflege des Lastenheftes zu verzichten.
Wir sprechen nachfolgend nicht vom Lastenheft, sondern von der Anforderungssammlung. Sie beschreibt die fachlichen Anforderungen aus Klientensicht. Lücken, Unklarheiten und Widersprüche sind darin normal. Erst die Anforderungsspezifikation sollte vollständig, klar und konsistent sein.
Bei der Analyse wird auch das Begriffslexikon angelegt; dieses wird während der gesamten Software-Entwicklung verwendet und ergänzt (siehe Abschnitt 16.3).
Oft kommt während der Entwicklung oder bei der Abnahme die Frage auf, woher eine Anforderung gekommen ist. Der Analytiker sollte daher konsequent dokumentieren, welcher Klient hinter welcher Anforderung steht. Bei Besprechungen und Prüfungen der Anforderungen sollte auch regelmäßig abgefragt werden, ob diese Zuordnungen richtig sind, denn nicht selten schütteln am Ende der Entwicklung alle verwundert den Kopf und fragen, wer denn dieses oder jenes Merkmal des Systems verlangt habe.
Formal betrachtet dient die Analyse dazu, den Soll-Zustand festzustellen. Es sollte darum eigentlich genügen, die Klienten nach ihren Wünschen für die Zukunft zu fragen. Praktisch führt das in aller Regel nicht zum Ziel. Denn die Klienten werden sich – wie alle Menschen – auf das konzentrieren, was ihnen am bestehenden Zustand nicht gefällt. Wer ein neues Auto sucht, kann ohne Schwierigkeiten sagen, dass der Motor stärker, der Kofferraum größer und die Heizung wirksamer sein soll. Er wird aber in der Regel nicht von selbst darauf kommen, dass der neue Wagen in die Garage passen muss, mit wenig Wartung auskommen sollte und beim Fahrer auch nach mehrstündiger Fahrt keine Rückenschmerzen hervorrufen darf, denn diese Punkte waren ja bislang in Ordnung. Wir sind also bei jeder Umstellung auf die Schwachpunkte des bestehenden Systems fixiert, seine Stärken nehmen wir erst wahr, wenn sie uns fehlen.
Implizit erwarten die Klienten aber, dass alles, was bisher akzeptabel oder gut war, unverändert bleibt oder besser wird. Die Anforderungen an das neue System bestehen also nur zum kleinsten Teil aus Änderungswünschen, die allermeisten Anforderungen gehen in Richtung Kontinuität. Darum hat die Ist-Analyse, also die Feststellung des bestehenden Zustands, große Bedeutung für die erfolgreiche Projektdurchführung. Nur wenn wir wissen, wie bisher gearbeitet wurde, können wir ein sinnvolles Bild der zukünftigen Arbeit entwerfen. Der Analytiker muss also die Fähigkeit haben, sich gut einzufühlen und genau zu beobachten, um vom Kunden zu erfahren, welche Aspekte des Ist-Zustands für ihn wichtig sind und beibehalten werden sollten.
Jeder Analytiker muss sich darauf einstellen, dass die Ist-Analyse eine undankbare Tätigkeit ist. Niemand wird Begeisterung zeigen, wenn man seine Situation erforscht, statt danach zu fragen, was er gern hätte. Und die meisten Menschen reagieren eher belustigt, wenn man Abläufe und Konventionen (und auch die Ausnahmen davon) erfasst, die ihnen völlig belanglos oder selbstverständlich erscheinen. Der folgende (erfundene) Dialog ist für die Ist-Analyse typisch:
Sie öffnen also morgens die Tür am Haupteingang?
Ja, habe ich Ihnen doch gesagt.
Jeden Morgen?
Natürlich.
Auch am Wochenende?
Nein, am Wochenende bleibt der Eingang zu.
Und während der Betriebsferien?
Da bleibt er natürlich auch zu.
Und wenn Sie krank sind oder Urlaub haben?
Dann macht das Herr X.
Und wenn auch Herr X ausfällt?
Dann klopft irgendwann ein Kunde ans Fenster, weil er nicht reinkommt.
Was bedeutet »morgens«?
...
Eine Analogie zeigt den Sinn der Ist-Analyse: Wenn der Zahnarzt eine größere Reparatur am Backenzahn vornimmt, muss er zuvor (!) die räumliche Situation auf hundertstel Millimeter genau erfassen. Andernfalls werden die Kiefergelenke durch eine höhere oder tiefere Kaufläche nach der Reparatur anders belastet und nehmen Schaden.
Der Ist-Zustand hat gegenüber dem Soll-Zustand einen großen Vorteil, er ist real. Wenn man es mit einer sehr heterogenen Schar von Klienten zu tun hat, muss man sich manchmal auf den Ist-Zustand zurückziehen, um einen Konsens zu finden: Wo man sich nicht über eine Veränderung einigen kann, bleibt oft nur der Ausweg, den Ist-Zustand beizubehalten.
Auch die Aufnahme der neuen Anforderungen ist heikel: Viele Analytiker fühlen sich eingeklemmt zwischen den – teilweise unrealistischen – Erwartungen der Klienten und dem verständlichen Wunsch der Entwickler, nicht vor Aufgaben gestellt zu werden, die nur schwer oder gar nicht lösbar sind. Sie übernehmen also eine weitere undankbare Rolle, die des Prellbocks.
Das ist falsch. Wer Anforderungen erhebt, sollte sich so verhalten, wie es kluge Eltern vor Weihnachten tun: Alle Wünsche der Kinder sind zulässig. Das bedeutet aber nicht, dass auch alle erfüllt werden. Der Analytiker schreibt also nach dem Diktat der Klienten Wunschzettel. Dabei sollte er sich jeder Wertung enthalten. Später, wenn alle Wunschzettel gesammelt sind, ist eine Bereinigung unvermeidlich. Sie kann und sollte aber – da kaum ein Klient an den Weihnachtsmann glaubt – im Einvernehmen mit den Klienten erfolgen. Zwei Probleme müssen unbedingt beseitigt werden:
Einige der Wünsche sind technisch nicht realisierbar oder sprengen offensichtlich den Kostenrahmen. Dann müssen die Anforderungen reduziert oder die Mittel aufgestockt werden. Beispiele sind irreale Forderungen an die Verfügbarkeit oder an die Erweiterbarkeit eines Systems.
Verschiedene Klienten haben Anforderungen, die unvereinbar sind. In solchen Fällen tut der Analytiker gut daran, das Problem vor den versammelten Klienten anzusprechen und auf eine Einigung zu drängen (siehe Abschnitt 16.2.8).
Dass der Analytiker nicht die Aufgabe hat, den Klienten seine Vorstellung des Systems aufzudrängen, wurde bereits deutlich gesagt. Er sollte aber umgekehrt auch nicht die Wünsche als Dogmen akzeptieren, sondern die Vor- und Nachteile unterschiedlicher Varianten zeigen. Spielraum gibt es dabei in drei Dimensionen:
Nur ein System, das vollautomatisch und unbetreut arbeitet, muss die gestellte Aufgabe vollständig abdecken. So etwas gibt es in technischen Anwendungen, z. B. in Systemen zur automatischen Sammlung und Übermittlung von Messdaten. Die große Mehrheit der Software-Systeme ist nicht vollständig autonom, sondern kann sehr spezielle Situationen oder Daten einem Menschen überlassen. Da gerade die Behandlung seltener Ausnahmefälle meist wesentlich höheren Aufwand erfordert als die Normalfälle, die über 99 % ausmachen, ist es zweckmäßig, den Abdeckungsgrad nach Kostengesichtspunkten zu begrenzen, besonders dann, wenn 100 % ohnehin nicht erreichbar sind. Ein Beispiel ist die Prüfung, ob ein Bankkunde kreditwürdig ist. In sehr vielen Fällen lässt sich diese Frage sehr zuverlässig nach einem Schema beantworten, also auch mit Software. Für Spezialfälle muss man viel Aufwand treiben – oder die Entscheidung dem Filialleiter überlassen. Ähnliches gilt für seltene Fehlerkonstellationen in Geräten; oft ist es nicht schlimm, in solchen Fällen eine Diode blinken zu lassen, bis der Benutzer das Gerät per Knopfdruck zurücksetzt.
In vielen Fällen wird vorrangig eine zentrale Komponente des Systems benötigt; andere Teile haben geringere Priorität. In solchen Fällen kann das System in Ausbaustufen entwickelt werden (siehe Abschnitt 9.5.4). Damit steht nicht nur die zentrale Funktion schneller zur Verfügung, sondern die weitere Entwicklung kann auch die Erfahrungen nutzen, die mit dem Kernsystem gesammelt wurden. Entscheidungen über den weiteren Ausbau können dann auch vom Geschäftsverlauf und vom Markt abhängig gemacht werden.
Die Verwendung vorhandener oder käuflicher Komponenten schränkt zwar die Flexibilität ein (siehe Abschnitt 24.6), verringert aber die Kosten und die Entwicklungszeit. Der Kunde sollte genau wissen, welche Vor- und Nachteile eine »handgeschmiedete« Lösung hat.
Wegen der starken Abhängigkeit vom Anwendungsgebiet der Software, von der Umgebung des Zielsystems, der Aufgabenstellung, den Vorkenntnissen des Analytikers, dem Verständnis der Gesprächspartner usw. kann man kaum allgemeine Regeln für die Analyse angeben. Man stelle sich zwei Analytiker vor, von denen einer in einem Modehaus die Planung zukünftiger Kollektionen untersucht, der andere die Regelung eines Flugzeugtriebwerks: Die beiden haben fachlich nur wenige Gemeinsamkeiten. Wichtig ist aber in jedem Fall, dass die Analyse als Tätigkeit wahr- und ernst genommen wird, dass Zeit und Personal dafür im notwendigen Maße zur Verfügung stehen und dass die Resultate in eine Form gebracht werden, die der Kunde nicht nur abzeichnen, sondern mit Verständnis prüfen und akzeptieren kann.
Es gibt viele Möglichkeiten, den Ist-Zustand kennenzulernen und die Anforderungen an den Soll-Zustand zu erfahren. Abbildung 16–2 nennt wichtige Techniken und zeigt, wo deren Stärken liegen. Die Techniken überlappen sich stark.
Abb. 16–2 Analysetechniken und ihre Eignung für die verschiedenen Aspekte der Analyse
Natürlich sollte der Analytiker die einschlägigen Vorschriften und Regeln sichten und die Aussagen herausfiltern, die seine Arbeit betreffen.
Wo die Möglichkeit besteht, sollte er direkt am Alltag derer teilnehmen, die später mit der Software umgehen werden oder deren Funktion später von der Software übernommen wird. Er sollte ihnen über die Schulter schauen oder, besser noch, selbst mitarbeiten. Dabei wird er vieles sehen und hören, was ihm niemand erzählt.
Dann kann er die Klienten systematisch befragen. Ein vorbereiteter Fragenkatalog (geschlossene und strukturierte Fragen) ist außerordentlich hilfreich, um Lücken zu erkennen und zu beseitigen. Offene Fragen (»Was erwarten Sie außerdem vom neuen System?«) geben den Klienten die Möglichkeit, neue Gedanken und Ideen einzubringen. Das geht am besten, wenn die Befragung in Form eines Gesprächs durchgeführt wird, also nicht per Fragebogenversand.
Immer wenn die abstrakte Vorstellung vom Zielsystem nicht ausreicht, um Anforderungen verbindlich festzulegen, muss etwas ausprobiert werden, sei es in Form einer Modell-Entwicklung, eines Experiments oder eines ausführbaren Prototyps. Ein Prototyp (siehe Abschnitt 9.5.1) deckt in vielen Fällen auf, dass sich die Klienten über die Konsequenzen ihrer Forderungen nicht klar waren.
Die Technik der partizipativen Entwicklung wurde zunächst in Skandinavien (Nygaard, 1986), später in Deutschland entwickelt (Floyd, 1989); dabei wird die Trennung zwischen Analyse und Entwicklung bewusst aufgehoben. Die neue Software wächst in den sozialen Kontext hinein, und die Entwickler reagieren direkt auf Probleme und Widersprüche. Wie Abbildung 16–2 andeutet, liegt die Stärke dieses Ansatzes in der frühen Klärung der Innovationsfolgen.
Wie oben gesagt wurde, ist es der Zweck der Analyse, die Anforderungen und Erwartungen der Klienten zu sammeln und aufeinander abzustimmen, sodass am Ende die Vision eines realisierbaren Systems steht.
Dass es nicht ausreicht, die Anforderungen beim Klienten abzufragen, wird unten diskutiert (Abschnitt 16.4.1). Es gehört zu den anspruchsvollsten Aufgaben des Analytikers, mit dem Klienten zusammen aus den nebulösen Vorstellungen, die wir alle mitbringen, wenn wir uns etwas Neues wünschen, eine präzise Definition zu machen. Der Analytiker läuft dabei ständig Gefahr, Anforderungen zu übersehen oder eigene Vorstellungen einzubringen, die nicht die des Klienten sind. Eventuell muss der Analytiker sogar damit rechnen, vom Klienten getäuscht zu werden. Beispielsweise wird ein Angestellter nicht einfach sagen, dass er hofft, auch mit dem geplanten Zeiterfassungssystem seine Zigarettenpausen durchmogeln zu können, so wie er es bisher konnte. Aber er wird später vielleicht das System sabotieren, wenn es seine kleinen Freiheiten gefährdet. Der gute Analytiker ist also weit mehr als ein fragender Ingenieur.
Die Analyse (und besonders die Ist-Analyse) wird in der Praxis oft vernachlässigt oder falsch fokussiert. Die Gründe sind offensichtlich:
Wo die Spezifikation selbst keine Rolle spielt, wird auch die Analyse keine Bedeutung haben.
Viele Entwickler sehen nicht, dass der Kunde primär keine Veränderung, sondern eine Verbesserung will. Sie vernachlässigen darum die Ist-Analyse.
Entwickler sind oft der (grundfalschen) Überzeugung, bereits zu wissen, was gewünscht oder benötigt wird. Diese Fehlhaltung kann geradezu als die Berufskrankheit der Informatiker diagnostiziert werden: »Der Kunde hat doch keine Ahnung, was er will und was er braucht. Ich, der Experte, sorge dafür, dass er bekommt, was er braucht.« Mit anderen Worten: Bei der Planung der Tierversuche könnten die Tiere nur stören.
Manche Klienten tragen durch ihr Verhalten dazu bei, dass die Analyse nicht ordentlich durchgeführt werden kann. Sie tun wenig dafür, dass ihre Fachleute den Analytikern zur Verfügung stehen: Die Analytiker verhungern. Gleichzeitig sehen manche Klienten in der Analyse wie in der Qualitätssicherung und in allen anderen Aktivitäten, die nicht unmittelbar ausführbaren Code liefern, ein Einsparungspotenzial. (Prinzip: »Ihr seid zu teuer, sonst könntet ihr euch diesen Schnickschnack gar nicht leisten!«) Und schließlich sabotieren sie den Entwicklungsprozess, indem sie noch am Ende der Entwicklung ungeniert neue Anforderungen präsentieren.
Einem Praxisbericht entnehmen wir die folgenden Angaben über das mögliche Vorgehen und einige Erfahrungen:
Die Analyse wird von einem Kernteam durchgeführt (drei bis vier Leute). Seine Mitglieder sind teilweise Fachleute aus der Anwendung, teilweise sind es Entwickler. Für die Analyse kommen nur die besten Leute in Frage.
Bei der Analyse müssen Entscheidungsträger (Manager), Fachleute und Anwender gehört werden. Die Anwender werden in der Regel durch Interviews beteiligt: Zwei Leute befragen eine Person ca. 90 min lang.
Das Rohmaterial (»der Zettelkasten«) wird in halb- oder ganztägigen Workshops mit sechs bis zehn Teilnehmern geordnet und bewertet. Diese Workshops dienen vor allem dem Ziel, die Widersprüche zwischen den Anforderungen sichtbar zu machen und eine Entscheidung darüber herbeizuführen, welche Anforderungen Priorität haben sollen. Der Analytiker überschreitet seine Kompetenzen, wenn er selbst einen Kompromiss wählt; sehr wahrscheinlich macht er sich damit nur alle Klienten zu Feinden. (»Wozu erzähle ich dem Menschen stundenlang meine Anforderungen, wenn er am Ende etwas ganz anderes liefert?«) Stattdessen sollte er im Workshop die Positionen darstellen und die Klienten zu einer Entscheidung drängen. (Beispiel: »Der Datenschützer verlangt, dass nur wenige Personen Zugriff auf die Daten haben. Der Verwaltungschef wünscht einen möglichst einfachen Zugriff aller Sachbearbeiter. Wie wollen wir verfahren? Ich sehe folgende Möglichkeiten: ...«)
Es ist aussichtslos, den Klienten mit formalen Darstellungen zu kommen; dazu zählen nicht nur die »harten« formalen Notationen wie Z oder algebraische Spezifikation, sondern auch scheinbar harmlose Diagramme, wie sie beispielsweise UML anbietet. Anwendungsfälle (Use Cases) sind dagegen gut zur Kommunikation geeignet.
Ein wichtiges Resultat der Analyse ist neben einer Sammlung der Anforderungen das Begriffslexikon.
In der Analyse wird ein Begriffslexikon angelegt. Aufbau und Weiterentwicklung dieses für die gesamte Software-Entwicklung wichtigen Dokuments sind wesentliche Aufgaben der frühen Phasen.
Das Begriffslexikon enthält Definitionen und Klärungen solcher Begriffe, die wichtig sind und möglicherweise von verschiedenen Leuten, insbesondere von den Klienten, den Analytikern und den Entwicklern, unterschiedlich ausgelegt werden. Dazu gehören häufig Begriffe, die auf den ersten Blick völlig klar zu sein scheinen.
Denken wir beispielsweise an ein Informationssystem, das die Prüfungsdaten von Studenten verwaltet. Dann müssen Begriffe wie »Student«, »Prüfung«, »Note«, »Erstprüfung«, »Wiederholungsprüfung« und noch etliche andere definiert werden.
Jeder Eintrag im Begriffslexikon sollte die folgenden Informationen enthalten:
a) Begriff und Synonyma (im Sinne der Spezifikation)
b) Bedeutung (Definition, Erklärung)
c) Abgrenzung (wo ist dieser Begriff nicht anzuwenden?)
d) Gültigkeit (zeitlich, räumlich, sonst)
e) Fragen der Bezeichnung, Eindeutigkeit u. Ä.
f) Unklarheiten, die noch nicht beseitigt werden konnten
g) verwandte Begriffe (Querverweise)
Natürlich ist es nicht Aufgabe des Analytikers, sich die Beschreibungen aus den Fingern zu saugen, sie müssen aus den Gesprächen und Interviews abgeleitet werden. In vielen Fällen zeigt sich dabei, dass die Aussagen verschiedener Personengruppen widersprüchlich sind. Dann muss der Analytiker die Widersprüche aufzeigen und – am besten in einem gemeinsamen Gespräch – einen Konsens finden. Das ist eine heikle Aufgabe, denn mindestens eine Gruppe muss ihre Sprache ändern. Ist das nicht akzeptabel, dann wird notfalls ein neuer Begriff eingeführt, der nicht vorbelastet ist.
Abbildung 16–3 zeigt ein Beispiel; als Kontext kann man sich eine Software-Entwicklung für die Universität Stuttgart vorstellen.
Begriff |
Student, synonym Studentin, Studierender, Studierende |
Bedeutung |
Eine Person, die an der Universität Stuttgart immatrikuliert ist und noch nicht exmatrikuliert wurde, die folglich legal einen Studentenausweis der Universität Stuttgart hat oder haben könnte. |
Abgrenzung |
Gasthörer und Studierende anderer Hochschulen sind im Sinne dieses Systems keine Studenten. |
Gültigkeit |
Mit der Immatrikulation an der Universität Stuttgart entsteht ein neuer Student; er existiert bis zur Exmatrikulation, gleichgültig, wie sie zustande kommt. Ein Fachwechsel oder eine Namensänderung implizieren keine Exmatrikulation. Hat sich eine Person im Laufe ihres Lebens mehrfach an der Universität Stuttgart immatrikuliert, so handelt es sich um mehrere, nicht identische Studenten. |
Bezeichnung |
Ein Student ist durch die Matrikelnummer und einen Zeitpunkt (zu dem die Matrikelnummer gültig war oder ist) eindeutig bestimmt, alle anderen Attribute, insbesondere der Name, können mehrfach vorkommen. |
Unklarheiten |
Es ist noch ungeklärt, wie Namen aus anderen Schriftsystemen (z. B. Russisch, Arabisch, Chinesisch) dargestellt werden. |
Querverweise |
Gasthörer, Matrikelnummer, Studentenausweis |
Abb. 16–3 Beispiel für einen Eintrag im Begriffslexikon
Wichtig ist, dass im Begriffslexikon klar zwischen Objekten, Rollen oder Typen der realen Welt und Daten der Software unterschieden wird. Gerade diese Unterscheidung ist bei der Software-Entwicklung oft keineswegs deutlich. Wenn wir, wie im Beispiel, Wörter wie »Student« verwenden, können wir
von einem Individuum, also einem speziellen Studenten, oder vom Typ »Student«, also von einem Begriff, sprechen,
die Studenten aus Fleisch und Blut oder die Datensätze meinen, die die realen Studenten repräsentieren.
In unserem Beispiel ist vom Begriff »Student«, also von einer Gruppe von Menschen die Rede, nicht von einem Datentyp. In manchen Fällen wird das durch den Kontext klar, sonst müssen wir sagen, was gemeint ist. Werden diese Bedeutungen verwechselt, so kann das zu schwerwiegenden Missverständnissen führen.
Die definierten Begriffe stehen selten für sich allein, sondern sind miteinander durch Beziehungen vernetzt. Es hat sich bewährt, die Begriffe und ihre Beziehungen explizit zu modellieren. So entsteht ein anwendungsfachliches Begriffsmodell. Neben allgemeinen Assoziationen verwenden wir dazu Generalisierungs-und Kompositionsbeziehungen. Abbildung 16–4 zeigt – in der Notation der UML-Klassendiagramme – einen Ausschnitt des Begriffsmodells für ein Prüfungsdaten-Verwaltungssystem.
In Abbildung 16–4 ist die folgende Struktur beschrieben (Entitäten und ihre Beziehungen sind kursiv gesetzt): Lehrveranstaltungen werden durch Prüfungen geprüft, dabei handelt es sich entweder um eine Erst- oder um eine Wiederholungsprüfung. Eine Prüfung wird immer von einem Prüfer abgehalten. Legt ein Student eine Prüfung ab, dann wird diese zusammen mit dem erzielten Prüfungsergebnis dem Studenten zugeordnet und als abgelegte Prüfung bezeichnet.
Begriffsmodelle helfen, den Anwendungsbereich zu erfassen und die Begriffe im Kontext zu verstehen.
Abb. 16–4 Ausschnitt aus einem Begriffsmodell
Der Begriff »Anforderung« ist vielschichtig, daher wird er hier unter verschiedenen Gesichtspunkten diskutiert. Es geht hier nicht primär um eine Taxonomie, vielmehr wollen wir damit zeigen, dass es sehr unterschiedliche Arten von Anforderungen gibt, die sich weder auf gleiche Weise erheben noch dokumentieren oder prüfen lassen. In der Praxis besteht eine starke Neigung, sich an diejenigen Anforderungen zu halten, die die wenigsten Probleme machen. Das ist ähnlich sinnvoll, wie wenn man sich nur die gut erreichbaren Schneidezähne putzt.
Allgemein kann man die Anforderungen am Qualitätenbaum festmachen (Abb. 5–2 auf S. 68). Jede Forderung nach einer bestimmten Qualität ist eine Anforderung. Darum müsste unter den Anforderungen auch die Prozessqualität auftauchen. In der Praxis ist die Spezifikation meist auf die Brauchbarkeit beschränkt, zur Wartbarkeit gibt es höchstens eine vage Forderung (»soll wartungsfreundlich sein«), und die Prozessqualität kommt gar nicht vor. Seit einigen Jahren werden aber auch Anforderungen an den Prozess gestellt (wenn auch nicht in der Spezifikation), sodass sich die Praxis dem Bild annähert.
Im einfachsten Fall hat der Klient seine Anforderungen bereits druckreif formuliert, und der Analytiker braucht sie nur einzusammeln, so wie Postangestellte den Inhalt der Briefkästen einsammeln (offene Anforderungen). Meist ist die Sache aber schwieriger: Der Klient ist sich der Anforderungen nicht bewusst, sie bleiben latent, solange er nicht mit einer Frage oder einer Situation konfrontiert wird, die ihm ihre Bedeutung vor Augen führt. Der Analytiker muss ihm also helfen, sich die latenten Anforderungen bewusst zu machen.
Schließlich kann es auch sein, dass der Klient zu einer Frage weder eine offene noch eine latente Anforderung hat, es ist ihm einfach gleich. In diesem Fall bleibt die Entscheidung als Entwickler-Option offen. Beispielsweise ist in vielen Software-Projekten die Programmiersprache vorgegeben, weil der Klient möglichst wenige Programmiersprachen im Hause haben will. Gibt es diese Vorgabe ausnahmsweise nicht, so kann der Analytiker notieren, dass die Wahl der Sprache den Entwicklern überlassen ist. Diese Notiz ist wichtig, weil sonst bei einer Prüfung der Spezifikation eine Lücke vermutet werden könnte.
Lehrbuchbeispiele, in denen ganze Zahlen berechnet oder Fragen mit »Ja« oder »Nein« beantwortet werden, zeigen harte Anforderungen. Auf die Frage, ob 99 eine Primzahl ist, kann es kein Wackeln geben, die Antwort »Nein« ist richtig, die Antwort »Ja« ist falsch. Ähnliches gilt auch für viele Software-Systeme in Verwaltungen, Banken und Versicherungen: Wenn das eine Konto belastet wurde, sollte innerhalb einer begrenzten Zeit die Gutschrift des genau gleichen Betrages auf dem anderen Konto erscheinen. Wenn ein Bürger in der Gemeinde gemeldet und im Besitz der bürgerlichen Rechte ist, muss er eine Wahlbenachrichtigung erhalten. All dies sind harte Anforderungen.
Weiche Anforderungen sind dadurch gekennzeichnet, dass es einen fließenden Übergang zwischen richtig und falsch gibt. Wenn ein System den Umfang eines Kreises mit dem Durchmesser 10 m berechnen soll, dann ist 31,41 m weder ganz richtig noch ganz falsch. 31,2 m wäre als Resultat schlechter, 31,412 m besser. Natürlich kann es sein, dass die Klienten eine zulässige Toleranz angegeben haben. Ähnlich verhält es sich mit den Forderungen an die Antwortzeiten; wenn wir den Klienten lange genug schütteln, gibt er uns vielleicht eine Zahl, sagt, dass die Antwort nie länger als 0,1 s dauern darf. Aber wenn sie später 0,11 s benötigt, wird er den »Fehler« womöglich gar nicht bemerken. Und ganz besonders weich werden die Anforderungen dort, wo wir sie nicht quantifizieren können. Wer kann schon ohne Skrupel die Grenze ziehen zwischen einem wartungsfreundlichen und einem (minimal schlechteren) nicht wartungsfreundlichen Programm?
Abb. 16–5 Der Nutzen bei harten (links) und weichen Anforderungen (rechts)
Weiche Anforderungen sind schwer zu erheben und ebenso schwer zu formulieren. Ideal wäre die Angabe von Nutzenfunktionen, wie sie in Abbildung 16–5 angedeutet sind. Die linke Seite zeigt eine harte Anforderung: Wenn das Programm nicht in den Speicher passt, ist sein Nutzen null. Die rechte zeigt eine weiche Anforderung: Eine etwas längere Antwortzeit mindert den Nutzen des Programms nur graduell. (Achtung: Natürlich sind beide Aussagen nicht generell gültig, und der Gesamtnutzen lässt sich nicht additiv ermitteln!) Auf der Grundlage solcher präziser Funktionen könnten dann die Entwickler denjenigen Entwurf suchen, der den Gesamtnutzen maximiert.
Natürlich ist dieses Verfahren nicht praktikabel, weil jede einzelne Nutzenfunktion nur mit großem Aufwand zu ermitteln wäre und die Wechselwirkungen zwischen verschiedenen Attributwerten die Sache nochmals wesentlich komplizierter machten. Aber der Analytiker sollte die Idee im Kopf haben, um zu verstehen, dass wir bei weichen Anforderungen einen Kompromiss finden müssen. Zudem sollte er Anforderungen nicht als betonhart darstellen, wenn sie in Wahrheit unter dem Druck entstanden sind, einen Zahlenwert zu nennen.
Wir brauchen die Anforderungen nicht nur, um die richtige Software zu entwickeln, wir brauchen sie auch als Referenz bei der Prüfung der Software: Wir prüfen das Resultat gegen die Spezifikation. Dazu müssen die Anforderungen objektivierbar sein. Ein Beispiel ist die Begrenzung des verfügbaren Speicherplatzes. Wenn das fertige System in den vorgegebenen Speicherplatz geladen und dort ausgeführt werden kann, ist die Anforderung erfüllt. Wäre nur gefordert worden, dass das Programm »wenig Speicher« benötigt, so wäre nicht eindeutig zu klären, ob die Spezifikation eingehalten wurde.
Man sollte daher stets versuchen, Anforderungen in objektivierbarer Form zu dokumentieren. Das gelingt aber nicht oder nur schlecht, wo wir keine sinnvolle Quantifizierung kennen oder – wie bei den Leistungsaspekten – zwar quantifizieren können, aber oft nicht wissen, welche Grenzwerte sinnvoll sind.
Der Nutzen, den uns eine Software bringt, liegt in ihrer Funktion, genauer in der Funktion des Programms. Ob es zuverlässig, komfortabel oder schnell ist, spielt keine Rolle, wenn wir seine Funktion nicht brauchen können.
Darum stehen die funktionalen Anforderungen im Vordergrund. Offensichtlich gehört zu den funktionalen Anforderungen die Beziehung zwischen Ein- und Ausgaben. Die Kurzbeschreibung eines Systems, also eine auf wenige Worte reduzierte Spezifikation, ist stets eine grobe Charakterisierung der Funktion, z. B.: »Dieses System sichert nachts die Inhalte aller Festplatten.«
Die funktionalen Anforderungen reichen aber nicht aus. Wir stellen an ein System auch Forderungen, die andere, nichtfunktionale Aspekte betreffen. Fast alle Aussagen zur Wartbarkeit (»Das System muss leicht portierbar sein.«) sind offensichtlich nichtfunktionale Anforderungen (non-functional requirements, NFRs).
Im Grenzbereich zwischen funktionalen und nichtfunktionalen Anforderungen liegen vor allem Anforderungen, die mit der Bedienoberfläche zu tun haben. Einerseits geht es hier um Ein- und Ausgabe, also um die Funktion des Systems; es wäre also möglich, Bedienbarkeit, Robustheit usw. präzise funktional zu spezifizieren. Andererseits haben wir von der Funktion meist nur eine abstrakte Vorstellung. Wenn uns das Kontoführungsprogramm den Kontostand auf irgendeine Weise in gut lesbarer, übersichtlicher Form anzeigt, sind wir als Klienten zufrieden. Wir machen weder uns noch dem Analytiker die gewaltige Mühe, die Oberfläche haarfein (und damit funktional) vorzugeben, sondern erheben stattdessen vage Forderungen nach Bedienungsfreundlichkeit oder Robustheit, oder wir geben einen bestimmten Stil vor: »Die Software soll das Look and Feel des Betriebssystems übernehmen.« Das sind NFRs. Man beachte aber, dass es kritische Systeme gibt (beispielsweise die Software der Fluglotsen), bei denen man sich diese Unschärfe nicht leisten kann. Hier gehören die Details der Oberfläche eindeutig zur Funktionalität. Stellt das System ein Flugzeug nicht in der richtigen Farbe oder Form dar, dann ist es fehlerhaft und unbrauchbar. Zur Einordnung der Leistungsmerkmale siehe Abschnitt 16.7.4!
Die NFRs bereiten uns große Probleme. Während sich die funktionalen Anforderungen recht präzise fassen lassen, sind die meisten NFRs weich (Abschnitt 16.4.2) und vage (Abschnitt 16.4.3). Sie werden stiefmütterlich behandelt, meist ganz weggelassen oder nur durch völlig unverbindliche Schlagwörter ausgedrückt. Oft liegen aber die Schwierigkeiten der Klienten mit der gelieferten Software gerade in den NFRs, die nie erhoben wurden, und entsprechend auch nicht formuliert und in der Entwicklung berücksichtigt worden sind.
Nichtfunktionale Gebrauchs- und Wartungsqualitäten lassen sich am besten definieren, wenn man auf Normen Bezug nehmen kann. Im Bereich der Ergonomie gibt es solche Normen, sie betreffen aber überwiegend nicht die Software, sondern die technische Gestaltung der Arbeitsplätze. Die Norm DIN EN ISO 9241 (2000) befasst sich in den Teilen 1 bis 9 mit der Technik, Teil 10 enthält die »Grundsätze der Dialoggestaltung«, und die Teile 11 bis 17 gehen in die Details der Dialoggestaltung. Allerdings bietet keiner der Standards harte Vorschriften, deren Einhaltung einfach und objektiv zu prüfen wäre.
Das Fehlen präziser Normen ist aber kein Grund, auf eine möglichst klare Formulierung der NFRs zu verzichten. Ein brauchbarer Kompromiss ist viel besser als ein Schlagwort, das nichts aussagt. Tabelle 16–1 zeigt einige Beispiele für NFRs. Keines der Beispiele ist vollständig: Die Sätze enthalten Begriffe, die weiter geklärt werden müssen. Wenn vom Laien die Rede ist, muss man wissen, ob es sich um einen Analphabeten handeln kann oder nur um einen Menschen, der dieses System zuvor nie benutzt hat. Ein »irregulärer Abbruch« muss definiert werden. Wenn auf eine Tastatur Bezug genommen wird, muss auch gesagt werden, um welche Tastatur es sich handelt. Das alles kann und muss präzisiert werden. Die gezeigte Formulierung ist jeweils nur ein möglicher Einstieg.
Schlagwort |
bessere Anforderung |
einfach bedienbar |
Das Programm soll auch von Laien ohne weitere Einweisung benutzt werden können. |
robust |
Eine Bedienung über die Tastatur darf unter keinen Umständen zu einem irregulären Abbruch des Programms führen. |
portabel |
Das Programm muss von einem Entwickler in höchstens 6 h von Windows XP auf Linux portiert werden können. |
übersichtlich kommentiert |
Die Module des Programms müssen einen Kopfkommentar nach Std. xyz enthalten. |
plattformunabhängig |
Alle prozessorspezifischen Teile des Programms müssen in einem speziellen Modul liegen. |
nicht zu große Module |
Module dürfen max. 300 Zeilen ausführbaren Code enthalten. |
angemessenes Handbuch |
Das Benutzungshandbuch wird gemäß Richtlinie ABC aufgebaut. Es wird vom Gutachter N.N. geprüft. |
Tab. 16–1 Beispiele für nichtfunktionale Anforderungen
Ingenieure, auch Software-Ingenieure, neigen dazu, sich auf den funktionalen Kern ihres Problems zu konzentrieren. Die Frage, wie man mit der Software arbeiten kann, wird als peripher beiseite geschoben. Dabei ist der konkrete Umgang mit dem System für die Menschen, die damit arbeiten, außerordentlich wichtig, meist wichtiger als irgendwelche funktionalen Besonderheiten, die kaum benötigt und darum auch kaum benutzt werden. Wir sollten es also als primäres Ziel betrachten, ein System zu schaffen, das leicht und einfach benutzbar ist.
Der englische Begriff »Usability« hat sich für diesen Aspekt der Software-Qualität durchgesetzt; man versteht darunter alle Merkmale eines Systems, die Einfluss darauf haben, wie mühsam oder mühelos die Benutzer mit dem System zurechtkommen. »Benutzbarkeit« hat eigentlich die gleiche Bedeutung, wird aber enger interpretiert, sodass wir hier das englische Wort verwenden.
Zur Usability gehören nach üblicher Auffassung die in der Tabelle 16–2 genannten Aspekte.
Aspekt |
Erklärung |
Beispiel |
Metapher, Benutzungsmodell |
Das System sollte dem Benutzer eine bekannte Metapher anbieten, die es gestattet, die Operationen am System und Änderungen im System nachzuvollziehen. Die Operationen müssen so realisiert werden, dass sie mit der Metapher konsistent sind. |
Informationen, die der Nutzer verwaltet, werden als logische Objekte behandelt, die eingegeben, angezeigt und gelöscht werden können (Prinzip des Zettelkastens). Der Nutzer hat jederzeit eine Vorstellung, wo sich die Information befindet, z. B. im Arbeitsbereich oder in der Datenbank. |
Übersichtlichkeit |
Die Benutzungsoberfläche sollte so gestaltet sein, dass der Nutzer alle relevanten Informationen leicht erkennt. |
Irrelevante Informationen werden nicht angezeigt; alle angezeigten Informationen sind logisch gruppiert. |
Konsistenz |
Gleiche oder ähnliche Operationen sollten auch mit gleichen oder ähnlichen Eingaben ausgelöst werden; ähnliche Inhalte sollten ähnlich dargestellt werden. |
Eine bestimmte Tastenkombination hat stets die gleiche Bedeutung, z. B. Löschen der markierten Information. Die geschätzte Ausführungszeit längerer Operationen wird stets mit den gleichen Symbolen angezeigt. |
Sicherheit |
Die Bedienung sollte so angelegt sein, dass der Nutzer irrtümlich keinen Schaden anrichtet. |
Operationen, die den internen Zustand verändern, werden erst wirksam, wenn der Nutzer die Änderung bestätigt hat. |
Ästhetik |
Die Benutzungsoberfläche sollte nach dem Empfinden des Nutzers schön (angenehm) sein. |
Unangenehme Kontraste (z. B. durch gelbe Schrift auf blauem Grund) werden nicht erzeugt, es sei denn, sie signalisieren eine besonders kritische Situation. |
Effizienz |
Der Aufwand für die Bedienung sollte so gering wie möglich sein. |
Es genügt, wenn der Nutzer einmal sein Passwort eingibt, um eine Folge von Operationen auszulösen, die jeweils ein Passwort erfordern. |
Erlernbarkeit |
Dem Nutzer sollte es leicht fallen, die Bedienung des Systems zu erlernen. |
Das System verhält sich ähnlich wie andere Systeme, die dem Nutzer bereits vertraut sind. Alle Unklarheiten des Nutzers werden durch Hilfe-Funktionen geklärt. |
Tab. 16–2 Aspekte der Usability
Traditionell werden die Anforderungen zur Usability wie die anderen nichtfunktionalen Anforderungen (siehe Abschnitt 16.4.4) vernachlässigt; damit ist es auch kaum möglich, die Usability des Systems später zu prüfen. Die bekannte Folge sind Systeme, deren Funktionalität im Großen und Ganzen in Ordnung ist, die aber bei den Benutzern auf Ablehnung stoßen. Darum wurde eine ganze Reihe von Methoden entwickelt, die Abhilfe schaffen können.
Allen Ansätzen gemeinsam ist das Ziel, die Situation der Benutzer vorstellbar zu machen. Das beginnt natürlich mit der Frage, wer die Benutzer sind. Wenn das zu entwickelnde System Vorgänger hat oder seine Zielgruppe aus anderen Gründen sehr klar ist (beispielsweise bei einer Software, die Mitarbeiter einer Versicherung bei der Beurteilung von Schadensfällen unterstützt), kann und sollte man diese Zielgruppe kennenlernen: Was sind das für Leute? Welche Ausbildung haben sie? Wie lösen sie ihre Probleme bisher? Welche Erfahrung haben sie mit Rechnern und Software? Eine gründliche Analyse der Zielgruppe ist ein wichtiger Baustein der Analyse.
Das statistische Material, das dabei entsteht, ist nicht immer leicht zu interpretieren. Wenn die Zielgruppe homogen ist, helfen Mittelwerte (oder Mediane), ein Bild der späteren Benutzer zu schaffen. Zerfällt die Zielgruppe aber in ganz unterschiedliche Fraktionen, sind Mittelwerte nutzlos und verstellen eher den Blick auf die Realität. Nehmen wir an, dass in der oben erwähnten Versicherung eine Reihe älterer Mitarbeiter vorwiegend im Büro arbeitet, während einige überwiegend jüngere die Schäden anschauen und direkt mit den Betroffenen sprechen. In diesem Fall hat es keinen Sinn, das Durchschnittsalter zu berechnen oder die bevorzugte Automarke festzustellen.
Oft hat sich in solchen Situationen das Konzept der Persona als nützlich erwiesen. »Persona« bedeutet ursprünglich so viel wie Figur auf der Bühne (von den mit Schalltrichtern ausgestatteten Masken, aus denen im griechischen Theater der Antike die Stimmen der Schauspieler kamen, personare = hindurchklingen). Cooper (2004) hat vorgeschlagen, die Benutzer eines zu entwickelnden Systems durch eine kleine Zahl solcher Personas (dieser falsche Plural hat sich leider eingebürgert!) vorstellbar zu machen. Die Idee wurde vielfach erprobt (Long, 2009) und eingesetzt. Wesentlich ist dabei, dass man einen fiktiven Menschen schafft, mit Namen, Bild, Geburtsdatum, Lebenslauf, Familie, Hobbys. Natürlich sollte dieser Mensch nicht völlig untypisch für die Zielgruppe (oder eine der Zielgruppen) sein.
Im Beispiel oben (Versicherung) liegt es nahe, jede der beiden Gruppen durch eine Persona zu repräsentieren, beispielsweise Walter Starke: 55 Jahre alt, hat eine Frau und zwei Kinder, von denen noch eines zu Haus ist und studiert. Walter Starke segelt in seiner Freizeit und kommt meist mit dem Motorrad ins Büro. Er bearbeitet Schadensfälle, in den meisten Fällen auf der Grundlage der Schadensmeldungen und der Akten. Walter Starke ist gelernter Versicherungskaufmann. Er ist in Köln geboren, aber schon als Kind nach Stuttgart gezogen.
Wenn Walter Starke nun noch ein Gesicht bekommt, haben alle das Gefühl, ihn zu kennen. Sie können dann Aussagen machen wie »Das wird Walter nicht so einfach kapieren, da müssen wir ihn vorher schulen« oder »Das gefällt ihm bestimmt!«. Mit einer zweiten Persona wird die Gruppe der jüngeren Mitarbeiter repräsentiert.
Cooper (2004) gibt ein Beispiel dafür, wie genau man sich eine Persona (»Emilee«) ausmalt:
We don’t just let Emilee drive to work. We give her a dark-blue 1991 Toyota Camry, with a gray plastic kid’s seat strapped into the back and an ugly scrape on the rear bumper.
Cooper (2004, S. 128)
Cooper argumentiert, dass nur die sehr genau beschriebene Persona die Entwickler daran hindert, sich ihre Nutzer nach den eigenen Bedürfnissen zurechtzubiegen. Darum ist auch die Detaillierung der Beschreibung wichtiger als ihre Korrektheit im statistischen Sinne.
In manchen Firmen, die für den Markt entwickeln, also ihre Kunden erst noch suchen müssen, gibt es für jedes Produkt eine Persona oder mehrere Personas. Bei Microsoft (Pruitt, Grudin, 2003) sind sie als Pappkameraden präsent, mit Namen, die aus einem Comic Strip zu kommen scheinen (»Eagle-Eye Edward«). Hier zeigt sich ein Problem: Die Persona wird zum Klischee, das auf reale Benutzer eher abschreckend wirkt. In der sehr kontroversen Literatur wird noch eine Reihe anderer Einwände genannt (z. B. von Chapman, Milham, 2006, ebenfalls bei Microsoft):
Die Verwendung von Personas ist ein in der Praxis bewährter Trick, kein wissenschaftlich fundierter Ansatz; für die richtige Wahl einer Persona gibt es keine begründete Methode, und das Ergebnis kann nicht validiert werden. Man kann also nur hoffen, die Zielgruppe(n) richtig zu treffen.
Reale Menschen altern, lernen und ändern sich. Es ist unklar, ob auch die Persona eine Entwicklung zeigen sollte oder wie Dorian Gray von der Zeit unberührt bleibt. (Im Beispiel oben: Ob Emilee wohl immer noch ein Auto von 1991 fährt? Und braucht sie den Kindersitz noch?)
Eine Persona kann nicht alle Benutzer der Zielgruppe repräsentieren. Beispielsweise gilt oft die Anforderung, dass Menschen mit Behinderungen mit dem System arbeiten können sollen. Natürlich kann man eine behinderte Persona vorsehen. Aber auch diese wird nicht alle Varianten von Behinderungen aufweisen, denn das wäre unrealistisch. Es gibt also wichtige Anforderungen, die nur abstrakt formuliert werden können, obwohl sie mit konkreten Benutzern zu tun haben.
Versucht man, alle Anforderungen von den Personas abzuleiten, dann werden Aspekte vernachlässigt, die nicht direkt mit den Personas in Verbindung zu bringen sind, z. B. die Portabilität des Systems oder die Wiederverwendbarkeit der entwickelten Komponenten.
Personas können bei den Entwicklern die Neigung verstärken, die realen Benutzer zu ignorieren.
Das bedeutet: Personas sind ein attraktives und wirksames Mittel, um quasi mit Benutzern des geplanten Systems in Kontakt zu treten und etwas zu entwickeln, das realen Benutzern später auch gefällt. Die Konkretisierung unterstützt unsere Fantasie, die brachliegt, wenn wir nur von den Benutzern reden (oder, schlimmer noch, im Singular von dem Benutzer). Technik-zentrierte Entwickler werden durch Personas gezwungen, die nichttechnische Welt zur Kenntnis zu nehmen.
Aber die Nachteile und Gefahren der Personas sollten bewusst und die realen Klienten im Blickfeld bleiben.
In der Praxis herrscht ein stark vereinfachtes Bild von den Anforderungen vor:
Wenn der Klient eine Anforderung nicht von selbst genannt hat, weil sie ihm nicht eingefallen oder nicht bewusst ist, dann hat er diese Anforderung nicht.
Wenn eine Anforderung funktional oder quantifizierbar ist, wird sie dokumentiert.
Alle anderen Anforderungen werden pauschal als nichtfunktionale Anforderungen bezeichnet und höchstens am Rande erwähnt. Das gilt sowohl für die Gebrauchsqualität, z. B. die Bedienbarkeit, als auch für die Wartungsqualität, z. B. die Erweiterbarkeit.
Wir empfehlen, nicht nur die »guten« Anforderungen zu dokumentieren und die »schlechten« (d. h. schwierigen) Anforderungen zu vergessen, sondern danach zu streben, alle Anforderungen, auch die latenten, zu erfassen und so weit wie möglich objektivierbar zu formulieren. Die Beispiele in Tabelle 16–1 können den Weg dafür weisen.
Das IEEE-Glossar enthält eine ganze Reihe von Definitionen im Kontext des Begriffs »Spezifikation«.
specification — A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied.
specification language — A language, often a machine-processible combination of natural and formal language, used to express the requirements, design, behavior, or other characteristics of a system or component. For example, a design language or requirements specification language.
Contrast with: programming language; query language.
requirements specification language — A specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document hardware or software requirements.
software requirements specification (SRS) — Documentation of the essential requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces.
IEEE Std 610.12 (1990)
Zieht man die Definitionen zu specification und SRS zusammen, so folgt daraus:
Die Anforderungsspezifikation dokumentiert die wesentlichen Anforderungen an eine Software und ihre Schnittstellen, und zwar präzise, vollständig und überprüfbar.
Hier ist nicht nachvollziehbar, warum die Schnittstellen eigens erwähnt werden, denn nahezu alle Aussagen über eine Software beziehen sich unvermeidlich auf ihre Schnittstellen. Wir verwenden das Wort Spezifikation, wo nichts anderes gesagt ist, synonym mit Anforderungsspezifikation, also nicht in dem allgemeinen Sinn, der in der IEEE-Definition von specification zum Ausdruck kommt.
Natürlich erfüllt auch eine Software, die mehr leistet als gefordert, die Spezifikation. Darum beschreibt die Spezifikation die entstehende Software nicht vollständig, sie gibt nur an, was die Software mindestens leisten muss.
Die Spezifikation ist im Idealfall inhaltlich
1. zutreffend
Sie gibt die Vorstellungen des Kunden (der Klienten) richtig wieder.
Jede (in einem Kopf oder in einem Dokument) vorhandene Anforderung ist in der Spezifikation enthalten.
3. widerspruchsfrei (oder konsistent)
Jede Anforderung ist mit allen anderen vereinbar. Andernfalls ist die Spezifikation inkonsistent und nicht vollständig realisierbar.
4. neutral (oder abstrakt)
Die Spezifikation schränkt die Realisierung nicht über die wirklichen Anforderungen hinaus ein.
5. nachvollziehbar
Die Quellen der Anforderungen sind dokumentiert, die Anforderungen sind eindeutig identifizierbar.
6. objektivierbar
Das realisierte System kann gegen die Spezifikation geprüft werden. Man spricht auch (missverständlich) von einer »testbaren« Spezifikation. Testbar (oder prüfbar) muss in Wahrheit das realisierte System sein.
Die Darstellung und Form der idealen Spezifikation ist
7. leicht verständlich
Alle Interessenten sind in der Lage, die Spezifikation zu verstehen.
8. präzise
Die Spezifikation schafft keine Unklarheiten und Interpretationsspielräume.
9. leicht erstellbar
Die Anfertigung und Nachführung der Spezifikation sind einfach und erfordern keinen nennenswerten Aufwand.
10. leicht verwaltbar
Die Speicherung der Spezifikation und der Zugriff darauf sind einfach und erfordern keinen nennenswerten Aufwand.
Diese Merkmale konkurrieren, d. h., die Steigerung der einen Qualität schadet der anderen. Beispielsweise stehen sich die Merkmale 6 und 7 bei durchschnittlichen Klienten, denen jede präzise, also formale Darstellung ein Gräuel ist, diametral gegenüber. Auch hier suchen wir also einen Kompromiss.
Die oben geforderte Neutralität der Spezifikation, also die scharfe Abgrenzung gegen den Entwurf, lässt sich nicht durchhalten. Dafür gibt es eine ganze Reihe sehr unterschiedlicher Gründe:
1. Vorhandene Komponenten sollen einbezogen werden. Damit ist der Entwurf teilweise schon vor Anfertigung der Anforderungsspezifikation festgelegt.
2. Durch den Klienten, durch Sicherheitsvorschriften, Normen oder Ähnliches ist unter Umständen eine ganz bestimmte Lösungsstruktur vorgeschrieben.
3. Bei einer überschaubaren Aufgabe, die mit einer hohen Sprache codiert wird, ist es oft das Einfachste und Billigste, direkt zu codieren, was gebraucht wird. Allgemein lassen sich oft Problemlösungen leichter angeben als Problemstellungen. Dieser Vorteil wird durch die Tatsache verstärkt, dass die meisten Software-Entwickler besser entwerfen als spezifizieren können.
4. Ein sehr komplexes System lässt sich erst dadurch handhaben und beschreiben, dass man es in überschaubare Einheiten zerlegt, also einen Systementwurf durchführt.
5. Erst die Realisierung belegt, dass die Spezifikation konsistent ist. Um also eine mit Risiken behaftete Spezifikation zu prüfen, muss eine Realisierung zumindest durchdacht worden sein.
6. Die Spezifikation muss Fragen beantworten, die sich erst durch den Entwurf stellen, d. h., Spezifikation und Entwurf stehen in einer dialektischen Beziehung, nicht in einer einfachen Hierarchie. Wenn gefordert wird, dass ein System einfach zu bedienen sein muss, dann kann im Entwurf entschieden werden, diese Forderung durch eine Sprachsteuerung zu erfüllen. Dann muss nachträglich spezifiziert werden, welche Sprachen das System verstehen soll.
7. Die reale Welt stellt nicht nur die Aufgabe, sondern verändert diese Aufgabe auch im Laufe der Zeit. Die Veränderungen erfolgen in den Begriffen und Strukturen der realen Welt. Folglich ist eine Nachführung der Software am einfachsten, wenn ihre Struktur mit der Struktur der realen Welt übereinstimmt, wenn sie also isomorph ist. Die Verwaltung einer Firma, die in drei klar getrennte Bereiche zerfällt, sollte genauso gegliedert sein; dann kann die Abspaltung eines Firmenteils in der Software relativ leicht nachvollzogen werden.
Deshalb entsteht eine strikt abstrakte Spezifikation nur, wenn das Problem
• gut verstanden,
• sicher lösbar,
• stabil und
• »flach« ist, also keine tiefen Verästelungen aufweist.
In den meisten Fällen liefert die Analyse nicht nur ein Bild der Anforderungen, sondern auch die Lösungsstruktur; beide Aspekte durchdringen sich und sind auch rückblickend nicht strikt zu trennen.
Dieser Zusammenhang zwischen Spezifikation und Entwurf wurde zu Beginn der Achtzigerjahre deutlich (Swartout, Balzer, 1982; Ludewig, 1982). Moderne iterative Vorgehensweisen haben diese Sicht übernommen (siehe z. B. Nuseibeh, 2001); Spezifikation und Entwurf werden als Aktivitäten verstanden, die sich bedingen und verschränkt auszuführen sind.
Wie oben festgestellt wurde, soll eine Spezifikation einerseits präzise und einer Bearbeitung mit Werkzeugen zugänglich, andererseits auch für Laien handhabbar, mindestens aber verständlich sein.
Da die Informatik starke Wurzeln in der Mathematik hat, war es naheliegend, für die Spezifikation auf formale Notationen zurückzugreifen. So entstanden zahlreiche Formalismen, die vor allem auf eine knappe Darstellung, eine präzise Semantik und die Möglichkeit der Bearbeitung durch Algorithmen zielen.
Mit diesen Notationen verwandt sind grafische Darstellungen der Spezifikation. Dabei steht aber weniger die formale Präzision als die Anschaulichkeit im Vordergrund.
Wer weder formal noch grafisch spezifiziert, bedient sich seiner (oder einer) natürlichen Sprache. Diese hat gegenüber den beiden zuvor genannten Möglichkeiten den Vorteil, grundsätzlich für jeden Menschen verständlich zu sein und ganz ohne spezielle Regeln und Werkzeuge auszukommen, wenn man von den Regeln der Grammatik und der Rechtschreibung absieht.
Nachfolgend werden die Möglichkeiten der formalen und der grafischen Darstellung kurz erörtert; das restliche Kapitel geht dann von einer mindestens überwiegend umgangssprachlichen Beschreibung aus. Allerdings ist die Abgrenzung in der Praxis weniger scharf: So werden die natürlichsprachigen Anwendungsfälle durch Anwendungsfalldiagramme ergänzt (siehe Abb. 16–7 auf S. 390), und an vielen Stellen bindet man formale Modelle in die Texte ein, z. B. eine BNF-Grammatik. Generell kann man sagen, dass ein guter Software-Ingenieur eine bereits erfolgte oder einfache Formalisierung eines (Teil-)Problems gern in Anspruch nimmt. So wäre es dumm, eine Bedienschnittstelle, der die Zustandsübergänge eines endlichen Automaten zu Grunde liegen, durch schwammigen Text zu beschreiben.
Für viele forschende Informatiker, die nach einer präzisen, eindeutigen und den mathematischen Methoden zugänglichen Spezifikation streben, liegt die Lösung in der Formalisierung. Deren Vorteile sind offensichtlich: Unklarheiten und Missverständnisse sind ausgeschlossen, eine Implementierung kann mit mathematischen Methoden (und das heißt praktisch auch: automatisch oder mit Rechnerunterstützung) auf Konsistenz mit der Spezifikation, also auf Korrektheit, geprüft werden. Selbst wenn sich die formalen Techniken nicht auf jede Software anwenden ließen, wäre es eine erhebliche Verbesserung, wenn sie für größere Bereiche der Software-Entwicklung tauglich würden; beispielsweise könnten viel benutzte Modul- oder Klassenbibliotheken formal spezifiziert, verifiziert und dann risikolos in andere Software eingebunden werden.
Schon in den Sechzigerjahren wurde auf diesem Gebiet gearbeitet. Waren die Notationen und Techniken der ersten Jahrzehnte, z. B. die Vor- und Nachbedingungen einzelner Anweisungen oder die Petri-Netze zur Beschreibung nebenläufiger Algorithmen, noch ungeeignet, um die Komplexität realer Programme in den Griff zu bekommen, sind etwa seit den Achtzigerjahren Modellierungen entstanden, die vor allem durch hierarchische Beschreibungen einen großen Schritt in Richtung Praxis gemacht haben. Zwei bekannte Beispiele sind die State Charts (Harel, 1987) und die Notationen auf der Grundlage von Mengen und Relationen (Alloy von Jackson, 2002). Als Prüfmittel sind sogenannte Model Checker entstanden, die mit beträchtlichem Rechenaufwand gewisse Eigenschaften von Modellen bestätigen oder widerlegen können (von Clarke, Emerson und Sifakis, die dafür 2004 mit dem Turing-Award ausgezeichnet wurden).
Nach wie vor ist es aber in der Praxis unmöglich, eine komplexe Software mit diesen Mitteln leidlich vollständig zu beschreiben; die Versuche scheitern an zwei ungelösten Problemen:
1. Erstellung, Prüfung und Verwendung formaler Spezifikationen
Formale Beschreibungen sind schwer zu erstellen und zu prüfen. Sie taugen damit nicht für die Kommunikation mit Kunden und Anwendern. Selbst unter hochqualifizierten Informatikern ist die Zahl derer, die damit arbeiten können (und wollen), sehr gering. Damit bleibt die formale Spezifikation die Domäne weniger Experten. Selbst wenn für ein Projekt ausreichend viele von ihnen verfügbar sind, können sie doch nicht prüfen, ob ihre Spezifikation die Anforderungen des Kunden korrekt repräsentiert; denn der versteht die formale Beschreibung sicher nicht. Alle weiteren Personen, die (etwa beim Test oder in der Wartung) an der Software arbeiten, müssen ebenfalls Experten sein. Das ist schwer vorstellbar.
Wir können auch keine Skizzen zeichnen, wie es die Ingenieure gern tun. Die bislang entwickelten formalen Notationen sind dafür nicht geeignet.
2. Die Beschränkung auf funktionale Anforderungen
Für funktionale Anforderungen, also den Zusammenhang zwischen Ein- und Ausgaben, stellt uns die Mathematik zahlreiche Modelle zur Verfügung. Beispielsweise können wir eine einfache Funktion f(x), die Berechnung der Quadratwurzel, so definieren:
Dabei ist ℜ die Menge der REAL-Zahlen eines bestimmten Rechners und e die Schranke eines Fehlers. Die funktionalen Anforderungen sind damit klar. Sie stellen aber nur einen kleinen, wenn auch wichtigen Teil der Anforderungen dar. Für die vielen anderen Anforderungen stehen uns keine formalen Modelle zur Verfügung, sie lassen sich darum – mit unserem heutigen Wissen – nicht formalisieren.
Das gilt für die weichen (Abschnitt 16.4.2) und mehr noch für die nichtfunktionalen Anforderungen (Abschnitt 16.4.4), beispielsweise
• ein »vernünftiges« Verhalten im Fehlerfall (Robustheit),
• eine akzeptable Wartbarkeit der Software,
• eine einfache Bedienung (falls die Funktion direkt bedienbar ist),
• die leichte Übertragbarkeit des Programms auf einen anderen Rechner.
Der Anteil solcher nichtfunktionaler Anforderungen wird umso höher, je umfangreicher die betrachtete Software oder Software-Komponente ist. Bei einem komplexen Software-System kann man in aller Regel zunächst keine einzige Funktion formal angeben, sondern hat nur recht vage Vorstellungen von den Leistungen, die das System erbringen soll.
In den letzten Jahren wird wieder mehr über die formalen Techniken nachgedacht und gesprochen. So ist OCL (Object Constraint Language, eine Sprache zur Formulierung logischer Zusammenhänge) in UML (Rumbaugh, Jacobson, Booch, 2004) aufgenommen worden. Allerdings ist vorerst unklar, welche Unterstützung dafür zukünftige Werkzeuge bieten werden. Bislang ist sie mager und vor allem nicht standardisiert. Jean-Raymond Abrial, Schöpfer der Spezifikationssprache Z, behauptet unter dem mutigen Titel »Faultless Systems: Yes we Can!« (Abrial, 2009), die Ära des formalen Vorgehens sei bereits angebrochen. Aber er löst das Versprechen nicht ein, sondern beklagt, dass die Entwickler falsch ausgebildet seien; das war schon vor dreißig Jahren ganz ähnlich zu hören. Vielleicht müssen sich die Forscher, frei nach Brecht, andere Entwickler suchen.
Ivar Jacobson, Bertrand Meyer und Richard Soley, bekannte Vordenker des Software Engineerings, haben 2009 das Projekt SEMAT ausgerufen (Software Engineering Methods and Tools, siehe SEMAT, o.J.). Sie stellen fest, dass eine solide, allgemein anerkannte theoretische Grundlage fehlt. Das wollen sie ändern. Bislang sind aber nur Ziele formuliert, sodass die Chancen nicht zu beurteilen sind. Die Erfahrungen der letzten vierzig Jahre machen aber nicht viel Hoffnung. Allzu oft haben wir gehört, dass der Durchbruch kurz bevorstehe. Darum mahnt Parnas (2010) einen Neubeginn an: »We must question the assumptions underlying the well-known current formal software development methods to see why they have not been widely adopted and what should be changed.«
Wir behandeln das Thema nicht weiter; wer sich dafür interessiert, wird eine große, aber unübersichtliche Menge von Literatur finden. Einen knappen, wenn auch nicht ganz aktuellen Zugang bietet die »NASA Langley Formal Methods Site« (NASA, 2002; Link »Philosophy«). Auch die englische Wikipedia-Seite »formal methods« ist als Einstieg geeignet.
Zwei Cartoons auf den NASA-Seiten nehmen das Sektierertum in der formalen Szene und die geringe Akzeptanz aufs Korn: Ein Mann mit rauchendem Colt sagt zu zwei anderen (der vierte liegt tot am Boden): »Ihr seid meine Zeugen. Der Kerl hat doch wirklich behauptet, dass die ZFC Mengenlehre der Typtheorie überlegen sei!« Das Bild eines Ladens, der »Zitteraal im Brötchen« (electric eel) anbietet, hat die Unterschrift: »Das einzige, was noch schwerer zu verkaufen ist als formale Methoden«.
Alle Ingenieure stellen Entwürfe, die noch Unklarheiten und Lücken enthalten, durch Skizzen dar. Im Software Engineering wurde dieses Konzept (siehe Abschnitt 1.7.5) in den Siebzigerjahren für die Darstellung der Spezifikation übernommen, noch bevor die technischen Voraussetzungen bestanden, um die Grafiken komfortabel am Bildschirm bearbeiten und ausgeben zu können; es kann im Rückblick nicht überraschen, dass die Arbeit mit Bleistift und sehr vielen Radiergummis die Akzeptanz der grafischen Notationen nicht gefördert hat. Der Pionier auf diesem Gebiet war Douglas Ross. Seine »Structured Analysis and Design Technique« (SADT; Ross, 1977) wurde enthusiastisch begrüßt, denn sie stellte in einer Software-Welt, in der es praktisch nur Informationen in Textform gab, eine Revolution dar. Dass SADT keinen anhaltenden Erfolg hatte, dafür gab es mehrere Gründe; alle später entstandenen Notationen, allen voran »Structured Analysis« (DeMarco, 1978), beruhten aber auf den Konzepten aus SADT. Structured Analysis war bis zum Aufkommen der objektorientierten Programmierung weltweit sehr populär und wurde durch viele Werkzeuge unterstützt.
Heute versieht man alle Notationen, in denen die Datenflüsse dominieren, mit dem Etikett »strukturiert« (weil dieses Wort in den Namen vorkommt); seit Anfang der Neunzigerjahre steht ihnen eine wachsende Zahl von Notationen für die »objektorientierte Analyse« gegenüber. Zu Beginn des 21. Jahrhunderts sind die meisten dieser Notationen vergessen, weil sie durch UML-Notationen verdrängt wurden. UML bietet eine Reihe von Notationen, die in der Analyse verwendet werden können, insbesondere die Anwendungsfalldiagramme; massiv unterstützt wird jedoch erst der Entwurf.
Ein guter Überblick über Notationen und Methoden des Requirements Engineerings ist in Partsch (1998) zu finden.
Wegen der oben beschriebenen Probleme mit formalen und grafischen Spezifikationen sind Texte meist das beste oder einzige Mittel zur Kommunikation mit den Klienten. Wie kann man die Nachteile der Verwendung natürlicher Sprachen vermindern oder beseitigen?
In der natürlichen Sprache gibt es eine ganze Reihe von Wörtern und Formulierungen, die keine konkrete Bedeutung haben (vgl. Abschnitt 5.5 in Deininger et al., 2005). Wenn man Wörter wie »sehr«, »meistens« oder »im Allgemeinen« verbietet, ebenso Formulierungen im Passiv oder Konjunktive wie »könnte«, hat man bereits einige Probleme vermieden. Ebenso kann man Textstellen erkennen, die höchstwahrscheinlich Unklarheiten erzeugen, beispielsweise das Wort »alle«.
Die Firma SOPHIST hat ein Regelwerk entwickelt, das diese Probleme angeht (Kap. 6 in Rupp et al., 2009). Tabelle 16–3 zeigt einige besonders wichtige Regeln. Dabei geht es immer darum, Lücken und Unschärfen zu vermeiden und deutlich zu machen, wer wann was tut.
|
Regel |
Erläuterung, Beispiel |
R1 |
Formulieren Sie jede Anforderung im Aktiv. |
Der Akteur wird angegeben, und es wird sichtbar, ob das System oder der Benutzer etwas tut. Fordert man, dass etwas »gelöscht wird«, so bleibt das unklar. |
R2 |
Drücken Sie Prozesse durch Vollverben aus. |
Vollverben (wie »liest«, »erzeugt«, nicht »ist«, »hat«) verlangen weitere Informationen (Objekte, Ergänzungen), die den Prozess genauer beschreiben. Nicht: »Wenn die Daten konsistent sind«, sondern »Wenn Programm ABC die Konsistenz der Daten geprüft hat«. Und natürlich muss auch spezifiziert sein, was geschehen soll, wenn sie nicht konsistent sind (R4). |
R3 |
Entdecken Sie unvollständig spezifizierte Prozesswörter (Verben). |
Fehlen Angaben (Objekte), dann wird nach diesen Angaben gesucht, um vollständige Aussagen zu erhalten. Wenn eine Komponente einen Fehler meldet, fragt sich, wem. |
R4 |
Ermitteln Sie unvollständig spezifizierte Bedingungen. |
Für Bedingungen der Form »Wenn-dann-sonst« müssen sowohl der Dann- als auch der Sonst-Fall beschrieben sein (vgl. das Beispiel für R2). |
R5 |
Bestimmen Sie die Universalquantoren. |
Sind Sätze mit »nie«, »immer«, »jedes«, »kein«, »alle« wirklich universell gültig, oder gibt es Einschränkungen? Sind »alle Personen« wirklich alle Personen, oder nur die Anwesenden, die Mitarbeiter, die Besitzer einer Eintrittskarte? |
R6 |
Überprüfen Sie Nominalisierungen. |
Nomen (z. B. »Generierung«, »Datenverlust«) weisen oft auf einen komplexen Prozess hin, der beschrieben werden muss. Verwendet man das Substantiv »Anmeldung«, dann fehlen meist die Ergänzungen, die beim Verb »anmelden« erwartet werden: Wer meldet sich wo und wofür an? |
R7 |
Erkennen und präzisieren Sie unbestimmte Substantive. |
Oft bleibt unklar, ob es sich um einen generischen Begriff oder um ein bestimmtes Objekt handelt. Ist vom »Bediener« die Rede, so fragt es sich, ob es nur einen gibt oder welcher gemeint ist. Ähnliches gilt für viele Begriffe (Gerät, Meldung). |
R8 |
Klären Sie die Zuständigkeiten bei Möglichkeiten und Notwendigkeiten. |
Ein Zwang muss realisiert werden. Steht in einer Anforderung, dass etwas möglich oder unmöglich ist, passieren kann, darf oder muss, so ist zu klären, wer dies erzwingt oder verhindert. |
R9 |
Erkennen Sie implizite Annahmen. |
Begriffe in den Anforderungen (»die Firewall«), die nicht erläutert sind, deuten oft auf implizite Annahmen (hier vermutlich auf die, dass es eine Firewall gibt). |
Tab. 16–3 Regeln für natürlichsprachliche Anforderungen (frei nach Rupp et al., 2009)
Natürlich ist generell jedes Wort daraufhin zu prüfen, ob seine Bedeutung klar ist. Selbst bei scheinbar einfachen Wörtern wie »soll« oder »kann« gehen die Meinungen weit auseinander: Ist das, was realisiert werden soll, nun gefordert, gewünscht oder freigestellt? Eine eindeutige Festlegung, die dann auch konsequent beachtet wird, verhindert viele Missverständnisse (siehe unten: Sprachschablonen).
Betrachten wir ein Beispiel: »Es soll geprüft werden, dass neben Autor und Titel des Dokuments auch immer der Aufbewahrungsort eingegeben wird.«
Untersuchen wir diese Anforderung, dann können, von der Frage zum Wort »soll« abgesehen, folgende Regeln angewendet werden:
|
R1: |
Die Anforderung ist im Passiv formuliert (»... soll geprüft werden«, »... eingegeben wird«), die Akteure fehlen. |
|
R7: |
Es muss klar sein, welcher Autor gemeint ist. Es könnte auch mehrere geben. Ähnliche Fragen gibt es zum Aufbewahrungsort. |
|
R3: |
Die Prozesswörter (»prüfen« und »eingeben«) sind unvollständig spezifiziert. Wer prüft wann, wer gibt wann etwas ein? |
|
R4: |
In der Anforderung steckt eine unvollständig spezifizierte Bedingung. Was soll geschehen, wenn der Aufbewahrungsort nicht eingegeben wurde? |
|
R5: |
Es muss nachgefragt werden, ob der angegebene Sachverhalt auch wirklich immer gelten soll. |
Eine verbesserte Fassung dieser Anforderung, die die Ergebnisse der sprachlichen Analyse berücksichtigt, könnte etwa so aussehen:
»Nachdem der Administrator den Dokument-Datensatz eingegeben hat, prüft das System, ob der Datensatz neben dem (einzigen oder ersten) Autor und dem Titel auch den Aufbewahrungsort enthält. Sonst erzeugt das System eine Fehlermeldung und lässt den Dokument-Datensatz unverändert.«
Diese Vorgehensweise, das Regelwerk und die Hinweise, wie man es anwendet, sind in Rupp et al. (2009) ausführlich beschrieben. Die Erfahrungen mit diesem Verfahren sind sehr positiv; wer schon einmal übliche, also vage und unvollständige Spezifikationen gelesen hat, sieht die klaren Vorteile.
Die Möglichkeiten der natürlichsprachlichen Spezifikation sind bei weitem nicht ausgeschöpft. Ralf Melchisedech (2000) hat sich in seiner Dissertation mit diesem Thema auseinandergesetzt und eine Werkzeugunterstützung entworfen. Auf dem Markt sind solche Werkzeuge auch zehn Jahre später noch nicht.
Ein konstruktiver Ansatz ist die Verwendung von Sprachschablonen: Die Spezifikation wird in einer sehr eingeschränkten natürlichen Sprache verfasst. Dadurch ist eine Kommunikation ohne Missverständnisse zwar nicht garantiert, aber wahrscheinlicher geworden. Wir alle kennen dieses Prinzip aus Gesetzen und anderen Regelwerken, beginnend mit den zehn Geboten (»Du sollst ...«). Solche Schablonen führen zwar zu einer sehr eintönigen Spezifikation, die von literarischer Qualität noch weiter entfernt ist als andere technische Texte. Dafür ist der Sinn der Aussagen klar definiert.
Die SOPHISTen geben dafür eine Art Grammatik an, die im Kern als Bauplan aller Anforderungen das Schema A B C D E F vorgibt:
|
A |
klärt, wann und unter welchen Bedingungen die Aktivität stattfindet. |
|
B |
ist MUSS (Pflicht), SOLL (Wunsch) oder WIRD (Absicht). |
|
C |
ist immer »das System« oder eine konkrete Nennung des Systems. |
|
D |
ist eine von drei Möglichkeiten: Die erste beschreibt eine selbständige Systemaktivität (»tut«), die zweite eine vom System angebotene Funktion (»bietet jemandem die Möglichkeit, zu tun«), die dritte die Inanspruchnahme einer von Dritten angebotenen Funktion (»ist fähig zu tun, wenn bestimmte Voraussetzungen gegeben sind«). |
|
E |
enthält Ergänzungen, insbesondere ein Objekt. |
|
F |
ist das eigentliche Prozesswort (was passiert). |
Zusammen kann das beispielsweise so aussehen:
Nach Ende der Bürozeiten (=A) soll (=B) das System (=C) dem Operator die Möglichkeit bieten (=D), alle neuen Anmeldungen auf einem externen Datenträger (=E) zu sichern (=F).
Bei einem automatischen Backup fiele Teil D (und das Wort »zu«) weg. Natürlich ist zu prüfen, ob im Satz noch implizite Annahmen stecken; beispielsweise scheint es definierte Bürozeiten zu geben. Ebenso ist der Allquantor »alle« zu prüfen. In Rupp et al. (2009), Kap. 7, wird dieser Ansatz detailliert beschrieben.
Wenn Programmierer ohne entsprechende Ausbildung eine Spezifikation verfassen, kommt dabei meist ein schlecht getarnter Entwurf heraus. Denn sie sind daran gewöhnt, in Lösungen zu denken, sie tun sich mit der Formulierung ursprünglicher, noch nicht in Lösungen umgesetzter Anforderungen sehr schwer.
Eine solche »Spezifikation« hat aber erhebliche Nachteile. Einerseits werden die echten Anforderungen nicht dokumentiert, und später lässt sich nicht mehr feststellen, was der Klient wirklich wollte. Andererseits werden dem Entwurf Fesseln angelegt, indem Entscheidungen vorzeitig und von den falschen Leuten getroffen werden. Ein Vergleich soll das anschaulich machen: Der Kunde eines Transportunternehmens möchte von A nach B befördert werden. Sein Gesprächspartner, ein Taxifahrer, notiert, dass der Kunde ein Auto braucht, und sucht die schnellste Strecke heraus. Auf diese Weise ist die ursprüngliche Anforderung verloren. Und die optimale Bedienung des Kunden (die womöglich in einer Bahn-, Flug- oder Schiffsreise bestanden hätte) ist wahrscheinlich ausgeschlossen. Wenn später ein neues Verkehrsmittel (eine Magnetschwebebahn) die Strecke bedient, führt das nicht zu einer Revision, weil die Spezifikation ein Auto vorschreibt.
Als in den Siebzigerjahren die frühen Phasen der Software-Entwicklung zum Gegenstand der Forschung wurden, bestand darum Konsens über die Regel, dass die Spezifikation aussagen soll, was das System leistet, und dass sie nicht aussagen soll, wie diese Leistung erbracht wird: »What, not how!«, lautete das Motto. Wer ein Programm zur Ermittlung der Nullstellen einer Funktion spezifiziert, sollte eine bestimmte Genauigkeit der Resultate und auch eine Grenze für die Rechenzeit angeben, aber nicht das konkrete Rechenverfahren.
Diese Trennung lässt sich, wie die weitere Forschung gezeigt hat, nicht konsequent durchhalten (siehe Abschnitt 16.5.3). Trotzdem bleibt die Forderung, dass die Spezifikation möglichst neutral, also nicht einschränkend für die Implementierung sein sollte, sinnvoll. Wir lassen uns zunächst davon leiten, welche Forderungen an das zu erstellende System von außen, d. h. an den Schnittstellen, erhoben werden.
Forderungen können entweder die Funktionalität oder die Qualität betreffen; diese Unterscheidung führt, wie in Abschnitt 16.4.4 beschrieben, zur Trennung der funktionalen Anforderungen von den nichtfunktionalen.
Die Funktion einer Software ist die in der Zeit ablaufende Transformation von Eingabedaten im allgemeinen Sinne, d. h. von Daten, die bereits im Speicher stehen oder eingelesen werden, in Ausgabedaten im allgemeinen Sinne, d. h. in Daten, die wieder im Speicher stehen oder ausgegeben werden. Dazu stehen Betriebsmittel in bestimmter Art und begrenzter Menge zur Verfügung. Die Funktionsbeschreibung sagt also aus,
wann welche Daten benötigt werden,
wann welche Daten erzeugt werden,
welche Mittel in welcher Menge dazu beansprucht werden.
Ist der Zeitpunkt der Ausführung oder die zeitliche Ordnung der Ausgabe irrelevant, so wird der Zeitaspekt auf die Reihenfolge beschränkt oder ganz weggelassen. Dabei wird unterstellt, dass die Effizienz insgesamt ausreicht. Beispielsweise sind die Ansteuerung eines Uhrwerks und die Auslösung eines Alarms zeitkritisch. Dagegen scheint die Antwort eines Auskunftssystems ebenso wenig wie die Archivierung von Buchungsvorgängen in einer Bank einer Zeitvorgabe zu bedürfen. Sie wegzulassen, ist aber in jedem Fall gefährlich. Denn eine Auskunft, die erst nach Minuten oder gar Stunden gegeben wird, ist nicht viel wert, und eine Archivierung, die zu langsam ist, um mit den Buchungen Schritt zu halten, kann nicht funktionieren. Darum sollte man auf keinen Fall darauf verzichten, Aussagen zur Zeit und zur Geschwindigkeit zu machen. Ähnliches gilt auch für andere Betriebsmittel, vor allem für den Speicher- und Prozessorbedarf sowie für die Bandbreite der benötigten Kommunikationswege.
Die Daten, um die es bei einem Software-System letztlich geht, sind die Ausgaben des Systems. Die Eingaben sind erforderlich, um die Ausgaben zu erzeugen, sie sind kein Selbstzweck. Wenn eine Eingabe nicht zur Erzeugung der Ausgabe benötigt wird, sollten wir sie auch nicht spezifizieren. Wir gehen also grundsätzlich von den Daten aus, die unser System liefern soll. Natürlich schließt hier der Begriff der Daten alle Außenwirkungen des Systems ein.
Es lag daher für die Schöpfer von Spezifikationssprachen nahe, die Kommunikation zwischen dem System und seiner Umgebung an den Anfang der Überlegungen zu stellen, beispielsweise im Context Diagram von Structured Analysis (DeMarco, 1978) und in den Use-Case-Diagrammen in UML (z. B. Rupp et al., 2005), wobei auch, wie bei SADT (Ross, 1985), der Betriebsmittelbedarf erfasst werden kann. Im Jackson System Development (JSD, Cameron, 1986) wird die Kommunikation in der zweiten, der sogenannten Vernetzungsphase, beschrieben. Zuvor werden (in der Modellierungsphase) die Begriffe der realen Welt ganz ohne Bezug zu einer Informatik-Lösung beschrieben.
Unabhängig von speziellen Verfahren können wir festhalten: Eine genaue Übersicht der Daten, die aus dem System kommen oder in das System fließen, mit ihren logischen Zusammenhängen ist der Kern jeder Spezifikation.
Ist eine Software realisiert und im Einsatz, dann gibt es darin sowohl Komponenten, die die Funktionalität im oben beschriebenen Sinne realisieren, als auch Hilfsfunktionen; diese organisieren die Software und behandeln Probleme, die nicht der Aufgabe, sondern der Lösung zuzuordnen sind. Im Beispiel der Lagerverwaltung (Abschnitt 16.7.4) gehört die Erstellung einer Lagerbestandsliste zur primären Funktionalität. Dagegen ist die Datensicherung, die in kurzen Abständen oder laufend erfolgt, keine primäre Funktion. Wenn uns ideale Technologie zur Verfügung stünde, gäbe es keine defekten Festplatten und generell keine Fehler der Hard- oder Software, auch keine Beschränkungen der Speicher- oder Prozessorkapazität und damit keinen Grund, über die Effizienz der Lösung nachzudenken. Darum ist es sinnvoll, die Anforderungen zunächst unter der Annahme idealer Technologie zu erfassen, denn das sind die wirklichen Wünsche der Klienten. Erst danach werden die Nebenbedingungen einbezogen, die durch die reale Technologie entstehen; diese Anforderungen können sich durch technische Innovationen ändern. Sowohl die »Essenzielle Analyse« (McMenamin, Palmer, 1984), eine Weiterentwicklung von Structured Analysis, als auch das oben erwähnte JSD beruhen auf diesem klugen Konzept.
Mit Anwendungsfällen werden funktionale Anforderungen an ein System aus der Außensicht formuliert. Anwendungsfälle wurden von Ivar Jacobson als Teil der Methode OOSE (Object Oriented Software Engineering) eingeführt. Seither hat sich dieser Ansatz in der Praxis bewährt (Weidmann, Hoffmann, Lichter, 2009). Jacobson et al. definieren den Begriff Anwendungsfall (Use Case) wie folgt:
use case — A sequence of interactions between an actor (or actors) and a system triggered by a specific actor, which produces a result for an actor.
Jacobson et al. (1992)
Diese Definition nennt einige der wesentlichen Merkmale eines Anwendungsfalls:
An einem Anwendungsfall ist neben dem System immer wenigstens ein Akteur (actor) beteiligt. Ein Akteur ist eine Rolle, die ein Benutzer oder ein externes System im Umgang mit dem zu spezifizierenden System einnimmt. Akteure gehören selbst nicht zum System, sie stehen außerhalb der Systemgrenze und interagieren mit dem System.
Ein Anwendungsfall wird durch ein spezielles Ereignis angestoßen, das ein Akteur, der Hauptakteur, auslöst. Dieses Ereignis wird auch Trigger genannt.
Ein Anwendungsfall ist immer zielorientiert, d. h., der Hauptakteur möchte ein bestimmtes Ziel erreichen.
Ein Anwendungsfall beschreibt alle Interaktionen zwischen dem System und den beteiligten Akteuren, die notwendig sind, um das angestrebte Ziel zu erreichen (oder schließlich zu verfehlen).
Ein Anwendungsfall endet, wenn das angestrebte Ziel erreicht ist oder wenn klar ist, dass es nicht erreicht werden kann.
Anwendungsfälle beschreiben die Leistungen und Interaktionen des Systems aus der Außensicht. Jeder Anwendungsfall muss das Systemverhalten für eine konkrete Situation vollständig spezifizieren. Dazu gehören auch alle Ausnahmefälle und die Reaktionen, wenn das angestrebte Ziel nicht erreicht werden kann.
Anwendungsfälle werden grundsätzlich in natürlicher Sprache, häufig aber in einer strukturierten Form notiert. Dazu gibt es eine Reihe von Vorlagen (Cockburn, 1996; Cockburn, 2001). Im folgenden Beispiel betrachten wir einen kleinen Ausschnitt aus der Spezifikation einer neuen Baureihe von Bankautomaten (BA42 genannt). Der in Abbildung 16–6 formulierte Anwendungsfall spezifiziert, wie ein Kunde, der Hauptakteur, mit einem BA42 interagiert, um sich zu authentifizieren (seine Identität nachzuweisen).
Authentifizieren |
||
Ziel |
Der Kunde möchte Zugang zu einem Bankautomaten BA42 erhalten |
|
Vorbedingung |
– Der Automat ist in Betrieb, die Willkommen-Botschaft wird angezeigt – Karte und PIN des Kunden sind verfügbar |
|
Nachbedingung |
– Der Kunde wurde akzeptiert – Die Leistungen des BA42 stehen dem Kunden zur Verfügung |
|
Nachbedingung im Sonderfall |
Der Zugang wird verweigert, die Karte wird entweder zurückgegeben oder einbehalten, die Willkommen-Botschaft wird angezeigt |
|
Akteure |
Kunde (Hauptakteur), Banksystem |
|
Normalablauf |
1. Der Kunde führt eine Karte ein 2. Der BA42 liest d. Karte und sendet d. Daten z. Prüfung ans Banksystem 3. Das Banksystem prüft, ob die Karte gültig ist 4. Der BA42 zeigt die Aufforderung zur PIN-Eingabe 5. Der Kunde gibt die PIN ein 6. Der BA42 liest die PIN und sendet sie zur Prüfung an das Banksystem 7. Das Banksystem prüft die PIN 8. Der BA42 akzeptiert den Kunden und zeigt das Hauptmenü |
|
Sonderfall |
2a |
Die Karte kann nicht gelesen werden 2a.1 Der BA42 zeigt die Meldung »Karte nicht lesbar« (4 s) 2a.2 Der BA42 gibt die Karte zurück 2a.3 Der BA42 zeigt die Willkommen-Botschaft |
Sonderfall |
2b |
Die Karte ist lesbar, aber keine BA42-Karte 2b.1 Der BA42 zeigt die Meldung »Karte nicht akzeptiert« (4 s) 2b.2 Der BA42 gibt die Karte zurück 2b.3 Der BA42 zeigt die Willkommen-Botschaft |
Sonderfall |
2c |
Das Banksystem ist nicht erreichbar 2c.1 Der BA42 zeigt die Meldung »Banksystem nicht erreichbar« (4 s) 2c.2 Der BA42 gibt die Karte zurück 2c.3 Der BA42 zeigt die Willkommen-Botschaft |
Sonderfall |
3a |
Die Karte ist nicht gültig oder gesperrt 3a.1 Der BA42 zeigt die Meldung »Karte ungültig oder gesperrt« (4 s) 3a.2 Der BA42 zeigt die Meldung »Karte wird eingezogen« (5 s) 3a.3 Der BA42 behält die Karte ein 3a.4 Der BA42 zeigt die Willkommen-Botschaft |
Sonderfall |
5a |
Der Kunde bricht den Vorgang ab 5a.1 Der BA42 zeigt die Meldung »Vorgang wird abgebrochen« (2 s) 5a.2 Der BA42 gibt die Karte zurück 5a.3 Der BA42 zeigt die Willkommen-Botschaft |
Sonderfall |
5b |
Der Kunde reagiert nach 5 Sekunden nicht 5b.1 Der BA42 zeigt die Meldung »Keine Aktivität, Abbruch« (2 s) 5b.2 Der BA42 gibt die Karte zurück 5b.3 Der BA42 zeigt die Willkommen-Botschaft |
Sonderfall |
6a |
Das Banksystem ist nicht erreichbar → Schritt 2c.1 |
Sonderfall |
7a |
Die erste oder zweite eingegebene PIN ist falsch 7a.1 Der BA42 zeigt die Meldung »Falsche PIN« (4 s) → Schritt 4 |
Sonderfall |
7b |
Die dritte eingegebene PIN ist falsch 7b.1 Der BA42 zeigt die Meldung »PIN dreimal falsch« (5 s) → Schritt 3a.2 |
Abb. 16–6 Anwendungsfall (Use Case) für die Authentifizierung am Bankautomaten BA42
Das Muster verlangt, dass neben den Schritten der Interaktion auch allgemeine Informationen zum Anwendungsfall angegeben werden. So müssen beispielsweise das angestrebte Ziel, die beteiligten Akteure und die Vor- und Nachbedingungen spezifiziert werden. Ferner trennt das Muster optisch klar die Interaktionen des Normalablaufs, der zum angestrebten Ziel führt, von der Spezifikation davon abweichender Sonderfälle. Das Beispiel zeigt auch, dass für jeden einzelnen Interaktionsschritt deutlich zum Ausdruck kommen soll, wer, Akteur oder System, agiert, also den Schritt ausführt.
Die Anwendungsfälle für ein System werden nach fachlichen Gesichtspunkten strukturiert, miteinander in Beziehung gesetzt und gruppiert. Mit den Use-Case-Diagrammen bietet UML nicht nur eine grafische Darstellung für die Anwendungsfälle, die Akteure und ihre Beziehungen, sondern auch Möglichkeiten zur Verkürzung und Verdichtung. Folgende Beziehungsarten werden angeboten:
Die Generalisierungsbeziehung zwischen Anwendungsfällen dient zur Abstraktion. Sie erlaubt es, abstrakte Anwendungsfälle zu formulieren, aus denen konkrete Anwendungsfälle abgeleitet werden können. Beispielsweise kann man die Einrichtung verschiedener Konten (Girokonten, Sparkonten, Wertpapierdepots) in einem abstrakten Anwendungsfall »Konto einrichten« zusammenfassen, der dann entsprechend spezialisiert wird. Auch für Akteure kann es einen generalisierten Akteur geben; der spezielle Akteur ist implizit an allen Anwendungsfällen beteiligt, in denen seine Generalisierung auftritt. Das ist oft praktisch, um die Gemeinsamkeiten verschiedener Personengruppen zu beschreiben (z. B. Kunde und Mitarbeiter).
Die Benutzt-Beziehung (include) zwischen zwei Anwendungsfällen kann mit einem Prozeduraufruf verglichen werden: Der benutzte Anwendungsfall wird im aufrufenden Anwendungsfall ausgeführt.
Die Erweitert-Beziehung (extend) zwischen zwei Anwendungsfällen bedeutet, dass ein Anwendungsfall an einer definierten Stelle (Erweiterungspunkt) im anderen Anwendungsfall ausgeführt wird, wenn eine dazu definierte Bedingung erfüllt ist.
Aus fachlicher Sicht hat es sich bewährt, bei den Anwendungsfällen zwischen Hauptfunktionen und Basisfunktionen zu unterscheiden. Anwendungsfälle, die Hauptfunktionen spezifizieren, beschreiben die geforderte fachliche Funktionalität des Systems. Ein Anwendungsfall, der eine Basisfunktion beschreibt, wird typischerweise in Hauptfunktionen verwendet und liefert dort einen Beitrag zur Funktionalität.
Abbildung 16–7 zeigt einen Ausschnitt der Anwendungsfälle für einen Bankautomaten BA42 als Use-Case-Diagramm. Die Akteure – Kunde und Banksystem – stehen außerhalb des modellierten Systems. Die Anwendungsfälle sind als Pakete gruppiert und durch Beziehungen der Arten include und extend miteinander verknüpft. »Kontostand abfragen«, »Auszug drucken«, »Geld beziehen« und »Dauerauftrag einrichten« spezifizieren Hauptfunktionen. Der Anwendungsfall »Authentifizieren« beschreibt eine Basisfunktion. Er wird in jeder Hauptfunktion verwendet; darum ist er durch eine include-Beziehung eingebunden. Eine Ausnahme bildet der Anwendungsfall »Auszug drucken«, weil dieser nicht nur direkt in Anspruch genommen werden kann, sondern (über den Erweiterungspunkt »Auszug drucken«) auch aus dem Anwendungsfall »Kontostand abfragen«.
Abb. 16–7 Beispiel eines UML-Use-Case-Diagramms
In diesem Fall soll aber keine zweite Authentifizierung verlangt werden. Daher wird »Authentifizieren« nur bei Bedarf in den Anwendungsfall »Auszug drucken« eingebunden. Dies modelliert die extend-Beziehung mit dem Erweiterungspunkt »nicht authentifiziert«.
Wir fassen zu den Anwendungsfällen und Use-Case-Diagrammen zusammen:
Use-Case-Diagramme geben einen guten Überblick über alle Anwendungsfälle und ihre Beziehungen, ersetzen aber in keinem Fall die detaillierten Beschreibungen der Anwendungsfälle. Beide Darstellungen sind notwendig.
Die Anwendungsfälle werden identifiziert, modelliert, formuliert und geprüft. Das geschieht nicht in einem einzigen Schritt, sondern iterativ. In Tabelle 16–4 sind wesentliche Aktivitäten dieses Prozesses aufgelistet. Sie basiert auf dem in Ryser (2003) beschriebenen Vorgehen.
Anmerkungen |
|
Bestimme alle Akteure und alle Ein- und Ausgaben |
Dazu sind die folgenden Fragen hilfreich: – Welche äußeren Ereignisse gibt es? – Wer nutzt oder verwaltet das System? – Wer liefert Eingaben? – Wer verwendet die Ausgaben und Resultate? |
Lege die Systemgrenzen fest |
Die Systemgrenzen definieren, welche Komponenten und Funktionen zum System gehören und welche nicht. |
Identifiziere und formuliere die Anwendungsfälle der Hauptfunktionen |
Die Anwendungsfälle der identifizierten Hauptfunktionen werden grob formuliert. Es muss sichergestellt werden, dass die Anwendungsfälle die Funktionalität vollständig abdecken. |
Strukturiere die Anwendungsfälle und die Akteure |
Die Beziehungen zwischen Akteuren und Anwendungsfällen sowie zwischen den Anwendungsfällen selbst werden identifiziert. Die Anwendungsfälle werden, wenn sinnvoll, in Pakete gruppiert. |
Beschreibe den Normalablauf der Anwendungsfälle |
Der Normalablauf, also der Weg zum angestrebten Ziel des Hauptakteurs, sollte zuerst formuliert werden. |
Beschreibe alle Sonderfälle und Alternativabläufe |
Es ist zu klären, welche Sonderfälle und welche Alternativabläufe auftreten können und wie diese vom Normalablauf abweichen. |
Extrahiere gleiche Interaktionssequenzen |
Gleiche Interaktionssequenzen können als Basisfunktionen definiert und an mehreren Stellen verwendet werden. Mit Hilfe der Generalisierungsbeziehung können Abläufe generisch spezifiziert, dann spezialisiert und wiederverwendet werden. |
Prüfe zusammen mit dem Klienten die Anwendungsfälle |
Die Anwendungsfälle werden vom Klienten in Reviews geprüft und, nachdem alle Korrekturen und Verbesserungen eingearbeitet sind, freigegeben. |
Tab. 16–4 Aktivitäten bei der Erstellung von Anwendungsfällen
Anwendungsfälle können nur in enger Zusammenarbeit mit dem Klienten erstellt werden. Sie helfen besonders dabei, die Ist- und Soll-Abläufe des zu erstellenden Systems mit den Fachleuten der Anwendung abzustimmen.
Die Entwickler lernen bei der Erstellung der Anwendungsfälle die Fachsprache und die Anwendungswelt kennen und verstehen. Die Fachbegriffe werden in das Begriffslexikon aufgenommen.
Anwendungsfälle sind eine gute Grundlage, um Prototypen zu erstellen, Testfälle für den Systemtest zu definieren (siehe Abschnitt 19.5.4) und die Benutzungsdokumentation zu schreiben.
Natürlich sind Anwendungsfälle alleine nicht ausreichend, um Anforderungen vollständig und präzise zu formulieren. So kann beispielsweise nicht modelliert werden, dass das System selbst eine Interaktion anstößt. (In unserem Beispiel sollte der Bankautomat die Karte zurückgeben oder einziehen, wenn der Kunde eine gewisse Zeit nicht aktiv war.) Dazu müssten sogenannte interne Akteure modellierbar sein (Nyßen, 2009). Glinz (2000) hat sich intensiv mit UML als Spezifikationssprache auseinandergesetzt und wesentliche Defizite identifiziert.
Vor allem in der Grundausbildung der Informatiker wird oft der Eindruck erweckt, als seien alle Verfahren und Algorithmen beliebig skalierbar. So, wie man in einer Liste mit hundert Einträgen einen bestimmten Namen durch lineare Suche lokalisiert, geht das auch bei hunderttausend Einträgen.
Formal ist das richtig, praktisch aber falsch. Jede Lösung, sei es eine Datenstruktur oder ein Algorithmus, hat ein bestimmtes Einsatzspektrum, auch hinsichtlich der Problemgröße. Wer nur wenige Werte sortieren muss, ist mit einem Bubble Sort gut bedient, wer die Einwohner Chinas verwaltet, sollte andere Sortierverfahren verwenden. Gerade wenn viele Daten zu verwalten sind, wird man eine kompakte Darstellung der Daten anstreben und die Schlüssel nicht länger machen, als für die Höchstzahl der Datensätze erforderlich ist. Darum ist das Mengengerüst, die Angabe der Mengen und Größen, die für die Software Bedeutung haben, ein wesentlicher Bestandteil der Spezifikation.
So ist das »Jahr-2000-Problem«, also die Untauglichkeit vieler Programme, Jahreszahlen größer 2000 zu verarbeiten, mindestens zum Teil dadurch entstanden, dass entsprechende Vorgaben in den Spezifikationen fehlten. Die Entwickler der Siebziger- und auch noch der Achtzigerjahre haben stillschweigend unterstellt, dass die Jahreszahl niemals größer als 1999 werden könne.
Die Leistungsmerkmale eines Systems können ebenfalls dem Mengengerüst zugeschlagen werden. Betrachten wir als Beispiel ein Depot, in dem viele Objekte, die durch eine Nummer und eine Bezeichnung identifiziert sind, einzeln gelagert sind. Der aktuelle Lagerbestand wird auf einem Bildschirm angezeigt. Im Mengengerüst sollten folgende Angaben definiert sein:
Zahl der Lagerplätze
Länge der Artikelnummern
Länge der Artikelbezeichnungen
Zahl gleicher Objekte
Veränderungsrate (bewegte Objekte pro Stunde)
Dauer bis zur Aktualisierung der Anzeige
Alle Angaben definieren die Obergrenzen; eventuell sind aber auch Untergrenzen von Bedeutung, beispielsweise bei der Zahl der mindestens verfügbaren freien Lagerplätze. Manchmal reicht auch eine einzige Grenze nicht aus, wenn beispielsweise das System für kurze Zeit mehr Veränderungen als im Dauerbetrieb verkraften muss.
Viele Autoren ordnen die Leistungsmerkmale eines Systems (Antwortzeiten, Speicherbedarf usw.) den nichtfunktionalen Anforderungen zu; wir sehen sie im Sinne des Betriebsmittelbedarfs als einen Aspekt der Funktionalität.
Wie bei anderen Software-Dokumenten ist es auch für die Spezifikation zweckmäßig, eine Standardstruktur zu verwenden. Dazu kann man entweder eine der verfügbaren Vorlagen verwenden oder sich an einer Norm orientieren. Zwei Quellen bieten erprobte Vorlagen für die Spezifikation:
Robertson und Robertson (1999) bieten eine Vorlage für die Spezifikation an. Sie ist im praktischen Einsatz gereift und unter Volere (o.J.) erhältlich.
Zum V-Modell XT (siehe Abschnitt 10.3) gibt es Vorlagen, auch für die Darstellung der Anforderungen. Sie können unter V-Modell XT (o.J.) bezogen werden.
Eine bewährte Basis bildet die Norm IEEE Std 830 (1998) (Recommended Practice for Software Requirements Specifications). Sie sieht die in Tabelle 16–5 erläuterten drei Kapitel vor. Die Liste der Anforderungen im Kapitel 3 der Spezifikation muss sinnvoll gegliedert sein, damit sie verwendet und geprüft werden kann. Unabhängig von der gewählten Gliederung muss sie die folgenden Informationen enthalten:
Funktionale Anforderungen
Qualitätsanforderungen
Leistungsanforderungen
Einschränkungen des Entwurfs
Definition der externen Schnittstellen zu anderen Systemen
In der Praxis dient diese Struktur häufig als Grundlage firmenspezifischer Vorlagen. Abbildung 16–8 zeigt ein Beispiel. Darin wurde zwar eine vom IEEE Std 830 abweichende Nummerierung verwendet, die Inhalte wurden aber übernommen. Die einzelnen Anforderungen, die gemäß IEEE Std 830 im Kapitel 3 beschrieben werden, wurden thematisch gruppiert und in dazu neu eingeführten Kapiteln strukturiert.
1.1 |
Zweck |
Beschreibt den Zweck und den Leserkreis der Spezifikation. |
1.2 |
Einsatzbereich und Ziele |
Gibt an, wo X eingesetzt werden soll und welche wesentlichen Funktionen es haben wird. Wo sinnvoll, sollte auch definiert werden, was X nicht leisten wird. Beschreibt die mit X verfolgten Ziele. |
1.3 |
Definitionen |
Dokumentiert alle verwendeten Fachbegriffe und Abkürzungen. (Besser ist ein separates Begriffslexikon, siehe Abschnitt 16.3.) |
1.4 |
Referenzierte Dokumente |
Verzeichnet alle Dokumente, auf die in der Spezifikation verwiesen wird. (Alternative: Liste im Anhang) |
1.5 |
Überblick |
Beschreibt, wie der Rest der Spezifikation aufgebaut ist, insbesondere, wie Kapitel 3 strukturiert ist. |
2. Allgemeine Beschreibung |
||
2.1 |
Einbettung |
Beschreibt, wie X in seine Umgebung eingebettet ist und wie X mit den umgebenden Komponenten und Systemen zusammenspielt. Dazu werden die Schnittstellen, Kommunikationsprotokolle etc. definiert. |
2.2 |
Funktionen |
Skizziert die wichtigsten Funktionen von X. |
2.3 |
Benutzerprofile |
Charakterisiert die Benutzergruppen von X und die Voraussetzungen, die diese jeweils mitbringen (Ausbildung, Know-how, Sprache, ...). |
2.4 |
Einschränkungen |
Dokumentiert Einschränkungen, die die Freiheit der Entwicklung reduzieren (z. B. Prozessmodell, Basis-Software, Ziel-Hardware). |
2.5 |
Annahmen und Abhängigkeiten |
Nennt explizit die Annahmen und externen Voraussetzungen, von denen bei der Spezifikation ausgegangen wurde. |
3. Einzelanforderungen |
||
3.i |
Anforderung i |
Beschreibt die Anforderung i so genau, dass bei der Verwendung der Spezifikation (im Entwurf usw.) keine Rückfragen dazu notwendig sind. |
Tab. 16–5 Struktur der Spezifikation für eine Software X nach IEEE Std 830 (1998)
Abb. 16–8 Beispiel für eine Spezifikationsstruktur auf Basis der IEEE-Norm 830
Es gibt eine ganze Reihe von Normen, die speziell die Analyse und Spezifikation regeln. Aus der IEEE-Normenfamilie ist neben dem schon in Abschnitt 16.8.1 erwähnten Standard IEEE Std 830 (1998) auch der Standard IEEE Std 1233 (1998) zu nennen; von den deutschsprachigen Normen ist die VDI-Richtlinie 2519 Blatt 1 (2001) speziell zu erwähnen.
IEEE Std 1233 (1998) (Guide for Developing System Requirements Specifications) Dieser Standard beschreibt Eigenschaften »gut« formulierter Anforderungen (well-formed requirements). In einem Prozess mit vier Unterprozessen ist beschrieben, wie man Anforderungen identifiziert, spezifiziert, strukturiert und präsentiert. Das Ergebnis wird in der System Requirements Specification festgehalten. Der Anhang des Standards enthält einen Vorschlag für die Struktur dieses Dokuments.
IEEE Std 830 (1998) (Recommended Practice for Software Requirements Specifications)
Dieser speziell für Software-Produkte entwickelte, sehr praxisnahe Standard gibt, wie in Abschnitt 16.8.1 erläutert, eine erprobte Struktur für die Beschreibung von Anforderungen vor. Er definiert Eigenschaften, die eine gute Spezifikation haben sollte, und erinnert daran, dass die Anforderungen in einem systematischen Änderungsprozess kontinuierlich gepflegt werden müssen.
VDI-Richtlinie 2519 Blatt 1 (2001) (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften)
Diese sehr knappe Richtlinie unterscheidet explizit zwischen Lasten- und Pflichtenheft und skizziert deren Inhalt. Sie beschreibt ein Vorgehen, um Lasten- und Pflichtenheft zu erstellen, und nennt eine Reihe von Qualitätskriterien, die ein Pflichtenheft erfüllen soll. Ferner wird eine Checkliste angegeben, mit der man zentrale Aspekte des Pflichtenheftes (z. B. die Beschreibung der Schnittstellen, der systemtechnischen Anforderungen, der Inbetriebnahme) prüfen kann.
Zusammenfassend formulieren wir einige Regeln, die als Leitfaden bei der Analyse und Spezifikation dienen sollen.
1. Ein Begriffslexikon anlegen und entwickeln
Wie wir in Abschnitt 16.3 beschrieben haben, ist das Begriffslexikon eines der wichtigsten Ergebnisse der Analyse. Niemand, der mit einem Begriffslexikon gearbeitet hat, wird darauf verzichten wollen.
Viele Spezifikationen gehen nicht von dem Problem, von der Fragestellung aus, sondern von der Lösung, die sich der Verfasser der Spezifikation vorstellt. Diese Gefahr besteht besonders dann, wenn ein Software-Entwickler spezifiziert (siehe Abschnitt 16.7.1). Entwickler entschuldigen diesen Fehler gern damit, dass ja ohnehin keine andere Lösung in Frage komme. Sie gehen dabei aber regelmäßig von ihren Erfahrungen und von der aktuellen Technologie aus. Wenn Jahre später eine Re-Implementierung ansteht, haben sich die Bedingungen möglicherweise verändert. Dann sollte die Spezifikation eine ganz andere Realisierung nicht verhindern.
Der Spezifizierende sollte sich also immer wieder zurücklehnen und sich fragen, ob die Aussagen, die er gerade formuliert, wirklich notwendig sind.
3. Nach den Daten (Objekten) suchen, nicht die (vermuteten) Programmabläufe beschreiben
Dies ist eine Konkretisierung der Regel 2. Die Daten (oder allgemeiner die Objekte, z. B. auch Interrupts) sind der Aufgabe näher als die Abläufe, durch die die Transformationen realisiert werden (siehe Abschnitt 16.7.2). Denn die Abläufe sind meist nur dadurch bedingt, dass die Programme auf einem einzelnen Prozessor ausgeführt werden. Andere Rechnerarchitekturen führen zu anderen Abläufen. Damit ist der Ablauf ein Merkmal der Implementierung.
4. Die Abstraktionsebene nicht innerhalb derselben Darstellung wechseln
Wenn man ein großes System beschreibt, so ist man in der Regel sehr unsicher und hat Mühe, allgemeine Aussagen zu machen; andererseits gibt es meist »Inseln« im Sumpf, die man sehr gut kennt und daher bis ins letzte Detail ausarbeitet. Unter diesen Umständen entstehen Spezifikationen, in denen abstrakte und sehr spezielle Aussagen vermischt sind. Solche Spezifikationen sind unübersichtlich, schwer lesbar und schlecht verwendbar. Die Verfeinerung eines einzelnen Teils kann u. U. auch schon vor der allgemeinen Verfeinerung sinnvoll sein, sie gehört dann aber in ein anderes Kapitel. Generell gilt, dass vor allem die allgemeinen Teile oft einen Schwachpunkt darstellen und darum besondere Aufmerksamkeit verdienen. Man sieht immer wieder Spezifikationen, deren Verfasser sich mit erkennbarer Mühe ein paar wolkige, unbestimmte Aussagen abgerungen und dann sehr rasch den Einzelheiten zugewandt hat. Der Leser hat dann keine Chance, aus dem Dokument die ihm fehlende Übersicht zu gewinnen.
5. Die Spezifikation nach Aspekten organisieren und Checklisten verwenden, die dabei weiterentwickelt werden
Innerhalb der Spezifikation kommen verschiedene Aspekte zum Ausdruck, z. B. Bedienung, Datenflüsse, Zuverlässigkeit, Datendurchsatz, Fehlerbehandlung. Innerhalb eines Abschnitts sollten der Aspekt und die Abstraktionsebene (siehe Regel 4) stabil bleiben. Die Aspekte stellen auch eine Art Checkliste dar. Wenn man daran gewöhnt ist, einen Aspekt »Installation« und einen Aspekt »Datensicherheit« zu behandeln, dann können diese Punkte nicht vergessen werden. Natürlich haben die Klienten zu beiden Punkten Anforderungen, aber sie werden in vielen Fällen nicht von selbst darauf kommen.
Selbstverständlich ist es sinnvoll, auch gewöhnliche Checklisten einzusetzen. Sie stellen die billigste Form der Erfahrungsdatenbank dar und können problemlos erweitert und ergänzt werden.
6. Ein Mengengerüst bilden
Das Mengengerüst enthält alle Zahlen, die die Entwickler zur Wahl der Datenstrukturen und Algorithmen benötigen. Siehe dazu Abschnitt 16.7.4.
7. Die Klienten einbeziehen
Es ist schwierig, einen nicht fachkundigen Anwender in die Arbeit an der Spezifikation einzubeziehen. Wenn man aber dieser Schwierigkeit ausweicht, indem man die Diskussion mit dem Klienten meidet, gerät man später in weitaus größere Probleme.
8. Sprachen und Werkzeuge verwenden, die die Regeln unterstützen
Nur ein sehr gutes Team ist in der Lage, nach allgemeinen Regeln, einer »Sammlung frommer Sprüche«, zu arbeiten; die meisten brauchen eine konkrete Führung. Diese erfolgt am besten durch eine Notation, die die Einhaltung der Regeln erzwingt (oder sehr nahe legt), und ein darauf abgestimmtes Werkzeug, das ihre Verwendung belohnt, indem es den Entwickler von nicht schöpferischen Arbeiten (wie Kopieren, Suchen, Vergleichen) entlastet. Das Werkzeug kann auch einfache, aber aufwändige Prüfungen übernehmen, es kann z. B. die Konsistenz von Schnittstellen prüfen.
9. Die Spezifikation der Konfigurationsverwaltung unterstellen und so bald wie möglich prüfen, z. B. durch Reviews oder Prototypen
Da die Fehler der Spezifikation besonders kostspielig sind, ist hoher Aufwand für die Prüfungen rentabel. Während der Prüfung und danach sollte die Spezifikation vor unkontrollierten Änderungen geschützt sein.
10. Die Spezifikation intensiv verwenden
Nachdem viel Aufwand in die Spezifikation investiert wurde, sollte sie zum Vorteil des Projekts auch angewendet werden. Das ist auch für die Spezifikation selbst nützlich, denn Fehler werden schneller entdeckt, und einer Ablösung von der Implementierung, d. h. einem Veralten der Spezifikation, wird vorgebeugt. Eine der wichtigsten Verwendungen, die regelmäßig Lücken und Unklarheiten aufdeckt, ist die Testvorbereitung (siehe Abschnitt 19.3.2).
