Richtlinie: Softwareanforderungsspezifikation
Die Softwareanforderungsspezifikation (SRS, Software Requirements Specification) sammelt und organisiert alle mit dem Projekt in Zusammenhang stehenden Anforderungen. Diese Richtlinie beschreibt, wie Sie eine Softwareanforderungsspezifikation erstellen.
Beziehungen
Hauptbeschreibung

Erläuterung

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.

Dokument oder Paket?

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).

Von der Vision zur Softwareanforderungsspezifikation

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.

Lebendes Artefakt

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.

Referenzstandard der Projektmitarbeiter

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.

Funktionale Anforderungen definieren

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.

Nicht funktionale Anforderungen definieren

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.

1 Allgemein

1.1 Annahmen und Probleme

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.

1.2 Geographische Organisation

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.

2 Vorgaben

2.1 Vorausgewählte Anwendungspakete?

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.

2.2 Weitere Vorgaben

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?

2.3 Besondere Hardware?

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
2.4 Vorhandene Daten?

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?

3 Standards

3.1 Technische Architektur / Strategischer Plan

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.

3.2 Netzarchitektur

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.
3.3 Verbindungsrichtlinien

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.
3.4 Weitere Richtlinien?

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 Zahlen

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.

5. Verfügbarkeit

5.1 Empfehlung zur Verfügbarkeit

Der empfohlene Ansatz für die Formulierung von Verfügbarkeitsanforderungen ist wie folgt:

  1. 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.
  2. Analysieren Sie die Auswirkungen der Serviceverfügbarkeit (bzw. Nichtverfügbarkeit) auf die Fähigkeit der Benutzer, ihre Geschäftsziele zu erfüllen.
  3. Legen Sie Verfügbarkeitsanforderungen fest, die direkt widerspiegeln, was die Benutzer erfordern, um ihre Geschäftsziele zu erreichen.
  4. 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 Sicherheit

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.

7 Benutzerfreundlichkeit

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.