4.3. Ergebnis des Anforderungs-Erfassungs-Prozesses

Fast alle Ergebnisse des Anforderungs-Erfassungs-Prozesses sind dokumentarisch. Das einzige Diagramm ist das Anwendungsfalldiagramm, das die Beziehungen zwischen den Anwendungsf??llen und den Akteuren darstellt.

4.3.1. Visions-Dokument

Typische Kapitel dieses Dokumentes k??nnten die folgenden sein.

  • Zusammenfassung. Eine Aussage zum Umfeld, zum Problem und zu den Zielen der L??sung.

  • Ziele. Was wir erreichen wollen (und wie wir es erreichen wollen).

  • Marktumfeld oder vertragliche Vereinbarungen. Bei einer Entwicklung zur Marktf??hrerschaft, sollte es die Zielm??rkte, die Alleinstellungsmerkmale, die zwingenden Ereignisse und so weiter aufzeigen. Bei einer vertraglich vereinbarten Entwicklung sollte es die Hauptelemente der vertraglichen Vereinbarung erl??utern.

  • Nutzer. Die Nutzer (im weitesten Sinne) des Systems. Viele davon werden als Akteure, oder Steuer-Equipment das in Akteure umgewandelt wird, abgebildet.

  • Haupteigenschaften. Auf einer sehr hohen Abstraktionsebene: Was sind die haupts??chlichen Aspekte des Problems/der gew??nschten L??sung. Es ist hilfreich, hier bereits zu priorisieren.

  • Randbedingungen. Eine Sicht auf die nicht-funktionalen Parameter des Systems auf einer sehr hohen Abstraktionsebene. Diese werden in der erg??nzenden Anforderungsspezifikation detailliert ausgearbeitet.

  • Anhang. Eine Liste der Akteure und Anwendungsf??lle die zur Erf??llung der Vision notwendig sind. Es ist hilfreich, diese mit den vorher beschriebenen Abschnitten zu verlinken um eine in sich geschlossene Darstellung sicherzustellen.

4.3.2. Anwendungsfalldiagramm

Das Visions-Dokument identifizierte die Anwendungsf??lle und Akteure. Das Anwendungsfalldiagramm stellt dar, wie sie interagieren. In unserem ATM (Geldautomat) Beispiel haben wir „Kunde nutzt den Automaten“, „Wartung des Automaten“ und „Revision“ als die drei Hauptanwendungsf??lle identifiziert. Als Akteure haben wir „Kunde“, „Wartungsingenieur“, „lokaler Zweigstellenbeamter “ und „Zentralcomputer“ identifiziert.

Abbildung 4.1, „ Grundlegendes Anwendungsfalldiagramm f??r einen Geldautomaten “ zeigt, wie das in einem Anwendungsfalldiagramm dargestellt werden kann. Die Anwendungsf??lle werden als Ovale dargestellt, die Akteure als Strichm??nnchen (auch wenn es Maschinen sind), mit Linien (als Assoziationen bekannt), die die Anwendungsf??lle mit den damit involvierten Akteuren verbinden. Ein Rahmen um die Anwendungsf??lle stellt die Abgrenzung zwischen dem System (durch die Anwendungsf??lle definiert) und den Akteuren dar, die extern sind.

[Anmerkung]Anmerkung

Nicht alle Analytiker m??chten einen Rahmen um die Anwendungsf??lle verwenden. Dies ist ein Fall pers??nlicher Vorlieben.

Abbildung 4.1. Grundlegendes Anwendungsfalldiagramm f??r einen Geldautomaten

Grundlegendes Anwendungsfalldiagramm f??r einen Geldautomaten


Die folgenden Abschnitte zeigen, wie das grundlegene Anwendungsfalldiagramm erweitert werden kann, um zus??tzliche Informationen ??ber das zu designende System darzustellen.

4.3.2.1. Aktive und passive Akteure

Aktive Akteure initiieren eine Interaktion mit dem System. Dies kann durch einen Pfeil in der Assoziation vom Akteur zum Anwendungsfall dargestellt werden. Im Geldautomaten-Beispiel ist der Kunde ein aktiver Akteur.

Die Interaktion mit passiven Akteuren wird durch das System initiiert. Dies kann durch einen Pfeil in der Assoziation vom Anwendungsfall zum Akteur dargestellt werden. Im Geldautomaten-Beispiel ist der Zentralcomputer ein passiver Akteur.

