Requirements-Management: Unterschied zwischen den Versionen
Zeile 153: | Zeile 153: | ||
|1 | |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. | ||
− | | 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] | |[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 ]] | ||
Zeile 159: | Zeile 159: | ||
|[[Anforderungen Geschäftsarchitektur Los 3]] | |[[Anforderungen Geschäftsarchitektur Los 3]] | ||
| | | | ||
− | |||
− | |||
|- | |- | ||
Zeile 174: | Zeile 172: | ||
| | | | ||
| | | | ||
− | |||
|- | |- | ||
Zeile 185: | Zeile 182: | ||
| | | | ||
| | | | ||
− | |||
|- | |- | ||
Zeile 199: | Zeile 195: | ||
| | | | ||
| | | | ||
− | |||
|- | |- | ||
|- 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. | ||
− | || | + | | |
− | || | + | | |
− | | | + | | |
− | + | | | |
+ | | | ||
|} | |} |
Version vom 1. Dezember 2016, 13:01 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 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 | 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 Geschäftsarchitektur Los 3 | ||||
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 |
---|---|---|---|---|
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 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 | 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. |
|