Previous Next V-Model Official Homepage by IABG  
Header  
SE1: System-Anforderungsanalyse  

  SD1 - System Requirements Analysis

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
    Extern - Alle Rahmenbedingungen - -      
    Extern - Alle Externe Vorgaben (AG) - -    
    SE2 akzeptiert Alle Systemarchitektur(1) - -    
    - - Alle Anwenderforderungen SE2
    SE3
    SE4-SW
    SE5-SW
    vorgelegt KOM(2)
    CRC(2)
    DFM
    ER(4)
    EXPM(8)
    FKTD
    FMEA(5)
    FNET(7)
    IAM(2)
    PRODIAG(2)
    ZUVM(6)
    SVM /(7)
    SSM(2)
    ZUSTO(3)
    UCM(2)
     
    - - Alle SWPÄ-Konzept SE9
    PM5
    vorgelegt OGG
    NWALK
     
    - - Alle Protokoll PM6 -    

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

    Abwicklung

    Abbildung 4.2

    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.

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