Dies ist ein gutes Beispiel, wo die Pfeile helfen, da es uns erlaubt, ein ereignisgetriebenes System (der Geldautomat initiiert die Interaktion mit dem Zentralcomputer) von einem zyklisch abfragenden System (der Zentralcomputer fragt den Geldautomaten von Zeit zu Zeit ab) zu unterscheiden.

Dort wo ein Akteur entweder aktiv oder passiv sein kann, je nach den Umst??nden, kann der Pfeil weggelassen werden. Im Geldautomaten-Beispiel f??llt der Bankingenieur in diese Kategorie. Normalerweise ist er aktiv, indem er regelm??ssig auftaucht um die Maschine zu warten. Wenn jedoch der Geldautomat einen Fehler entdeckt, kann er den Ingenieur auffordern diesen zu beheben.

Die Verwendung von Pfeilen bei Assoziationen wird als Navigation der Assoziation bezeichnet. Wir sollten dies sp??ter in der UML im Einsatz sehen. Die Wahl der OMG eine bidirektionale Assoziation durch keine anstelle von zwei Pfeilspitzen darzustellen ist unvorteilhaft. Mit dieser Konvention k??nnen Sie nicht zwischen einer Assoziation unterscheiden, deren Navigation noch zu bestimmen ist und einer die bidirektional ist.

Abbildung 4.2, „ Anwendungsfalldiagramm f??r einen Geldautomaten mit Navigation. “ zeigt das Geldautomaten-Anwendungsfalldiagramm mit dargestellter Navigation.

Abbildung 4.2. Anwendungsfalldiagramm f??r einen Geldautomaten mit Navigation.

Anwendungsfalldiagramm f??r einen Geldautomaten mit Navigation.


4.3.2.2. Multiplizit??t

Es kann sehr n??tzlich sein, die Multiplizit??t von Assoziationen zwischen Akteuren und Anwendungsf??llen darzustellen. Damit meinen wir, wie viele Auspr??gungen eines Akteurs mit wie vielen Auspr??gungen eines Anwendungsfalles interagieren.

Standardm????ig nehmen wir an, dass eine Auspr??gung eines Akteurs mit einer Auspr??gung eines Anwendungsfalles interagiert. In den anderen F??llen k??nnen wird die Multiplizit??t an einem Ende der Assoziation kennzeichnen. Entweder mit einer Nummer, um darzustellen, wie viele Auspr??gungen involviert sind, oder mit einem durch zwei Punkten separierten Bereich (.. ). Ein Stern (*) wird verwendet, um eine beliebige Zahl darzustellen.

Im Geldautomaten-Beispiel gibt es nur einen Zentralcomputer, aber es k??nnen beliebig viele Nutzungen des Geldautomaten aufgezeichnet werden. Daher plazieren wir das Kennzeichen 0..* am Ende des Anwendungsfalles. Es gibt keine Notwendigkeit f??r eine Kennzeichnung am anderen Ende, da der Standard 1 ist.

Eine lokale Bank kann bis zu drei Beamte haben, die autorisiert sind, die Geldautomaten zu leeren und zu bef??llen. Daher plazieren wir bei der Beziehung zwischen dem Akteur und dem Anwendungsfall Wartung Geldautomat am Ende zum Akteur die Kennzeichnung 1..3. Sie k??nnen sich mit beliebig vielen Geldautomaten befassen, so dass wir auf dem anderen Ende das Kennzeichen 0..* plazieren.

Es gibt beliebig viele Kunden und beliebig viele Geldautomaten die diese nutzen d??rfen. Daher plazieren wir an jedem Ende der Assoziation das Kennzeichen 0..*.

Abbildung 4.3, „ Anwendungsfalldiagramm f??r einen Geldautomaten und dargestellter Multiplizit??t. “ zeigt das Geldautomaten-Anwendungsfalldiagramm mit dargestellter Multiplizit??t.

Abbildung 4.3. Anwendungsfalldiagramm f??r einen Geldautomaten und dargestellter Multiplizit??t.

Anwendungsfalldiagramm f??r einen Geldautomaten und dargestellter Multiplizit??t.


Die Multiplizit??t kann ein Diagramm ??berladen und wird oft nicht angezeigt, ausser wo es f??r das Verst??ndnis kritisch ist. Im Beispiel Geldautomat w??rde wir nur 1..3 zum lokalen Bankbeamten darstellen, da alle anderen aus dem Kontext heraus offensichtlich sind.

