Requirements-Management: Unterschied zwischen den Versionen
(20 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 15: | Zeile 15: | ||
: 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 == | |
− | == Requirements Management in | + | *In der Phase A werden mit Hilfe von Business Szenarien das Problem und mögliche Schritte zur Lösung des Problems beschrieben. |
− | 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. | + | *Dabei entstehen erste Anforderungen, die erfasst und dokumentiert werden müssen. |
− | Im Anschluss ist zu Prüfen, ob diese Anforderungen zur Architekturvision passen. | + | *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 32: | Zeile 30: | ||
[[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]] | ||
+ | | | ||
+ | | | ||
|- | |- | ||
Zeile 43: | Zeile 43: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 52: | Zeile 53: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 64: | Zeile 66: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 77: | Zeile 80: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 89: | Zeile 93: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 98: | Zeile 103: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 107: | Zeile 113: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 116: | Zeile 123: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|- | |- | ||
Zeile 129: | Zeile 137: | ||
|| | || | ||
|| | || | ||
− | + | | | |
+ | | | ||
|} | |} | ||
− | |||
== Requirements Management in Phase B - Geschäftsarchitektur == | == 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. | + | *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" | {| 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 |
|- | |- | ||
|- style="vertical-align:top;" | |- 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 ]] | [[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;" | |- style="vertical-align:top;" | ||
− | + | |2 | |
− | + | |Grundanforderungen: | |
* Anforderungen der jeweiligen Phase festlegen | * Anforderungen der jeweiligen Phase festlegen | ||
* Stakeholder der Anforderungen bestätigen | * Stakeholder der Anforderungen bestätigen | ||
* Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | * Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |3 | |
− | + | |Überwachung der Grundanforderungen | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |4 | |
− | + | |Identifikation geänderter Anforderungen | |
* Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten | * Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten | ||
* Neu aufgekommene Anforderungen hinzufügen | * Neu aufgekommene Anforderungen hinzufügen | ||
* Bestehende Anforderungen ändern, falls nötig | * Bestehende Anforderungen ändern, falls nötig | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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 | * Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind | ||
* Neue aufkommende Anforderungen hinzufügen | * Neue aufkommende Anforderungen hinzufügen | ||
* Sicherstellen, dass Konflikte erkannt werden und gemanagt werden | * 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] | * 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;" | |- style="vertical-align:top;" | ||
− | + | |6 | |
− | + | |* Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen | |
* Einfluss der Anforderungs-Änderung der vorherig 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 | * 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 | * Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |7 | |
− | + | |Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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;" | |- style="vertical-align:top;" | ||
− | + | |9 | |
− | + | |Änderungen in den jeweiligen Phasen implementieren | |
− | + | | | |
− | || | + | | |
− | || | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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: | 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, 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) | * 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. | Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs. | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|} | |} | ||
== Requirements Management in Phase C - Informationsarchitektur == | == 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. | + | *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" | {| 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 |
|- | |- | ||
|- style="vertical-align:top;" | |- 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 ]] | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | ||
− | + | |[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | |
+ | | | ||
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |2 | |
− | + | |Grundanforderungen: | |
* Anforderungen der jeweiligen Phase festlegen | * Anforderungen der jeweiligen Phase festlegen | ||
* Stakeholder der Anforderungen bestätigen | * Stakeholder der Anforderungen bestätigen | ||
* Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | * Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |3 | |
− | + | |Überwachung der Grundanforderungen | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |4 | |
− | + | |Identifikation geänderter Anforderungen | |
* Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten | * Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten | ||
* Neu aufgekommene Anforderungen hinzufügen | * Neu aufgekommene Anforderungen hinzufügen | ||
* Bestehende Anforderungen ändern, falls nötig | * Bestehende Anforderungen ändern, falls nötig | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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 | * Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind | ||
* Neue aufkommende Anforderungen hinzufügen | * Neue aufkommende Anforderungen hinzufügen | ||
* Sicherstellen, dass Konflikte erkannt werden und gemanagt werden | * 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] | * 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;" | |- style="vertical-align:top;" | ||
− | + | |6 | |
− | | | + | | |
− | * Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen | + | *Einfluss der Anforderungs-Änderungen in der aktiv 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 | + | *Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen |
− | * Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment | + | *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;" | |- style="vertical-align:top;" | ||
− | + | |7 | |
− | + | |Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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;" | |- style="vertical-align:top;" | ||
− | + | |9 | |
− | + | |Änderungen in den jeweiligen Phasen implementieren | |
− | + | | | |
− | || | + | | |
− | || | + | | |
+ | | | ||
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |10 | |
− | ||Bewertung und Revision der durchgeführten Gap-Analysen der vorher durchlaufenen Phasen. | + | || |
+ | 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: | 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, 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) | * 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. | Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs. | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|} | |} | ||
== Requirements Management in Phase D - Technologiearchitektur == | == 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. | + | *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" | {| 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 |
|- | |- | ||
|- style="vertical-align:top;" | |- 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 ]] | [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]] | ||
− | + | |[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]] | |
+ | | | ||
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |2 | |
− | + | |Grundanforderungen: | |
* Anforderungen der jeweiligen Phase festlegen | * Anforderungen der jeweiligen Phase festlegen | ||
* Stakeholder der Anforderungen bestätigen | * Stakeholder der Anforderungen bestätigen | ||
* Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | * Anforderungen festhalten, wenn möglich in einem hierfür festgelegten Repository | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |3 | |
− | + | |Überwachung der Grundanforderungen | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | + | |4 | |
− | + | |Identifikation geänderter Anforderungen | |
* Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten | * Priorisierte Anforderungen, die geändert werden sollen, entfernen oder ersetzten | ||
* Neu aufgekommene Anforderungen hinzufügen | * Neu aufgekommene Anforderungen hinzufügen | ||
* Bestehende Anforderungen ändern, falls nötig | * Bestehende Anforderungen ändern, falls nötig | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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 | * Identifikation der geänderten Anforderung und passende Priorisierung der Anforderungen, die für die jeweilige Phase am essentiellsten sind | ||
* Neue aufkommende Anforderungen hinzufügen | * Neue aufkommende Anforderungen hinzufügen | ||
* Sicherstellen, dass Konflikte erkannt werden und gemanagt werden | * 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] | * 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;" | |- style="vertical-align:top;" | ||
− | + | |6 | |
− | | | + | | |
− | * Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen | + | *Einfluss der Anforderungs-Änderungen in der aktiv 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 | + | *Einfluss der Anforderungs-Änderung der vorherig durchlaufenen Phase beurteilen |
− | * Festhalten auf dem in Step 5 erstellten Requirements Impact Assessment | + | *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;" | |- style="vertical-align:top;" | ||
− | + | |7 | |
− | + | |Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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;" | |- style="vertical-align:top;" | ||
− | + | |9 | |
− | + | |Änderungen in den jeweiligen Phasen implementieren | |
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|- | |- | ||
|- style="vertical-align:top;" | |- 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: | 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, 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) | * 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. | Anforderungen die aus Lücken sich ergeben sind immer Anforderungen des ersteren Typs. | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|} | |} | ||
---- | ---- | ||
[[Hauptseite|<< Zurück zur Hauptseite]] | [[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. |