Aufgabe: Ergänzende Spezifikationen entwickeln |
|
 |
Diese Aufgabe erfasst die Anforderungen, die sich nicht auf spezifische Anwendungsfälle anwenden lassen. |
|
Zweck
Anforderungen erfassen, die nicht von einem Anwendungsfall
repräsentiert werden. |
Beziehungen
Rollen | Hauptrollen:
| Zusätzliche Rollen:
| Unterstützende Rollen:
|
Eingaben | Verbindlich:
| Optional:
| Extern:
|
Ausgaben |
|
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.
|
|
Eigenschaften
Mehrere Vorkommen |  |
Ereignisgesteuert |  |
Fortlaufend |  |
Optional |  |
Geplant |  |
Wiederholt anwendbar |  |
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
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|