Collegiate Sports Paging System

Plan für das Anforderungsmanagement
 
 

Version 1.0


 



 
 

Revisionsprotokoll


Datum
Version
Beschreibung
Autor
2. Juli 2000
1.0
Erstes Release
Kontextintegration


Inhaltsverzeichnis
 
 

1. Einführung

1.1 Zweck

1.2 Umfang

1.3 Definitionen, Akronyme und Abkürzungen

1.4 Referenzinformationen

2. Anforderungsmanagement

2.1 Organisation, Zuständigkeiten und Schnittstellen

2.2 Tools, Umgebung und Infrastruktur

3. Programm für Anforderungsmanagement

3.1 Definition der Anforderungen

3.2 Rückverfolgbarkeit

Kriterien für Features

Kriterien für Stakeholder-Bedarf

Kriterien für Anwendungsfälle

Kriterien für ergänzende Anforderungen

3.3 Attribute

Kriterien für Features

Attribute für Stakeholder-Bedarf

Attribute für Anwendungsfälle

Attribute für ergänzende Anforderungen

3.4 Berichte und Maßnahmen

3.5 Management der Anforderungsänderungen

3.6      Workflows und Aktivitäten

4. Meilensteine

5. Schulung und Ressourcen
 


Plan für das Anforderungsmanagement

1.  Einführung

1.1  Zweck

Dieses Dokument beschreibt die Richtlinien, nach denen das Projekt Collegiate Sports Paging System (CSPS) die Anforderungsdokumente, Anforderungstypen und Anforderungsattribute erstellt. Gemäß diesen Richtlinien wird auch die Rückverfolgbarkeit geboten, die die Verwaltung der Anforderungen des Softwareprojekts ermöglicht. Dieses Dokument fungiert auch als Konfigurationsdokument für das Anforderungsmanagementtool Rational RequisitePro.

1.2  Umfang

Dieser Plan betrifft alle Phasen des Projekts.

1.3  Definitionen, Akronyme und Abkürzungen

Siehe Glossar.

1.4  Referenzinformationen

CSPS - Softwareentwicklungsplan
CSPS - Entwicklungsfall 

CSPS - Bewertungsplan 

CSPS - Plan für das Konfigurationsmanagement

2.  Anforderungsmanagement

2.1  Organisation, Zuständigkeiten und Schnittstellen

Siehe CSPS - Softwareentwicklungsplan.

2.2  Tools, Umgebung und Infrastruktur

Rational RequisitePro wird zur Verwaltung von Anforderungen verwendet. Weitere Informationen zur Infrastruktur und Umgebung finden Sie im Softwareentwicklungsplan für das CSPS.

3.   Programm für das Anforderungsmanagement

3.1  Festlegung der Anforderungen

 
Artefakt (Dokumenttyp)
Anforderungstyp
Beschreibung
Vision
Stakeholder-Bedarf
Wichtiger Stakeholder- oder Benutzerbedarf
Vision
Feature
Rahmenbedingungen oder Funktionalität dieses System-Release
Anwendungsfallmodell
Anwendungsfall
Anwendungsfälle für dieses Release, dokumentiert in Rational Rose, mit Details in Rational RequisitePro.
Ergänzende Spezifikation
Ergänzende Anforderung
Nicht funktionale Anforderungen, die nicht in diesem Anwendungsfallmodell erfasst sind
Tabelle 3.1-1 Anforderungsartefakte und -typen

3.2  Rückverfolgbarkeit

Gekennzeichnet unten im Inhalt

Abbildung 1: Diagramm zur Rückverfolgbarkeit

Kriterien für Features

Features werden zu Anwendungsfällen zurückverfolgt.

Kriterien für Stakeholder-Bedarf

Der Benutzerbedarf wird zu Features zurückverfolgt. Es wird kein Bedarf implementiert, der nicht zu einem Feature zurückverfolgt werden kann.

Kriterien für Anwendungsfälle

Anwendungsfälle werden zu Testfällen zurückverfolgt.

Kriterien für ergänzende Anforderungen

Ergänzende Spezifikationen werden zu Testfällen zurückverfolgt.

3.3  Attribute

Attribute für Features

