Requirements-Management

Architektur Requirements-Management

Allgemeine Infos

Das Requirements-Management wird während den Steps zur Entwicklung einer IVS-Architektur kontinuierlich angewendet. Es handelt sich hierbei um einen dynamischen Ansatz, bei dem innerhalb der Phasen Anforderungen an die Architektur identifiziert werden.

Zudem werden im Requirements-Management spätere Änderungen und daraus resultierende Anforderungen an die Architektur in den jeweiligen Phasen eingepflegt.

Identifikation von Anforderungen

Um Anforderungen, die der Architektur-Vision entsprechen, zu ermitteln, kann die Technik der Business-Szenarios angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen. Genaueres hierzu siehe: Business-Szenarios

Hinweis

Hier können auch sicherheitsrelevante Themen miteingearbeitet werden, speziell Datenschutz, etc.

Mögliche Tools zur Unterstützung bei Requirements-Management (Empfehlung TOGAF): Requirement-Tools

Steps

Näheres hierzu, siehe Requirements-Management-Steps nach TOGAF

Requirements Management in Phase A - Architekturvision

• In der Phase A werden mit Hilfe von Business Szenarien das Problem und mögliche Schritte zur Lösung des Problems beschrieben.
• Dabei entstehen erste Anforderungen, die erfasst und dokumentiert werden müssen.
• Im Anschluss ist zu Prüfen, ob diese Anforderungen zur Architekturvision passen.

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Anleitung	Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables	Empfehlungen für IVS-Refenzarchitekturen	Empfehlungen für IVS-Architekturen realer IVS-Dienste
1	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken.	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken.	Business-Szenarios Template: Baustein IVS-Anforderung	K: IVS-Anforderungen
2	Grundanforderungen: Anforderungen der jeweiligen Phase festlegen Stakeholder der Anforderungen bestätigen Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository
3	Überwachung der Grundanforderungen
4	Identifikation geänderter Anforderungen Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten Neu aufgekommene Anforderungen hinzufügen Bestehende Anforderungen ändern, falls nötig
5	Identifikation geänderter Anforderungen: Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind Neue aufkommende Anforderungen hinzufügen Sicherstellen, dass Konflikte erkannt werden und gemanagt werden Erstellung eines Dokuments zur Protokollierung der durchgeführten Änderungen, siehe hierzu: Requirements Impact Assessment
6	* Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen Festlegen, ob Änderungen übernommen werden oder in einen späteren Zyklus der ADM übertragen wird; falls die Entscheidung zur Übernahme getroffen wird, muss der Zeitraum für die Änderung festgelegt und bewertet werden Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment
7	Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
8	Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
9	Änderungen in den jeweiligen Phasen implementieren
10	Bewertung und Revision der durchgeführten Gap-Analysen der vorher durchlaufenen Phasen. Gaps, die in den Phasen A bis D angefallen sind beziehen sich auf Lücken zwischen Ist-/ und Soll-Architektur, daraus ergeben sich Anforderungen, die ADM beschreibt zwei Arten an Gaps: Etwas, was in der Ist-(Grund)-Architektur vorhanden ist, jedoch nicht in der Ziel-Architektur (bspw. unabsichtliches Eliminieren) Etwas ist nicht in der Ist-Architektur, muss aber in der Ziel-Architektur existieren (bspw. neue Anforderung) Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs.

Requirements Management in Phase B - Geschäftsarchitektur

• In Phase B werden Requirements in Bezug auf die Geschäftsarchitektur erfasst.
• Sollte es schon ähnliche Requirements aus der Phase A geben, können diese hier verfeinert werden.

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Anleitung	Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables	Empfehlungen für IVS-Refenzarchitekturen	Empfehlungen für IVS-Architekturen realer IVS-Dienste
1	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu anderen Techniken.	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu anderen Techniken.	Business-Szenarios Template: Baustein IVS-Anforderung	K: IVS-Anforderungen	Anforderungen - Los 3: Geschäftsarchitektur
2	Grundanforderungen: Anforderungen der jeweiligen Phase festlegen Stakeholder der Anforderungen bestätigen Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository
3	Überwachung der Grundanforderungen
4	Identifikation geänderter Anforderungen Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten Neu aufgekommene Anforderungen hinzufügen Bestehende Anforderungen ändern, falls nötig
5	Identifikation geänderter Anforderungen: Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind Neue aufkommende Anforderungen hinzufügen Sicherstellen, dass Konflikte erkannt werden und gemanagt werden Erstellung eines Dokuments zur Protokollierung der durchgeführten Änderungen, siehe hierzu: Requirements Impact Assessment
6	* Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen Festlegen, ob Änderungen übernommen werden oder in einen späteren Zyklus der ADM übertragen wird; falls die Entscheidung zur Übernahme getroffen wird, muss der Zeitraum für die Änderung festgelegt und bewertet werden Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment
7	Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
8	Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
9	Änderungen in den jeweiligen Phasen implementieren
10	Bewertung und Revision der durchgeführten Gap-Analysen der vorher durchlaufenen Phasen. Gaps, die in den Phasen A bis D angefallen sind beziehen sich auf Lücken zwischen Ist-/ und Soll-Architektur, daraus ergeben sich Anforderungen, die ADM beschreibt zwei Arten an Gaps: Etwas, was in der Ist-(Grund)-Architektur vorhanden ist, jedoch nicht in der Ziel-Architektur (bspw. unabsichtliches Eliminieren) Etwas ist nicht in der Ist-Architektur, muss aber in der Ziel-Architektur existieren (bspw. neue Anforderung) Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs.

