PTA_OOA_Anforderungsmanagement.pdf - PTA GmbH

seit 1969 

Beratung 

Organisation 

Softwareentwicklung 

Anforderungsmanagement Anforderungsmanagement in in der der 

Inception-Phase Inception-Phase (RUP) (RUP) 

Vorschlag für eine Vorgehensweise und 

den Einsatz von Werkzeugen

Anforderungsmanagement in der Inception-Phase 

Gliederung 

• Das Vorgehensmodell 

– Kurze Einführung in Use Cases 

– Anforderungen und Softwareentwicklungsprozess 

– Methoden und Werkzeuge 

– Vorgehensweise für die Inception-Phase 

• Das Anforderungsmanagement 

– Der Anforderungsmanagementplan 

– Das Werkzeug Rational RequisitePro 

– Strukturierung von Use Cases 

• Die Projektplanung 

– Die Initialisierungsphase 

– Überwachung und Verfolgung 

– Bilden von Arbeitspaketen 

12.02.2007 PTA GmbH, Unternehmensberatung 2


Die Bedeutung von Use Cases 

• Anwendungsfallgesteuerte Modellierung (Use Case driven object modeling) 

Use Case Model 

Design Model Implementation Model Test Model 

• Die Use Cases bestimmen den funktionalen Inhalt des geplanten Systems. 



• Ein Use Case kann mit einem Vertrag zwischen Interessenvertretern eines Systems 

(Akteuren) verglichen werden, der das vereinbarte Systemverhalten festlegt. 

• Ein Use Case beschreibt im Sinne der Interessensvertreter, des Hauptakteurs unter 

verschiedenen Bedingungen das Systemverhalten sowie mögliche Interaktionen als 

Antwort auf Systemanfragen, wobei aufgezeigt wird, ob die Zielsetzung des Hauptakteurs 

erreicht bzw. nicht erreicht wird. 

• Ein Use Case ist eine Sammlung von Szenarien in Bezug auf die Zielsetzung des 

Hauptakteurs. 

has a goal 

Primary actor 

requests 

Was ist ist ein Use Case? 

Use Case System 

Scenario A 

responds 

Scenario B 

 

responds 

Secondary actor 

Ein Akteur legt bestimmte Verhaltensweisen an den Tag, er kann Entscheidungsprozesse 

ausführen. 

Ein Akteur kann sein ein (mechanisches) System (Schnittstelle), ein Computer, eine Person, eine 

Organisation oder eine Kombination davon. 

Der Hauptakteur ist meistens derjenige, der den Use Case anstößt. 



• Ein Use Case ist wie eine Erfolgsstory aufgebaut, üblicherweise beschreibt 

er einen Prozess oder Ablauf, um ein bestimmtes Ziel zu erreichen. 

• Ein Akteur stellt eine Anforderung an das System und erhält von diesem 

eine entsprechende Antwort. 

• Der Geschichtsinhalt eines Use Case besteht aus mehreren Teilen und 

erzählt vom Erfolg bzw. Misserfolgen. 

• Zum Inhalt haben Use Cases funktionale Anforderungen, in einer Form, die: 

– leicht zu lesen sind, 

– leicht zu verfolgen sind und 

– vorrangig in Prosa gehalten werden (optional auch graphisch). 

Den richtigen Detaillierungsgrad eines Use Case zu finden, ist wichtig! 

* Siehe Alistair Cockburn, Writing Effective Use Cases" 

Was ist ist ein Use Case*? 



Detaillierungsgrad eines Use Cases (Level of of Goal *) *) 

• In Abhängigkeit von der Zielsetzung eines Use Cases 

wählt der Schreiber den gewünschten Detaillierungsgrad 

aus: 

– Hohe, sehr verallgemeinerten Ebene - Prozessebene 

(Very High) Summary) - Farbe Weiß 

– detaillierte konkrete Ebene - Aktionsebene 

User-Goal - Farbe Blau 

– tiefen eher technischen Ebene - Funktionsebene 

Subfunction - Farbe Indigo und Schwarz 

• Cockburn bringt den Vergleich der Ebenen in Bezug auf 

die Meereshöhe (Sea Level): 

– Über Meereshöhe 

– Auf Meereshöhe 

– Unter Meereshöhe 


Very high summary 

Summary 

User-goal 

Subfunction 

Too low 

12.02.2007 PTA GmbH, Unternehmensberatung 6 