Status
Wird nach Festlegung und Überprüfung durch das Projektmanagementteam festgelegt. Überwacht den Fortschritt bei der Definition der Projektbasis.

 
Proposed
Zur Beschreibung von Features, die noch diskutiert werden, jedoch noch nicht von offizieller Seite überprüft und akzeptiert wurden, z. B. eine Arbeitsgruppe aus Vertretern des Projektteams, des Produktmanagements und der Benutzer- bzw. Kundengruppe.
Approved
Leistungsmerkmale, die als nützlich und machbar eingestuft und von offizieller Seite für die Implementierung genehmigt wurden.
Incorporated
Features, die zu einem bestimmten Zeitpunkt in das Basisprodukt eingebunden wurden.

Benefit

Wird vom Marketing, dem Produktmanager oder Geschäftsanalytiker festgelegt. Nicht alle erstellten Anforderungen haben die gleiche Wertigkeit. Dadurch, dass die Anforderungen je nach deren relativem Nutzen für den Benutzer in eine bestimmte Rangfolge gesetzt werden, beginnt ein Dialog zwischen Kunden, Analytiker und Mitgliedern des Entwicklerteams. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.
 
Critical
Wesentliche Features. Kann die Implementierung nicht durchgeführt werden, bedeutet das, dass das System nicht den Kundenanforderungen genügen kann. Alle kritischen Features müssen in das Release implementiert werden, andernfalls kann der Zeitplan nicht eingehalten werden.
Important
Features, die hinsichtlich der Effektivität und Effizienz des Systems für die meisten Anwendungen wichtig sind. Die Funktionalität kann nicht einfach auf andere Weise bereitgestellt werden. Wenn ein wichtiges Feature nicht aufgenommen wird, kann sich dies negativ auf die Kundenzufriedenheit oder sogar den Umsatz auswirken. Zu beachten ist, dass die Freigabe, sollte ein wichtiges Feature fehlen, sich nicht verzögert.
Useful
Features, die in weniger typischen Anwendungen nützlich sind, seltener verwendet werden oder für die akzeptable Strategien zur Behebung von Problemen möglich sind. Wenn ein solches Element nicht in ein Release aufgenommen wird, sind keine wesentlichen negativen Auswirkungen auf die Kundenzufriedenheit oder den Umsatz zu befürchten.

Effort

Wird vom Entwicklerteam festgelegt. Da einige Features mehr Zeit und Ressourcen erfordern als andere, empfiehlt es sich in diesen Fällen, die Anzahl der Wochen, die für die Lösung der Aufgabe benötigt werden, pro Team bzw. Person zu schätzen. Dabei sind Details, wie z. B. der erforderliche Umfang der Codezeilen oder Funktionspunkte, zu berücksichtigen. Auf diese Weise kann am besten beurteilt werden, wie komplex eine Aufgabe sich gestaltet und was in einem bestimmten Zeitrahmen erreicht bzw. nicht erreicht werden kann. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.  

Risk

Wird vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass während des Projekts unerwünschte Ereignisse eintreten, wie z. B. ausufernde Kosten, Verzögerungen im Zeitplan oder sogar der Projektabbruch. Die meisten Projektleiter sind der Ansicht, dass die Risikokategorien Hoch, Mittel und Niedrig ausreichend sind, obwohl detailliertere Unterteilungen möglich sind. Ein Risiko kann man oft indirekt beurteilen, indem man die Unsicherheitsfaktoren bei der vom Projektteam vorgenommenen Schätzung des Zeitplans untersucht.  

Stability

Wird vom Analytiker und vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass das Feature bzw. das Verständnis, das das Team vom Feature hat, sich ändert. Wird verwendet, um die Festlegung von Prioritäten bei der Entwicklung zu vereinfachen und die Punkte zu bestimmen, mit denen man sich detaillierter auseinander setzen muss.  

Target Release

Gibt die Produktversion an, in der das Feature zum ersten Mal erscheinen soll. Über dieses Feld können Sie Features aus einem Visionsdokument einem bestimmten Basis-Release zuordnen. In Kombination mit dem Statusfeld kann das Team verschiedene Release-Features vorschlagen, erfassen und diskutieren, ohne sie für die Entwicklung festzuschreiben. Nur Features, deren Status auf Incorporated gesetzt und deren Ziel-Release (Target Release) definiert ist, werden implementiert. Wenn der Release-Umfang bestimmt wird, kann die Versionsnummer des Ziel-Release heraufgesetzt werden, damit der Artikel im Visionsdokument bleibt und trotzdem für ein späteres Release eingeplant wird.  

