Inhalt
<Teamname>
Spezifikation der Softwareanforderungen**[1]**
für <System>
Version <x.y>
[Anmerkung: Die folgende Vorlage**[2]** basiert auf einer Vorlage von IBM. Texte in eckigen Klammern sind Anleitungen zum Ausfüllen des Dokumentes und sollten vor der Veröffentlichung des Dokuments gelöscht werden.]
Revisionsprotokoll
Änderungsdatum | Version | Beschreibung | Autor |
<tt/mm/jj> | <x.y> | <Details> | <Name> |
Inhaltsverzeichnis
1. Einführung
1.1 Verwendungszweck
1.2 Definitionen, Akronyme und Abkürzungen
2. Allgemeine Beschreibung
2.1 Geschäftschance
2.2 Problembeschreibung
2.3 Produktpositionierung
2.4 Benutzerübersicht
2.5 Benutzerumgebung
2.6 Bedarf und Features
2.7 Produktperspektive
2.8 Annahmen und Abhängigkeiten
3. Spezifische Anforderungen (Funktionale Anforderungen)
3.1 UML-Anwendungsfalldiagramm
3.2 Anwendungsfall-Spezifikationen und zugehörige UML-Diagramme
3.2.1 Anwendungsfall-Spezifikation und zugehöriges UML-Diagramm zu <Name des Anwendungsfalles>
3.2.2 Anwendungsfall-Spezifikation und zugehöriges UML-Diagramm zu <Name des Anwendungsfalles>
3.2.3 ...
4. Ergänzende Anforderungen (Nicht-funktionale Anforderungen)
4.1 Benutzungsfreundlichkeit
4.2 Zuverlässigkeit
4.3 Leistung
4.4 Servicefreundlichkeit
4.5 Designeinschränkungen
4.6 Anforderungen an die Onlinedokumentation für Benutzer und das Hilfesystem
4.7 Gekaufte Komponenten
4.8 Schnittstellen
4.8.1 Benutzerschnittstellen
4.8.2 Hardwareschnittstellen
4.8.3 Softwareschnittstellen
4.8.4 Übertragungsschnittstellen
4.9 Lizenzanforderungen
4.10 Rechtliche Hinweise, Copyright und Bemerkungen
4.11 Geltende Standards
Anhang
A Klassendiagramm
B ggf. UML-Sequenz- und Zustandsdiagramme
C Personas
D Storyboard
E Link auf den Online-Prototypen und Screenshots des Prototypen
Spezifikation der Softwareanforderungen
1. Einführung
[Die Einführung zur Spezifikation der Softwareanforderungen gibt einen Überblick über die gesamte Spezifikation. Die Einführung gibt außerdem Verwendungszweck, Umfang, Definitionen, Akronyme, Abkürzungen und Referenzen der Spezifikation der Softwareanforderungen an.]
[Anmerkung: Diese Spezifikation deckt sämtliche Softwareanforderungen für das System oder einen Teil des Systems ab.]
[Spezifikationen der Softwareanforderungen können ganz unterschiedlich aufgebaut sein. Wenn Sie sich über die hier gegebenen Erläuterungen hinaus mit diesem Thema beschäftigen möchten und sich für weitere Optionen beim Aufbau von Spezifikationen der Softwareanforderungen interessieren, sollten Sie [IEEE830-1998] lesen.]
1.1 Verwendungszweck
[Geben Sie den Verwendungszweck dieses Dokuments an.]
1.2 Definitionen, Akronyme und Abkürzungen
[Dieser Unterabschnitt enthält eine Definition aller Begriffe, Akronyme und Abkürzungen, damit die Spezifikation ordnungsgemäß interpretiert werden kann.](Glossar)
2. Allgemeine Beschreibung
[In diesem Abschnitt sind die allgemeinen Faktoren beschrieben, die das Produkt und die geltenden Anforderungen beeinflussen. Dieser Abschnitt enthält keine spezifischen Anforderungen. Er gibt vielmehr Hintergrundinformationen zu den Anforderungen, die im Abschnitt 3 detailliert aufgeführt sind, um sie besser verständlich zu machen. Nehmen Sie Punkte wie die folgenden auf:
2.1 Geschäftschance
[Beschreiben Sie kurz die Geschäftschance, die dieses Projekt bietet.]
2.2 Problembeschreibung
[Beschreiben Sie das Problem, das durch dieses Projekt gelöst werden soll. Sie können das folgende Format verwenden:]
Das Problem, | [Problem beschreiben] |
betrifft | [die vom Problem betroffenen Stakeholder] |
Auswirkung des Problems: | [Was sind die Auswirkungen des Problems?] |
Eine erfolgreiche Lösung besteht darin, | [Einige wichtige Vorzüge einer erfolgreichen Lösung auflisten] |
2.3 Produktpositionierung
[Allgemeine Aussage, die auf der höchsten Ebene zusammenfassend beschreibt, welche einzigartige Position das Produkt am Markt einnehmen soll. Das folgende Format kann verwendet werden:]
Für | [Zielgruppen], |
erfüllt das Produkt / ermöglicht das Produkt |
[Aussage zum Bedarf bzw. zur Gelegenheit] |
Das vorliegende Produkt (Produktname) | ist ein(e) [Produktkategorie] |
und zeichnet sich dadurch aus, dass | [Aussage zum entscheidenden Vorteil des vorliegenden Produkts (zwingender Kaufgrund)] |
Im Gegensatz zu | [primäre Konkurrenzprodukte] |
hat das vorliegende Produkt folgende Eigenschaften | [Aussage zur grundlegenden Abgrenzung von Konkurrenzprodukten] |
[Eine Produktpositionierung kommuniziert allen beteiligten Mitarbeitern den Zweck der Anwendung und die Bedeutung des Projekts.]
2.4 Benutzerübersicht
[Erstellen Sie eine zusammenfassende Liste aller identifizierten Benutzer.]
Name | Beschreibung | Zuständigkeiten |
[Geben Sie den Benutzertyp an.] | [Beschreiben Sie kurz, welche Funktion die Benutzer im Hinblick auf das System haben.] |
[Listen Sie die wichtigsten Zuständigkeiten des Benutzers im Hinblick auf das zu entwickelnde System auf. Beispiele:
|
2.5 Benutzerumgebung
[Geben Sie die Arbeitsumgebung des Zielbenutzers detailliert an. Einige Vorschläge zur Vorgehensweise:
Wie viele Personen sind an der Ausführung der Aufgabe beteiligt? Ändert sich die Anzahl?
Wie lang ist ein Aufgabenzyklus? Zeitraum pro Aktivität? Ändert sich das?
Gibt es eindeutige Umweltbedingungen: mobil, draußen, an Bord?
Welche Systemplattformen werden heute verwendet? Welche Plattformen sollen in Zukunft verwendet werden?
Welche anderen Anwendungen werden verwendet? Muss Ihre Anwendung in diese Anwendungen integriert werden?
Hier können Auszüge aus dem Geschäftsmodell aufgenommen werden, um die entsprechenden Aufgaben, Rollen usw. zu umreißen.]
2.6 Bedarf und Features
[Vermeiden Sie technische Details. Beschreiben Sie die Features nur allgemein. Konzentrieren Sie sich auf die erforderlichen Funktionen, und geben Sie an, warum (nicht wie) sie implementiert werden sollen.]
Bedarf | Priorität | Features |
2.7 Produktperspektive
[Dieser Unterabschnitt der Spezifikation der Softwareanforderungen setzt das Produkt in Relation zu vergleichbaren anderen Produkten und zur Umgebung des Benutzers. Falls es sich um ein vollkommen unabhängiges Produkt handelt, geben Sie dies hier an. Sollte das Produkt eine Komponente eines größeren Systems sein, müssen Sie in diesem Unterabschnitt angeben, wie die Systeme interagieren und welche Schnittstellen es zwischen den Systemen gibt. Am leichtesten lassen sich die Hauptkomponenten eines größeren Systems sowie deren Wechselwirkungen und externe Schnittstellen in einem Diagramm (z.B. einem UML-Paketdiagramm) darstellen.]
2.8 Annahmen und Abhängigkeiten
[Dieser Abschnitt beschreibt alle wichtigen Annahmen zur technischen Durchführbarkeit, zur Verfügbarkeit von Subsystemen oder Komponenten sowie weitere projektbezogene Annahmen, von denen die Wirtschaftlichkeit der Software, die in dieser Spezifikation der Softwareanforderungen beschrieben ist, abhängen kann.]
3. Spezifische Anforderungen (Funktionale Anforderungen)
[In diesem Abschnitt der Spezifikation der Softwareanforderungen sind alle Softwareanforderungen so detailliert angegeben, dass Entwickler ein System entwerfen können, das diese Anforderungen erfüllt, und dass Tester überprüfen können, ob das System den genannten Anforderungen gerecht wird. Wenn Sie mit Anwendungsfallmodellen arbeiten, werden diese Anforderungen in Anwendungsfällen und den geltenden ergänzenden Spezifikationen erfasst. Das ist in SWE II der Fall.]
3.1 UML-Anwendungsfalldiagramm
[Fügen Sie hier Ihr/e Anwendungsfalldiagramm/e ein. (Screenshot)]
3.2 Anwendungsfall-Spezifikationen in Form von UML-Aktivitätsdiagrammen
[Wenn Anwendungsfallmodelle erstellt werden, definieren die Anwendungsfälle häufig die meisten funktionalen Anforderungen des Systems und einige nicht funktionale Anforderungen.
Nehmen Sie in diesen Abschnitt die Anwendungsfall-Spezifikation zu jedem Anwendungsfall im obigen Anwendungsfalldiagramm oder zu ausgewählten Anwendungsfällen des Modells auf oder fügen Sie hier Verweise auf diese Spezifikationen ein. Stellen Sie sicher, dass jede Anforderung klar benannt ist.]
(Fügen Sie in den Unterkapiteln die zum jeweiligen Anwendungsfall gehörigen Anwendungsfall-Spezifikation in Form von Aktivitätsdiagrammen mit Schwimmbahnen sowie Vor- und Nachbedingungen ein.)
3.2.1 UML-Aktivitätsdiagramm zu <Name des Anwendungsfalles a>
(Screenshot des zugehörigen Aktivitätsdiagrammes)
.....
3.2.2 UML-Aktivitätsdiagramm zu <Name des Anwendungsfalles b>
...
3.2.3 ...
4. Ergänzende Anforderungen (Nicht-funktionale Anforderungen)
[Anforderungen, die nicht in den Anwendungsfällen enthalten sind, werden in ergänzenden Spezifikationen dokumentiert. Die speziellen Anforderungen aus diesen Spezifikationen, die für dieses Subsystem oder Feature gelten, sollten hier eingefügt und so weit präzisiert werden, dass sie das Subsystem oder Feature detailliert beschreiben. Sie können an dieser Stelle aber auch auf die einzelnen ergänzenden Spezifikationen verweisen. Stellen Sie sicher, dass jede Anforderung klar benannt ist.]
Wenn es zu einem Abschnitt keine relevanten Anforderungen gibt, löschen Sie diesen.
4.1 Benutzungsfreundlichkeit
[Dieser Abschnitt enthält alle Anforderungen mit Einfluss auf die Benutzungsfreundlichkeit. Beispiele:
- Geben Sie die Schulungszeit an, die erforderlich ist, bis normale und professionelle Benutzer bestimmte Operationen produktiv ausführen können.
- Geben Sie messbare Zeiten für typische Aufgaben an oder verwenden Sie die Benutzerfreundlichkeit bekannter Systeme, die bei den Benutzern beliebt sind, als Grundlage für die Benutzerfreundlichkeit des neuen Systems.
- Nennen Sie Anforderungen an die Konformität mit allgemeinen Standards für die Benutzerfreundlichkeit an, z. B. mit den CUA-Standards der IBM oder mit den GUI-Standards von Microsoft.]
4.2 Zuverlässigkeit
[Hier sollten Sie Anforderungen an die Zuverlässigkeit des Systems angeben. Vorschläge:
- Verfügbarkeit —Geben Sie die Verfügbarkeitszeit in Prozent an (xx,xx %), die Nutzungsdauer, den Wartungszugriff, den Betrieb im eingeschränkten Modus und dergleichen mehr.
- Mittlere Zeit zwischen auftretenden Fehlern — Diese Zeit wird normalerweise in Stunden angegeben, kann aber auch in Tagen, Monaten oder Jahren angegeben werden.
- Mittlere Reparaturzeit —Wie lange kann das System bei einem Ausfall außer Betrieb bleiben?
- Genauigkeit—Geben Sie die für Systemausgaben erforderliche Genauigkeit (Auflösung) und Präzision (nach bekanntem Standard) an.
- Maximale Programmfehler- oder Mängelrate — Diese Rate wird in der Regel in Programmfehlern pro tausend Codezeilen oder in Programmfehlern pro Funktionspunkt angegeben.
- Programmfehler- oder Mängelquote — Diese Quote wird als Anzahl geringfügiger, signifikanter und kritischer Programmfehler angegeben. Die Anforderungen müssen definieren, was unter einem “kritischen” Programmfehler zu verstehen ist (beispielsweise ein vollständiger Datenverlust oder die Unmöglichkeit, bestimmte Funktionen des Systems zu verwenden.]
4.3 Leistung
[Umreißen Sie in diesem Abschnitt die Leistungsmerkmale des Systems. Geben Sie spezifische Antwortzeiten an.
- Antwortzeit für eine Transaktion (durchschnittlich, maximal)
- Durchsatz (z. B. Transaktionen pro Sekunde)
- Kapazität (z. B. mögliche Anzahl von Kunden oder Transaktionen)
- Eingeschränkte Modi (Welcher Betriebsmodus ist akzeptabel, wenn das System in irgendeiner Form eingeschränkt ist?)
- Ressourcennutzung (Speicher, Datenträger, Kommunikation usw.)]
4.4 Servicefreundlichkeit
[Dieser Abschnitt enthält alle Anforderungen, die der Verbesserung der Servicefreundlichkeit oder Wartungsfreundlichkeit des zu erstellenden Systems dienen. Dazu gehören Codierungsstandards, Namenskonventionen, Klassenbibliotheken, Wartungszugriff und Wartungsdienstprogramme.]
4.5 Designeinschränkungen
[In diesem Abschnitt werden alle Designeinschränkungen des zu erstellenden Systems angegeben. Designeinschränkungen sind Designentscheidungen, die obligatorisch und zu respektieren sind. Beispiele sind Einschränkungen für Softwaresprachen, Anforderungen an Softwareprozesse, Vorschriften für die Verwendung von Entwicklungstools, Rahmenbedingungen für Architektur und Design, gekaufte Komponenten, Klassenbibliotheken usw.]
4.6 Anforderungen an die Onlinedokumentation für Benutzer und das Hilfesystem
[Beschreiben Sie hier die Anforderungen an die Onlinedokumentation für Benutzer, das Hilfesystem, Hilfe zu Anmerkungen usw.]
4.7 Gekaufte Komponenten
[Dieser Abschnitt beschreibt alle Komponenten, die für das System gekauft werden, alle geltenden Lizenzierungs- oder Nutzungsbedingungen sowie alle zugehörigen Kompatibilitäts- und Interoperabilitätsstandards oder Schnittstellenstandards.]
4.8 Schnittstellen
[Dieser Abschnitt definiert die Schnittstellen, die die Anwendung unterstützen muss. Er sollte mit angemessener Genauigkeit Protokolle, Ports und logische Adresse etc. angeben, so dass die Software auf der Basis der Schnittstellenanforderungen entwickelt und geprüft werden kann.]
4.8.1 Benutzerschnittstellen
[Beschreiben Sie die Benutzerschnittstellen, die von der Software implementiert werden müssen.]
4.8.2 Hardwareschnittstellen
[Dieser Abschnitt definiert alle Hardwareschnittstellen (einschließlich der logischen Struktur, der physischen Adressen, des erwarteten Verhaltens usw.), die die Software unterstützen muss.]
4.8.3 Softwareschnittstellen
[Dieser Abschnitt beschreibt Softwareschnittstellen zu anderen Komponenten des Softwaresystems. Es kann sich um gekaufte Komponenten handeln, um wiederverwendete Komponenten einer anderen Anwendung oder um Komponenten, die für ganz andere Subsysteme entwickelt wurden, mit denen diese Softwareanwendung jedoch interagieren muss.
4.8.4 Übertragungsschnittstellen
[Beschreiben Sie alle Übertragungsschnittstellen zu anderen Systemen oder Einheiten (z. B. lokale Netze, ferne serielle Einheiten etc.).]
4.9 Lizenzanforderungen
[Dieser Abschnitt definiert alle Anforderungen an die Lizenzierung oder an andere Nutzungsbeschränkungen für die Software.]
4.10 Rechtliche Hinweise, Copyright und Bemerkungen
[Dieser Abschnitt beschreibt den rechtlich zulässigen Haftungsausschluss, die erforderliche Gewährleistung, Copyright-Vermerke, bestehende Patente, geschützte Wörter, Marken oder Logos und Konformitätsaspekte der Software.]
4.11 Geltende Standards
[Dieser Abschnitt verweist auf alle geltenden Standards und gibt die spezifischen Abschnitte des jeweiligen Standards an, die auf das zu beschreibende System anwendbar sind. Dabei kann es sich um gesetzliche Vorschriften, Qualitätsnormen und Verwaltungsvorschriften, Industrienormen für Benutzerfreundlichkeit, Interoperabilität, Internationalisierung, Betriebssystemkonformität usw. handeln.]
Anhang
A Klassendiagramm
B ggf. UML-Sequenz- und Zustandsdiagramme
C Personas
D Storyboard
E Link auf den Online-Prototypen und Screenshots des Prototypen
[1] Dieses Template wird anstelle eines Pflichtenheftes verwendet!
[2] Angepasstes Word-Template auf Basis der Templates für “Software Requirements Specification” und ”Vision” des IBM Rational Unified Process