Strategic Goals 

Normal level


• Eine Use Case Spezifikation sollte Antwort auf folgende Fragen geben: 

– Wer? (Der Akteur) 

– Warum? (Die Zielvorstellungen) 

– Wann? (Der Auslöser) 

– Was? (Der normale Verlauf) 

– Was sonst? (Die Sonderfälle: Varianten bzw. Erweiterungen) 

• Die generelle Form des Textes: 

– … 

– … … 

– … … 

– … 

Inhalt eines Use Cases 

Beispiel: 

• Nach dem Abschlussbericht 

• stellt das Labor-Sekretariat 

• die Rechnung für den Rechnungsempfänger aus, 

• wenn der Auftrag vom Vorgesetzten bestätigt 

wurde. 



Use Case Name . < The name is the goal as a short active verb phrase > Level: Summary 

Use Case Description . < A longer statement of the goal in context > 

Associated Actors 

Type Interests 

Primary . < Anyone or anything with behavior: 

Secondary . A system, a person, an organization e.g. > 

… 

Triggering Event . < The event that gets the use case started. > 

Pre-Conditions . < What the system will ensure to be true before letting the use case start. > 

Post-Conditions . < The state of the system upon completion, successfully or not > 

Basic Flow 

Struktur eines Use Cases --Template Template 

Extensions & Variations 

Step Action 

1 . < The main success scenario > 

2 . < The sequence of goal-achieving actions by the various actors > 

… . < Description of the action or name of sub-use case > 

Step Branching Action 

1.1 . < Put here the variations or extensions to the step of the main scenario 

1.2 . with conditions of the variation or extension. > 

… . < Description of the action or name of sub-use case > 

Assumptions . < Conditions that must be true for Use Case to terminate successfully - 

internal conditions. > 

Business Rules . < Declarations of policy or condition that must be satisfied within the business - 

external conditions. > 

List of Issues . < List of issues awaiting decision affecting this use case > 



Was ist ist eine Anforderung? 

Software requirements 

Functional 

Nonfunctional 

Design 

… 

Stakeholder 

needs 

(functional and nonfunctional) 

(Product) Features 

Hardware requirements 

Siehe Dean Leffingwell, "Features, Use Case, Requirements, Oh My!" 

• Zielvorstellung der Auftraggeber bedingt durch Anforderungen aus dem 

Geschäftsalltag. 

• Produkteigenschaften und -merkmale, um bestimmte Zielvorstellungen der 

Auftraggeber zu erfüllen. 

• Softwareanforderungen, um bestimmte Produkteigenschaften zu gewährleisten. 


… 

… 

… 

…

Formal rules 

Other rules 


Anforderungsarten 

Business rules Legal, Political Issues 

Use case requirements 

(functional) 



Supplement requirements 

(nonfunctional) 

Erfüllen Zielvorstellungen 

Gewährleisten bestimmte 

Produkteigenschaften 

• Softwareanforderungen werden abgleitet aus den gewünschten Produkteigenschaften, 

untergliedert in: 

– Funktionale: Use Case Requirements 

– Nichtfunktionale (ergänzende): Supplement Requirements 

Weitere Informationen zu Supplement Requirements siehe gesondertes Dokument PTA_OOA_Anforderungsmanagement_Suppl_Req_e.doc 


Formal rules 

Other rules 





(functional) 



Design requirements Implementation requirements 



Test requirements 

• Softwareanforderungen werden durchgehend im Software-Entwicklungszyklus 

definiert! 


Formal rules 

Other rules 





(functional) 



Design requirements Implementation requirements 



Test requirements 

• Im ersten Schritt (Inception Phase) werden folgende Anforderungen benötigt: 

– Product Features 

– Use Case Requirements 

– Supplement Requirements 


Formal rules 

Other rules 






Use case driven object modeling 

Use Case Requirements Supplement Requirements 

(functional) 


Use case model 

Design Requirements 

Design model 

Implementation 

Implementation 

Requirements 

model Test 

Test 

model 

Requirements 

• Die Anforderungen bestimmen inhaltlich die nachfolgenden Entwicklungsschritte! 



Strukturierung von Anforderungen --Anforderungen Anforderungen untersuchen! untersuchen! 

• Zum Beispiel in Form von Mind Maps 

Gruppierungen 

schaffen! 



Strukturierung von Anforderungen --Gruppierungen Gruppierungen bilden! bilden! 