Assigned To

In vielen Projekten werden angegebene Attribute oder Feature-Teams zugeordnet, die für die weitere Ausarbeitung, das Schreiben der Softwareanforderungen und die Implementierung zuständig sind. Diese einfache Pulldown-Liste dient den Mitgliedern des Projektteams zum besseren Verständnis der Zuständigkeiten.  

Reason

Dieses Textfeld wird verwendet, um die Quelle des angeforderten Feature zu bestimmen. Anforderungen bestehen aus bestimmten Gründen. In diesem Feld wird eine Erklärung oder ein Verweis auf eine Erklärung erfasst. Der Verweis kann sich z. B. auf eine Seite und Zeilennummer in der Spezifikation einer Produktanforderung oder auf eine Minutenmarkierung in einem Video eines wichtigen Kundeninterviews beziehen.

Attribute für Stakeholder-Bedarf

Status
Wird nach Festlegung und Überprüfung durch das Projektmanagementteam gesetzt. Überwacht den Fortschritt bei der Definition der Projektbasis.

 
Proposed
Zur Beschreibung von Bedarfssituationen, die noch diskutiert werden, jedoch noch nicht von offizieller Seite überprüft und akzeptiert wurden, z. B. eine Arbeitsgruppe aus Vertretern des Projektteams, des Produktmanagements und der Benutzer- bzw. Kundengruppe.
Approved
Leistungsmerkmale, die als nützlich und machbar eingestuft und von offizieller Seite für die Implementierung genehmigt wurden.
Incorporated
Bedarfssituationen, die zu einem bestimmten Zeitpunkt in praktische Lösungen im Basisprodukt umgesetzt wurden.

Effort

Wird vom Entwicklerteam festgelegt. Da einige Bedarfssituationen mehr Zeit und Ressourcen erfordern als andere, empfiehlt es sich in diesen Fällen, die Anzahl der Wochen, die für die Lösung der Aufgabe benötigt werden, pro Team bzw. Person zu schätzen. Dabei sind Details, wie z. B. der erforderliche Umfang der Codezeilen oder Funktionspunkte, zu berücksichtigen. Auf diese Weise kann am besten beurteilt werden, wie komplex eine Aufgabe sich gestaltet und was in einem bestimmten Zeitrahmen erreicht bzw. nicht erreicht werden kann. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.  

Risk

Wird vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass während des Projekts unerwünschte Ereignisse eintreten, wie z. B. ausufernde Kosten, Verzögerungen im Zeitplan oder sogar der Projektabbruch. Die meisten Projektleiter sind der Ansicht, dass die Risikokategorien Hoch, Mittel und Niedrig ausreichend sind, obwohl detailliertere Unterteilungen möglich sind. Ein Risiko kann häufig indirekt beurteilt werden, und zwar, indem man die Einhaltung des Zeitplans überwacht.  

Stability

Wird vom Analytiker und vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass der Bedarf bzw. das Verständnis, das das Team vom Bedarf hat, sich ändert. Wird verwendet, um die Festlegung von Prioritäten bei der Entwicklung zu vereinfachen und die Punkte zu bestimmen, mit denen man sich detaillierter auseinander setzen muss.  

Target Release

Gibt die Produktversion an, in der der Bedarf zum ersten Mal in eine praktische Lösung umgesetzt werden soll. Über dieses Feld können Sie Features aus einem Visionsdokument einem bestimmten Basis-Release zuordnen. In Kombination mit dem Statusfeld kann das Team verschiedene Release-Features vorschlagen, erfassen und diskutieren, ohne sie für die Entwicklung festzuschreiben. Nur Anforderungen, deren Status auf Incorporated gesetzt und deren Ziel-Release (Target Release) definiert ist, werden implementiert. Wenn der Release-Umfang bestimmt wird, kann die Versionsnummer des Ziel-Release heraufgesetzt werden, damit der Artikel im Visionsdokument bleibt und trotzdem für ein späteres Release eingeplant wird.  