4.3.2.3. Hierarchien von Anwendungsf??llen

In unserem Geldautomatenbeispiel haben wir jetzt drei Anwendungsf??lle, um das Verhalten des Systems zu beschreiben. Auch wenn Anwendungsf??lle immer einen signifikanten Teil des Systemverhaltens beschreiben sollten, wenn diese zu generell sind, k??nnen sie schwer zu beschreiben sein.

Wir k??nnten zum Beispiel das Verhalten des Anwendungsfalles „Geldautomat nutzen“ durch das Verhalten von drei einfacheren Anwendungsf??llen, wie „Bargeld lagern“, „Bargeld ausgeben“ und „Konto abfragen“ ausdr??cken. Der Hauptanwendungsfall k??nnte durch einbinden (include) des Verhaltens der ben??tigten Unteranwendungsf??lle spezifiziert werden.

Der Anwendungsfall „Geldautomat warten“ k??nnte ebenfalls durch zwei Anwendungsf??lle „Equipment warten “ und „Geldautomat neu starten“ definiert werden. In diesem Fall sind die zwei im Hauptanwendungsfall involvierten Akteure nat??rlich nur in einem oder dem anderen der beiden Unteranwendungsf??lle involviert. Dies wird im nachfolgenden Diagramm dargestellt.

Die Aufteilung eines Anwendungsfalles in einfacherere Unteranwendungsf??lle wird in UML durch eine include Beziehung, einem gestrichelten Pfeil vom Hauptanwendungsfall zum Unteranwendungsfall mit der Kennzeichnung «include» bezeichnet.

Abbildung 4.4. Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen.

Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen.


Include-Beziehungen sind ideal f??r das Herunterbrechen des Anwendungsfallverhaltens in Hierarchien. Wir wollen jedoch auch einen Anwendungsfall, der eine Erweiterung (extension) eines existierenden Anwendungsfalles darstellt, in bestimmten Umst??nden darstellen.

Im Geldautomatenbeispiel haben wir einen Anwendungsfall „ Equipment warten“, der die Routinewartung des Geldautomaten beinhaltet. Wir wollen aber auch den Spezialfall einer ungeplanten Reparatur abdecken, die durch den vom Geldautomaten erkannten internen Fehlers ausgel??st wurde.

Dies wird in UML durch die extend-Beziehung dargestellt. Im Hauptanwendungsfall spezifizieren wir einen Namen f??r einen Ort in der Beschreibung, an den die Erweiterung des Verhaltens hinzugef??gt werden kann. Der Name und der Ort werden in einem separaten Abschnitt innerhalb des Anwendungsfall- Ovales dargestellt. Die Darstellung der extend-Beziehung entspricht der include-Beziehung, aber mit dem Kennzeichen «extend». An der extend- Beziehung spezifizieren wird die Bedingung, unter der das Verhalten hinzugef??gt wird.

Abbildung 4.5, „ Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung. “ zeigt das Geldautomaten-Anwendungsfalldiagramm mit einer extend- Beziehung auf einen Anwendungsfall f??r ungeplante Reparaturen. Das Diagramm ist jetzt sehr komplex so dass wir es in zwei aufteilen sollten. Eines f??r die haupts??chlichen Dinge, das andere f??r den Kundennutzen und Revision.

Der Anwendungsfall „Equipment warten“ definiert den Namen „Unshed“ am Anfang seiner Beschreibung. Der erweiterte Anwendungsfall „ungeplante Reparatur“ wird herangezogen, wenn der Geldautomat einen internen Fehler entdeckt.

Abbildung 4.5. Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung.

Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung.


Anwendungsf??lle k??nnen auch auf andere Art und Weise miteinander verkn??pft sein. Ein Anwendungsfall kann eine Generalisierung eines Sub-Anwendungsfalles (oder alternativ: Der Sub-Anwendungsfall ist eine Spezialisierung des Hauptanwendungsfalles). Das ist der extend-Beziehung sehr ??hnlich, aber ohne die Bedingung des spezifischen Erweiterungspunktes, unter welcher der Haupt-Anwendungsfall erweitert wird und ohne Bedingung unter welcher der Sub-Anwendungsfall verwendet wird.