• Den gleichen Detaillierungsgrad finden! 

• Die Kernaktivitäten aus Prozesssicht bestimmen! 

• Den Detaillierungsgrad auswählen! 



Strukturierung von Anforderungen --Use Use Cases finden! 

• Aus Prozesssicht sind die Use Cases zu bestimmen und zu ordnen: 

– Ein Geschäftsprozess ist eine Abfolge von Aktivitäten, um ein bestimmtes Ziel 

aus Kunden- bzw. Marktsicht zu erreichen. 

– Die Anforderungen sind auf die wesentlichen Geschäftsprozesse hin zu 

untersuchen. 

Beschaffungsprozess 

Laboruntersuchung 

Auftragsbearbeitung 

Personalplanung 

Archivierung von Proben 

… 

Qualitätssicherung 

Entsorgung von 

Schadstoffen 


…



• Was ist der Hauptprozess mit erfolgreichem Abschluss? 

MindManager 

Top down - bottom up! 

Activity Diagram 

Create Order 

Assign tests to 

work area 

Execute order 

Report results 

Start process 

End process 


Hauptprozess mit Erfolg



• Was ist der nächst tiefere Detaillierungsgrad? 

Hauptprozess mit Erfolg 

Stufe 0 

Create order 

Assign tests to 

work area 

Execute order 

Report results 

Start process 

End process 

Stufe 1 

Enter order data 

Assign patient 

Assign sample 

Register and 

validate tests 

Start process 

End process 




Strukturierung von Anforderungen --Use Use Cases schreiben II 

• Beispiel Stufe 0 - Auftragsbearbeitung 



Strukturierung von Anforderungen --Use Use Cases schreiben II II 

FLOW 


Weitere Use Cases 

- Nächste Stufe - 

UC Create Order 

UC Assign Test to 

Work Area 

UC Execute Order 

UC Report Results 

UC Bill Order 



Strukturierung von Anforderungen --Use Use Cases schreiben III III 




Strukturierung von Anforderungen --Use Use Cases schreiben IV IV 

FLOW 

• Beispiel Stufe 1 - Create Order 

Weitere Use Cases 

- Pre-Conditions - 

UC Create User Profile 

UC Create Order Entry Screen 

UC Create Test 



Hauptprozess mit erfolgreichem Abschluss 

• Probe bereits gezogen oder noch nicht. 

Hauptprozess mit Erfolg 

Request 

Create Order 


Assign sample 

Register and 


Start process 

End process 

Sample 

Create Order 


Assign sample 

Register and 


Start process 

End process 


Request 

Print label 

Organize sample 

collection 

Take sample 

Sample 



Hauptprozess mit erfolgreichem Abschluss 

• Was ist der Unterschied zwischen den Abläufen? 

Request 

Create Order 


Assign sample 

Register and 


Start process 

End process 

Sample 

Erweiterung 

Create Order 


Assign sample 

Register and 


Start process 

End process 


Request 

Print label 


collection 

Take sample 

Sample


Strukturierung von Anforderungen --Use Use Cases schreiben V 

UC Create Patient 

• Beispiel Stufe 1 - Create Order - Extensions 


... 

UC Find Patient


"System under discussion (SuD)" * 

"System under discussion (SuD)"* 

• Was für ein System ist zu entwickeln? 

• Welche Aktivitäten sind vom neuen System zu unterstützen? 

Create order 

Start create 


Assign sample 

Register and 


is sample available? 

( yes ) 

( no ) 

End create 

Lab 

Print label 

Hospital 

extension extension 


collection 

Take sample 

extension 




Strukturierung von Anforderungen --Use Use Cases strukturieren 

• Strukturierung: Basic flow, pre-, post-conditions, extensions und variations! 



Strukturierung von Anforderungen --Regeln Regeln für für Use Use Cases 

Weitere Informationen siehe gesondertes Dokument PTA_OOA_UseCaseLeitfaden_e.doc 



Vorgehensweise für die Inception-Phase 

• Was ist eine Inception-Phase? 

• Welches Vorgehensmodell wird eingesetzt? 



Rational Unified Process (RUP) 

• In zahlreichen Firmen wird Rational Suite eingesetzt. 

• RUP ist das Prozessmodell für Softwareentwicklung von Rational (IBM). 



Rational Unified Process (RUP) --Dimensionen Dimensionen 

• RUP hat zwei Dimensionen: 