Reason

Dieses Textfeld wird verwendet, um die Quelle des Bedarfs zu bestimmen. Anforderungen bestehen aus bestimmten Gründen. In diesem Feld wird eine Erklärung oder ein Verweis auf eine Erklärung erfasst. Der Verweis kann sich z. B. auf eine Seite und Zeilennummer in der Spezifikation einer Produktanforderung oder auf eine Minutenmarkierung in einem Video eines wichtigen Kundeninterviews beziehen.

Attribute für Anwendungsfälle

Status
Wird nach Festlegung und Überprüfung durch das Projektmanagementteam gesetzt. Überwacht den Fortschritt bei der Definition der Projektbasis.

 
Proposed
Zur Beschreibung von Anwendungsfällen, die noch diskutiert werden, jedoch noch nicht von offizieller Seite überprüft und akzeptiert wurden, z. B. eine Arbeitsgruppe aus Vertretern des Projektteams, des Produktmanagements und der Benutzer- bzw. Kundengruppe.
Approved
Anwendungsfälle, die als nützlich und machbar eingestuft und von offizieller Seite für die Implementierung genehmigt wurden.
Incorporated
Anwendungsfälle, die zu einem bestimmten Zeitpunkt in das Basisprodukt eingebunden wurden.

Benefit

Wird vom Marketing, dem Produktmanager oder Geschäftsanalytiker festgelegt. Nicht alle erstellten Anforderungen haben die gleiche Wertigkeit. Dadurch, dass die Anforderungen je nach deren relativem Nutzen für den Benutzer in eine bestimmte Rangfolge gesetzt werden, beginnt ein Dialog zwischen Kunden, Analytiker und Mitgliedern des Entwicklerteams. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.
 
Critical
Wesentliche Anwendungsfälle. Kann die Implementierung nicht durchgeführt werden, bedeutet das, dass das System nicht den Kundenanforderungen genügen kann. Alle kritischen Anwendungsfälle müssen in das Release implementiert werden, andernfalls kann der Zeitplan nicht eingehalten werden.
Important
Anwendungsfälle, die hinsichtlich der Effektivität und Effizienz des Systems für die meisten Anwendungen wichtig sind. Die Funktionalität kann nicht einfach auf andere Weise bereitgestellt werden. Wenn ein wichtiges Feature nicht aufgenommen wird, kann sich dies negativ auf die Kundenzufriedenheit oder sogar den Umsatz auswirken. Zu beachten ist, dass die Freigabe, sollte ein wichtiges Feature fehlen, sich nicht verzögert.
Useful
Anwendungsfälle, die in weniger typischen Anwendungen nützlich sind, seltener verwendet werden oder für die akzeptable Strategien zur Behebung von Problemen möglich sind. Wenn ein solches Element nicht in ein Release aufgenommen wird, sind keine wesentlichen negativen Auswirkungen auf die Kundenzufriedenheit oder den Umsatz zu befürchten.

Effort

Wird vom Entwicklerteam festgelegt. Da einige Anwendungsfälle mehr Zeit und Ressourcen erfordern als andere, empfiehlt es sich in diesen Fällen, die Anzahl der Wochen, die für die Lösung der Aufgabe benötigt werden, pro Team bzw. Person zu schätzen. Dabei sind Details, wie z. B. der erforderliche Umfang der Codezeilen oder Funktionspunkte, zu berücksichtigen. Auf diese Weise kann am besten beurteilt werden, wie komplex eine Aufgabe sich gestaltet und was in einem bestimmten Zeitrahmen erreicht bzw. nicht erreicht werden kann. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.  

Risk

Wird vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass während des Projekts unerwünschte Ereignisse eintreten, wie z. B. ausufernde Kosten, Verzögerungen im Zeitplan oder sogar der Projektabbruch. Die meisten Projektleiter sind der Ansicht, dass die Risikokategorien Hoch, Mittel und Niedrig ausreichend sind, obwohl detailliertere Unterteilungen möglich sind. Ein Risiko kann man oft indirekt beurteilen, indem man die Unsicherheitsfaktoren bei der vom Projektteam vorgenommenen Schätzung des Zeitplans untersucht.  

