Previous Next V-Model Official Homepage by IABG  
Header  
SD1: System Requirements Analysis  

  SE1 - System-Anforderungsanalyse

Contents  
  • Product Flow
  • Handling
  • Roles
    		•  
  • Sub-activities
  • External Norms
  • Links to the V-Model Mailinglist
    		•      

    Product Flow

    From Product to Methods Tool Req. Ext. Norms
    Activity State Chapter Title Activity State
    External - All Marginal Conditions - -      
    External - All External Specifications (customer) - -    
    SD2 accepted All System Architecture (1) - -    
    - - All User Requirements SD2
    SD3
    SD4-SW
    SD5-SW    		 submitted COM(2)
    CRC(2)
    DFM
    ER (4)
    EXPM (8)
    FCTD
    FMEA (5)
    FNET (7)
    IAM(2)
    PRODIAG(2)
    RELM (6)
    SBM /(7)
    SSM(2)
    STMO (3)
    UCM(2)     		 
    - - All SWMM Concept SD9
    PM5    		 submitted OGC
    BAR    		  
    - - All Protocol PM6 -    

    + "Chapter" are extra columns from the original printed version of GD 250

    Handling

    Figure 4.2

    Figure 4.2: SD1 - System Requirement Analysis

    * Setting up the User Requirements

    The User Requirements are used (in connection with the System in question) as a complete, user-level set of requirements. When the System is finished, it must be proven by means of validation that the external specifications and the User Requirements have been met.

    Activity SD1 - System Requirements Analysis includes recording and analysis of the actual status. Depending on the design objective, this actual recording/analysis is realized on several levels of the existing technical System and also regards the organizational and technical integration of the System. Weak points and the corresponding causes are also identified.

    Next, the overall horizon for the system functionality is to be specified on the basis of the external specifications. This is done in the form of a preliminary system description, making up the framework for all further refinements and additions of the User Requirements in the following development cycles.

    The further steps include the definition of the technical, organizational and other marginal conditions as well as the requirements with regard to quality, in as far as they can be detected in the external specifications for the system development.

    The System must now be structured from the user-level point of view. The functionality of the System has to be defined in a degree of refinement corresponding to the complexity of the System, i. e. the central functionality must be clearly described from the user's point of view, and the range of function has to be defined with regard to the overall horizon.

    Next, the possible threats and risks have to be analyzed. As a result of the threat and risk analysis other requirements for the System might have to be defined.

    * Realization of Requirements Controlling

    Feasibility and profitability are assessed on the basis of the first architectural considerations which might result in a modification of the User Requirements. This is realized and agreed between user and customer/implementor. The results of the requirements controlling are documented in a Protocol.

    * Setting up the SWMM Concept

    The frame for the SWMM in the later system operation is defined in the SWMM Concept. Organization and SWMM procedure are documented.

    ---------- The following part is an extension of the original printed version of GD 250 -----------

    Roles

    Role Participation
    Data Administrator cooperating (SD1.5)
    Data Protection Specialist advising (SD1.5)
    IT Representative cooperating (SD1.5,SD1.5)
    IT Security Representative responsible (SD1.6)
    Project Leader cooperating (SD1.7,SD1.8)
    System Administrator cooperating (SD1.5)
    System Analyst cooperating (SD1.7),
    responsible (SD1.1, SD1.2, SD1.3, SD1.4, SD1.5)
    System Designer advising (SD1.1),
    cooperating (SD1.7
    responsible (SD1.8)
    Technical Author cooperating (SD1.5)
    User cooperating (SD1.1, SD1.2, SD1.3, SD1.4, SD1.5, SD1.8
    responsible (SD1.7)

    Sub-activities

    SD1.1 - Recording of Actual Status and Analysis
    SD1.2 - Description of Application System
    SD1.3 - Definition of Criticality and Quality Requirements
    SD1.4 - Definition of Marginal Conditions
    SD1.5 - User-Level System Structure
    SD1.6 - Threat and Risk Analysis
    SD1.7 - Realization of Requirements Controlling
    SD1.8 - Generation of Software Maintenance and Modification Concept

    External Norms

    Being defined

    Links to the V-Model Mailinglist

    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)
    Notes

    (1)   The System Architecture is an input information when requirements controlling is to be realized on the basis of a concrete architecture suggestion.

    (2) The methods have to be applied in object-oriented developments.

    (3) Method STMO is to be applied for the dynamic system modeling in object-oriented procedures.

    (4) Method ER is to be applied for information systems.

    (5) Method FMEA is to be applied in case where reliability requirements are high.

    (6) Method RELM is to be applied in case of high demands to realiability.

    (7) Method SBM is to be applied for realtime applications or respectively distributed systems with a high level of criticality. Method FNET is to be applied for information systems.

    (8) Method EXPM is intended for knowledge-based systems.

    Previous Next This page online  •  GDPA Online  •  Last Updated 10.Sep.2002 by C. Freericks