Requirements-Management: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 3: Zeile 3:
 
;Allgemeine Infos
 
;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.  
 
: 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.  
+
:Zudem werden im Requirements-Management spätere Änderungen und daraus resultierende Anforderungen an die Architektur in den jeweiligen Phasen eingepflegt.  
  
 
;Identifikation von Anforderungen
 
;Identifikation von Anforderungen

Version vom 30. Juni 2016, 13:37 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.
Steps
Näheres hierzu, siehe Requirements-Management-Steps nach TOGAF
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. Business-Szenarios O: IVS-Anforderung


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.