Stability

Wird vom Analytiker und vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass der Anwendungsfall bzw. das Verständnis, das das Team vom Anwendungsfall hat, sich ändert. Wird verwendet, um die Festlegung von Prioritäten bei der Entwicklung zu vereinfachen und die Punkte zu bestimmen, mit denen man sich detaillierter auseinander setzen muss.  

Target Release

Gibt die Produktversion an, in der der Anwendungsfall zum ersten Mal erscheinen soll. Über dieses Feld können Sie Anwendungsfälle aus einem Dokument mit einer Anwendungsfallübersicht einem bestimmten Basis-Release zuordnen. In Kombination mit dem Statusfeld kann das Team verschiedene Anwendungsfälle vorschlagen, erfassen und diskutieren, ohne sie für die Entwicklung festzuschreiben. Nur Anwendungsfälle, deren Status auf Incorporated gesetzt werden und deren Ziel-Release (Target Release) definiert ist, werden implementiert. Wenn der Release-Umfang bestimmt wird, kann die Versionsnummer des Ziel-Release heraufgesetzt werden, damit der Artikel im Visionsdokument bleibt und trotzdem für ein späteres Release eingeplant wird.  

Assigned To

In vielen Projekten werden Anwendungsfälle Teams zugeordnet, die für die weitere Ausarbeitung, das Schreiben der Softwareanforderungen und die Implementierung zuständig sind. Diese einfache Pulldown-Liste dient den Mitgliedern des Projektteams zum besseren Verständnis der Zuständigkeiten.  

Reason

Dieses Textfeld wird verwendet, um die Quelle des angeforderten Anwendungsfalls zu bestimmen. Anforderungen bestehen aus bestimmten Gründen. In diesem Feld wird eine Erklärung oder ein Verweis auf eine Erklärung erfasst. Der Verweis kann sich z. B. auf eine Seite und Zeilennummer in der Spezifikation einer Produktanforderung oder auf eine Minutenmarkierung in einem Video eines wichtigen Kundeninterviews beziehen.

Attribute für ergänzende Anforderungen

Status
Wird nach Festlegung und Überprüfung durch das Projektmanagementteam gesetzt. Überwacht den Fortschritt bei der Definition der Projektbasis.

 
Proposed
Zur Beschreibung von ergänzenden Spezifikationen, die noch diskutiert werden, jedoch noch nicht von offizieller Seite überprüft und akzeptiert wurden, z. B. eine Arbeitsgruppe aus Vertretern des Projektteams, des Produktmanagements und der Benutzer- bzw. Kundengruppe.
Approved
Leistungsmerkmale, die als nützlich und machbar eingestuft und von offizieller Seite für die Implementierung genehmigt wurden.
Incorporated
Ergänzende Spezifikationen, die zu einem bestimmten Zeitpunkt in das Basisprodukt eingebunden wurden.

Benefit

Wird vom Marketing, dem Produktmanager oder Geschäftsanalytiker festgelegt. Nicht alle erstellten Anforderungen haben die gleiche Wertigkeit. Dadurch, dass die Anforderungen je nach deren relativem Nutzen für den Benutzer in eine bestimmte Rangfolge gesetzt werden, beginnt ein Dialog zwischen Kunden, Analytiker und Mitgliedern des Entwicklerteams. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.
 
Critical
Wesentliche Spezifikation. Kann die Implementierung nicht durchgeführt werden, bedeutet das, dass das System nicht den Kundenanforderungen genügen kann. Alle kritischen Features müssen in das Release implementiert werden, andernfalls kann der Zeitplan nicht eingehalten werden.
Important
Spezifikationen, die hinsichtlich der Effektivität und Effizienz des Systems für die meisten Anwendungen wichtig sind. Die Funktionalität kann nicht einfach auf andere Weise bereitgestellt werden. Wenn wichtige Spezifikationen nicht aufgenommen wird, kann sich dies negativ auf die Kundenzufriedenheit oder sogar den Umsatz auswirken. Zu beachten ist, dass die Freigabe, sollte ein wichtiges Feature fehlen, sich nicht verzögert.
Useful
Spezifikationen, die in weniger typischen Anwendungen nützlich sind, seltener verwendet werden oder für die akzeptable Strategien zur Behebung von Problemen möglich sind. Wenn ein solches Element nicht in ein Release aufgenommen wird, sind keine wesentlichen negativen Auswirkungen auf die Kundenzufriedenheit oder den Umsatz zu befürchten.

