<Projektname>

Vision

 

Version <1.0>

 

 

[Anmerkung: Die folgende Vorlage ist für den Rational Unified Process bestimmt. Blau und kursiv dargestellte Texte (style=InfoBlue) in eckigen Klammern sind Anleitungen für den Autor und sollten vor der Veröffentlichung des Dokuments gelöscht werden. Ein auf diesen Stil folgender Absatz wird automatisch auf den normalen Stil (style=Body Text) gesetzt.]

 


Revisionsprotokoll

Datum

Version

Beschreibung

Autor

<dd/mmm/jj>

<x.x>

<Details>

<Name>

 

 

 

 

 

 

 

 

 

 

 

 

 


Inhaltsverzeichnis

1.       Einführung          

1.1     Verwendungszweck      

1.2     Inhalt und Umfang      

1.3     Definitionen, Akronyme und Abkürzungen      

1.4     Referenzen      

1.5     Übersicht      

2.       Positionierung          

2.1     Geschäftschance      

2.1.1     Aktuelle Position 

2.1.2     Rechtfertigung für Änderung

2.2     Problemstellung      

2.3     Produktpositionierung     

3.       Beschreibungen von Stakeholdern und Benutzern  

3.1     Marktdemographie     

3.2     Stakeholder-Übersicht     

3.3     Benutzerübersicht     

3.4     Benutzerumgebung     

3.5     Stakeholder-Profile     

3.5.1     <Stakeholder-Name>           

3.6     Benutzerprofile     

3.6.1     <Benutzername>           

3.7     Wichtigste Erfordernisse für Stakeholder oder Benutzer     

3.8     Alternativen und Wettbewerb     

3.8.1     <ein Wettbewerber>           

3.8.2     <ein weiterer Wettbewerber>           

3.9      In Erwägung gezogene Entwicklungsalternativen

4.       Product Übersicht      

4.1     Produktperspektive     

4.2     Zusammenfassung der Leistungsmerkmale     

4.3     Annahmen und Abhängigkeiten     

4.4     Kosten und Preisgestaltung     

4.5     Lizenzierung und Installation     

5.       Produktfeatures         

5.1     Features     

5.1.1       <ein Feature>

5.1.2       <ein weiteres Feature>

5.2     Betriebsszenarios

5.3       Bereitstellung von Unterstützung    

6.       Einschränkungen         

7.       Qualitätsstufen

8.       Vorrangstellung und Priorität

9.       Weitere Produktanforderungen

9.1     Geltende Standards     

9.2     Systemanforderungen     

9.3     Leistungsanforderungen     

9.4     Umgebungsanforderungen   

9.5       Physische Anforderungen  

10.            Dokumentationsanforderungen               

10.1     Benutzerhandbuch     

10.2     Onlinehilfe     

10.3     Installationshandbücher, Guides, Konfigurationsanleitung und Readme-Datei     

10.4     Aufmachung und Kennzeichnung     

A.                 Featureattribute               

   


Vision

1.                   Einführung

[In diesem Dokument werden die wichtigsten Anforderungen an und die wichtigsten Features von <<Systemname>> erfasst, analysiert und definiert. Das Dokument konzentriert sich vor allem auf das von den Stakeholdern und Zielbenutzern benötigte Leistungsspektrum und an den Ursachen für den Bedarf der Stakeholder und Benutzer. Wie <<Systemname>> diesem Bedarf gerecht wird, ist ausführlich in den ergänzenden Spezifikationen zum Anwendungsfall beschrieben.] Anmerkung: Diese Visionsvorlage versucht, alle Arten von Entwicklungen abzudecken, angefangen bei handelsüblichen Produkten, die spekulativ für einen wahrgenommenen Markt entwickelt werden, über einmalige, in Vertragsentwicklung hergestellte Systeme bis hin zu Systemen, die nach den spezifischen Anforderungen eines Kunden entwickelt werden. Deshalb können die Wörter 'Produkt' und 'System' ohne sorgfältige Differenzierung verwendet werden. Beide Wörter bezeichnen 'etwas, das zu entwickeln ist'. Wir erwarten, dass die Dokumentanpassung diese Nomenklatur für eine bestimmte Anwendung eingrenzt.]

[Die Einführung zum Visionsdokument gibt einen Überblick über das gesamte Dokument. Die Einführung sollte außerdem Verwendungszweck, Inhalt und Umfang, Definitionen, Akronyme, Abkürzungen und Referenzen des Visionsdokuments angeben.]

1.1               Verwendungszweck

[Geben Sie den Verwendungszweck dieses Visionsdokuments an.]

1.2               Inhalt und Umfang

