Wylie College

Plan für das Anforderungsmanagement

 

Version 2.0

 

 

Revisionsprotokoll

Datum

Version

Beschreibung

Autor

08. Januar 1999

1.0

Erstes Release

Simon Jones

10. Februar 1999

2.0 

Planerweiterung 

 Simon Jones

 
 
 
 
 
 
 
 

 


Inhaltsverzeichnis

1.     Einführung  

1.1      Verwendungszweck  

1.2      Geltungsbereich  

1.3      Definitionen, Akronyme und Abkürzungen  

1.4      Referenzen  

2.     Anforderungsmanagement

2.1      Organisation, Zuständigkeiten und Schnittstellen  

2.2      Tools, Umgebung und Infrastruktur  

3.     Programm für Anforderungsmanagement   

3.1      Anforderungen identifizieren  

3.2      Rückverfolgbarkeit  

3.2.1     Kriterien für Produktanforderungen

3.2.2     Kriterien für die Anforderungen an Anwendungsfälle

3.2.3     Kriterien für Testfälle

3.3      Attribute  

3.3.1      Attribute für die Anforderungen an Anwendungsfälle

3.3.2     Attribute für Testfälle

3.4      Berichte und Messungen  

3.5      Änderungsmanagement für Anforderungen

3.6      Disziplinen und Aufgaben  

4.     Meilensteine  

5.     Schulung und Ressourcen  


Plan für das Anforderungsmanagement

1.                  Einführung

1.1               Verwendungszweck

Die Richtlinien für Anforderungsattribute benennen und beschreiben die Attribute, die für die Verwaltung der Anforderungen an alle Softwareprojekte des Wylie College verwendet werden. Dieses Dokument umreißt darüber hinaus die Rückverfolgbarkeit der Projektanforderungen während der Entwicklung.

Anhand der Attributen, die den einzelnen Anforderungen zugeordnet werden, wird die Softwareentwicklung verwaltet und werden den Features der einzelnen Releases Prioritäten zugeordnet.

Ziel der Rückverfolgbarkeit der Anforderungen ist es, die Anzahl der gegen Ende des Entwicklungszyklus festgestellten Mängel zu reduzieren. Wenn sichergestellt ist, dass die Softwarevoraussetzungen, das Design und die Testfälle vollständig sind, kann eine bessere Produktqualität erreicht werden.

1.2            Geltungsbereich

Die Richtlinien für Attribute und Rückverfolgbarkeit in diesem Dokument gelten für die Produkt-, Software- und Testanforderungen aller Softwareprojekte des Wylie College.

1.3                Definitionen, Akronyme und Abkürzungen

Die hier verwendeten Begriffe sind im Rational Unified Process und in der Dokumentation zu Rational RequisitePro definiert.

1.4                Referenzen

Die folgenden Referenzen sind auf der Website des Wylie College zum Softwareprozess verfügbar.

1. Konfigurationsmanagementplan des Wylie College
2. Rational Unified Process
3. Entwicklungsfall des Wylie College

2.                  Anforderungsmanagement

2.1                Organisation, Zuständigkeiten und Schnittstellen

Im Softwareentwicklungsplan des jeweiligen Projekts beschrieben

2.2                Tools, Umgebung und Infrastruktur

Anforderungsattribute und Rückverfolgbarkeit werden mit Rational RequisitePro verwaltet. Die übrigen Infrastrukturdetails finden Sie auf der Website des Wylie College zum Softwareprozess.

3.                  Programm für Anforderungsmanagement

3.1                Anforderungen identifizieren

Für jedes Projekt werden folgende Anforderungstypen identifiziert und verwaltet:

 

Arbeitsergebnisse

 

Anforderungstyp

Beschreibung

Vision

Produktanforderungen

Produktfeatures, Einschränkungen, Qualitätsstufen und weitere Produktanforderungen

Anwendungsfallmodell

Anwendungsfall

In Rational Rose dokumentierte Anwendungsfälle

Testplan

Testfälle

Fälle, die beschreiben, wie geprüft werden kann, ob sich das System wie erwartet verhält

 

3.2                Rückverfolgbarkeit

3.2.1     Kriterien für Produktanforderungen