Der Generalisierung wird in einem Anwendungsfalldiagramm durch einen Pfeil mit durchgehender Linie und einer weissen Pfeilspitze vom Sub-Anwendungsfall zum Hauptanwendungsfall dargestellt. Das kann hilfreich sein, wenn ein Sub-Anwendungsfall das Verhalten des Hauptanwendungsfalles in einer Vielzahl von Positionen und in einem weiten Bereich von Sachverhalten spezialisiert. Das Fehlen jeglicher Einschr??nkungen macht es sehr schwierig, die Generalisierung genau zu beschreiben. Im Normalfall verwenden Sie besser eine extend-Beziehung.

4.3.3. Die Anwendungsfall-Spezifikation

Jeder Anwendungsfall muss dokumentiert sein, um das das spezifizierte Verhalten im Detail zu erl??utern. ArgoUML unterst??tzt Sie in diesem Bereich durch das Generieren graphischer Dateien, die in diese Dokumentation eingebunden werden kann. Dieses Dokument ist unter verschieden Namen in verschiedenen Prozessen bekannt: Anwendungsfall-Spezifikation, Anwendungsfall-Szenario oder auch (verwirrend) nur Anwendungsfall.

Eine typische Anwendungsfall-Spezifikation wird folgende Kapitel enthalten.

  • Name. Der Name des Anwendungsfalles.

  • Ziel. Eine ein oder zweizeilige Zusammenfassung dar??ber, was dieser Anwendungsfall f??r seine Akteure ausf??hrt.

  • Akteure. Die in diesen Anwendungsfall involvierten Akteure und jeden Umstand bez??glich Ihrer Einbindung.

    [Anmerkung]Anmerkung

    Dies sollte keine Beschreibung des Akteurs sein. Die sollte mit dem Akteur im Anwendungsfalldiagramm verkn??pft sein.

  • Vorbedingung. Diese w??rden besser als „Voraussetzungen“ bezeichnet, aber der ??berall verwendete Begriff ist Vorbedingungen. Dies ist eine Beschreibung jeder vereinfachenden Voraussetzung, die wir zum Start des Anwendungsfalles machen k??nnen.

    Im Geldautomatenbeispiel k??nnten wir beim Anwendungsfall „Equipment warten“ die Voraussetzung haben, das immer ein Ingenieur verf??gbar ist und wir uns nicht vor dem Fall f??rchten m??ssen, in dem ein Routinewartungs-Besuch ausgelassen wurde.

    [Achtung]Achtung

    Vermeiden Sie Vorbedingungen wo immer das m??glich ist. Sie m??ssen sich absolut sicher sein, dass die Vorbedingung unter allen m??glichen Umst??nden eingehalten wird. Wenn nicht, ist ihr System zu wenig spezifiziert und wird daher fehlschlagen, wenn die Vorbedingung nicht wahr ist. Wenn Sie nicht sicher sein k??nnen, dass die Vorbedingung immer wahr ist, m??ssen Sie einen zweiten Anwendungsfall spezifizieren, der den Fall handhabt, wenn die Vorbedingung falsch ist. Im ersten Fall sind die Vorbedingungen die Ursache der Probleme, im zweiten Fall die Ursache f??r mehr Arbeit.

  • Standardablauf. Die aufeinander folgenden Schritte, die das Verhalten des Anwendungsfalles im „Normalfall“ beschreiben. Wo ein Anwendungsfall mehrere normale Szenarien aufweist, wird einer davon willk??rlich ausgew??hlt. Die Spezifizierung des Standardablaufes wird nachfolgend detaillierter beschrieben Abschnitt 4.3.3.1, „Den Standardablauf spezifizieren“.

  • Alternative Abl??ufe. Eine Reihe von linearen Sequenzen beschreiben jede der alternativen, gegen??ber dem Standardablauf abweichenden Verhaltensweisen. Die Spezifizierung alternativer Abl??ufe ist detaillierter in Abschnitt 4.3.3.2, „Alternative Abl??ufe spezifizieren“ beschrieben.

  • Nachbedingungen. Dies ist der Zustand jeder Nachbedingung, den wir am Ende des Anwendungsfalles feststellen k??nnen. Sehr hilfreich, wo der Anwendungsfall einer von einer Serie von in den Hauptanwendungsfall eingebundenen Unteranwendungsf??llen ist, wo sie die Vorbedingung f??r den n??chsten einzubindenden Anwendungsfall bilden.

    [Achtung]Achtung

    Nachbedingungen sind wie Vorbedingungen am Besten zu vermeiden. Sie bilden eine Belastung f??r die Spezifikation des Anwendungsfallablaufes, das sichergestellt sein muss, dass die Nachbedingung immer eingehalten wird. Daher sind sie auch eine Ursache von Problemen und zus??tzlicher Arbeit.

  • Anforderungen. In einer idealen Welt w??rden das Visionsdokument, die Anwendungsfalldiagramme, die Anwendungsfallbeschreibungen und die Spezifikation der zus??tzlichen Anforderungen die Anforderungen f??r ein Projekt bilden.

    Bei den meisten Marktf??hrer-Entwicklungen, ist es gew??hnlich der Fall, dass sich die Eigentumsrechte der Anforderungen im gleichen Business befinden, wie das Team, das die Entwicklung durchf??hren wird. Die Marketingabteilung kann das Erfassen und die Analyse der Anwendungsfallanforderungen erlernen, um ihre kundenspezifischen Aktivit??ten damit zu verbinden.

    Bei externen Vertragsentwicklungen jedoch, kann der Kunde auf einer traditionellen „Liste von Features“ als Basis des Vertrages bestehen. Wo dies der Fall ist, sollte dieser Abschnitt der Anwendungsfallspezifikation mit den vertraglich festgelegten Features ??bereinstimmen, die durch den Anwendungsfall abgedeckt werden.

    Das wird oft mit Hilfe eines Third-Party-Werkzeuges ausgef??hrt, das Dokumente verkn??pfen kann und eine automatische Pr??fung des Geltungsbereiches enth??lt. In diesem Fall wird dieser Abschnitt nicht ben??tigt oder kann automatisch generiert werden.