[Dies ist eine kurze Beschreibung des Geltungsbereichs dieses Visionsdokuments, der zugeordneten Projekte sowie aller weiteren Faktoren, die von diesem Dokument betroffen sind oder beeinflusst werden.]

1.3               Definitionen, Akronyme und Abkürzungen

[Dieser Unterabschnitt enthält eine Definition aller Begriffe, Akronyme und Abkürzungen, damit das Visionsdokument ordnungsgemäß interpretiert werden kann. Diese Informationen können durch Verweise auf das Projektglossar bereitgestellt werden.]

1.4               Referenzen

[Dieser Unterabschnitt enthält eine Liste aller Dokumente, auf die das Visionsdokument verweist. Geben Sie zu jedem Dokument den Titel, ggf. die Berichtsnummer, das Datum und die publizierende Organisation an. Geben Sie die Quellen für die Referenzdokumente an. Diese Informationen können durch Verweise auf einen Anhang oder ein anderes Dokument bereitgestellt werden.]

1.5               Übersicht

[Dieser Unterabschnitt beschreibt den Inhalt im verbleibenden Teil des Visionsdokuments und erläutert die Organisation des Dokuments.]

2.                  Positionierung

2.1               Geschäftschance

[Beschreiben Sie kurz die Geschäftschance, die dieses Projekt bietet.]

2.1.1     Aktuelle Position

[In diesem Unterabschnitt beschreiben Sie den Hintergrund, den Zweck und den Umfang des vorhandenen Systems bzw. des Geschäftsumfelds, einschließlich der geltenden Richtlinien (sofern zutreffend), der Leistungsmerkmale des aktuellen Systems, der involvierten Stakeholders und der Unterstützungsprobleme.]

2.1.2     Rechtfertigung für Änderung

[In diesem Unterabschnitt beschreiben Sie die neuen Umstände oder Bedürfnisse, die in einem Geschäft oder in betrieblicher Hinsicht entstanden sind und eine Änderung erfordern. Stellen Sie kurz die vorgeschlagenen und abgelehnten Änderungen und die zugehörige Begründung vor. Wenn Handelsstudien (zu Änderungsanforderungen) durchgeführt wurden, kann auf diese verwiesen werden.]

2.2               Problemstellung

[Fassen Sie kurz das Problem zusammen, das mit diesem Projekt gelöst wird. Sie können folgendes Format verwenden:]

Problem:

[Problembeschreibung]

Betrifft:

[Vom Problem betroffene Stakeholder]

Auswirkungen:

[Wie wirkt sich das Problem aus?]

Erfolgreiche Lösung:

[Listen Sie einige wichtige Vorteile einer erfolgreichen Lösung auf.]

2.3               Produktpositionierung

[Fassen Sie hier ganz kurz die spezifische Marktposition des Produkts zusammen.] Sie können folgendes Format verwenden:]

Zielgruppe

[Zielkunde]

Aktivitäten der Zielgruppe

[Bedarf oder Potenzial]

Produkt (Produktname):

Das Produkt ist gehört zur [Produktkategorie].

Aufgabe des Systems:

[Wichtigster Vorteil, der ausschlaggebend für die Kaufentscheidung ist]

Gegensatz:

[Primäre Alternative von Wettbewerbern]

Unser Produkt:

[Wichtigste Differenzierungsmerkmale]

[Die angegebene Produkt- oder Systempositionierung gibt Auskunft über den geplanten Verwendungszweck des Systems und die Wichtigkeit des Projekts für alle beteiligten Mitarbeiter.]

3.                  Beschreibungen von Stakeholdern und Benutzern

[Wenn Sie Produkte und Dienstleistungen anbieten möchten, die dem tatsächlichen Bedarf der Stakeholder und Benutzer entsprechen, müssen Sie alle Stakeholder in den Prozess der Anforderungsmodellerstellung einbeziehen. Sie müssen die Benutzer des Systems identifizieren und sicherstellen, dass sie durch die Stakeholder angemessen repräsentiert werden. Dieser Abschnitt enthält Profile der am Projekt beteiligten Stakeholder und Benutzer und beschreibt die wichtigsten Probleme, die mit dem Lösungsvorschlag gelöst werden sollen. Die spezifischen Anfragen oder Anforderungen sind in einem gesonderten Artefakt (Stakeholder-Anfragen) enthalten und werden hier nicht beschrieben. Geben Sie hier stattdessen Hintergründe und Ursachen für die Anforderungen und den Bedarf der Stakeholder/Benutzer an.]

3.1               Marktdemographie

