Requirements-Management: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(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-Anforderungen| O: IVS-Anforderung ]]
+
[[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

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

Abgerufen von „http://wikiivs.albrechtconsult.com/index.php?title=Requirements-Management&oldid=8855“