Die abschliessende Gr??sse der Anwendungsfallspezifikation h??ngt von der Komplexit??t der Anwendungsf??lle ab. Als Faustregel gilt, dass die meisten Anwendungsf??lle ca. 10-15 Seiten f??r die Spezifikation ben??tigen, das meiste davon f??r die alternativen Abl??ufe. Wenn sie sehr viel gr??sser sind, sollten Sie die Anwendungsf??lle aufteilen. Wenn sie sehr viel kleiner sind, betrachten Sie, ob der Anwendungsfall einen zu kleinen Bereich des Verhaltens beschreibt.

4.3.3.1. Den Standardablauf spezifizieren

Alle Abl??ufe in einer Anwendungsfallspezifikation sind linear — d.h. es gibt keine bedingte Verzweigung. Jede Auswahl im Ablauf wird durch einen anderen, nach dem Auswahlpunkt kommenden alternativen Ablauf behandelt. Es ist wichtig, sich daran zu erinnern, dass wir hier das Verhalten und nicht die Programmierung spezifizieren.

Ein Ablauf wird durch eine Reihe von numerierten Schritten spezifiziert. Jeder Schritt muss einige Interaktionen mit einem Akteur oder mindestens eine ??nderung generieren, die durch einen Akteur extern ??berwacht wird. Das Anforderungen erfassen sollte nicht das versteckte interne Verhalten eines Systems spezifizieren.

In unserem Geldautomatenbeispiel k??nnten wir im Anwendungsfall „Bargeld ausgeben“ die folgende Sequenz von Schritten im Standardablauf haben:

  1. Der Kunde gibt an, dass eine Quittung erforderlich ist.

  2. Der Kunde gibt die gew??nschte Bargeldmenge ein.

  3. Der Geldautomat ??berpr??ft mit dem Zentralcomputer, dass der Kunde diese Auszahlung durchf??hren kann.

  4. Der Geldautomat gibt das Bargeld an den Kunden.

  5. Der Geldautomat gibt die Quittung an den Kunden aus.

Zur Erinnerung: Dies ist ein Sub-Anwendungsfall der im Haupt- Anwendungsfall „Geldautomat benutzen“ enthalten ist, der voraussichtlich das Pr??fen von Karten und PINs handhaben wird, bevor dieser eingebundene Anwendungsfall aufgerufen wird.

[Anmerkung]Anmerkung

Der erste Schritt ist keine Bedingung. Wir nehmen als unseren Standardablauf den Fall, wo der Kunden eine Quittung haben m??chte. Der Fall, wo der Kunde keine Quittung haben will, wird ein alternativer Ablauf sein.

4.3.3.2. Alternative Abl??ufe spezifizieren