[Tragen Sie die wichtigsten Fakten zur Marktdemographie zusammen, die die Motivation für Produktentscheidungen darstellen. Beschreiben Sie die Zielmarktsegmente. Schätzen Sie die Marktgröße und das Wachstumspotenzial des Marktes ein. Stützen Sie sich dabei auf die Anzahl potenzieller Benutzer und auf die finanziellen Mittel, die Ihre Kunden zur Deckung ihres Bedarfs einzusetzen bereit sind. Untersuchen Sie wichtige Branchentrends und Technologien. Beantworten Sie folgende strategische Fragen:

? Welche Reputation hat Ihre Organisation in diesen Märkten?

Welche Reputation hätten Sie gern?

? Wie dient dieses Produkt Ihren Zielen?]

3.2               Stakeholder-Übersicht

[Es gibt eine Reihe von Stakeholdern, die ein Interesse an der Entwicklung haben, jedoch nicht alle Benutzer sind. Erstellen Sie Sie eine zusammenfassende Liste dieser Stakeholder. (Die Benutzerliste folgt im Abschnitt 3.3.)]

Name

Beschreibung

Zuständigkeiten

[Geben Sie den Stakeholder-Typ an.]

[Beschreiben Sie den Stakeholder kurz.]

[Fassen Sie die wichtigsten Zuständigkeiten des Stakeholders im Hinblick auf das zu entwickelnde System (sein Interesse als Stakeholder) zusammen. Beispiele:

Der Stakeholder vergewissert sich, dass das System servicefreundlich ist.

Der Stakeholder vergewissert sich, dass die Features des Produkts auf dem Markt nachgefragt werden.

Der Stakeholder überwacht den Fortschritt des Projekts.

Der Stakeholder bewilligt die Geldmittel.]

3.3               Benutzerübersicht

[Erstellen Sie eine zusammenfassende Liste aller identifizierten Benutzer.]

Name

Beschreibung

Zuständigkeiten

Stakeholder

[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:

Der Benutzer erfasst Details.

Der Benutzer erstellt Berichte.

Der Benutzer koordiniert Arbeiten.]

[Falls ein Benutzer durch einen Stakeholder vertreten wird, geben Sie an, welcher Stakeholder die Interessen dieses Benutzers vertritt.]

 

3.4               Benutzerumgebung

[Beschreiben Sie detailliert die Arbeitsumgebung des Zielbenutzers. Vorschläge:

An dieser Stelle können Sie die erforderlichen Aufgaben, Mitarbeiter (Rollen) usw. anhand von Auszügen aus dem Geschäftsmodell darstellen.]

3.5               Stakeholder-Profile 

[Beschreiben in der folgenden Tabelle die einzelnen Stakeholder. Beachten Sie, dass es so viele unterschiedliche Stakeholder-Typen geben kann, wie es verschiedene Benutzer, Abteilungen und technische Entwickler gibt. Ein konkretes Profil für jeden Stakeholder sollte die folgenden Angaben enthalten.]

3.5.1          <Stakeholder-Name>

Ansprechpartner

[Wer ist der Ansprechpartner des Stakeholders für das Projekt? (Optional, wenn dies anderweitig dokumentiert ist.) Hier muss ein Name eingetragen werden.]

Beschreibung

[Kurzbeschreibung des Stakeholder-Typs]

Profiltyp

[Geben Sie das Know-how, den technischen Hintergrund und die Erfahrenheit des Stakeholders (Koryphäe, Geschäftsexperte, Gelegenheitsbenutzer usw.) an.]

Zuständigkeiten

[Listen Sie die wichtigsten Zuständigkeiten des Stakeholders im Hinblick auf das zu entwickelnde System (sein Interesse als Stakeholder) auf.]

Erfolgskriterien

[Wie definiert der Stakeholder Erfolg?

Welche Gegenleistung erhält der Stakeholder?]

Engagement

[Wie ist der Stakeholder am Projekt beteiligt? Ordnen Sie nach Möglichkeit eine Rolle des Rational Unified Process zu (z. B. Anforderungsprüfer usw.).]

Liefergegenstände

[Gibt es zusätzliche Liefergegenstände, die für den Stakeholder erforderlich sind? Dabei kann es sich um Liefergegenstände des Projekts oder um Ausgaben des in Entwicklung befindlichen Systems handeln.]

Kommentare / Fragen

[Geben Sie hier Probleme an, die einem Erfolg des Projekts im Wege stehen könnten. Nehmen Sie alle weiteren Informationen auf, die Ihnen wichtig erscheinen.]

 

3.6               Benutzerprofile 

[Beschreiben Sie in der folgenden Tabelle die einzelnen Benutzer. Bedenken Sie, dass Benutzer Koryphäen, aber auch blutige Anfänger sein können. Eine Koryphäe würde vielleicht ein ausgeklügeltes flexibles Tool mit Unterstützung für mehrere Plattformen benötigen, ein Anfänger dagegen vor allem ein benutzerfreundliches Tool, das einfach einzusetzen ist. Ein konkretes Profil für jeden Benutzer sollte die folgenden Angaben enthalten.]