Effort

Wird vom Entwicklerteam festgelegt. Da einige Spezifikationen mehr Zeit und Ressourcen erfordern als andere, empfiehlt es sich in diesen Fällen, die Anzahl der Wochen, die für die Lösung der Aufgabe benötigt werden, pro Team bzw. Person zu schätzen. Dabei sind Details, wie z. B. der erforderliche Umfang der Codezeilen oder Funktionspunkte, zu berücksichtigen. Auf diese Weise kann am besten beurteilt werden, wie komplex eine Aufgabe sich gestaltet und was in einem bestimmten Zeitrahmen erreicht bzw. nicht erreicht werden kann. Wird verwendet zur Bestimmung des Umfangs und der Entwicklungspriorität.  

Risk

Wird vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass während des Projekts unerwünschte Ereignisse eintreten, wie z. B. ausufernde Kosten, Verzögerungen im Zeitplan oder sogar der Projektabbruch. Die meisten Projektleiter sind der Ansicht, dass die Risikokategorien Hoch, Mittel und Niedrig ausreichend sind, obwohl detailliertere Unterteilungen möglich sind. Ein Risiko kann man oft indirekt beurteilen, indem man die Unsicherheitsfaktoren bei der vom Projektteam vorgenommenen Schätzung des Zeitplans untersucht.  

Stability

Wird vom Analytiker und vom Entwicklerteam festgelegt. Dabei wird beurteilt, wie wahrscheinlich es ist, dass die Spezifikation bzw. das Verständnis, das das Team von der Spezifikation hat, sich ändert. Wird verwendet, um die Festlegung von Prioritäten bei der Entwicklung zu vereinfachen und die Punkte zu bestimmen, mit denen man sich detaillierter auseinander setzen muss.  

Target Release

Gibt die Produktversion an, in der das angegebene Attribut oder Feature zum ersten Mal erscheinen soll. Über dieses Feld können Sie Spezifikationen einem bestimmten Basis-Release zuordnen. In Kombination mit dem Statusfeld kann das Team verschiedene Release-Spezifikationen vorschlagen, erfassen und diskutieren, ohne sie für die Entwicklung festzuschreiben. Nur Angaben, deren Status auf Incorporated gesetzt werden und deren Ziel-Release (Target Release) definiert ist, werden implementiert. Wenn der Release-Umfang bestimmt wird, kann die Versionsnummer des Ziel-Release heraufgesetzt werden, damit der Artikel im Dokument zur ergänzenden Spezifikation bleibt und trotzdem für ein späteres Release eingeplant wird.  

Assigned To

In vielen Projekten werden angegebene Attribute oder Funktionen Teams zugeordnet, die für die weitere Ausarbeitung, das Schreiben der Softwareanforderungen und die Implementierung zuständig sind. Diese einfache Pulldown-Liste dient den Mitgliedern des Projektteams zum besseren Verständnis der Zuständigkeiten.

3.4  Berichte und Messungen

Siehe CSPS - Bewertungsplan.

3.5  Management der Anforderungsänderungen

Siehe CSPS - Plan für das Konfigurationsmanagement.
Die folgenden Zugriffsgruppen werden konfiguriert, um den Zugriff auf die Anforderungen in Rational RequisitePro zu steuern.

 
 

- Tool-Administrator - hat vollständigen Zugriff auf jede Komponente des Tools. Kann Personen Benutzer hinzufügen und entfernen, deren Zugriffsberechtigungen ändern etc. 

- Autor - kann neue Anforderungen erstellen. 

- Projektleiter - legt den Status von Anforderungen fest. 

- Tester_QA - legt den Status der Anforderungen für Testfälle fest.

3.6       Workflows und Aktivitäten

Siehe CSPS - Entwicklungsfall.

4.  Meilensteine

Siehe CSPS - Softwareentwicklungsplan.

5.  Schulung und Ressourcen

Siehe CSPS - Softwareentwicklungsplan.

 
 
Rational Unified Process