Dies erfasst die alternativen Szenarien, wie lineare Abl??ufe, die durch den Standardablauf referenziert werden. Zu Beginn erzeugen wir eine Liste der alternativen Abl??ufe.

    1. Der Kunde ben??tigt keine Quittung.

    2. Das Kundenkonto unterst??tzt keine Auszahlung.

    3. Die Kommunikation mit dem Zentralcomputer ist unterbrochen.

    4. Der Kunde unterbricht die Transaktion.

    5. Der Kunde macht beim Annehmen des Bargeldes Fehler.

Nachfolgend arbeiten wir jeden alternativen Ablauf als Referenz zum Standardablauf aus. Der erste alternative Ablauf k??nnte zum Beispiel wie folgt aussehen:

    1. Der Kunde ben??tigt keine Quittung.

      1. In Schritt 1 des Standardablaufes sagen die Kunden, dass Sie keine Quittung ben??tigen.

      2. Der Standardablauf geht von Schritt 2 in Schritt 4, Schritt 5 wird nicht ben??tigt.

Die Konvention ist, dass die verschiedenen alternativen Abl??ufe numeriert werden, wie A.1, A.2, A.3, usw. Die Schritte innerhalb eines alternativen Ablaufes werden darauf aufbauend numeriert. So dass die Schritte der ersten Alternative wie folgt lauten w??rden: A.1.1, A.1.2, A.1.3, usw.

4.3.3.3. Iterative Entwicklung der Anwendungsfallspezifikationen

Die Iterative Entwicklung wird die die Anwendungsf??lle priorisieren und die erste Iteration wird die wichtigsten adressieren.

Fr??he Iterationen werden den Standardablauf der wichtigsten Anwendungsf??lle nur mit den grundlegenden Details erfassen und die ??berschriften der haupts??chlichen alternativen Abl??ufe auflisten.

Sp??tere Iterationen werden die verbleibenden Anwendungsf??lle adressieren, die Schritte der individuellen alternativen Abl??ufe ausformulieren und wahrscheinlich mehr Details ??ber die individuellen Schritte enthalten.

4.3.4. Erg??nzende Anforderungsspezifikation

Dies erfasst die nicht-funktionalen Anforderungen oder Randbedingungen, die f??r das System gelten. Da Anwendungsf??lle von Natur aus inh??rent funktional sind, k??nnen sie diese Art von Information nicht aufnehmen.

[Anmerkung]Anmerkung

Einige Analytiker plazieren nicht-funktionale Anforderungen in einem Abschnitt am Ende einer jeden Anwendungsfallspezifikation, der die nicht-funktionalen, anwendungsfallbezogenen Anforderungen enth??lt.

Dies kann einige Probleme verursachen. Der erste Punkt ist, dass nicht-funktionale Anforderungen (zum Beispiel ??ber die Performance) in vielen Anwendungsf??llen erscheinen mu?? und es ist eine schlechte Praxis, Informationen zu replizieren. Zweitens gibt es einige invariable systemweite nicht-funktionale Anforderungen, die ein systemweites Dokument erfordern. Daher meine Pr??ferenz f??r eine einzige erg??nzende Anforderungsdokumentation.

Es sollte ein Abschnitt f??r jeden Hauptbereich der nicht-funktionalen Anforderungen geben. Die Checkliste von Ian Sommerville in seinem Buch Software Engineering (Third Edition, Addison-Wesley, 1989) ist eine hilfreiche Anleitung.

  • Geschwindigkeit. Prozessorleistung, Anwender-/Ereignis-Antwortzeiten, Bildauffrischungszeiten.

  • Gr??sse. Hauptspeicher (und m??gliche Zwischenspeicher), Plattenkapazit??t.

  • Leichte Anwendbarkeit. Ausbildungszeit, Stil und Details des Hilfesystems.

  • Zuverl??ssigkeit. Durchschnittliche Fehlerauftrittszeit, die Nichtverf??gbarkeitswahrscheinlichkeit, die Fehlerrate, die Verf??gbarkeit.

  • Widerstandsf??higkeit. Wiederanlaufzeit nach einem Fehler, Prozentsatz der Ereignisse, die Fehler verursachen, die Wahrscheinlichkeit von Datenverlust bei einem Fehler.

  • Portabilit??t. Prozentsatz von zielabh??ngigem Code/Klassen, Anzahl der Zielsysteme.

Dazu sollten wir Abschnitte ??ber die Umgebung (Temperatur, Feuchtigkeit, Blitzschutz) und ??bereinstimmung mit Standards hinzuf??gen.