3.6.1          <Benutzername>

Ansprechpartner

[Wer ist der Ansprechpartner des Benutzers für das Projekt? (Optional, wenn dies anderweitig dokumentiert ist.) Oft wird hier der Stakeholder angegeben, der eine Gruppe von Benutzern vertritt (beispielsweise Stakeholder1).]

Beschreibung

[Eine kurze Beschreibung des Benutzertyps]

Profiltyp

[Geben Sie das Know-how, den technischen Hintergrund und die Erfahrenheit des Benutzers (Koryphäe, Gelegenheitsbenutzer usw.) an.]

Zuständigkeiten

[Listen Sie die wichtigsten Zuständigkeiten des Benutzers im Hinblick auf das zu entwickelnde System auf (z. B. erfasst Einzeldaten, erstellt Berichte, koordiniert die Arbeit usw.).]

Erfolgskriterien

[Wie definiert der Benutzer Erfolg?

Welche Gegenleistung erhält der Benutzer?]

Engagement

[Wie ist der Benutzer am Projekt beteiligt? Ordnen Sie nach Möglichkeit eine Rolle des Rational Unified Process zu (z. B. Anforderungsprüfer usw.).]

Liefergegenstände

[Werden vom Benutzer Liefergegenstände erzeugt, und wenn ja, für wen?]

Kommentare / Fragen

[Geben Sie hier Probleme an, die einem Erfolg des Projekts im Wege stehen könnten. Nehmen Sie alle weiteren Informationen auf, die Ihnen wichtig erscheinen. Dies könnten beispielsweise Entwicklungstrends sein, die die Arbeit des Benutzers vereinfachen oder erschweren.]

 

3.7               Wichtigste Erfordernisse für Stakeholder oder Benutzer

[Listen Sie die wichtigsten Probleme mit der bestehenden Lösung aus Sicht der Stakeholder auf. Stellen Sie zu jedem Problem Folgendes klar:

Wo liegen die Ursachen dieses Problems?

Wie ist es derzeit gelöst?

Welche Lösung wünscht der Stakeholder oder Benutzer?]

[Es ist wichtig, dass Sie verstehen, welche Wichtigkeit der Stakeholder oder Benutzer den einzelnen Problemen in Relation beimisst. Mit Einstufungs- und Stimmauszählungsverfahren kann festgestellt werden, welche Probleme gelöst werden müssen und welche gelöst werden sollten.

Vervollständigen Sie die folgende Tabelle. Falls Sie den Bedarf mit Rational RequisitePro erfassen, können Sie hier einen Auszug oder Bericht dieses Tools einfügen.]

Bedarf

Priorität

Problemstellung

Aktuelle Lösung

Vorgeschlagene Lösungen

Broadcastnachrichten

 

 

 

 

 

3.8               Alternativen und Wettbewerb

[Geben Sie die Alternativen an, die der Stakeholder ins Auge fassen könnte. Dies könnte der Kauf eines Konkurrenzprodukts, die Entwicklung einer unternehmenseigenen Lösung oder die Beibehaltung des Status quo sein. Listen Sie bekannte Optionen von Wettbewerbern auf, die es bereits gibt oder die künftig verfügbar sein könnten. Geben Sie die wichtigsten Stärken und Schwachpunkte der einzelnen Wettbewerber aus Sicht des Stakeholders oder Benutzers an.]

3.8.1          <ein Wettbewerber>

3.8.2          <ein weiterer Mitbewerber>

3.9       In Erwägung gezogene Entwicklungsalternativen

[In diesem Unterabschnitt beschreiben Sie alle Alternativen für das vorgeschlagene Produkt, die in Erwägung gezogen wurden, und alle zugehörigen Handelsstudien.]

4.                  Produktübersicht

[Dieser Abschnitt gibt einen groben Überblick über die Fähigkeiten des Produkts, die Schnittstellen zu anderen Systemen und die Systemkonfigurationen.]

4.1               Produktperspektive

[Dieser Unterabschnitt des Visionsdokuments 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 ein, 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 Blockdiagramm darstellen.  

Beschreiben Sie die betrieblichen, organisatorischen und entwicklungstechnischen Auswirkungen auf die Stakeholder und andere Systeme.]

4.2               Zusammenfassung der Leistungsmerkmale

[Fassen Sie die wichtigsten Vorteile und Features des Produkts zusammen. Ein Visionsdokument für ein Kundenunterstützungssystem könnte in diesem Abschnitt Informationen zur Fehlerdokumentation, Fehlerweiterleitung und zur Erstellung von Fehlerberichten enthalten, ohne detailliert auf die einzelnen Funktionen einzugehen.

Geben Sie die Funktionen so an, dass die Liste für den Benutzer oder jeden anderen Leser dieses Dokuments verständlich ist. Eine einfache Tabelle mit den wichtigsten Vorzügen und den entsprechenden Features ist ausreichend. Beispiel:]