– Phasen 

– Workflows 



Rational Unified Process (RUP) --Workflows Workflows in in den den Phasen 

• Jede Phase hat einen Anteil an jedem Workflow: 

– mit steigendem Anteil: 

– mit sinkendem Anteil: 

– oder gemischt: 



Rational Unified Process (RUP) --Iterationen Iterationen 

• Jede Phase besteht aus einer oder mehreren Iterationen. 

• Jede Iteration endet mit einem verwertbaren Projektergebnis (Produkt). 



Rational Unified Process (RUP) --Projektergebnisse Projektergebnisse 

Business model 

Business process 

... 

• Jeder Workflow endet mit seinen vordefinierten Projektergebnissen. 




Produkteigenschaften 

Anorderungen 

... 





Analysemodell 

Designmodell 

… 





Quellcode 

Testprotokolle 

… 



Requirements 


Die Werkzeugkiste 

Inception Elaboration Construction Transition 

RequisitePro 

Repository 

Anforderungen 

 

Änderungswünsche 

Change 

Use Case Modell 

 

Anforderungsmodell 

Anforderungen 

 

Modellelemente 

ClearQuest 

Repository 

Model\Code 

Rose 

Anforderungen 

 

Testfälle 

TestManager 

• Integration der Werkzeuge in der Rational Suite: 

RequisitePro ist das führende System! 

Functional Test 

Manual 

Repository 


Robot 

Versionierung der 

Projektergebnisse 

Control 

ClearCase 

Repository


Vorgehensweise in in der Inception-Phase --Teil Teil II 

• Initialisierung 

– Anforderungsmanagementplan erstellen 

– Werkzeug auswählen: z.B. Rational RequisitePro 

– Arbeitspläne für die Inception-Phase anlegen 

– Das Vision-Dokument erstellen bzw. verabschieden 

• Administration 

– Projektstand und -verlauf verfolgen 

– Arbeitspaketstrukturen für die Folgephasen festlegen 

– Projektplan für die Inception-Phase aufstellen 

– Dokumente an die Review-Teilnehmer verteilen 



Vorgehensweise in in der Inception-Phase --Teil Teil II II 

• Dokumentenbearbeitung 

– Grobe Struktur der Use Cases festlegen (auf einem hohen Level) 

– Kontinuierlich diese Struktur überarbeiten 

• Kriterien für die Anforderungsverfolgung überprüfen 

– Use Case Spezifikation anlegen und bearbeiten 

– Supplementary Requirements überarbeiten 

– Komplette Use Case Dokumentation erzeugen 

– Komplette Anforderungsdokumentation erzeugen 

– Use Cases und Anforderungen lt. Review überarbeiten 

• Qualitätssicherung 

– Inhaltlich Use Cases prüfen 

– Formal die Dokumentation prüfen 

• Abnahmeregeln anwenden 



Gliederung 















• Rollen definieren 


• Anforderungsarten bestimmen 

Anforderungsmanagementplan 

• Attribute der Anforderungen festlegen 

• Arten von Dokumenten festsetzen 

• Kriterien für die Anforderungsverfolgung festlegen 



Anforderungsmanagementplan --Rollen Rollen 

• Auftraggeber 

– Bestimmt die strategischen und geschäftlichen Ziele der Anwendung. 

• Anforderungsanalytiker 

– Erarbeitet die Spezifikation einzelner Funktionsbausteine als Teil der gesamten 

Anwendung durch Beschreibung der funktionalen und nichtfunktionalen 

Anforderungen in einen oder mehreren Use Cases. 

• Projektmanager 

– Sorgt dafür, dass die einzelnen Aktivitäten in der festgelegten Reihenfolge 

zeitlich, kostenmäßig und in der erforderlichen Qualität abgearbeitet werden. 


– Ist verantwortlich dafür, dass die Projektstandards von allen Projektmitgliedern 

beachtet und angewendet werden: 

• Formale Review 

• Inhaltliche Review 



Anforderungsmanagementplan --Anforderungsarten Anforderungsarten 

Anforderungsart 

Product Feature 

Use Case Requirement 

Supplementary Requirement 

Glossary Term 

Präfix 

FEAT 

UCSR 

SUPR 

TERM 

Beschreibung 

Die Beschreibung der Produkteigenschaften (z.B. vom Produktmarketing). 

Die Beschreibung der funktionalen Anforderungen zum Systemverhalten. 

