Aufgabe: Ergänzende Spezifikationen entwickeln
Diese Aufgabe erfasst die Anforderungen, die sich nicht auf spezifische Anwendungsfälle anwenden lassen.
Disziplinen: Anforderungen
Zweck
Anforderungen erfassen, die nicht von einem Anwendungsfall repräsentiert werden.
Beziehungen
Hauptbeschreibung

Bei allen Aktivitäten, die hinsichtlich der Anforderungen ausgeführt werden und auf den erfassten Angaben der Stakeholder basieren, werden die Anforderungen, die mit keinem spezifischen Anwendungsfall übereinstimmen, in der ergänzenden Spezifikation erfasst. In dieser Spezifikation können sowohl funktionale als auch nicht funktionale Anforderungen erfasst werden.  

Weitere Informationen zur Kategorisierung und Erfassung von Anforderungen finden Sie im Artikel Konzept: Anforderungen.

Stellen Sie sicher, dass alle Anforderungen so detailliert angeben sind, dass sie Designern, Testern und Dokumentationsautoren ausgehändigt werden können. Wenn Anforderungen zurückverfolgt oder in anderer Weise formal verwaltet werden, sollten Sie sich vergewissern, dass jede Anforderung klar identifiziert und gekennzeichnet ist.

Schritte
Funktionale Anforderungen, die nicht anwendungsfallspezifisch sind, erfassen

Funktionale Anforderungen beschreiben die Verhaltensweisen (Funktionen oder Services) des Systems, das Ziele, Aufgaben oder Aktivitäten des Benutzers unterstützt [siehe Veröffentlichung MAL2001].

Viele der funktionalen Anforderungen werden zwar durch einen Anwendungsfall dokumentiert, einige der funktionalen Anforderungen können jedoch nicht auf bestimmte Anwendungsfälle angewendet werden. Beispielsweise sollten funktionale Anforderungen wie Berichterstellung, Protokollierung, Drucken, Sicherheit, Lizenzunterstützung/-umsetzung, Authentifizierungsanforderungen etc. in der ergänzenden Anforderung dokumentiert werden.  

Gibt es viele systemweite funktionale Anforderungen, ist es wichtig, sie in diesem Abschnitt zu ordnen. Ein typisches Ordnungskriterium ist das Feature oder die Feature-Gruppe, es sind jedoch auch alternative Methoden möglich. Beispielsweise kann auch das Ordnen nach Benutzer oder Subsystem sinnvoll sein.

Das 'F' in "FURPS+ steht für funktionale Anforderungen. Weitere Informationen zu "FURPS+" finden Sie im Abschnitt Konzept: Anforderungen.

Systemmerkmale erfassen

Nicht funktionale Anforderungen beinhalten Merkmale und Vorgaben [siehe Veröffentlichung MAL2001]. In diesem Schritt werden Merkmale diskutiert. Die Vorgaben werden in einem separaten Schritt behandelt.

Als Systemmerkmale werden die Merkmale des Systems bezeichnet, die für die Stakeholder interessant sind und Einfluss darauf haben, wie zufrieden sie mit dem System sind. [siehe Veröffentlichung MAL2001]

Die Zeichenfolge "URPS" im Namen "FURPS+" steht für die Merkmale. Die Problemstellungen der einzelnen Anforderungskategorien lauten wie folgt:

  • U steht für Benutzerfreundlichkeit: Ästhetik und Konsistenz in der Benutzeroberfläche.
  • R steht für Zuverlässigkeit: Verfügbarkeit (aktive Systemzeit), Genauigkeit der Systemberechnungen und die Fähigkeit des Systems zur Fehlerbehebung.
  • P steht für Leistung: Durchsatz, Antwortzeit, Wiederanlaufzeit, Initialisierungszeit, Beendigungszeit.
  • S steht für Servicefreundlichkeit: Testfähigkeit, Anpassungsfähigkeit, Wartungsfreundlichkeit, Kompatibilität, Konfigurierbarkeit, Installierbarkeit, Skalierbarkeit und Lokalisierbarkeit.