Die im Visionsdokument definierten Produktanforderungen werden aus den entsprechenden Anwendungsfällen oder aus ergänzenden Anforderungen in den Spezifikationen der Anwendungsfälle und in der ergänzenden Spezifikation hergeleitet.

Jede Produktanforderung wird aus den Anforderungen für mindestens einen Anwendungsfall und den ergänzenden Anforderungen abgeleitet.

Jede Produktanforderung wird aus den Anforderungen für mindestens einen Anwendungsfall und den ergänzenden Anforderungen abgeleitet.

3.2.2     Kriterien für die Anforderungen an Anwendungsfälle

Die in den Spezifikationen der Anwendungsfälle und der ergänzenden Spezifikation definierten Anforderungen an Anwendungsfälle werden aus den entsprechenden, im Testplan angegebenen Testfällen abgeleitet.

Jede Anforderung an einen Testfall wird aus mindestens einem Systemtestfall abgeleitet.

3.2.3     Kriterien für Testfälle

Die im Testplan angegebenen Testfälle werden von den Produktanforderungen (aus dem Visionsdokument) und den Anforderungen an Anwendungsfälle, die mit dem jeweiligen Testfall überprüft werden, hergeleitet.

Ein Testfall kann aus mindestens einer Produktanforderung und den Anforderungen für mindestens einen Anwendungsfall abgeleitet werden. Wenn mit dem Testfall eine abgeleitete Anforderung oder das Design überprüft wird, lässt sich der Testfall möglicherweise nicht auf die ursprünglichen Produktanforderungen oder die ursprünglichen Anforderungen an Anwendungsfälle zurückführen.

3.3                Attribute

3.3.1      Attribute für Anforderungen an Anwendungsfälle

Die Anforderungen an Anwendungsfälle und die ergänzende Spezifikation werden mit Hilfe der in diesem Abschnitt definierten Attribute verwaltet. Diese Attribute sind für die Verwaltung der Entwicklungsschritte, die Bestimmung des Iterationsinhalts und die Zuordnung von Anwendungsfällen zu einem bestimmten Rose-Modell geeignet.

Status

Wird gesetzt, nachdem die Anwendungsfälle per Analyse entworfen wurden. Protokolliert den Fortschritt der Entwicklung des Anwendungsfalls vom ersten Entwurf bis hin zur abschließenden Validierung.

Vorgeschlagen

Anwendungsfälle, die festgelegt, jedoch noch nicht überprüft oder genehmigt wurden

Genehmigt

Für die weitere Gestaltung und Implementierung freigegebene Anwendungsfälle

Validiert

In einem Systemtest validierte Anwendungsfälle

Priorität

Die Priorität wird vom Projektmanager festgelegt. Die Wichtigkeit der Zuordnung von Entwicklungsressourcen zu einem Anwendungsfall und der Überwachung des Fortschritts bei der Anwendungsfallentwicklung bestimmt die Priorität eines Anwendungsfalls. Der erkennbare Vorteil für den Benutzer, die geplante Freigabe, die geplante Iteration, die Komplexität des Anwendungsfalls (Risiko) und der Aufwand für die Implementierung eines Anwendungsfalls bilden in der Regel die Basis für die Priorität.

Hoch

Die Priorität des Anwendungsfalls bezüglich der strikten Überwachung seiner Implementierung und der Zuordnung von geeigneten Ressourcen für die jeweiligen Aufgaben ist hoch.

Mittel

Verglichen mit anderen Anwendungsfällen hat dieser Anwendungsfall eine mittlere Priorität.

Niedrig

Der Anwendungsfall hat eine niedrige Priorität. Die Implementierung dieses Anwendungsfalls ist weniger kritisch und kann auch auf spätere Iterationen oder Releases verschoben werden.

Aufwandsschätzung

Diese Schätzung wird vom Entwicklerteam abgegeben. Da einige Anwendungsfälle mehr Zeit und Ressourcen als andere erfordern, kann beispielsweise anhand einer Einschätzung der Team- oder Mannwochen und der erforderlichen Anzahl von Codezeilen oder Funktionspunkten 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. Auf dieser Einschätzung basiert das Scope-Management. Außerdem werden ausgehend von dieser Einschätzung die Prioritäten bei der Entwicklung gesetzt. Der Projektmanager kann auf der Basis dieser Aufwandsschätzung den Projektzeitplan festlegen und effizient die Ressourcen für die einzelnen Aufgaben planen.