Die Beschreibung der nichtfunktionalen Anforderungen. 

Das Glossar über die im Projekt erarbeiteten Begriffe. 








Glossary Term 

Präfix 

FEAT 

UCSR 

SUPR 

TERM 

(Product) Feature (FEAT) 

Beschreibung 

Use Case Req. (UCSR) Supplementary Req. (SUPR) 

(functional requirements) 

Glossary Term (TERM) 

(nonfunctional and functional) 

ist 

abgeleitet 

von 





(nonfunctional requirements) 






Use Case 

Requirement 

Supplementary 

Requirement 

Präfix 

FEAT 

UCSR 

SUPR 

Beschreibung 

Typ: Funktional, Nichtfunktional (oder detaillierter) 

Priorität: Hoch, Mittel, Gering 

Schwierigkeitsgrad: Hoch, Mittel, Gering 

Dauerhaftigkeit: Hoch, Mittel, Gering 

Quelle: Abteilung, Fachbereich 

Die gleichen Attribute wie FEAT (nur ohne Attribut Typ) und zusätzlich: 

Status: Vorgeschlagen, Genehmigt, Validiert 

Sachbearbeiter: Name der Person 

Genehmigt von: Name der Person 

Genehmigt am: Datum 

Validiert von: Name der Person 

Validiert am: Datum 

Auswirkung auf die Architektur?:J/N 

Die gleichen Attribute wie UCSR oben. 



Anforderungsmanagementplan --Attribute Attribute Anforderungen 



Use case 

specification 

Supplementary 

requirement 

Präfix 

FEAT 

UCSR 

SUPR 

Beschreibung 

Typ: Funktional, Nichtfunktional (oder detaillierter) 

Priorität: Hoch, Mittel, Gering 

Schwierigkeitsgrad: Hoch, Mittel, Gering 

Dauerhaftigkeit: Hoch, Mittel, Gering 

Quelle: Abteilung, Fachbereich 

The same fields and additional: 

Status: Proposed, Approved, Validated 

Zusätzliches Attribut: 

Erfüllungsgrad Assigned to: Person name 

Approved by: Person name 

Approval date: Date 

Validated by: Person name 

Validation date: Date 

Affects Architecture: Y/N 

The same fields as above. 

(nonfunctional and functional) 

Product Feature (FEAT) 

ist 

abgeleitet 

von 

Use Case Req. (UCSR) Supplementary Req. (SUPR) 

(functional requirements) (nonfunctional requirements) 



Anforderungsmanagementplan --Dokumentationsarten Dokumentationsarten 

• Anforderungsmanagementplan Requirements Management Plan (RMP) 

– Legt die Anforderungsarten, die einzelnen Attribute von Anforderungen, die 

verschiedenen Dokumentationen sowie die Strategie der Anforderungsverfolgung 

fest. 

• Vision (VIS) 

– Definiert Projektziel und Projektumfang und legt die grundlegende Produkteigenschaften 

(sowie Anforderungen) fest. 

• Use Case Dokument (UCS) 

– Beschreibt die funktionalen und nichtfunktionalen Anforderungen für einen Use 

Cases, dessen Ablauf sowie die Voraussetzungen hierfür wie auch Folgebedingungen. 

• Supplementary Requirements Spezifikation (SUP) 

– Beschreibt systemweit (anwendungsfallübergreifend) die nichtfunktionalen 

Anforderungen sowie die Implementierungsanforderungen. 

• Glossary (GLS) 

– Hat die projektbezogenen Definitionen zum Inhalt. 

Ein Dokument kann mehr als eine Anforderungsart zum Inhalt haben! 



Anforderungsmanagementplan --Dokumente Dokumente und und Anforderungen 





Glossary Term 

VIS 

FEAT 

SUPR 

UCSR 

UCS 

Präfix 

FEAT 

UCSR 

SUPR 

TERM 

TERM 

Beschreibung 





GLS 

SUP 



Anforderungsmanagementplan --Verfolgungskriterien Verfolgungskriterien 

• Anforderungsverfolgung: Besteht zwischen zwei Anforderungen eine 

Abhängigkeit (ist abgleitet von), so sollten Veränderungen der einen 

Anforderung zur anderen verfolgt (Trace-ability) werden können. 


Product Feature (FEAT) Use Case Spec. (UCSR) Supplementary Spec.(SUPR) 

FEAT1 