Tabelle 4-1   Kundenunterstützungssystem

Vorteil für den Kunden

Unterstützende Features

Kurze Einarbeitungszeiten für neue Mitarbeiter

Wissensbasis, die Mitarbeitern hilft, bekannte Fehler und Problemlösungsstrategien schnell zu finden

Erhöhte Kundenzufriedenheit, weil nichts übersehen wird

Eindeutige Aufschlüsselung, Klassifizierung und Verfolgung von Problemen während des Lösungsprozesses. Automatische Benachrichtigung bei länger ungeklärten Fragen.

Das Management kann Problemfelder erkennen und die Auslastung der Mitarbeiter besser abschätzen

Trend- und Verteilungsberichte mit einer gründlichen Prüfung des Fehlerstatus

Dezentrale Unterstützungsteams können zusammen an der Lösung von Problemen arbeiten.

Ein Replikationsserver bietet die Möglichkeit, aktuelle Datenbankinformationen unternehmensweit zu nutzen.

Kunden können sich selbst helfen und so die Unterstützungskosten senken und die Reaktionszeit verbessern.

Die Wissensbasis kann über das Internet zur Verfügung gestellt werden. Sie bietet Suchfunktionalität in Form von Hypertext und eine grafische Abfragesteuerkomponente.

4.3               Annahmen und Abhängigkeiten

[Listen Sie alle Faktoren auf, die Einfluss auf die im Visionsdokument genannten Features haben. Listen Sie Annahmen auf, die eine Änderung des Visionsdokuments nach sich ziehen würden, wenn sie nicht zutreffen. Die Vision wird beispielsweise im Kontext eines größeren Unternehmens erstellt, und wenn sich etwas in diesem Kontext ändert, muss die Vision unter Umständen geändert werden. Dazu können beispielsweise wirtschaftliche, politische, gesetzliche oder Umweltfaktoren gehören. Die Vision kann außerdem von der Verfügbarkeit von Geräten, Software oder anderen Systemkomponenten oder der Verfügbarkeit von besonderen Fertigkeiten oder Qualifikationen abhängen.]

4.4               Kosten und Preisgestaltung

[Bei Produkten, die an externe Kunden verkauft werden sollen, und bei vielen firmeninternen Systemen können die Kosten und die Frage der Preisgestaltung direkt die Definition und Implementierung des Systems beeinflussen. Notieren Sie in diesem Abschnitt alle relevanten Einschränkungen in Bezug auf Kosten und Preisgestaltung. Vorgaben für die Verteilungskosten (Anzahl Disketten oder CD-ROMs, CD-Mastering) oder für andere Verkaufskosten (Handbücher, Verpackung) können je nach Art des Systems einen starken oder zu vernachlässigenden Einfluss auf den Erfolg des Projekts haben.]

4.5               Lizenzierung und Installation

[Fragen der Lizenzierung und Installation können die Entwicklung ebenfalls direkt beeinflussen. Der Bedarf an Zugriffskontrollen, Serialisierungsunterstützung, Kennwortschutz oder Netzlizenzierung generiert beispielsweise zusätzliche Anforderungen an das System, die bei der Entwicklung berücksichtigt werden müssen.

Installationsanforderungen können sich auch auf die Softwareerstellung auswirken oder eine separate Installationssoftware erforderlich machen. Physische Systeme können spezielle Installationsanforderungen haben, wenn sie beispielsweise besonderen Sicherheits- oder Überwachungsanforderungen unterliegen.]

5.                  Produktfeatures

