Requirements-Management: Unterschied zwischen den Versionen
(27 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
Zeile 10: | Zeile 10: | ||
;Hinweis | ;Hinweis | ||
: Hier können auch sicherheitsrelevante Themen miteingearbeitet werden, speziell Datenschutz, etc. | : Hier können auch sicherheitsrelevante Themen miteingearbeitet werden, speziell Datenschutz, etc. | ||
+ | : Mögliche Tools zur Unterstützung bei Requirements-Management (Empfehlung TOGAF): [http://www.volere.co.uk/tools.htm Requirement-Tools] | ||
;Steps | ;Steps | ||
: Näheres hierzu, siehe [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap17.html#tag_17_04/ Requirements-Management-Steps nach TOGAF] | : Näheres hierzu, siehe [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap17.html#tag_17_04/ 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. | ||
{| 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 !! Empfehlungen für IVS-Refenzarchitekturen !! Empfehlungen für IVS-Architekturen realer IVS-Dienste |
|- | |- | ||
Zeile 21: | Zeile 26: | ||
||1 | ||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. | ||
− | || | + | || Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken. |
− | ||[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap26.html#tag_26/ Business-Szenarios] | + | ||[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap26.html#tag_26/ Business-Szenarios] |
− | ||[[IVS- | + | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] |
− | + | ||[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | |
+ | | | ||
+ | | | ||
|- | |- | ||
Zeile 36: | Zeile 43: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 45: | Zeile 53: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 57: | Zeile 66: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 70: | Zeile 80: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 82: | Zeile 93: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 91: | Zeile 103: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 100: | Zeile 113: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 109: | Zeile 123: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 122: | Zeile 137: | ||
|| | || | ||
|| | || | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |} | ||
+ | |||
+ | == 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. | ||
+ | |||
+ | {| class="wikitable" | ||
+ | ! 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 | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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. | ||
+ | |[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap26.html#tag_26/ Business-Szenarios] | ||
+ | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | ||
+ | |[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | ||
+ | |[[Anforderungen Geschäftsarchitektur Los 3 | Anforderungen - Los 3: Geschäftsarchitektur ]] | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |2 | ||
+ | |Grundanforderungen: | ||
+ | * Anforderungen der jeweiligen Phase festlegen | ||
+ | * Stakeholder der Anforderungen bestätigen | ||
+ | * Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |3 | ||
+ | |Überwachung der Grundanforderungen | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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: [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html#tag_36_02_18/ Requirements Impact Assessment] | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |7 | ||
+ | |Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |8 | ||
+ | |Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |9 | ||
+ | |Änderungen in den jeweiligen Phasen implementieren | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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. | ||
+ | |||
+ | {| class="wikitable" | ||
+ | ! 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 | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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. | ||
+ | |[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap26.html#tag_26/ Business-Szenarios] | ||
+ | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | ||
+ | |[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |2 | ||
+ | |Grundanforderungen: | ||
+ | * Anforderungen der jeweiligen Phase festlegen | ||
+ | * Stakeholder der Anforderungen bestätigen | ||
+ | * Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |3 | ||
+ | |Überwachung der Grundanforderungen | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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: [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html#tag_36_02_18/ Requirements Impact Assessment] | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |7 | ||
+ | |Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |8 | ||
+ | |Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |9 | ||
+ | |Änderungen in den jeweiligen Phasen implementieren | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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. | ||
+ | {| class="wikitable" | ||
+ | ! 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 | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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. | ||
+ | |[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap26.html#tag_26/ Business-Szenarios] | ||
+ | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | ||
+ | |[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |2 | ||
+ | |Grundanforderungen: | ||
+ | * Anforderungen der jeweiligen Phase festlegen | ||
+ | * Stakeholder der Anforderungen bestätigen | ||
+ | * Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |3 | ||
+ | |Überwachung der Grundanforderungen | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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: [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html#tag_36_02_18/ Requirements Impact Assessment] | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |7 | ||
+ | |Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |8 | ||
+ | |Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |9 | ||
+ | |Änderungen in den jeweiligen Phasen implementieren | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | |- style="vertical-align:top;" | ||
+ | |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. | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
|} | |} | ||
+ | ---- | ||
+ | [[Hauptseite|<< Zurück zur Hauptseite]] |
Aktuelle Version vom 1. Dezember 2016, 13:13 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 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 | 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 | 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 | K: IVS-Anforderungen | Anforderungen - Los 3: Geschäftsarchitektur | |
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 | 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 | K: IVS-Anforderungen | ||
2 | Grundanforderungen:
|
|||||
3 | Überwachung der Grundanforderungen | |||||
4 | Identifikation geänderter Anforderungen
|
|||||
5 | Identifikation geänderter Anforderungen:
|
|||||
6 |
|
|||||
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 | 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 | K: IVS-Anforderungen | ||
2 | Grundanforderungen:
|
|||||
3 | Überwachung der Grundanforderungen | |||||
4 | Identifikation geänderter Anforderungen
|
|||||
5 | Identifikation geänderter Anforderungen:
|
|||||
6 |
|
|||||
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. |