SE 1: System-Anforderungsanalyse



		SE1: System-Anforderungsanalyse

SD1 - System Requirements Analysis

Inhalt
Produktfluß
Abwicklung
Rollen

Teilaktivitäten
Externe Normen
Verknüpfungen mit der V-Modell Mailingliste

Inhalt		Produktfluß Abwicklung Rollen		Teilaktivitäten Externe Normen Verknüpfungen mit der V-Modell Mailingliste

Produktfluß

von		Produkt		nach		Methoden	Werkzeug Anf.	Externe Normen
Aktivität	Zustand	Kapitel	Titel	Aktivität	Zustand	Methoden	Werkzeug Anf.	Externe Normen
Extern	-	Alle	Rahmenbedingungen	-	-
Extern	-	Alle	Externe Vorgaben (AG)	-	-
SE2	akzeptiert	Alle	Systemarchitektur ⁽¹⁾	-	-
-	-	Alle	Anwenderforderungen	SE2 SE3 SE4-SW SE5-SW	vorgelegt	KOM ⁽²⁾ CRC ⁽²⁾ DFM ER ⁽⁴⁾ EXPM ⁽⁸⁾ FKTD FMEA ⁽⁵⁾ FNET ⁽⁷⁾ IAM ⁽²⁾ PRODIAG ⁽²⁾ ZUVM ⁽⁶⁾ SVM /⁽⁷⁾ SSM ⁽²⁾ ZUSTO ⁽³⁾ UCM ⁽²⁾
-	-	Alle	SWPÄ-Konzept	SE9 PM5	vorgelegt	OGG NWALK
-	-	Alle	Protokoll	PM6	-

+ "Kapitel" sind zusätzliche Spalten zum Originalausdruck AU 250

Abwicklung

Abbildung 4.2: SE1 - System-Anforderungsanalyse

* Anwenderforderungen erarbeiten

Die Anwenderforderungen werden (in bezug auf das betrachtete System) als vollständige, fachliche Forderungen verstanden. Die Erfüllung der externen Vorgaben und der Anwenderforderungen ist am fertigen System durch Validierung nachzuweisen.

Die Aktivität SE1 "System-Anforderungsanalyse" beinhaltet die Aufnahme und Analyse des Ist-Zustands. Je nach Entwicklungsziel erstreckt sich diese Ist-Aufnahme/-Analyse über mehrere Ebenen des bestehenden technischen Systems und betrachtet auch dessen organisatorische und technische Einbindung. Dabei werden Schwachstellen und deren Ursachen identifiziert.

Nachfolgend ist auf der Basis der externen Vorgaben ein Gesamthorizont für die Funktionalität des Systems zu spezifizieren. Dies geschieht in der Form einer groben Systembeschreibung, die den Rahmen für alle weiteren Verfeinerungen und Ergänzungen der Anwenderforderungen in nachfolgenden Entwicklungszyklen bildet.

In weiteren Schritten sind die technischen, organisatorischen und weiteren Randbedingungen sowie die Anforderungen an die Qualität festzuhalten, soweit sie aus den externen Vorgaben für die Systementwicklung erkennbar sind.

Anschließend ist das System fachlich zu strukturieren. Die Funktionalität des Systems ist in einer der Komplexität des Systems entsprechenden Detaillierung festzulegen, d.h. aus Anwendersicht ist die Kernfunktionalität klar zu beschreiben, und der Funktionsumfang ist im Sinne eines Gesamthorizonts anzugeben.

Nachfolgend sind die möglichen Bedrohungen und Risiken zu analysieren. Als Ergebnis der Bedrohungs- und Risikoanalyse werden evtl. weitere Anforderungen an das System definiert.

* Forderungscontrolling durchführen

Auf der Basis erster Architekturüberlegungen werden Betrachtungen zur Realisierbarkeit und zur Wirtschaftlichkeit angestellt, die zur Modifizierung der Anwenderforderungen führen können. Dies findet im Einvernehmen zwischen Anwender und Auftraggeber/Realisierer statt. Die Ergebnisse des Forderungscontrolling werden in einem Protokoll dokumentiert.

* Erarbeitung des SWPÄ-Konzepts

Im SWPÄ-Konzept wird der Rahmen für die SWPÄ im späteren Systembetrieb festgelegt. Organisation und Vorgehensweise in der SWPÄ werden beschrieben.

---------- Der folgende Teil ist eine erweiterung zum Originalausdruck AU 250 -----------

Rollen

Rolle	Beteilungsarten
Datenadministrator	mitwirkend (SE1.5)
Datenschutzbeauftragter	beratend (SE1.5)
IT-Beauftragter	mitwirkend (SE1.5,SE1.5)
IT-Sicherheitsbeauftragter	verantwortlich (SE1.6)
Projektleiter	mitwirkend (SE1.7,SE1.8)
Systembetreuer	mitwirkend (SE1.5)
Systemanalytiker	mitwirkend (SE1.7), verantwortlich (SE1.1, SE1.2, SE1.3, SE1.4, SE1.5)
Systemdesigner	beratend (SE1.1), mitwirkend (SE1.7 verantwortlich (SE1.8)
Technischer Autor	mitwirkend (SE1.5)
Anwender	mitwirkend (SE1.1, SE1.2, SE1.3, SE1.4, SE1.5, SE1.8 verantwortlich (SE1.7)

Teilaktivitäten

SE1.1 - Ist-Aufnahme/-Analyse durchführen
SE1.2 - Anwendungssystem beschreiben
SE1.3 - Kritikalität und Anforderungen an die Qualität def.
SE1.4 - Randbedingungen definieren
SE1.5 - System fachlich strukturieren
SE1.6 - Bedrohung und Risiko analysieren
SE1.7 - Forderungscontrolling durchführen
SE1.8 - Software-Pflege- und Änderungs-Konzept erstellen

Externe Normen

Im Bearbeitung

Verknüpfungen mit der V-Modell Mailingliste

Mail 0595 - Re: Unterstützung der Betriebseinführung (595)
Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0318 - Re: Anwenderforderung zur Datenhaltung (318)
Mail 0316 - Re: Anwenderforderung zur Datenhaltung (316)
Mail 0178 - Re: Technische Anforderungen (178)

Hinweise

(1) Die Systemarchitektur ist dann Eingangsinformation, wenn ein Forderungscontrolling auf der Basis eines konkreten Architekturvorschlags durchgeführt werden soll.

(2) Die Methoden sind bei objektorientierter Entwicklung einzusetzen.

(3) Die Methode ZUSTO ist für die dynamische Systemmodellierung bei objektorientierter Vorgehensweise anzuwenden.

(4) Die Methode ER ist für Informationssysteme anzuwenden.

(5) Die Methode FMEA ist im Falle hoher Anforderungen an die Zuverlässigkeit anzuwenden.

(6) Die Methode ZUVM ist im Falle hoher Anforderungen an die Zuverlässigkeit anzuwenden.

(7) Die Methode SVM ist anzuwenden, wenn es sich um eine Echtzeitanwendung bzw. ein verteiltes System handelt und die Kritikalität hoch ist. Die Methode FNET ist für Informationssysteme anzuwenden.

(8) Die Methode EXPM ist für wissensbasierte Systeme anzuwenden.

This page online • GDPA Online • Last Updated 27.Jun.2003 by C. Freericks