[Listen Sie die Produktfeatures auf und beschreiben Sie sie kurz. Features sind die Hauptleistungsmerkmale des Systems, die den Benutzern die gewünschten Vorteile bringen. Beschreiben Sie außerdem für jedes Features die Leistungsmerkmale, d. h. "wie gut" etwas ausgeführt werden muss, und geben Sie Messwerte an, z. B. Zeit, Antwortzeit, Transaktionsrate. Das Wort 'Feature' hat hier keine spezielle Bedeutung, Sie können auch die Wörter 'Fähigkeit' oder 'Funktion' verwenden. Alle beschreiben etwas, das das Produkt bzw. System ausführen soll. Jedes Feature ist ein extern erwünschter Service, der in der Regel einige Eingaben erfordert, um die gewünschten Ergebnisse zu erzielen. Ein Feature eines Fehlerverfolgungssystems könnte beispielsweise die Fähigkeit zur Erstellung von Trendberichten sein. Aktualisieren Sie die Beschreibung und nehmen Sie Bezug auf die Anwendungsfälle, wenn das Anwendungsmodell mehr an Gestalt gewinnt.

Das Visionsdokument wird von vielen verschiedenen beteiligten Personen geprüft. Der Beschreibung sollte so allgemein gehalten sein, dass jede dieser Personen den Inhalt versteht. Sie muss aber dennoch detailliert genug sein, um dem Team die zur Erstellung eines Anwendungsfallmodells erforderlichen Informationen zu liefern.

Für eine effektive Verwaltung der Komplexität sollten Sie das Leistungsspektrum von neuen Systemen oder Ergänzungen zu einem vorhandenen System mit 25 bis maximal 99 Features darstellen. Diese Features bilden die Basis für die Produktdefinition, das Scope-Management und das Projektmanagement. Detaillierter werden die einzelnen Features im Anwendungsfallmodell herausgearbeitet oder in natürlicher Sprache, falls im Projekt keine Anwendungsfälle erstellt werden.

Die Beschreibungen in diesem Abschnitt sollen Benutzern, Bedienern oder anderen externen Personen/Systemen Sinn und Zweck der Features vermitteln. Sie sollten die Funktionalität und alle für die Verwendung der Features wichtigen Aspekte beschreiben. Es gelten folgende Richtlinien:

Vermeiden Sie Ausschmückungen. Halten Sie die Beschreibungen allgemein. Konzentrieren Sie sich auf die geforderten Leistungsmerkmale und die Gründe für den Bedarf nach diesen Merkmalen. (Was implementiert werden soll, ist entscheidend, und nicht die Art der Implementierung.)

Falls Sie das Toolkit von Rational RequisitePro verwenden, müssen Sie zur besseren Referenzierung und Überwachung alle als Anforderungen des Typs 'Feature' auswählen.]

5.1               Features

5.1.1     <ein Feature>

5.1.2     <ein weiteres Feature>

5.2               Einsatzszenarios

[Beschreiben Sie einige Anwendungen des Produkts oder System, die interessante oder wichtige Interaktionen zwischen dem System und seinen Benutzern, seiner Umgebung und/oder anderen Systemen veranschaulichen.]

5.3               Unterstützungsbereitstellung

[In diesem Unterabschnitt beschreiben Sie, wie die Unterstützung konzeptionell bereitgestellt werden soll. Fügen Sie Beschreibungen der Unterstützungsorganisation, der Geräte, Wartungszyklen und Bereitstellungsabsprachen ein.]

6.                  Einschränkungen

[Notieren Sie alle Designeinschränkungen, externen Einschränkungen und sonstigen Abhängigkeiten.]

7.                  Qualitätsansprüche

[Definieren Sie den Qualitätsanspruch an die Leistung, Stabilität, Fehlertoleranz, Benutzerfreundlichkeit und ähnliche Leistungsmerkmale, soweit er nicht im Featureset erfasst ist.]

8.                  Vorrangstellung und Priorität

[Definieren Sie die Priorität der verschiedenen Systemfeatures.]

9.                  Weitere Produktanforderungen

[Listen Sie stichpunktartig die geltenden Standards, Hardware- oder Plattformanforderungen, Leistungsanforderungen und Umgebungsanforderungen auf.]

9.1               Geltende Normen

[Nennen Sie alle Standards, denen das Produkt entsprechen muss. Dazu können gesetzliche und behördliche Vorschriften (z. B. der EU oder des UCC, Uniform Code Council), Übertragungsstandards (wie TCP/IP oder ISDN), Konformitätsnormen für Plattformen (Windows, UNIX usw.) sowie Qualitäts- und Sicherheitsstandards (UL, ISO, CMM) gehören.]

9.2               Systemanforderungen

[Definieren Sie für die Softwaresystementwicklung alle Systemvoraussetzungen für die Unterstützung der Anwendung. Dabei kann es sich um die unterstützten Hostbetriebssysteme und Netzplattformen handeln, aber auch um Konfigurationen, Speicher, Peripheriegeräte und begleitende Software.]

9.3               Leistungsanforderungen

[Führen Sie in diesem Abschnitt detailliert die Leistungsanforderungen auf. Dazu gehören Auslastungsfaktoren, die Bandbreite oder Übertragungskapazität, der Durchsatz, die Genauigkeit und die Zuverlässigkeit oder Antwortzeiten und verschiedenen Lastbedingungen.]

9.4               Umgebungsanforderungen

[Geben Sie detailliert die Umgebungsanforderungen an. Bei physische Systeme gehören dazu Temperatur, Schlag-/Stoßeinwirkung, Feuchtigkeit, Strahlung usw. Zu den Umgebungsfaktoren für Softwaresysteme gehören die Nutzungsbedingungen, die Benutzerumgebung, die Ressourcenverfügbarkeit, Wartungsfragen sowie die Fehlerbehandlung und -behebung.]

