Requirements-Management: Unterschied zwischen den Versionen
Zeile 139: | Zeile 139: | ||
{| class="wikitable" | {| class="wikitable" | ||
− | ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Anleitung !! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables | + | ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Anleitung !! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables !! IVS-Referenzarchitektur !! IVS-Architektur realer IVS-Dienste |
|- | |- | ||
Zeile 149: | Zeile 149: | ||
[[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | ||
||[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | ||[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | ||
+ | ||[[Anforderungen Geschäftsarchitektur Los 3]] | ||
+ | || | ||
|- | |- |
Version vom 1. Dezember 2016, 06:57 Uhr
Inhaltsverzeichnis
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 der 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 |
---|---|---|---|---|
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 | K: IVS-Anforderungen |
2 | Grundanforderungen:
|
| ||
3 | Überwachung der Grundanforderungen |
| ||
4 | Identifikation geänderter Anforderungen
|
| ||
5 | Identifikation geänderter Anforderungen:
|
| ||
6 | * Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen
|
| ||
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:
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 | IVS-Referenzarchitektur | IVS-Architektur 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 | K: IVS-Anforderungen | Anforderungen Geschäftsarchitektur Los 3 | |
2 | Grundanforderungen:
|
| ||||
3 | Überwachung der Grundanforderungen |
| ||||
4 | Identifikation geänderter Anforderungen
|
| ||||
5 | Identifikation geänderter Anforderungen:
|
| ||||
6 | * Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen
|
| ||||
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:
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 |
---|---|---|---|---|
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 | K: IVS-Anforderungen |
2 | Grundanforderungen:
|
| ||
3 | Überwachung der Grundanforderungen |
| ||
4 | Identifikation geänderter Anforderungen
|
| ||
5 | Identifikation geänderter Anforderungen:
|
| ||
6 | * Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen
|
| ||
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:
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 |
---|---|---|---|---|
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 | K: IVS-Anforderungen |
2 | Grundanforderungen:
|
| ||
3 | Überwachung der Grundanforderungen |
| ||
4 | Identifikation geänderter Anforderungen
|
| ||
5 | Identifikation geänderter Anforderungen:
|
| ||
6 | * Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen
|
| ||
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:
Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs. |
|