FEAT2 

FEAT3 

FEAT… 

Trace 

Trace 

(functional requirements) (nonfunctional requirements) 

UCSR1 

UCSR2 

UCSR3 

UCSR… 

SUPR1 

SUPR2 

SUPR3 

SUPR… 

Use Case Requirements und Supplementary Requirements lassen sich zu den Produkteigenschaften zurückverfolgen. 

• Kriterien (Beispiel): Jede FEAT-Anforderung muss zu einer oder mehreren 

UCSR oder zu einer oder mehreren SUPR in Beziehung stehen. 

– Jede UCSR-Anforderung lässt sich zurückführen auf eine FEAT-Anforderung. 

– Jede SUPR-Anforderung lässt sich zurückführen auf eine FEAT-Anforderung. 



Werkzeug Rational RequisitePro 

• Zwei Arbeitsoberflächen - Zwei Verfahren, um Anforderung zu definieren: 

– Anforderungen in einem MS Word-Dokument definieren, das von RequisitePro 

erzeugt wird. 

– Anforderungen direkt in den Dialogen von RequisitePro definieren. 

• Änderungsprotokollierung 

• Projektstruktur: 

– Ersten Aufstellungen von Anforderungen auswerten. 

– Ersten Entwurf einer Struktur für die Anforderungen festlegen. 



Werkzeug Rational RequisitePro --Datenbank Datenbank und und Dokumente 

Project 

Externe Dateien 

Repository für die Attribute einer Anforderung: 

• Oracle RDBMS 

• MS SQL Server 

• MS Access 



Werkzeug Rational RequisitePro --Zwei Zwei Arbeitsoberflächen 

Project 

• Anforderungen können angelegt werden: 

– in einem MS Word Dokument (Word Workplace) 

– in einer Pflegemaske Anforderungen direkt in RequisitePro (View Workplace) 

• Automatische Synchronisation zwischen Dokumenten and Datenbank 



Werkzeug Rational RequisitePro --Arbeitsoberfläche Arbeitsoberfläche Word 

Project 



Werkzeug Rational RequisitePro --Arbeitsoberfläche Arbeitsoberfläche Word 

Öffnen, Sichern, Schließen, Anlegen eines MS Word Dokuments Anlegen und Löschen von Anforderungen in dem Dokument 

Datenpflege von Anforderung in der Datenbank 

• Die RequisitePro-Funktionalität zur Datenbank ist integriert in dem MS 

Word (Add-On in der MS Word-Menustruktur)! 



Werkzeug Rational RequisitePro --Pflegemaske Pflegemaske 



Werkzeug RequisitePro --Änderungsprotokollierung Änderungsprotokollierung 

• Die Änderungsverwaltung setzt Änderungsnummern und -kennungen wie 

folgt ein: 

– Anforderungen 

– Dokumente 

– Projektdefinitionen (Merkmale) 


Project 


Werkzeug RequisitePro --Projektstruktur Projektstruktur 

• Coverage Analysis 

– Auswertungen über den Status der Dokumentenerstellung und -bearbeitung 

• Features and Vision 

– Dokumente, Auswertungen und die Produkteigenschaften (Features). 

• Glossary 

– Dokumente, Auswertungen und das Glossar. 

• Impact Analysis (Änderungsverfolgung) 

– Auswertungen über den Status der Anforderungsverfolgung 

• Supplementary Requirements 

– Dokumente, Auswertungen und die Supplementary Requirements. 

• Use Cases 

– Dokumente, Auswertungen und die Use Case Requirements. 

• Requirements Management Plan 

– Das Dokument selbst 


Project 


Werkzeug RequisitePro --Projektstruktur Projektstruktur 

• Coverage Analysis 

– View: Features ohne Beziehung zu einem Supplementary Request 

– View: Features ohne Beziehung zu einem Use Cases 

– View: Features mit Beziehung zu Use Cases (Auswertung funktionaler 

Anforderungen) 

– … 

• Features and Vision 

– Das Vision-Dokument 

– Auswertung: All Produkteigenschaften (Übersicht) 

– … 

– Die einzelnen Produkteigenschaften 

• Glossary 

– Das Glossar 

– Auswertung : Alle Begriffe 

– … 


Prod. Feature (FEAT) 

Use Case Req. (UCSR) Suppl. Req. (SUPR) 

(functional) (nonfunctional) 