9.5        Physische Anforderungen

[Wenn es physische Anforderungen, z. B. Gewichts- oder Mengenbegrenzungen gibt, beschreiben Sie sie in diesem Unterabschnitt.]

10.             Dokumentationsanforderungen

[Dieser Abschnitt beschreibt die Dokumentation, die zur Unterstützung des System-Deployments entwickelt werden muss.]

10.1            Benutzerhandbuch

[Beschreiben Sie den Verwendungszweck und Inhalt des Benutzerhandbuchs. Geben Sie den gewünschten Umfang und den Detaillierungsgrad an. Erwähnen Sie, ob das Handbuch einen Index und/oder ein Glossar enthalten soll. Soll es mehr den Charakter eines Lernprogramms haben oder eher wie ein klassisches Handbuch aufgebaut sein? In diesen Abschnitt gehören auch Vorgaben für Format und Druck.]

10.2            Onlinehilfe

[Viele Systeme unterstützen den Benutzer mit einer Onlinehilfe. Der Charakter dieser Systeme ist ungewöhnlich, weil er Aspekte der Programmierung (Hyperlinks usw.) mit Aspekten der technischen Dokumentation (Gliederung und Präsentation) kombiniert. Vielfach wird die Meinung vertreten, die Entwicklung eines Onlinehilfesystems ist ein Projekt in einem Projekt, das ein rechtzeitiges Scope-Management und eine rechtzeitige Planung erfordert.]

10.3            Installationshandbücher, Konfigurationsanleitung und Readme-Datei

[Ein Dokument mit Installationsanweisungen und Konfigurationsrichtlinien ist wichtiger Bestandteil eines kompletten Lösungsangebots. Eine Readme-Datei gehört in der Regel als Standardkomponente dazu. In der Readme-Datei kann es einen Abschnitt "Neuheiten in diesem Release" geben und eine Beschreibung der Kompatibilität mit früheren Releases. Die meisten Benutzer wissen Hinweise auf bekannte Programmfehler und Strategien zur Fehlerbehebung in einer Readme-Datei sehr zu schätzen.]

10.4            Aufmachung und Kennzeichnung

[Die modernen Systeme zeichnen sich durch Konsistenz in Darstellung und Funktionsweise aus. Dies beginnt beim Produktpaket und reicht bis zu den Installationsmenüs, Eingangsanzeigen, Hilfesystemen, Dialogen der Benutzerschnittstelle usw. In diesem Abschnitt werden die Anforderungen an die Kennzeichnung und die Kennzeichnungsarten, die in das System aufzunehmen sind, definiert. Hierzu gehören beispielsweise Copyrightvermerke und Patenthinweise, Unternehmenslogos, genormte Symbole und andere grafische Elemente etc.]

A.          Featureattribute

[Den Features werden Attribute zugeordnet, mit denen für die Implementierung vorgesehene Produktelemente bewertet, erfasst, mit einer Priorität versehen und verwaltet werden können. Alle Anforderungstypen und -attribute müssen im Plan für das Anforderungsmanagement angegeben werden. Hier können Sie jedoch kurz die Attribute für die von Ihnen ausgewählten Features auflisten und beschreiben. In den folgenden Unterabschnitten finden Sie einige Vorschläge für Featureattribute.]

A.1            Status

[Dieses Attribut wird nach Absprache mit dem Projektmanagementteam und Überprüfung durch das Projektmanagementteam für das Projekt gesetzt. Es dient der Verfolgung des Fortschritts bei der Definition der Referenzversion für das Projekt.]

Vorgeschlagen

[Dieses Attribut beschreibt Features, die im Gespräch sind, jedoch noch nicht offiziell (d. h. von einer Arbeitsgruppe mit Vertretern des Projektteams, des Projektmanagementteams und einer Benutzer- oder Kundengruppe) überprüft oder akzeptiert wurden.]

Genehmigt

[Dieses Attribut beschreibt Leistungsmerkmale die für sinnvoll und realisierbar gehalten werden und deren Implementierung offiziell genehmigt wurde.]

Einbezogen

[Attribut für Features, die zu einem bestimmten Zeitpunkt in die Referenzversion des Produkts einbezogen wurden]

A.2            Vorteil

[Dieses Attribut wird von der Marketingabteilung, dem Produktmanager oder dem Geschäftsanalytiker gesetzt. Nicht alle Anforderungen entstehen auf die gleiche Weise. Eine Klassifizierung von Anforderungen nach ihrem relativen Vorteil für den Benutzer kann die Grundlage für Gespräche mit Kunden, Analytiker und Mitgliedern des Entwicklungsteams bilden. Dieses Attribut wird für das Scope-Management des Projekts und die Bestimmung von Prioritäten bei der Entwicklung verwendet.]