Weitere Informationen zu "FURPS+" und zur Erfassung nicht funktionaler Anforderungen finden Sie im Abschnitt Konzept: Anforderungen.

Je nach Anzahl der für das System zu dokumentierenden Merkmale können Sie Unterabschnitte für jeden dieser Merkmaltypen angeben.

Die folgenden Abschnitte enthalten einige Beispiele für die Arten der Informationen, die Sie für jedes dieser Merkmale erfassen möchten:

Benutzerfreundlichkeit

Bei der Beschreibung der Anforderungen für die Benutzerfreundlichkeit können Sie folgende Angaben machen:

  • Schulungszeit, die normale Benutzer bzw. professionelle Anwender benötigen, um bei bestimmten Operationen produktiv zu sein
  • Messbare Aufgabenzeiten für typische Aufgaben
  • Anforderungen hinsichtlich allgemeiner Standards für Benutzerfreundlichkeit, z. B. CUA-Standards von IBM oder GUI-Standards von Microsoft

Zuverlässigkeit

Bei der Beschreibung der Anforderungen für die Zuverlässigkeit können Sie folgende Angaben machen:

  • Verfügbarkeit. Geben Sie die verfügbare Zeit in Prozent (xx,xx %), die Betriebsstunden, die Zugriffe im Rahmen der Verwaltung, die Operationen mit verminderter Leistung usw. an.
  • Mittlere Zeit zwischen auftretenden Fehlern. Wird normalerweise in Stunden angegeben, kann aber auch in Tagen, Monaten oder Jahren angegeben werden.
  • Mittlere Reparaturzeit. Wie lang darf das System nach einem Fehler außer Betrieb sein?
  • Genauigkeit. Geben Sie die Genauigkeit (Auflösung) nach einem bekannten Standard an, der in der Systemausgabe erforderlich ist.
  • Maximalanzahl der Programmfehler oder Mängelrate. Wird normalerweise in Programmfehler/KLOC (pro Tausend Codezeilen) oder Programmfehler/Funktionspunkt angegeben.
  • Programmfehler oder Mängelrate. Wird in die Kategorien Untergeordnet, Wichtig und Kritisch eingeteilt. In der Anforderung bzw. den Anforderungen muss definiert sein, was mit einem "kritischen" Programmfehler gemeint ist, z. B. totaler Datenverlust oder die Unfähigkeit, bestimmte Komponenten der Systemfunktionalität zu nutzen.

Leistung

Bei der Beschreibung der Leistungsanforderungen können Sie folgende Angaben machen:

  • Antwortzeit für eine Transaktion (Durchschnittswert, Maximalwert)
  • Durchsatz (z. B. Transaktionen pro Sekunde)
  • Kapazität (z. B. die Anzahl der Kunden oder Transaktionen, die vom System bewältigt werden können)
  • Modi bei verminderter Leistung (was ist die richtige Betriebsart, wenn die Systemleistung sich in irgendeiner Form vermindert hat)
  • Ressourcennutzung: Speicher, Platte, Kommunikation usw.

Geben Sie bei der Dokumentation der Leistungsanforderungen unbedingt die spezifischen Antwortzeiten an. Geben Sie, soweit zutreffend, immer einen zugehörigen Anwendungsfall namentlich an.

Servicefreundlichkeit

Bei der Beschreibung der Anforderungen für die Servicefreundlichkeit können Sie folgende Angaben machen:

  • Codierungsstandards
  • Namenskonventionen
  • Klassenbibliotheken
  • Zugriffe im Rahmen der Verwaltung
  • Wartungsdienstprogramme.
Vorgaben erfassen

In diesem Schritt dokumentieren Sie alle Vorgaben für das Design in dem zu erstellenden System. Allgemein gesagt grenzt eine Vorgabe die Freiheit bei der Bereitstellung einer Lösung ein [siehe Veröffentlichung LEF2000]. Designvorgaben repräsentieren verbindliche Designentscheidungen. 

