Requirements-Management

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen

Architektur Requirements-Management

Allgemeine Infos
Das Requirements-Management wird während den Steps zur Entwicklung einer IVS-Architektur kontinuierlich angewendet. Es handelt sich hierbei um einen dynamischen Ansatz, bei dem innerhalb der Phasen Anforderungen an die Architektur identifiziert werden.
Zudem werden im Requirements-Management spätere Änderungen und daraus resultierende Anforderungen an die Architektur in den jeweiligen Phasen eingepflegt.
Identifikation von Anforderungen
Um Anforderungen, die der Architektur-Vision entsprechen, zu ermitteln, kann die Technik der Business-Szenarios angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen. Genaueres hierzu siehe: Business-Szenarios
Hinweis
Hier können auch sicherheitsrelevante Themen miteingearbeitet werden, speziell Datenschutz, etc.
Mögliche Tools zur Unterstützung bei Requirements-Management (Empfehlung TOGAF): Requirement-Tools
Steps
Näheres hierzu, siehe Requirements-Management-Steps nach TOGAF

Requirements Management in der Phase A - Architekturvision

  • In der Phase A werden mit Hilfe von Business Szenarien das Problem und mögliche Schritte zur Lösung des Problems beschrieben.
  • Dabei entstehen erste Anforderungen, die erfasst und dokumentiert werden müssen.
  • Im Anschluss ist zu Prüfen, ob diese Anforderungen zur Architekturvision passen.
Schritt TOGAF Tailoring IVS-Rahmenarchitektur Anleitung Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
1 Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken. Identifizierung/Dokumentation von Anforderungen – mithilfe der Business-Szenario-Technik, oder analog dazu andere Techniken. Business-Szenarios

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 Empfehlung für IVS-Refenzarchitekturen Empfehlung für IVS-Refenzarchitekturen 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 Geschäftsarchitektur Los 3
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
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
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