Kritisch

[Attribut für wesentliche Features. Werden diese Features nicht implementiert, sind die Anforderungen des Kunden nicht erfüllt. Alle kritischen Features müssen im Release implementiert werden, da es sonst zu Verzögerungen im Zeitplan kommt.]

Wichtig

[Attribut für Features, die für die Effektivität und Effizienz des Systems bei den meisten Anwendungen wichtig sind. Die Funktionalität kann nicht so einfach auf andere Weise bereitgestellt werden. Fehlt ein wichtiges Feature, wird der Kunde oder Benutzer nicht zufrieden sein oder gar Ertragseinbußen erleiden. Das Fehlen eines solchen Features bedeutet aber keine Verzögerung für das Release.]

Sinnvoll

[Attribut für Features, die nicht so häufig verwendet werden, weil sie nur in weniger typischen Anwendungen sinnvoll sind oder weil es effiziente Alternativen gibt. Wird ein solches Feature nicht in ein Release aufgenommen, sind keine Beeinträchtigung der Kundenzufriedenheit oder des Ertrags zu erwarten.]

 

A.3            Aufwand

[Dieses Attribut wird vom Entwicklerteam gesetzt. Da einige Features mehr Zeit und Ressourcen als andere erfordern, kann beispielsweise anhand einer Einschätzung der Team- oder Mannwochen oder anderer Messwerte für Größe (z. B. erforderliche Anzahl von Codezeilen oder Funktionspunkten für Software) am besten bewertet werden, was in einem bestimmten Zeitrahmen erreichbar ist und was nicht und wie komplex die Aufgaben innerhalb des gesteckten Zeitrahmens sein werden. Dieses Attribut wird für das Scope-Management des Projekts und die Bestimmung von Prioritäten bei der Entwicklung verwendet.]

A.4            Risiko

[Dieses Attribut wird vom Entwicklerteam gesetzt und basiert auf der Wahrscheinlichkeit unerwünschter Ereignisse im Verlaufe des Projekts. Dazu gehören Budgetüberschreitungen, Terminverschiebungen oder Abbrüche. Für die meisten Projektmanager ist eine Klassifizierung der Risiken als 'hoch', 'mittel' und 'niedrig' ausreichend. Eine detailliertere Einstufung ist jedoch möglich. Risiken können oft indirekt beurteilt werden, indem die Unsicherheiten im Zeitplanentwurf des Projektteams ermittelt werden.]

A.5            Stabilität

[Dieses Attribut wird vom Analytiker und vom Entwicklerteam gesetzt. Es basiert auf der Wahrscheinlichkeit für eine Änderung des Features oder eine veränderte Einschätzung des Features. Dieses Attribut wird für die Etablierung von Entwicklungsprioritäten und zur Bestimmung der Elemente verwendet, für die zunächst weitere Informationen eingeholt werden müssen.]

A.6            Zielrelease

[Dieses Attribut dokumentiert die geplante Produktversion, in der das Feature erstmalig enthalten sein wird. Sie können dieses Feld nutzen, um Features aus einem Visionsdokument einem bestimmten Release der Referenzversion zuzuordnen. In Kombination mit dem Statusfeld kann das Team anhand dieses Attributs verschiedene Features für das Release vorschlagen, dokumentieren und besprechen, ohne eine definitive Entwicklungszusage zu geben. Es werden nur Features implementiert, deren Status auf 'Einbezogen' gesetzt und deren Zielrelease definiert ist. Im Rahmen des Scope-Managements für das Projekt kann die Versionsnummer des Zielrelease erhöht werden. Das Element bleibt dann im Visionsdokument enthalten, wird jedoch für ein späteres Release vorgesehen.

A.7            Zuständig

[Bei vielen Projekten werden Features Featureteams zugewiesen, die für die Sondierung, die Erfassung und die Präzisierung der Anforderungen und für die Implementierung verantwortlich sind. Diese einfache Pulldown-Liste gibt einen guten Überblick über die Zuständigkeiten im Projektteam.]

A.8            Grund

[Dieses Textfeld wird verwendet, um den Grund der Featureanforderung zu protokollieren. Anforderungen kann es aus verschiedenen Gründen geben. Dieses Feld enthält eine Erläuterung oder einen Verweis auf eine solche. Es kann beispielsweise auf eine Seite und eine Zeilennummer in einer Spezifikation der Produktanforderungen oder auf eine Zeitmarke in der Videoaufzeichnung eines wichtigen Kundengesprächs verweisen.]