Die Aufwandsschätzung wird in Manntagen (bei 7,5 Arbeitsstunden pro Werktag) angegeben.

Technische Risiken

Diese Risiken definiert das Entwicklerteam ausgehend von der Wahrscheinlichkeit, mit der unerwünschte Ereignisse in Anwendungsfällen zu erwarten sind. Hierzu gehören Designfehler, eine hohe Anzahl von Mängeln, geringe Qualität, geringer Durchsatz, ein übermäßiger Aufwand usw. Solche unerwünschten Ereignisse sind oft auf unzureichend verstandene oder definierte Anforderungen, fehlende Kenntnisse, mangelnde Ressourcen, technische Komplexität, neue Technologien, neue Tools oder neue Ausrüstung zurückzuführen.

Für Projekte des Wylie College werden die technischen Risiken jedes einzelnen Anwendungsfalls als hoch, mittel oder niedrig eingestuft.

Hoch

Die Auswirkungen des Risikos sind schwerwiegend und die Risikowahrscheinlichkeit ist hoch.

Mittel

Die Auswirkungen des Risikos sind weniger schwerwiegend und die Risikowahrscheinlichkeit ist weniger hoch.

Niedrig

Die Auswirkungen des Risikos sind minimal und die Risikowahrscheinlichkeit ist niedrig.

Zieliteration für die Entwicklung

Protokolliert die Entwicklungsiteration, in der der Anwendungsfall implementiert wird. Es ist davon auszugehen, dass sich die Entwicklung der einzelnen Releases über mehrere Entwicklungsiterationen in der Konstruktionsphase des Projekts erstrecken wird.

Anhand der Iterationsnummer jedes Anwendungsfalls plant der Projektmanager die Aktivitäten des Projektteams.

Die Werte setzen sich aus Buchstaben für die Iteration (Kp, A, Kt, Ü für Konzeption, Ausarbeitung, Konstruktion und Übergang) und der Iterationsnummer zusammen. Beispiele:

 A1

Geplant für Iteration 1 der Ausarbeitungsphase

Kt1

Geplant für Iteration 1 der Konstruktionsphase

Kt2

Geplant für Iteration 2 der Konstruktionsphase

Kt3

Geplant für Iteration 3 der Konstruktionsphase

Zuständig

Analyse, Design und Implementierung der Anwendungsfälle werden einzelnen Personen oder Entwicklerteams zugewiesen. Eine einfache Pulldown-Liste gibt einen guten Überblick über die Zuständigkeiten im Projektteam.

Rational-Rose-Modell

Bezeichnet das der Anwendungsfallanforderung zugeordnete Rose-Anwendungsfallmodell.

3.3.2     Attribute für Testfälle

Teststatus

Der Status wird von der Testleitung angegeben, die den Status jedes Testfalls verfolgt.

Nicht getestet

Der Testfall wurde nicht ausgeführt.

Gescheitert

Der Test wurde durchgeführt und ist gescheitert.

Bedingt bestanden

Der Test wurde mit Problemen beendet. Dem Test wird der Status 'Bestanden' zugeordnet, jedoch unter der Bedingung, dass bestimmte Maßnahmen ergriffen werden.

Bestanden

Der Test wurde erfolgreich abgeschlossen.

Build-Nummer

Gibt den System-Build an, bei dem der spezielle Testfall überprüft wird.

Getestet von

Die Person, die mit der Durchführung und Prüfung des Testfalls betraut wurde. Diese einfache Pulldown-Liste gibt einen guten Überblick über die Zuständigkeiten im Projektteam.

Testdatum

Das geplante oder tatsächliche Testdatum

Anmerkungen zum Test

Anmerkungen zur Planung oder Ausführung des Tests

3.4                Berichte und Messungen

NZE

3.5                Änderungsmanagement für Anforderungen

Siehe Konfigurationsmanagementplan des Wylie College

3.6               Disziplinen und Aufgaben

Siehe Entwicklungsfall des Wylie College

4.                  Meilensteine

Die Meilensteine werden im Softwareentwicklungsplan des jeweiligen Projekts beschrieben.

5.                  Schulung und Ressourcen

Diese Informationen enthält der Softwareentwicklungsplan zum jeweiligen Projekt.