Vorgaben werden durch das Zeichen '+' in "FURPS+" symbolisiert und können wie folgt weiter kategorisiert werden:

  • Designvorgabe: Gibt die Optionen für die Architektur und/oder das Design eines Systems an oder schränkt diese ein. Beispielsweise kann angegeben werden, dass eine relationale Datenbank für die persistente Speicherung verwendet wird.
  • Implementierungsvorgabe: Eine Implementierungsanforderung spezifiziert die Codierung bzw. Konstruktion eines Systems oder schränkt sie ein. Beispiele: erforderliche Standards, Prozesse, Tools, Implementierungssprachen, Hardwareplattformen, Betriebssysteme, Komponenten von Drittherstellern, Klassenbibliotheken und Ressourcengrenzen (Verwendung von Speicher- oder Plattenspeicherplatz).
  • Vorgabe für Schnittstelle: Gibt ein externes Element an, mit dem ein System interagieren muss, oder Vorgaben zu Formaten oder anderen Faktoren, die innerhalb einer solchen Interaktion verwendet werden. Beispiel: Bildung einer Schnittstelle zu einem externen System über Nachrichtenwarteschlangen.
  • Physische Vorgabe: Gibt eine physische Vorgabe für die Systemhardware an, z. B. Form, Größe oder Gewicht.

Je nach Anzahl der für das System zu dokumentierenden Vorgaben können Sie Unterabschnitte für jeden dieser Vorgabentypen angeben. Zusätzlich gilt Folgendes:

  • Wenn zu den Anforderungen auch der Kauf von Komponenten Dritter gehört, müssen Sie alle anwendbaren Vorgaben für Lizenzierung und Nutzung sowie alle zugeordneten Kompatibilitäts-, Interoperabilitäts- oder Schnittstellenstandards unbedingt dokumentieren. Es wird empfohlen, einen separaten Abschnitt pro gekaufter Komponente anzulegen.
  • Wenn die Anforderungen spezifische Schnittstellenanforderungen einschließen, wird empfohlen, separate Abschnitte für die verschiedenen Schnittstellentypen (z. B. Benutzer, Hardware, Software) bereitzustellen. Stellen Sie bei jeder Schnittstelle sicher, genügend Spezifikationen, Protokolle, Ports und logische Adressen usw. anzugeben, damit die Software entwickelt und gegen Schnittstellenanforderungen überprüft werden kann. Beachten Sie dabei Folgendes:
    • Beschreiben Sie im Falle von Benutzerschnittstellen die Benutzerschnittstellen, die von der Software implementiert werden sollen.
    • Geben Sie im Falle von Hardwareschnittstellen logische Strukturen, physische Adressen, erwartetes Verhalten usw. an.
    • Geben Sie im Falle von Softwareschnittstellen eine Beschreibung der Schnittstellen zu anderen Komponenten des Softwaresystems an. Dabei kann es sich um Komponenten handeln, die gekauft oder von anderen Anwendungen übernommen wurden oder für Subsysteme außerhalb des Bereichs dieses Systems entwickelt werden, mit denen diese Softwareanwendung jedoch interagieren muss.

Weitere Informationen zu "FURPS+" und zur Erfassung von Vorgaben finden Sie im Abschnitt Konzept: Anforderungen.

Kompatibilitätsanforderungen erfassen

Unter Kompatibilität fällt die Einhaltung von Standards (einschließlich Regelstandards, Codierungsstandards oder Regelstandards oder Stilhandbücher für Benutzeroberflächen) sowie die Einhaltung von Vorschriften im Zusammenhang mit Haftungsausschlüssen, Gewährleistungen, Copyrightvermerken, Patentvermerken, Wortmarken, Marken, und/oder Logos.

