Die Softwareanforderungsspezifikation konzentriert sich auf die
Zusammenstellung und Organisation aller mit Ihrem Projekt in Zusammenhang stehenden Anforderungen. Wenn Sie einen
Anforderungsmanagementplan haben, ziehen Sie diesen für die Bestimmung der korrekten Position und Organisation der
Anforderungen zu Hilfe. Beispielsweise kann es sich empfehlen, eine gesonderte Softwareanforderungsspezifikation zu
erstellen, in der Sie alle Softwareanforderungen für jedes Feature
in einem bestimmten Release des Produkts beschreiben. Dazu können mehrere Anwendungsfälle aus dem Anwendungsfallmodell des Systems gehören, um die funktionalen
Anforderungen dieses Features zu beschreiben, sowie ergänzende Spezifikationen mit detaillierten Anforderungen.
Da Sie möglicherweise mit verschiedenen Tools arbeiten müssen, um diese Anforderungen zu erfassen, müssen Sie sich
unbedingt im Klaren darüber sein, dass die Anforderungen auf unterschiedliche Artefakte und Tools verteilt sein können.
Vielleicht halten Sie es für zweckmäßig, inhaltliche Anforderungen wie nicht funktionale Anforderungen, Designvorgaben
usw. in einem Tool für Textdokumente (siehe Ergänzende Spezifikationen) festzuhalten, aber andere (oder alle)
funktionale Anforderungen in Anwendungsfällen mit einem Tool zu beschreiben das für die Definition
des Anwendungsfallmodells geeignet ist.
Es gibt eigentlich keinen triftigen Grund, hier auf die Unterschiede zwischen den verwendeten Tools einzugehen. Letzen
Endes tragen Sie die Anforderungen zusammen und dabei sollten Sie sich auf eine effiziente Zusammenstellung und
Organisation der Anforderungen konzentrieren, egal welche Tools verfügbar sind. Da wir uns hier auf die Anforderungen
und nicht auf die Tools konzentrieren, setzen wir voraus, dass die Sammlung der Anforderungen in der
Softwareanforderungsspezifikation ein Informationspaket darstellt. Die Ausarbeitung der verschiedenen Anforderungen
für das System wird in ein Paket eingeschlossen, die so genannte Softwareanforderungsspezifikation (SRS, Software Requirements
Specification).
Das SRS-Paket ist mit dem Visionsdokument verbunden. Das Visionsdokument dient als Grundlage
für die Softwareanforderungsspezifikation. Die beiden Artefakte bedienen jedoch unterschiedliche Anforderungen und
werden normalerweise von unterschiedlichen Autoren geschrieben. In diesem Stadium des Projekts verschiebt sich der
Fokus des Projekts von einer allgemeinen Beschreibung der Benutzerbedürfnisse, Ziele und Zielsetzungen, Zielgruppe und
System-Features hin zu den Details, die darlegen, wie diese Features in der Lösung implementiert werden.
Was jetzt benötigt wird, ist eine Sammlung oder ein Paket der Artefakte, die bzw. das das komplette externe Verhalten
des Systems beschreibt, d. h. ein Paket, das ganz deutlich sagt "Das System muss Folgendes leisten, um diese Feature
bereitzustellen". Dieses Paket ist das SRS-Paket.
Das SRS-Paket ist kein eingefrorener Wälzer, der zum Zweck der ISO-9000-Konformität erstellt wird, dann in einer Ecke
verschwindet und im Verlauf des Projekts ignoriert wird. Es ist vielmehr ein aktives, lebendes Artefakt. Die Entwickler
werden es bei ihren Implementierungsarbeiten zu vielerlei Zwecken verwenden. Es dient als Basis für die Kommunikation
zwischen den beteiligten Parteien, d. h. zwischen den Entwicklern selbst und zwischen den Entwicklern und den externen
Gruppen (Benutzern und anderen Stakeholdern), mit denen sie kommunizieren müssen. Es stellt formal und formlos eine
vertragliche Vereinbarung zwischen den verschiedenen Parteien dar. Wenn etwas nicht im SRS-Paket enthalten ist, sollten
die Entwickler auch nicht daran arbeiten. Wenn eine Funktionalität im SRS-Paket beschrieben ist, sind die Entwickler
auch dafür verantwortlich, diese zu liefern.
Die SRS dient als Referenzstandard für den Projektleiter. Der Projektleiter hat wahrscheinlich nicht die Zeit,
die Energie und das Know-How, um den Code zu lesen, der von den Entwicklern generiert wird, und diesen direkt mit dem
Visionsdokument zu vergleichen. Er muss sich bei Diskussionen mit dem
Projektteam auf das SRS-Paket als Standardreferenz berufen.
Wie bereits erwähnt, dient die Softwareanforderungsspezifikation als Grundlage für die Design- und
Implementierungsgruppen. Je nach Organisation des Projekts können die Implementierer an früheren Problembehebungs- und
Features-Definitionsaufgaben beteiligt gewesen sein, aus denen schließlich das Visionsdokument hervorgegangen ist. Aber
es ist das SRS-Paket, das im Mittelpunkt steht, wenn sie entscheiden, was der Code leisten muss. Es dient als Eingabe
für die Softwaretest- und QS-Gruppen. Diese Gruppen sollten auch an einigen der früheren Diskussionen beteiligt gewesen
sein, und es ist offensichtlich hilfreich für sie, ein tiefgreifendes Verständnis der in den Visionsdokumenten
dargelegten "Vision" zu haben. Ihr Auftrag ist es jedoch, Testfälle und QS-Prozeduren, zu erstellen, um
sicherzustellen, dass das entwickelte System auch wirklich die im SRS-Paket beschriebenen Anforderungen erfüllt. Das
SRS-Paket dient auch als Standardreferenz für ihre Planung und Testaufgaben.
Auf den Seiten Richtlinie:
Anwendungsfallmodell und Richtlinie:
Anwendungsfall finden Sie eine vollständige Beschreibung des empfohlenen Ansatzes für die Definition funktionaler
Anforderungen in einem Anwendungsfallmodell und in den Anwendungsfällen.
Die nicht funktionalen Anforderungen Ihres Systems müssen im Arbeitsergebnis Ergänzende Spezifikationen dokumentiert werden. Im Folgenden finden
Sie Richtlinien für die Definition dieser Anforderungen.
Während Sie die nicht funktionalen Anforderungen erfassen und validieren, sollten Sie Listen mit Annahmen und Problemen
führen.
Einige Aufgaben werden Ihnen keine zufriedenstellenden Antworten geben. Dies kann auf fehlende Informationen oder
einfach darauf zurückzuführen sein, dass Sie die Antwort für eine Bedrohung der Zuverlässigkeit des Systems halten.
Erstellen Sie deshalb zwei Listen und pflegen Sie diese während der gesamten Designstudie.
Dokumentieren Sie alle Annahmen, die Sie während des Anforderungs- und Designprozesses treffen, einschließlich der
Begründung oder Denkprozesse, die diesen Annahmen zugrunde liegen. Annahmen können verwendet werden, um zugehörige
Unterprojekte oder Arbeitspositionen zu identifizieren, die außerhalb des Rahmens des Projekts liegen oder nach diesem
Projekt ausgeführt werden können.
Dokumentieren Sie alle Probleme (wichtige Problemstellungen, die zu Hemmschuhen werden können).
Die Probleme müssen am Ende jeder Phase mit dem Kunden geprüft werden. Die Annahmen müssen ebenfalls am Ende jeder
Phase geprüft werden, aber der Kunde ist bei den weniger wichtigen Annahmen möglicherweise nicht immer die richtige
Ansprechperson.
Annahmen und Probleme beziehen sich auf alle Arbeitsergebnisse, aber insbesondere für nicht funktionale Anforderungen.
Dokumentieren Sie die geographische Organisation des Auftraggebers.
Dokumentieren Sie die geographischen Standorte für den Teil des Geschäfts, der von diesem System betroffen ist. Die
Definition muss auch die nicht betroffenen Standorte ansprechen, an denen sich wichtige IT-Einrichtungen befinden.
Berücksichtigen Sie insbesondere alle mobilen Teile der Organisation, z. B. Verkaufsteams, die herumreisen und
Workstations verwenden. Dokumentieren Sie alle geographischen Standorte, an denen Sie unter Umständen spezielle
NLS-Unterstützung (National Language Support, Unterstützung nationaler Zeichensätze) bereitstellen müssen.
Spezifizieren die Anforderungen die Verwendung von Anwendungspaketen? Eine sehr wichtige "Vorgabe", die einige
Systemdesignentscheidungen stark lenkt, ist die Verwendung eines bestimmten Anwendungspakets, das vordefinierte
Softwarelogik und Datenstrukturen enthält. Einige Softwarepakete sind flexibel und lassen weitreichende Anpassungen zu,
einige sind sehr streng und beschränkend. Pakete können Komponenten und Entscheidungen vorschreiben, z. B.:
-
Workstation-Typ
-
Verbindungsmethoden
-
Prozessor- und DASD-Typ (Direct Access Storage Device)
-
Systemsteuerprogramm
-
Datenstruktur, -platzierung und - verwaltung
-
Programmiersprache
-
Schnittstelle für Stapelverarbeitung
-
Prozess- und Datenbeziehungen
-
Geschäftslogik
-
Anzeigendesign und Benutzerschnittstellen
-
Leistungs- und Verfügbarkeitskriterien
-
Vorhandene oder erforderliche Architektur für Druckprozesse, z. B. bevorzugte Druckausgabeformate (z. B.
PostScript, PCL, IPDT)
-
Unterstützung nationaler Zeichensätze
Es ist wichtig zu verstehen, welchen Einfluss ein bestimmtes Paket auf Ihr Design hat. Wenn Sie ein "vorgegebenes"
Paket haben, müssen Sie sicherstellen, dass das richtige Know-how und Wissen für dieses Paket zur Verfügung steht.
Dieses kann von den folgenden Quellen stammen:
-
Paketlieferant
-
Externe Berater
-
Speziell geschulte Mitglieder des Designteams
Gehen Sie nicht davon aus, dass dieses Wissen griffbereit ist. Stellen Sie sicher, dass es verfügbar ist, wenn Sie es
benötigen.
Dokumentieren Sie alle anderen Vorgaben in den Anforderungen, die die Flexibilität Ihres Designs einschränken.
Damit erfassen Sie alle spezifischen Anforderungen, die in den früheren Aufgaben nicht explizit abgedeckt wurden und
die die Flexibilität Ihres Designs einschränken könnten. Suchen Sie nach Folgendem:
-
Verwendung vorhandener Prozessoren oder Betriebssystem-Images
-
Verwendung vorhandener Workstations
-
Verwendung eines vorhandenen Netzes
-
Verwendung vorhandener Systemmanagementverfahren
-
Verwendung eines speziellen Modells, z. B. 'Sie müssen ein Client/Server-Systemmodell für das Design verwenden, das
die Darstellungs-/Geschäfts-/Datenzugriffslogik und ihre Schnittstellen klar veranschaulicht'.
Wirkt sich eine dieser Vorgaben auf das neue System aus? Wenn das neue System mit einem vorhandenen Prozessor,
Betriebssystem-Image oder einer vorhandenen Netzkonfiguration ausgeführt werden soll, wirken sich die Merkmale der
vorhandenen Plattform und der Arbeitslast auf das neue System aus?
Wie viel der Verbindungs- und Verarbeitungskapazität wird bereits von der vorhandenen Arbeitslast aufgebraucht?
Welche Sicherheitssteuerungen werden von vorhandenen Arbeitslasten verwendet? Dokumentieren Sie diese und prüfen Sie,
ob sie den Sicherheitsanforderungen des neuen Systems entsprechen.
Welches sind die Verfügbarkeitsmerkmale der vorhandenen Arbeitslast?
Dokumentieren Sie alles, was sich auf das spätere Verfügbarkeitsdesign für das neue System auswirken könnte. Muss der
Prozessor beispielsweise aufgrund der vorhandenen Arbeitslast jede Nacht heruntergefahren werden?
Spezifizieren die Anforderungen die Verwendung spezieller Hardware?
Diese Anforderungen können generisch ("das System muss einen Hochgeschwindigkeitsflachbett-Plotter unterstützen") oder
spezifischer beschrieben sein ("die vorhandenen GAs der Panda Corp. werden unterstützt"). Dokumentieren Sie so viel,
wie Sie können:
-
Alle Hardware- und Softwarevoraussetzungen
-
Die Lieferanten und ihre Unterstützungsorganisationen
-
NLS-Belange
-
Verschlüsselungseinrichtungen
Spezifizieren die Anforderungen die Verwendung vorhandener Daten? Wenn ja, wirkt sich dies auf Ihr Systemdesign aus.
Dokumentieren Sie Folgendes:
-
Auf welchen Systemen sind die Daten derzeit vorhanden
-
Die Datenstruktur (z. B. relational oder unstrukturierte Datei)
-
Datengröße
-
Welche Benutzer und welche Systeme verwenden diese Daten derzeitig
-
Verfügbarkeitsgesichtspunkte (z. B. Zeiträume, in denen die Daten aufgrund von Datenbankpflege oder
Stapelverarbeitungsaufgaben nicht verfügbar sind)
-
Können diese Daten verschoben oder kopiert werden?
Hat der Client eine technische Architektur und/oder einen strategischen IT-Plan (oder entsprechende Standards)?
Eine technische Architektur entspricht im Groben:
-
der technischen Plattform eines Unternehmens
-
der technischen Infrastruktur eines Unternehmens
-
einer Technologiearchitektur
In einer technischen Architektur sind einige der folgenden Punkte unter Umständen bereits definiert:
-
Anzahl und Verwendung der Rechenzentren
-
Netzkonnektivität des Unternehmens (WAN)
-
Lokalisierte Konnektivität bestimmter Einrichtungen (LAN)
-
Client/Server-Infrastrukturservices (Middleware), die Folgendes abdecken:
· Verzeichnis- und Namensservices, die die Netzressourcen und -attribute überwachen
· Sicherheitsservices, die Netzressourcen vor unbefugter Verwendung schützt, indem Benutzer und ihre
Berechtigungsstufen registriert werden
· Zeitservices, die Datum und Uhrzeit im Netz regulieren
· Transaktionsmanagementservices, die die Ressourcenwiederherstellung auf verschiedenen Systemen in einem Netz
koordinieren
-
Entwicklungsmethoden, die für neue Anwendungen verwendet werden
-
Akzeptierte unterstützte Produkte, z. B.:
· Hardware
· Systemsteuerungssoftware
· verbreitete Anwendungssoftware wie "Office"
· Help-Desk
· Sicherheitsregeln
-
Drucksubsystemarchitektur
Die Liste kann sehr umfassend sein. Die Einträge in der Liste können streng kontrolliert oder gar nicht umgesetzt
werden.
Dokumentieren Sie alle Anforderungen, die speziell nach der Verwendung von Unterarchitekturen verlangen bzw. diese
ausschließen. Beispiel:
-
OSI oder SNA
-
UNIX**
-
SAA
-
PS/2* mit OS/2* EE
Spezielle Architekturen, die durch die Verwendung einer Standardsoftwarelösung impliziert sein können. Denken Sie
daran, dass einige Anwendungspakete selber Architekturdefinitionen sind.
Dokumentieren Sie den Grad der Offenheit (d. h. Lieferantenunabhängigkeit und Interoperabilität), die der Client
erfordert. Wenn es eine technische Architektur gibt, muss Ihr Design diese sicherlich einhalten. Sie müssen sich mit
dieser Architektur auseinandersetzen und die Regeln verstehen, die sich auf das Design des Systems auswirken.
Hat der Client eine Netzarchitektur, mit der dieses System konform sein muss? Eine Netzarchitektur setzt sich aus einer
allgemeinen Gruppe von Regeln für Konnektivität und einer allgemeinen Transportinfrastruktur zusammen. Dazu kann die
Definition eines zentralen Netzes einschließlich Konzentratoren und Leitungen gehören. Wenn es eine solche Architektur
gibt, müssen Sie die wichtigen Regeln und die Topologie verstehen und dokumentieren:
Überlegungen zur physischen Topologie (d. h. befindet sich das Netz in einem ländlichen Gebiet oder in einem
Ballungszentrum in einem dicht oder weniger dicht besiedelten Gebiet).
Welche Verbindungsfunktionen auf hoher Ebene werden von der aktuellen Netzinfrastruktur unterstützt.
Welche Kommunikationsstandards werden verwendet (z. B. SNA, OSI, TCP/IP), um diese Verbindungsfunktionen zu
unterstützen.
Welche Programmierschnittstellen werden unterstützt.
Alle Netzarchitekturdefinition der Konnektivität zwischen Client/Server-Schichten oder Basissystemmodellschichten, z.
B.:
-
Relationaler Datenzugriff zwischen Client-Workstations und relationalen LAN-Servern muss über die Protokolle eines
bestimmten relationalen Datenbankprodukts erfolgen.
-
Die Darstellungslogik muss sich immer auf der Workstation und die Datenzugriffslogik immer auf einem zentralen
Hostsystem befinden.
Hat der Client festgelegte Richtlinien für Verbindungen?
Selbst wenn Sie keine technischen oder Netzarchitekturen haben, kann es trotzdem Verbindungsrichtlinien geben.
Dokumentieren Sie alle Richtlinien und berücksichtigen Sie dabei Folgendes
-
Die Verwendung bestimmter Protokolle oder Kommunikationseinrichtungen (für Verbindungen in einem einzelnen Gebäude
oder außerhalb des Gebäudes bzw. der Organisation).
-
Ob bestimmte Protokolle implizit erforderlich sind, um vorhandene Geräte oder Software zu unterstützen.
-
Ob vorhandene physische Konnektivitätseinrichtungen verwendet werden müssen (d. h. Verkabelungen, Netz- oder
Peripheriecontroller und Fernmeldeeinrichtungen). Wenn nicht, kann es Vorgaben zum Typ der physischen Einrichtungen
geben, die verwendet werden können (Richtlinien, gesetzliche Verordnungen, physisch vorhandener Platz, Eigentümer
der Betriebsgebäude, Beteiligung Dritter). Dokumentieren Sie diese.
-
Wenn voraussichtlich Installationen oder Änderungen physischer Einrichtungen erforderlich sind, müssen unter
Umständen Fremdanbieter einbezogen werden (z. B. Subunternehmer oder Fernmeldegesellschaften). Stellen Sie fest,
wie diese Verträge oder Zuständigkeiten verwaltet werden könnten. Dies ist besonders wichtig, wenn sich die
Geschäftsbeziehungen auf internationale Ebene ausdehnen.
-
Unterstützung mobiler Benutzer.
Hat der Auftraggeber andere Richtlinien, Standards oder Regeln, die nicht explizit in den Anforderungen genannt sind?
Beispiel:
-
Alle neuen Systemschnittstellen für Benutzer müssen nach objektorientierten Prinzipien entworfen werden, um
Aktionen des Typs "ziehen und übergeben" zu zu unterstützen.
-
Alle neuen Systeme müssen auf dem Client/Server-Anwendungsmodell basieren.
-
Alle neuen Systeme müssen mit offenen Standards definiert werden.
-
Standards und Richtlinien für die Unterstützung nationaler Zeichensätze, insbesondere Rechts-Links-Schreibrichtung.
-
Sicherheitsrichtlinie, die Managementzuständigkeit und Standards für die Benutzerauthentifizierung,
Zugriffsteuerung und Datenschutz definiert.
-
Standards für den Datenaustausch zwischen Anwendungen (z. B. UNEDIFACT oder VISA), die die Verwendung spezieller
Verbindungs- oder Sicherheitseinrichtungen implizieren.
Wenn es weitere Richtlinien gibt, stellen Sie sicher, dass Sie sie verstehen und Zugriff auf sie haben, um zu
gewährleisten, dass Ihr Design in den späteren Phasen des Designprozesses diesen Standards entspricht. Die Verwendung
einer Standardsoftwarelösung kann implizierte Standards mit sich bringen.
Welche Richtlinien gelten bezüglich des Hinzufügens und/oder Entwickelns eigener lokaler Programme durch Benutzer oder
Abteilungen auf:
-
Workstations
-
Server (insbesondere Belegung des Plattenspeicherplatz)
Wenn Sie keine Kontrollen durchführen, werden Sie unter Umständen feststellen, dass durch lokale Nutzung recht schnell
Ressourcen verbraucht werden, die von den Produktionssystemen benötigt werden, für die die lokalen Komponenten
eigentlich gekauft wurden. Dies könnte dazu führen, dass Sie das Produktionssystem nicht installieren können, wenn es
dann für das Rollout bereit ist.
4.1 "Messeinheiten"
Gliedern Sie zusammen mit dem Anwendungsentwicklungspersonal die Geschäftsprozesse in differenzierte Einheiten, z. B.
kleinere Geschäftsprozesse oder Transaktionen.
Der Grund hierfür ist, dass Sie in der nächsten Frage Zahlen erfassen und entscheiden müssen, was gezählt wird.
Ein Geschäftsprozess kann mehrere Instanzen kleinerer Geschäftstransaktionen starten (z. B. mehrere Positionen pro
Kundenauftrag). Dieses Multiplikatoren müssen berücksichtigt werden, wenn Sie die Zahlen dokumentieren. Verlieren Sie
sich jedoch nicht zu sehr im Detail, insbesondere, wenn das System komplex ist.
Ein "Geschäftsprozess" (z. B. "Kundenauftragsbearbeitung") wird in der Regel von einer "Anwendung" (ein IT-Begriff)
oder mehreren Anwendungen implementiert. In jeder Anwendung gibt es gewöhnlich viele "IT-Transaktionen", z. B.
"Lagerbestand abfragen" oder "Kundenbrief generieren".
Verschiedene Communitys verwenden eigene Namen, um die Einheiten zu beschreiben, auf die wir versuchen, uns zu einigen.
Beispielsweise kann das Wort "Transaktion" für Personen mit Erfahrung in der Anwendungsentwicklung etwas völlig anderes
bedeuten als für ein Infrastrukturteam. Es ist wichtig zusammenzuarbeiten, um die Namen zu korrelieren und die
Informationen anschließend zu erfassen.
4.2 "Geschäftsvolumen und -größe"
Ermitteln und dokumentieren Sie Informationen zu Volumen und Größe für jede der Einheiten, die unter 4.1:
"Messeinheiten" genannt sind, z. B.:
-
Wie viele Benutzer werden voraussichtlich die einzelnen Geschäftsprozesse oder Anwendungen verwenden
(durchschnittlich und Stoßzeiten).
-
Wann sind die Spitzenwerte zu erwarten (täglich, wöchentlich, monatlich usw.).
-
Welche Rate muss bei der Verarbeitung von Transaktionen durchschnittlich und zu Stoßzeiten erreicht werden.
-
Die Anzahl der Datenelemente und Instanzen in jeder Datengruppe und ihre Größen.
4.3 "Leistungskriterien für Geschäftsprozesse"
Der Auftraggeber hat möglicherweise Leistungskriterien für einige oder alle Geschäftsprozesse spezifiziert. Denken Sie
jedoch auch daran, Leistungsziele für Systemunterstützungsprozesse (z. B. Systemdatensicherung) und
Anwendungsentwicklungsprozesse, sofern angegeben, zu dokumentieren. Dokumentieren Sie für jede Kategorie Folgendes:
-
Die Anforderungen in Bezug auf Antwort- und Bearbeitungszeiten für jede Kategorie.
-
Wo sollen diese gemessen werden.
-
Sind zu unterschiedlichen Zeiten unterschiedliche Kriterien anzusetzen (z. B. geringe Systemauslastung/über Nacht).
-
Müssen die Kriterien auch bei Wiederherstellung oder Zurücksetzen erfüllt werden.
-
Ist eine Leistungsgarantie erforderlich.
-
Welche Auswirkungen hat es auf die Parteien, wenn die Leistungsanforderungen nicht erfüllt werden.
-
Beschreiben Sie die Mindestleistungsbedingungen, die der Geschäftsprozess erfüllen muss, um als verfügbar zu gelten
(d. h. den Punkt, bis zu dem das System als "nicht verfügbar" und nicht als "langsam" gilt).
-
Wenn bereits eine Standardsoftwarelösung ausgewählt wurde, müssen Sie sicherstellen, dass Sie Zugriff auf deren
Leistungskenndaten haben. Sie benötigen unter Umständen nicht alle sofort, sollten aber wissen, woher Sie sie
bekommen, das Sie sie wahrscheinlich in künftigen Aufgaben benötigen. Fordern Sie die Informationen besser sofort
an, da manche Fremdanbieter die erforderlichen Zahlen möglicherweise nicht gleich liefern können.
Der empfohlene Ansatz für die Formulierung von Verfügbarkeitsanforderungen ist wie folgt:
-
Ermitteln Sie die wahren Benutzer des Systems, die Geschäftsprozesse, die sie ausführen, und die Zeiten, zu denen
die Benutzer diese Prozesse ausführen.
-
Analysieren Sie die Auswirkungen der Serviceverfügbarkeit (bzw. Nichtverfügbarkeit) auf die Fähigkeit der Benutzer,
ihre Geschäftsziele zu erfüllen.
-
Legen Sie Verfügbarkeitsanforderungen fest, die direkt widerspiegeln, was die Benutzer erfordern, um ihre
Geschäftsziele zu erreichen.
-
Wenn bereits eine Standardsoftwarelösung ausgewählt wurde, können Struktur und Design dieser Lösung signifikante
Auswirkungen auf die Verfügbarkeitsmerkmale der Anwendung für die Benutzer haben. Ein Paket, das nicht dafür
ausgelegt ist, im Dauerbetrieb zu arbeiten, kann im Dauerbetrieb schwierig zu nutzen sein, insbesondere was die
Zeiten für Pflege und Stapelverarbeitung anbelangt.
Halten Sie sich beim Formulieren der Verfügbarkeitsanforderungen an die folgenden Richtlinien:
-
Anstatt "globale" Anforderungen für das gesamte System zu formulieren, definieren Sie differenzierte
Verfügbarkeitsanforderungen auf niedriger Ebene (z. B. für einzelne Prozesse, Benutzergruppe, Datengruppen usw.).
Dies gibt dem Designer mehr Flexibilität, um auf die Bedürfnisse der Benutzer einzugehen, und ist ein besonders
wichtiger Faktor für Systeme, die sehr hohe Anforderungen an eine ständige Verfügbarkeit haben.
Beispiele:
-
Die Anweisung "Das System muss 24 Stunden pro Tag verfügbar sein, um Benutzern in New York und Hongkong zur
Verfügung zu stehen" gibt dem Designer sehr viel weniger Designflexibilität als die Anweisung "Benutzer in New York
müssen in der Lage sein, Transaktionen mit ihren Daten von 7 Uhr morgens bis 7 Uhr abends ihrer Zeit durchzuführen,
und Benutzer in Hongkong müssen in der Lage sein, Transaktionen mit ihren Daten von 7 Uhr morgens bis 7 Uhr abends
ihrer Zeit durchzuführen". Im letzteren Fall hat der Designer die Flexibilität, Wartungsarbeiten an den Daten oder
Systemkomponenten einer Zeitzone durchzuführen, während die andere Zeitzone noch mitten in ihrem Produktionstag
ist.
-
In einer Geldautomatenwendung kann es kritisch sein, Montags morgens um 3 Uhr Einzahlungen entgegen zu nehmen und
Bargeld auszuzahlen, während die Bereitstellung exakter Kontostände um diese Uhrzeit weniger kritisch sein kann.
-
Unterscheiden Sie zwischen Verfügbarkeitsmerkmalen, die erwünscht sind, und solchen, die verbindlich sind.
Beispiel: "Der GA MUSS in der Lage sein, 24 Stunden am Tag Einzahlungen entgegen zu nehmen und Bargeld auszuzahlen.
Es wird GEWÜNSCHT, dass der GA den Kunden rund um die Uhr exakte Kontostände liefert. Gelegentlich Unterbrechungen
beim Kontostandsabfrageprozess können zugestanden werden, aber diese MÜSSEN weniger als 10 Minuten dauern und
zwischen 3:00 und 4:00 morgens auftreten".
-
Wenn sich die Nichterfüllung eines bestimmten Verfügbarkeitsziels nicht direkt auf die Fähigkeit der Benutzer
auswirkt, ihre Geschäftsziele zu erreichen, ist dieses Ziel unter Umständen nicht tauglich, um als
Verfügbarkeitsanforderung für das System formuliert zu werden.
-
Verfügbarkeitsanforderungen, die nur indirekt die für den Kunden wahrnehmbare Verfügbarkeit widerspiegeln (z. B.
"Die IMS-Steuerregion muss aktiv sein"), sind im Allgemeinen nicht so hilfreich wie Anforderungen, die die direkte
Verfügbarkeit beschreiben (z. B. "Kassierer müssen die Prozesse X und Y ausführen können").
5.2 "Geplante Servicezeiten"
Geben Sie für alle Geschäftsprozesse und Gruppen von Benutzern, die diese Prozesse ausführen müssen, die Stunden an, in
denen der Benutzer in der Lage sein muss, den jeweiligen Prozess auszuführen. Dies gilt auch für die Prozesse, die
Benutzergruppen nicht direkt zugeordnet sind.
Wenn es Benutzergruppen in unterschiedlichen Zeitzonen (denken Sie an das vorherige Beispiel mit New York und
Hongkong), behandeln Sie diese als separate Benutzergruppen.
Zeigen Sie auch solche Zeiträume auf, in denen die Anwendungen möglicherweise nicht benötigt wird (z. B.
Betriebsferien). (Dies gibt dem Designer die Flexibilität, solche Zeiträume für ausgedehnte Wartungsarbeiten zu
verwenden.) Welche Änderungen werden voraussichtlich in diesen Servicezeiten in der projektierten Lebensdauer der
Anwendung durchgeführt?
Die Servicezeiten des Systems können auch durch die anderer Systeme betroffen sein, mit denen das System interagiert.
Wie werden sich die geplanten Servicezeiten des Systems voraussichtlichen in der projektierten Lebensdauer
voraussichtlichen ändern?
5.3 "Kosten für Serviceausfälle"
Sie müssen den Einfluss auf die Geschäftsabläufe, die finanziellen Kosten und die Risiken verstehen, die mit
Serviceunterbrechungen während der geplanten Servicezeiten in Zusammenhang stehen.
Um festzustellen, welche Verfügbarkeitsanforderungen für das System wirklich wichtig sind, sollten Sie sich die
Geschäftsprozesse und Benutzergruppen anschauen und dann einschätzen, welchen Einfluss die folgenden Faktoren auf die
Geschäftsabläufe haben könnten:
-
Eine kurze Unterbrechung oder eine Periode mit inakzeptabel langsamen Antwortzeiten während der geplanten
Servicezeiten. Definieren Sie "kurz" und "inakzeptabel langsam" für diese eine Anwendung (siehe "Leistungskriterien
für Geschäftsprozesse").
-
Mehrere länger andauernde Serviceunterbrechungen während der genannten Zeiten (eine Minute, ein paar Minuten, 15
Minuten, 30 Minuten, eine Stunde, zwei Stunden, vier Stunden usw.).
-
Lang andauernde Serviceunterbrechungen (eine Schicht, ein Tag, mehrere Tage usw.).
-
Berücksichtigen Sie auch alle Prozesse, die nicht direkt einer Benutzergruppe zugeordnet sind (z. B.
Scheckabrechnung über Nacht).
Wenn Sie die Auswirkungen jedes Ausfalls bewerten, müssen Sie Ausweichprozeduren identifizieren und überlegen, wie
diese die tatsächlichen Auswirkungen des Ausfalls auf den Geschäftsablauf mindern können.
Versuchen Sie, diese Auswirkungen in Kosten zu quantifizieren (Kosten für Verlust von Mitarbeitern oder Produktivität
von Einrichtungen, Wert des entgangenen Geschäfts, geschätzter Verlust für künftige Geschäfte aufgrund von
Kundenunzufriedenheit, Zinsaufwände, Vertragsstrafen usw.).
Tragen Sie so viele Antworten wie möglich zusammen, um Unterschiede in den Kosten und Risiken für Ausfälle mit
unterschiedlicher Länge, zu unterschiedlichen Tageszeiten, für geplante und ungeplante Ausfälle und deren Auswirkungen
auf Geschäftsprozesse oder Benutzer festzustellen.
Welche Änderungen in den geschäftlichen/finanziellen Auswirkungen einer Serviceunterbrechung sind während der geplanten
Lebensdauer des Systems zu erwarten?
Prüfen Sie jeden dieser vereinbarten wichtigen Geschäftsprozesse, um Alternativen zu finden, damit die kritischsten
Elemente dieser Prozesse weitergeführt werden können, falls Teile des Systems vorübergehend ausfallen. Die Fähigkeit,
den Betrieb vorübergehend mit eingeschränkter Geschäftsfunktion fortzusetzen, kann eine Möglichkeit sein, die
Auswirkungen von gegenseitigen Abhängigkeiten zwischen kritischen Prozessen und Daten auf die Verfügbarkeit zu
reduzieren.
Beispiele:
-
VOLLSTÄNDIGE FUNKTION 1 Bestandsdatensatz lesen und aktualisieren.
-
EINGESCHRÄNKTE FUNKTION 1 Aktualisierung des Bestandsdatensatzes eingeben und für spätere Verarbeitung in die
Warteschlange stellen.
-
VOLLSTÄNDIGE FUNKTION 2 Aktuellen Kontostand des Kunden lesen.
-
EINGESCHRÄNKTE FUNKTION 2 Kontostand des Kunden aus einer anderen Quelle lesen, die möglicherweise nicht auf dem
neuesten Stand ist.
-
VOLLSTÄNDIGE FUNKTION 3 Computertagebuch aktualisieren.
-
EINGESCHRÄNKTE FUNKTION 3 Gedruckte Version des Tagebuchs aktualisieren.
Der Systembetrieb mit eingeschränkter Funktion ist jedoch für die Geschäftsprozesse nur für eine bestimmte Zeit
akzeptabel. Beispielsweise darf das System nicht mehr als 24 Stunden mit einem veralteten Kundenkontostand arbeiten.
Wenn der Service während der geplanten Zeiten (siehe "Geplante Servicezeiten") ausfällt, richten sich die Auswirkungen
gewöhnlich nach der Dauer des Ausfalls und anderen Bedingungen. Einige Ausfälle haben nur geringfügige Auswirkungen auf
die Fähigkeit der Benutzer, ihre Geschäftsprozesse auszuführen (kurze Ausfallzeiten, Ausfälle zu Tageszeiten mit
geringer Arbeitslast, Ausfälle, die sich nur auf einen Teil der Benutzergruppe auswirken, oder Ausfälle, für die eine
angemessene manuelle Rücksetzprozedur vorhanden ist). Andere Ausfälle, z. B. länger andauernde oder solche, die zu
"kritischen" Zeiten am Tag auftreten, können wesentlich mehr Auswirkungen haben.
Beispiele:
-
Ein kurzer Ausfall der Steuerungsprozesse für eine Fertigungsanlage kann geringfügige Auswirkungen auf die
Produktivität haben, da die Arbeit basierend auf zuvor gedruckten Fertigungsaufträgen fortgesetzt werden kann und
die Änderungen für spätere Eingabe manuell dokumentiert werden können. Ein Ausfall, der länger als 60 Minuten
dauert, kann jedoch dazu führen, dass die Anlage für den verbleibenden Teil der Schicht heruntergefahren werden
muss.
-
Der Ausfall eines Verrechnungssystem mit hohen Dollarumsätzen in der letzten Börsenstunde kann erhebliche
Zinsaufwände oder Vertragsstrafen zur Folge haben.
-
Polizei- und Feuerwehr können unter Einsatz einer manuellen Ausweichlösung auch dann weiterhin auf
lebensbedrohliche Notfälle reagieren, wenn ein System in der Notrufzentrale ausfällt. Aufgrund der erhöhten
Arbeitslast des Disponenten können die Reaktionszeiten jedoch zunehmen, was unter Umständen Leben gefährden kann.
-
Der Ausfall eines Flugbuchungs- oder Hotelreservierungssystems zu Spitzenzeiten kann nicht nur zu kurzfristigen
Geschäftsverlusten führen (die Kunden wenden sich an einen Mitbewerber und machen dort ihre Buchungen), sondern
auch langfristige Folgen haben, wenn die Kunden so unzufrieden sind, dass sie auch zukünftig eine andere
Fluggesellschaft oder ein anderes Hotel vorziehen.
5.4 "Verfügbarkeits und Wiederherstellungskriterien"
Identifizieren Sie die Verfügbarkeits- und Wiederherstellungskriterien für "normale" Situationen.
Schließen Sie "Katastrophensituationen" aus, z. B. längerer Ausfall der gesamten Datenverarbeitungsanlage.
Entwickeln Sie basierend auf den Kosten und Risiken, die Sie unter "Kosten für Serviceausfälle" identifiziert haben,
eine Spezifikation der Verfügbarkeitskriterien, die erfüllt werden müssen, damit Benutzergruppen die ihnen zugewiesenen
Geschäftsprozesse ungestört ausführen können. Solche Kriterien können in folgender Form spezifiziert werden:
-
Prozentsatz der Ausfälle, die innerhalb einer bestimmten Anzahl von Minuten/Sekunden behoben werden.
-
Wöchentliche/monatliche/jährliche Höchstdauer, während der ein Benutzer eine bestimmte Funktion nicht ausführen
kann.
Sie müssen Faktoren wie Unterschiede zwischen geplanten und nicht geplanten Ausfällen, Ausfallzeiten (z. B. "kritische"
und unkritische Zeiträume), Anzahl der betroffenen Benutzern usw. möglichst genau spezifizieren.
Geben Sie keine unnötig strengen Verfügbarkeitskriterien an, da sich dies auf die Implementierungskosten auswirken
könnte. Wenn wesentliche Kosten oder Risiken anhand von bestimmten Ausfallbedingungen nicht bestimmt werden können,
kann dies ein Hinweis darauf sein, dass diese Ausfallbedingungen nicht in die dokumentierten Verfügbarkeitskriterien
aufgenommen werden sollten .
Wenn unter "Geplante Servicezeiten" angegeben ist, dass sich die geplanten Servicezeiten wahrscheinlich ändern, oder
unter "Kosten für Serviceausfälle" angegeben ist, dass sich die Kosten oder Risiken für eine Serviceunterbrechung
wahrscheinlich während der vorgesehenen Lebensdauer des Systems ändern, müssen Sie schätzen, wie sich die
Verfügbarkeitskriterien dementsprechend ändern.
Wenn mit Verschlüsselung gearbeitet werden soll, sind weitere Aspekte bezüglich Wiederherstellung und Verfügbarkeit zu
berücksichtigen. Beispiele:
-
Die Möglichkeit, vertrauliche Informationen wiederherzustellen, die außerhalb des Systems aufbewahrt werden.
-
Die Anforderung sicherzustellen, dass durch Verschlüsselung geschützte Daten einhergehend mit der Wiederherstellung
der entsprechenden Chiffrierschlüssel wiederhergestellt werden.
5.5 "Wiederherstellung nach einem Katastrophenfall?"
Ist eine Wiederherstellung nach einem Katastrophenfall in diesem Designprojekt erforderlich (Verfügbarkeit während
"Katastrophensituationen", z. B. längerer Ausfall der gesamten Datenverarbeitungsanlage)? Wenn ja, wie lauten die
Kriterien für eine solche Wiederherstellung?
Wahrscheinlich erfordern nicht alle Geschäftsprozesse Funktionen für eine Wiederherstellung nach einem
Katastrophenfall. Wählen Sie nur die Prozesse aus, die kritisch sind und eine Wiederherstellung nach einem
Katastrophenfall erfordern. Selbst in solchen Prozessen müssen nicht alle Funktionen abgedeckt sein.
-
Wie schnell muss der Service wieder verfügbar sein? Wird für die Bestimmung des Zeitraums der Zeitpunkt des
Ausfalls oder der Zeitpunkt der Entscheidung, auf ein fernes System auszuweichen, herangezogen?
-
Welche Bedingungen müssen vorliegen, dass die Organisation entscheidet, auf ein fernes System und nicht auf ein
lokales System auszuweichen?
-
Wie aktuell müssen die Daten auf dem fernen System sein, damit die Geschäftsprozesse fortgesetzt werden können
(sekundengenau, Abweichung von einigen Minuten, Daten des vorherigen Tags akzeptabel)?
-
Wann wird der Service zum ersten Mal vom fernen System aus wiederhergestellt?
-
Zu einem zukünftigen Zeitpunkt?
-
Welche Wiederherstellungspriorität weist das ferne System diesen Anwendungen im Vergleich mit anderen
Geschäftsanwendungen zu, die von demselben Datenverarbeitungssystem abhängig sind?
Es können unterschiedliche Kriterien für unterschiedliche Teile des Systems oder je nach Typ des Katastrophenfalls
angewendet werden.
Welche Änderungen an den genannten Anforderungen an die Wiederherstellung nach einem Katastrophenfall werden während
der vorhergesehenen Lebensdauer der Anwendung erwartet?
5.6 "Weitere Hinweise zum Verfügbarkeitsdesign"
Um ein System zu entwerfen, das möglichst schnell wiederhergestellt werden kann, muss der Designer wissen, welche
Freiheiten er bei der Implementierung der Anwendung hat - natürlich unter Einhaltung der funktionalen Anforderungen der
Anwendung. Im Folgenden sind einige Fragen aufgeführt, die hilfreich für den Designer sein können:
1. Gibt es für die Ausführung erforderlicher Wartungsaufgaben Zeiträume, in denen das System
a. Abfragen, aber keine Aktualisierungen durchgeführt?
b. Aktualisierungsanfragen vom Benutzer akzeptiert, aber die Datenbank erst dann aktualisiert wird, wenn die
Wartungsaufgaben abgeschlossen sind?
2. Ist es bei einem Ausfall, der die Wiederherstellung von Daten erfordert, wichtiger
c. den Service möglichst schnell wiederherzustellen, selbst wenn dies bedeuten würde, dass Daten verwendet werden,
die nicht alle auf dem neuesten Stand sind, oder
d. alle Daten im aktuellen Zustand wiederherzustellen, bevor der Service wieder verfügbar gemacht wird, selbst wenn
dies länger dauert?
3. Falls sich zum Zeitpunkt des Ausfalls eine Benutzeranforderung in Bearbeitung befindet, kann dem Benutzer zugemutet
werden, dass er die Anforderung nach der Wiederherstellung des Service erneut eingibt?
4. Gibt es nicht technische Aspekte, die sich auf die Verfügbarkeit des Systems auswirken (z. B. Geschäftsstrategie,
die besagt, dass Prozess A erst dann Benutzern zur Verfügung gestellt werden darf, wenn auch Prozess B verfügbar ist)?
Wird erwartet, dass sich die oben genannten Designüberlegungen mit der Zeit ändern?
Für Prozesse, die geschäftskritisch sind, ist es hilfreich, Alternativen zu ermitteln, die es ermöglichen, die
kritischsten Elemente dieser Prozesse als betriebsfähig erscheinen zu lassen, selbst wenn Teile des Systems
vorübergehend nicht verfügbar sind. Die Fähigkeit, den Betrieb vorübergehend mit eingeschränkter Geschäftsfunktion
fortzusetzen, kann eine Möglichkeit sein, die Auswirkungen von gegenseitigen Abhängigkeiten zwischen kritischen
Prozessen und Daten auf die Verfügbarkeit zu reduzieren.
6.1 "Sicherheitsanforderungen"
1. Zu schützende Daten identifizieren
2. Art der Sicherheitsrisiken identifizieren, denen jeder Typ von Daten ausgesetzt ist:
-
Versehentliche Beschädigung oder Zerstörung
-
Absichtliche Beschädigung oder Zerstörung
-
Betriebsspionage
-
Betrug
-
Hackerangriffe
-
Viren
1. Risiken für physische Sicherheit identifizieren:
-
Diebstahl von Komponenten
-
Unbefugter physischer Zugriff
-
Physische Sicherheit von Benutzern
2. Personen identifizieren, von denen diese Risiken ausgehen können:
-
Personal im Rechenzentrum
-
Andere IT-Mitarbeiter (z. B. Entwicklung)
-
Andere Mitarbeiter innerhalb der Organisation
-
Personen außerhalb der Organisation
3. Alle speziellen oder ungewöhnlichen Sicherheitsanforderungen identifizieren, insbesondere in Bezug auf:
-
Zugriff auf das System
-
Verschlüsselung von Daten
-
Überprüfbarkeit
4. Gibt es allgemeine Richtlinien (z. B. Gesetz über die Auskunftspflicht öffentlicher Einrichtungen), die das
Sicherheitsdesign des Systems beeinflussen?
5. Einige Standardsoftwarelösungen haben eigene Sicherheitssubsysteme. Wenn Sie ein solches Paket verwenden, müssen
Sie sich mit den Sicherheitsfunktionen vertraut machen.
Zum Aufstellen und Klassifizieren der Sicherheitsanforderungen können Sie den folgenden Ansatz wählen:
1. Listen Sie die Objekte auf, die durch logische oder physische Sicherheitseinrichtungen geschützt werden müssen.
2. Identifizieren Sie die Risiken, denen jedes einzelne Objekt ausgesetzt ist. Typische Kategorien sind:
-
Anzeigezugriff (Verstoß gegen die Vertraulichkeit), z. B. Kontendaten, Kundenverzeichnisse, Patente.
-
Aktualisierungszugriff, d. h. Änderung der Daten in betrügerischer Absicht, zur Vertuschung oder zur
Entwendung von Geldmitteln.
-
Verlust von Assets, d. h. die Assets gelangen in Besitz anderer und stehen dem Eigner nicht mehr zur
Verfügung (Unterschied zum Verlust von Assets aufgrund eines Katastrophenfalls). Beispiele sind Listen mit
Kunden und potenziellen Kunden, Verträge usw.
Nicht alle Objekte sind allen zuvor genannten Risiken ausgesetzt.
3. Identifizieren Sie alle Gefahren, denen Ihre Umgebung ausgesetzt ist. Beispiele:
-
verärgerte Mitarbeiter
-
nicht autorisierte Mitarbeiter
-
geöffnete Terminalsitzungen in allgemein zugänglichen Bereichen
-
Hacker
-
Anzapfen von Leitungen
-
Verlust von Geräten (z. B. tragbaren PCs)
4. Bestimmen Sie die Bedrohungen für jedes Objekt und ordnen Sie sie dem jeweiligen Sicherheitsrisiko zu.
Möglicherweise müssen Sie die Sicherheitsanforderungen für das Objekt sowohl an einer statischen Position (z. B. auf
einer Festplatte) als auch während der Übertragung überprüfen.
Wenn das Design vorsieht, dass sich das Objekt auch in nicht gesicherten Umgebungen befinden kann, müssen Sie unter
Umständen auf dieses Thema zurückkommen.
Die Sicherheitsaspekte einiger Systemdesigns können sehr anspruchsvoll sein. Sie können Ihre Designentscheidungen
maßgeblich beeinflussen. Sie könnten sogar der Anlass dafür sein, dass ansonsten taugliche Optionen für die Struktur-
und Komponentenauswahl verworfen werden müssen. Legen Sie sich jetzt also definitiv fest, ob das zu entwerfende System
besonders anspruchsvolle Sicherheitsanforderungen stellt. Beispiele:
-
ein sensibles militärisches System
-
ein Übertragungssystem für hohe Geldsummen
-
ein System, das vertrauliche persönliche Informationen bearbeitet
Wenn Sie der Meinung sind, dass besondere Sicherheitsanforderungen vorliegen, sollten Sie einen Sicherheitsexperten
oder Fachmann hinzuziehen, der Sie bei den Designaspekten Ihres Systems unterstützt.
Die Anforderungen an die Benutzerfreundlichkeit definieren, wie benutzerfreundlich die Benutzerschnittstelle sein muss.
Die Anforderungen an die Benutzerfreundlichkeit sollten die Mindestansprüche definieren, die das System erfüllen muss.
Die Anforderungen sollten nicht festlegen, zu was das System Ihrer Meinung nach in der Lage ist. Anders ausdrückt, die
Anforderungen an die Benutzerfreundlichkeit sollten kein Ziel, d. h. keine Obergrenze sein. Anforderungen an die
Benutzerfreundlichkeit sollten das absolute Mindestmaß für die Verwendbarkeit des Systems beschreiben. Das heißt jedoch
nicht, dass Sie die Benutzerfreundlichkeit nicht verbessern können, wenn die Anforderungen an die
Benutzerfreundlichkeit erfüllt sind.
Es das System erbringen muss, um verwendbar zu sein, richtet sich häufig danach, welche Alternativen es zur Verwendung
des Systems gibt. Es ist angemessen zu fordern, dass das System wesentlich benutzerfreundlicher als die Alternativen
ist. Beispiele für Alternativen sind:
-
vorhandene manuelle Prozeduren,
-
traditionelle Systeme,
-
Konkurrenzprodukte,
-
frühere Versionen des Systems.
Anforderungen an die Benutzerfreundlichkeit können auch dem Bedarf entspringen, das neue System wirtschaftlich zu
rechtfertigen. Wenn der Kunde 3 Millionen Euro für das neue System bezahlen muss, möchte er unter Umständen
Anforderungen an die Benutzerfreundlichkeit stellen, die ihm möglicherweise 1 Million Euro pro Jahr in Folge der
geringeren Arbeitslast seiner Mitarbeiter einsparen.
Im Folgenden finden Sie verschiedene Beispiele für allgemeine Anforderungen an die Benutzerfreundlichkeit:
-
Maximale Ausführungszeit: Wie lange darf ein geschulter Benutzer für die Ausführung eines allgemeinen Szenarios
benötigen.
-
Maximale Fehlerrate: Wie viele Fehler macht ein geschulter Benutzer durchschnittlich in einem allgemeinen
Szenario.
Die einzigen Fehler, die sich zu messen lohnen, sind solche, die nicht behebbar sind und die negative Auswirkungen
auf die Organisation haben, z. B. Geschäftsverlust oder Beschädigung überwachter Hardware. Wenn die einzige
Konsequenz eines Fehlers darin besteht, dass Zeit für die Fehlerbehebung aufgewendet werden muss, wirkt sich dies
auf die gemessene Ausführungszeit aus.
-
Einarbeitungszeit: Wie lange dauert es, bis der Benutzer ein Szenario schneller ausführen kann, als für die
maximale Ausführungszeit angegeben ist.
Das folgende Beispiel veranschaulicht einige spezielle Anforderungen an die Benutzerfreundlichkeit für einen
Anwendungsfall "Eingehende Mail verwalten".
-
Der Mail-Benutzer muss in der Lage sein, Mail-Nachrichten mit einem Mausklick anzuordnen.
-
Der Mail-Benutzer muss in der Lage sein, den Text seiner Mails über Tasten auf der Tastatur durchzublättern.
-
Der Mail-Benutzer darf beim Lesen vorhandener Mails nicht durch den Eingang neuer Mails gestört werden.
|