Requirements-Management - Versionsgeschichte

Albrecht: /* Requirements Management in Phase D - Technologiearchitektur */

2016-12-01T12:13:09Z

Requirements Management in Phase D - Technologiearchitektur

Albrecht: /* Requirements Management in Phase D - Technologiearchitektur */

2016-12-01T12:12:51Z

Requirements Management in Phase D - Technologiearchitektur

Albrecht: /* Requirements Management in Phase D - Technologiearchitektur */

2016-12-01T12:12:22Z

Requirements Management in Phase D - Technologiearchitektur

Albrecht: /* Requirements Management in Phase C - Informationsarchitektur */

2016-12-01T12:10:05Z

Requirements Management in Phase C - Informationsarchitektur

Albrecht: /* Requirements Management in Phase C - Informationsarchitektur */

2016-12-01T12:09:24Z

Requirements Management in Phase C - Informationsarchitektur

Albrecht: /* Requirements Management in der Phase A - Architekturvision */

2016-12-01T12:06:44Z

Requirements Management in der Phase A - Architekturvision

Albrecht: /* Requirements Management in Phase B - Geschäftsarchitektur */

2016-12-01T12:04:58Z

Requirements Management in Phase B - Geschäftsarchitektur

Albrecht: /* Requirements Management in Phase D - Technologiearchitektur */

2016-12-01T12:03:17Z

Requirements Management in Phase D - Technologiearchitektur

Albrecht: /* Requirements Management in Phase C - Informationsarchitektur */

2016-12-01T12:02:57Z

Requirements Management in Phase C - Informationsarchitektur

Albrecht: /* Requirements Management in Phase B - Geschäftsarchitektur */

2016-12-01T12:02:35Z

Requirements Management in Phase B - Geschäftsarchitektur

@@ Zeile 489: / Zeile 489: @@
+|
+|
 |-

@@ Zeile 403: / Zeile 403: @@
 *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
+! 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 407: / Zeile 407: @@
 |-
 |- style="vertical-align:top;"
-||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.
+| 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-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]]
 |-
 |- style="vertical-align:top;"
-||2
+|2
-||Grundanforderungen:
+|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
+|3
-||Überwachung der Grundanforderungen
+|Überwachung der Grundanforderungen
 ||
 ||
-||
-−
+|
 |-
 |- style="vertical-align:top;"
-||4
+|4
-||Identifikation geänderter Anforderungen
+|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
+|5
-||Identifikation geänderter Anforderungen:
+|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
+|6
-||* Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen
-* 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;"
-||7
+|7
-||Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
+|Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
 ||
 ||
 ||
-−
+|
 |-
 |- style="vertical-align:top;"
-||8
+|8
-||Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
+|Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
 ||
 ||
-||
-−
+|
 |-
 |- style="vertical-align:top;"
-||9
+|9
-||Änderungen in den jeweiligen Phasen implementieren
+|Änderungen in den jeweiligen Phasen implementieren
-||
 ||
-||
-−
+|
 |-
 |- style="vertical-align:top;"
-||10
+|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:
 * 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]]

@@ Zeile 341: / Zeile 341: @@
 |6
+|
-* Einfluss der Anforderungs-Änderungen in der aktiv durchlaufenen Phase beurteilen
+*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
+|
+|
@@ Zeile 360: / Zeile 360: @@
+|
+|
 |-
@@ Zeile 383: / Zeile 380: @@
+|
+|
-−
 |-

@@ Zeile 274: / Zeile 274: @@
 {| 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;"
-||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.
+| 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-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]]
 |-
 |- style="vertical-align:top;"
-||2
+|2
-||Grundanforderungen:
+|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
+|3
-||Überwachung der Grundanforderungen
+|Überwachung der Grundanforderungen
 ||
 ||
-||
-−
+|
 |-
 |- style="vertical-align:top;"
-||4
+|4
-||Identifikation geänderter Anforderungen
+|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
+|5
-||Identifikation geänderter Anforderungen:
+|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
+|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
+|7
-||Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
+|Anforderungen, die in Phase H – Architecture Change Management – anfallen, implementieren
 ||
 ||
 ||
-−
+|
 |-
 |- style="vertical-align:top;"
-||8
+|8
-||Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
+|Update des Repository der identifizierten Anforderungen mit den, im Änderungsantrag der Phase H anfallenden Änderungen und Anforderungen
 ||
 ||
-||
-−
+|
 |-
 |- style="vertical-align:top;"
-||9
+|9
-||Änderungen in den jeweiligen Phasen implementieren
+|Änderungen in den jeweiligen Phasen implementieren
-||
 ||
 ||
-−
+|
 |-
 |- style="vertical-align:top;"
-||10
+|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.
 ||
 ||
-||
-−
+|
 |}

@@ 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]
-== Requirements Management in der Phase A - Architekturvision ==
+== 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.

@@ Zeile 157: / Zeile 157: @@
 [[IVS-Anforderungen| Template: Baustein IVS-Anforderung ]]
 |[[Media:IVS-Anforderung-Template-Katalog_00-00-01.docx | K: IVS-Anforderungen]]
-|[[Anforderungen Geschäftsarchitektur Los 3]]
+|[[Anforderungen Geschäftsarchitektur Los 3 | Anforderungen - Los 3: Geschäftsarchitektur ]]
+|

@@ Zeile 386: / Zeile 386: @@
 == 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"
 ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Anleitung !! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables

@@ Zeile 270: / Zeile 270: @@
 == 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"

@@ Zeile 252: / Zeile 252: @@
+|
+|
 |-