Kompatibilitätsanforderungen können durch andere Anforderungen realisiert werden (funktionale und nicht funktionale Anforderungen sowie Vorgaben). In diesen Fällen müssen die Anforderungen in den anwendbaren Abschnitten der ergänzenden Spezifikation detailliert dokumentiert werden, wie in den früheren Schritten beschrieben. Es ist jedoch wichtig, die Standards und Policys, die ein System unterstützen muss, zusammenzufassen. Die sich ergebenden Kompatibilitätsanforderungen können sich je nach Bedarf auf anwendbare detaillierte Anforderungen beziehen.

Je nach Anzahl der für das System zu dokumentierenden Kompatibilitätsanforderungen können Sie Unterabschnitte für die verschiedenen Arten der Kompatibilität, die das System beeinflussen, angeben.

Die folgenden Abschnitte enthalten einige Beispiele für die Arten von Informationen, die Sie für verschiedene Kompatibilitätsarten erfassen möchten:

Lizenzvoraussetzungen

Definieren Sie alle Lizenzvoraussetzungen oder andere Nutzungsbeschränkungen für die Software.

Gesetzliche Bestimmungen, Copyrightvermerke und andere Bemerkungen

Beschreiben Sie alle einzuhaltenden Vorschriften im Zusammenhang mit Haftungsausschlüssen, Gewährleistungen, Copyrightvermerken, Patentvermerken, Wortmarken, Marken, und/oder Logos.

Gültige Standards

Beschreiben Sie alle gültigen Standards sowie die spezifischen Abschnitte dieser Standards, die für das zu beschreibende System gültig sind. Das können gesetzliche, Qualitäts- und Regelstandards, Branchenstandards für Benutzerfreundlichkeit, Interoperabilität, Internationalisierung, Kompatibilität mit dem Betriebssystem usw. sein.

Dokumentationsanforderungen erfassen

In diesem Schritt beschreiben Sie die Anforderungen für die Dokumentation, falls vorhanden. Dokumentationsanforderungen können die Onlinehilfe sowie die Dokumentation für den Endbenutzer (z. B. Installationshandbücher, Benutzerhandbücher, Schulungsmaterial etc.) enthalten.  

Wie die Kompatibilitätsanforderungen steuern die Dokumentationsanforderungen andere Anforderungstypen. Dies betrifft insbesondere funktionale Anforderungen (das System muss den funktionalen Zugriff auf die Onlinehilfe unterstützen) sowie Anforderungen hinsichtlich der Benutzerfreundlichkeit (On-Demand-Zugriff auf Informationen zur Systemnutzung unterstützt die Benutzerfreundlichkeit des Gesamtsystems).  

Daher sollten die detaillierten Anforderungen, die die Dokumentationsanforderungen unterstützen, wie die Kompatibilitätsanforderungen in den anwendbaren Abschnitten der ergänzenden Spezifikation detailliert dokumentiert werden, wie in den früheren Schritten beschrieben. Die sich ergebenden Anforderungen können sich auf anwendbare detaillierte Anforderungen beziehen.

Je nach Anzahl der für das System zu dokumentierenden Dokumentationsanforderungen können Sie Unterabschnitte für die verschiedenen Arten der Dokumentation, die für das System bereitgestellt werden, angegeben.

Wichtige Hinweise

Die Anforderungen, die über Anwendungsfälle hinausgehen (möglicherweise systemweite Anforderungen) treiben die Entwicklung der Systemarchitektur oft voran. Tatsächlich können solche Anforderungen viel wichtiger sein als ihre eher domänenspezifischen (oder anwendungsfallspezifischen) Pendants. Wenn Sie z. B. lebenserhaltende medizinische Systeme entwickeln möchten, dann sind die Anforderungen bezüglich der Zuverlässigkeit kritisch.

Leider sind solche Anforderungen schwer zu erfassen und werden daher häufig übersehen. Diese Aufgabe beschreibt den gesamten Ansatz zur Erfassung dieser Anforderungen. Weitere Informationen zu einem "systematischen" Ansatz für die Erfassung dieser Anforderungen anhand spezifischer Fragebögen finden Sie in der Veröffentlichung [EEL2004].

Weitere Informationen