• Impact Analysis (Änderungsverfolgung) 

– Auswertung : Supplementary Requirements von Änderungen von Produkteigenschaften 

betroffen 

– Auswertung : Use Case Requirements von Änderungen von Produkteigenschaften 

betroffen 

– … 



Werkzeug RequisitePro --Struktur Struktur der der Anforderungen 

• Supplementary Requirements 

– Struktur der Anforderungen (Gruppierungen) 

– Supplementary Requirements Dokument(e) 

– Die einzelnen Supplementary Requirements 

– Auswertung: Alle Supplementary Requirements 

– … 

• Use Cases 

– Struktur der Anforderungen (Gruppierungen) 

– Use Case Dokumente 

– Die einzelnen Use Case Requirements 

– Auswertung : Alle Use Case Requirements 

– … 



Gliederung 
















Projektplanung --Initialisierung Initialisierung 

• Arbeitspakete bilden durch nach funktionalen Gesichtspunkten zusammengefasste 

Use Cases 

– Während der Inception-Phase kann dies durch die fachliche Bildung von 

Gruppen geschehen 

• Arbeitspakete den Bearbeitern zuordnen 

• Arbeitspakete den QS-Reviewern zuordnen 

• Arbeitsumfeld einrichten 

• Arbeitsaufgaben planen 

• Projektüberwachung und -verfolgung aufsetzen 



Projektplanung --Arbeitspakete Arbeitspakete bilden 

Product Feature (FEAT) 

FEAT1 

FEAT2 

FEAT3 

FEAT4 

FEAT5 

FEAT… 

Arbeitspaket A 

Unterpaket G 

Unterpaket G 

SUPR1 

UCSR8 

SUPR… 

Querschnittsaufgabe A 

Struktur in RequisitePro 

Use Case Spez. (UCSR) Supplementary Spez.(SUPR) 

Paket A 

Paket C 

Unterpaket B 

UCSR10 

UCSR11 

UCSR… 

Arbeitspaket B 

UCSR1 

UCSR2 

UCSR… 

Arbeitsunterpaket B.1 

Paket C 

UCSR10 

UCSR11 

Struktur der Arbeitspakete 

Querschnittsaufgabe B 

Arbeitsunterpaket B.2 

Für spätere Phasen 

Paket F 

Paket L 

Unterpaket G 

SUPR10 

SUPR11 

SUPR… 

• Die fachliche Struktur der Use Cases über alle Phasen hinweg aufrecht erhalten! 

Unterpaket G 


SUPR1 

SUPR2 

SUPR…


Projektverfolgung und -überwachung 

• Auswertungen in RequisitePro 

– Status für Use Case und Supplementary Requirements: 

• Vorgeschlagen 

• Genehmigt 

• Abgenommen 

– Produkteigenschaften ohne Bezug zu Use Cases oder 

Supplementary Requirements 

– Produkteigenschaften und ihr Erfüllungsgrad 

– … 

• Berechnungen in RequisitePro (Export nach MS Excel) 

– Anzahl Anforderungen je Status 

– Proz. Anteil von abgenommen Use Case Requirements 

– … 

• Spez. Auswertungen über kompl. Abfragen in Access: 

– Auswertungen über alle Anforderungsarten 

mit komplexen Selektionskriterien 

– … 



Projektverfolgung und -überwachung --Aufwandsschätzung Aufwandsschätzung 

Summe des Aufwands 

Annahme 50% 



Projektverfolgung und -überwachung --Aufwandsschätzung Aufwandsschätzung 

Summe des 

Aufwands 



Projektverfolgung und -überwachung --In In den den Folgephasen 

Requirements 

RequisitePro 

Repository 

Anforderungen 

 

Modellelemente 

Use Case Modell 

 

Anforderungsmodell 


Model\Code 

Rose


• Schulung 

– RequisitePro anwenden 

– Use Cases erstellen und bearbeiten 

Projektsitzungen 

• Projektbesprechungen 

– In wöchentlichen oder monatlichen Abständen 

– Projektstand präsentieren 

– Offene Punkte klären 

• Dokumentenbearbeitung 

– Sitzung je Gliederungspunkt 

– Struktur der Use Cases abstimmen 

– Inhalt der Use Cases besprechen 


– Sitzung je Gliederungspunkt 

– Review-Ergebnisse einarbeiten

PTA_OOA_Anforderungsmanagement.pdf - PTA GmbH

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?