Requirements Management in Phase C - Informationsarchitektur

• In Phase C werden Requirements in Bezug auf die Daten- und Anwendungsarchitektur erfasst.
• Sollte es schon ähnliche Requirements aus der Phase A geben, können diese hier verfeinert werden.

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Anleitung	Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables	Empfehlungen für IVS-Refenzarchitekturen	Empfehlungen für IVS-Architekturen realer IVS-Dienste
1	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken.	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken.	Business-Szenarios Template: Baustein IVS-Anforderung	K: IVS-Anforderungen
2	Grundanforderungen: Anforderungen der jeweiligen Phase festlegen Stakeholder der Anforderungen bestätigen Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository
3	Überwachung der Grundanforderungen
4	Identifikation geänderter Anforderungen Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten Neu aufgekommene Anforderungen hinzufügen Bestehende Anforderungen ändern, falls nötig
5	Identifikation geänderter Anforderungen: Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind Neue aufkommende Anforderungen hinzufügen Sicherstellen, dass Konflikte erkannt werden und gemanagt werden Erstellung eines Dokuments zur Protokollierung der durchgeführten Änderungen, siehe hierzu: Requirements Impact Assessment
6	Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen Festlegen, ob Änderungen übernommen werden oder in einen späteren Zyklus der ADM übertragen wird; falls die Entscheidung zur Übernahme getroffen wird, muss der Zeitraum für die Änderung festgelegt und bewertet werden Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment
7	Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
8	Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
9	Änderungen in den jeweiligen Phasen implementieren
10	Bewertung und Revision der durchgeführten Gap-Analysen der vorher durchlaufenen Phasen. Gaps, die in den Phasen A bis D angefallen sind beziehen sich auf Lücken zwischen Ist-/ und Soll-Architektur, daraus ergeben sich Anforderungen, die ADM beschreibt zwei Arten an Gaps: Etwas, was in der Ist-(Grund)-Architektur vorhanden ist, jedoch nicht in der Ziel-Architektur (bspw. unabsichtliches Eliminieren) Etwas ist nicht in der Ist-Architektur, muss aber in der Ziel-Architektur existieren (bspw. neue Anforderung) Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs.

Requirements Management in Phase D - Technologiearchitektur

• In Phase D werden Requirements in Bezug auf die Technologiearchitektur erfasst.
• Sollte es schon ähnliche Requirements aus der Phase A geben, können diese hier verfeinert werden.

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Anleitung	Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables	Empfehlungen für IVS-Refenzarchitekturen	Empfehlungen für IVS-Architekturen realer IVS-Dienste
1	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken.	Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken.	Business-Szenarios Template: Baustein IVS-Anforderung	K: IVS-Anforderungen
2	Grundanforderungen: Anforderungen der jeweiligen Phase festlegen Stakeholder der Anforderungen bestätigen Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository
3	Überwachung der Grundanforderungen
4	Identifikation geänderter Anforderungen Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten Neu aufgekommene Anforderungen hinzufügen Bestehende Anforderungen ändern, falls nötig
5	Identifikation geänderter Anforderungen: Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind Neue aufkommende Anforderungen hinzufügen Sicherstellen, dass Konflikte erkannt werden und gemanagt werden Erstellung eines Dokuments zur Protokollierung der durchgeführten Änderungen, siehe hierzu: Requirements Impact Assessment
6	Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen Festlegen, ob Änderungen übernommen werden oder in einen späteren Zyklus der ADM übertragen wird; falls die Entscheidung zur Übernahme getroffen wird, muss der Zeitraum für die Änderung festgelegt und bewertet werden Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment
7	Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
8	Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
9	Änderungen in den jeweiligen Phasen implementieren
10	Bewertung und Revision der durchgeführten Gap-Analysen der vorher durchlaufenen Phasen. Gaps, die in den Phasen A bis D angefallen sind beziehen sich auf Lücken zwischen Ist-/ und Soll-Architektur, daraus ergeben sich Anforderungen, die ADM beschreibt zwei Arten an Gaps: Etwas, was in der Ist-(Grund)-Architektur vorhanden ist, jedoch nicht in der Ziel-Architektur (bspw. unabsichtliches Eliminieren) Etwas ist nicht in der Ist-Architektur, muss aber in der Ziel-Architektur existieren (bspw. neue Anforderung) Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs.

---

<< Zurück zur Hauptseite