Collegiate Sports Paging System Plan für das Anforderungsmanagement Version 1.0 Revisionsprotokoll
Inhaltsverzeichnis 1.3 Definitionen, Akronyme und Abkürzungen 2.1 Organisation, Zuständigkeiten und Schnittstellen 2.2 Tools, Umgebung und Infrastruktur 3. Programm für Anforderungsmanagement 3.1 Definition der Anforderungen Kriterien für Stakeholder-Bedarf Kriterien für ergänzende Anforderungen Attribute für Stakeholder-Bedarf Attribute für ergänzende Anforderungen 3.5 Management der Anforderungsänderungen Plan für das Anforderungsmanagement 1. Einführung1.1 ZweckDieses 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 UmfangDieser Plan betrifft alle Phasen des Projekts.
1.3 Definitionen, Akronyme und AbkürzungenSiehe Glossar.
1.4 ReferenzinformationenCSPS - Softwareentwicklungsplan
CSPS - Entwicklungsfall
CSPS - Bewertungsplan CSPS - Plan für das Konfigurationsmanagement 2. Anforderungsmanagement2.1 Organisation, Zuständigkeiten und SchnittstellenSiehe CSPS - Softwareentwicklungsplan.
2.2 Tools, Umgebung und InfrastrukturRational 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 Anforderungsmanagement3.1 Festlegung der Anforderungen
3.2 Rückverfolgbarkeit![]() Abbildung 1: Diagramm zur Rückverfolgbarkeit Kriterien für FeaturesFeatures werden
zu Anwendungsfällen zurückverfolgt.
Kriterien für Stakeholder-BedarfDer
Benutzerbedarf wird zu Features zurückverfolgt. Es wird kein
Bedarf implementiert, der nicht zu einem Feature zurückverfolgt werden kann.
Kriterien für AnwendungsfälleAnwendungsfälle
werden zu Testfällen zurückverfolgt.
Kriterien für ergänzende AnforderungenErgänzende
Spezifikationen werden zu Testfällen zurückverfolgt.
3.3 AttributeAttribute für FeaturesStatus
Wird nach Festlegung und Überprüfung durch das
Projektmanagementteam festgelegt. Überwacht den Fortschritt bei der Definition der Projektbasis.
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.
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-BedarfStatus
Wird nach Festlegung und Überprüfung durch das
Projektmanagementteam gesetzt. Überwacht den Fortschritt bei der Definition der Projektbasis.
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älleWird nach Festlegung und Überprüfung durch das
Projektmanagementteam gesetzt. Überwacht den Fortschritt bei der Definition der Projektbasis.
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.
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 AnforderungenStatus
Wird nach Festlegung und Überprüfung durch das
Projektmanagementteam gesetzt. Überwacht den Fortschritt bei der Definition der Projektbasis.
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.
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 MessungenSiehe CSPS - Bewertungsplan.
3.5 Management der AnforderungsänderungenSiehe 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ätenSiehe CSPS - Entwicklungsfall.
4. MeilensteineSiehe CSPS - Softwareentwicklungsplan.
5. Schulung und RessourcenSiehe CSPS - Softwareentwicklungsplan.
|
Rational Unified Process
|