Previous Next V-Model Official Homepage by IABG  
Header  
8.2.2 System Architecture (SysArc)  

  Systemarchitektur

Contents  
  • Introduction
  • Document Index
  • Document Structure
  • Product Flow
  • Links to the V-Model Mailinglist
  • Introduction

    The System Architecture describes the static system structure as a network structure with the elements of the generic product structure. The description includes the elements of the product structure up to the SW Units/HW Units. The architectures of the SW Units and the HW Units can be found in the corresponding architecture documents.

    The product System Architecture includes possible solution proposals, results from feasibility studies, the IT security concept, the IT security model, and the allocation between User Requirements and the elements of the System Architecture.


    Document Index

    1. General Information
    2. System Structure
         2.1. Representation of the Technical System Architecture
               2.1.1. Technical System Structure
               2.1.2. Identification of Interfaces
               2.1.3. Requirements Allocation
         2.2. Explanation of the Cooperation of Technical Elements
    3. Realization
         3.1. Solution Proposals
         3.2. Feasibility Studies
    4. IT Security Concept
    5. IT Security Model

    Document Structure

    1. General Information

    See schema 1. General Information.

    2. System Structure

    2. 1. Representation of the Technical System Architecture

    2. 1. 1. Technical System Structure

    The System is represented as a network of elements of the technical architecture. In this connection, the possibilities of the generic product structure are applied, if possible, to combine SW Units/HW Units into suitable Segments, and the Segments into Systems. The architectural parts are uniquely identified and marked by means of the information from the CM Plan. The element list of the architecture must be complete and consistent.

    Those parts of the System that are to be realized with off-the-shelf products or in which off-the-shelf products are to be used have to be specified.

    During the System Architecture design it is necessary to observe that, normally, the technical structure of an IT system and the organization at the user have an impact on each other. The user organization has an important impact on solution approaches, and has to be consulted, on the one hand, with regard to considerations about the System Architecture. In IT systems with a client-server architecture, on the other hand, capacities for technical system and user support may have to be planned at the actual site, in the user organization. These considerations should also include the distribution of new system versions and variants during system utilization, and should be regulated in an organizational manner. In this connection, both technical and economical aspects have to be taken into consideration.

    2. 1. 2. Identification of Interfaces

    The identification of the interfaces results from the architecture; the interfaces are uniquely identified in a table, together with the name of the corresponding partner. The interfaces are defined within the scope of the technical design. This is where the system-internal and system-external interfaces are identified. Technical interfaces are identified that, in general, do not uniquely match with user-level interfaces.

    2. 1. 3. Requirements Allocation

    The relationships between the elements of the System Architecture (Segments and SW Units/HW Units) and the requirements (interface requirements, functional requirements, quality requirements, etc.) as well as the marginal conditions contained in the product User Requirements are set up in the form of a table. This is to prove that all requirements and marginal conditions are addressed by the elements of the System Architecture.

    The table includes

    The following items have to be observed: When allocating User Requirements to elements, it is possible to make references to the specifications with regard to technical operation. While doing so, it is possible to refer to technical architecture.

    In object-oriented development, the following must be observed: The functional User Requirements are described by means of "use cases". These User Requirements are finally realized in class hierarchies and the corresponding cooperation. In object-oriented development, the allocation of the User Requirements can therefore be realized by an allocation of "use cases" to class (hierarchy) groups, whereby these requirements will be met by the cooperation of these "use cases" and class groups.

    2. 2. Explanation of the Cooperation of Technical Elements

    This contains an illustration of the technical sequences of operation, as they result from the technical architectural decisions. This is only realized on the basis of the technical architecture. (In no case does this concern a change or overlap with regard to the contents with the user-level business processes.)

    In addition, the inter-computer process communication that is to be refined within the scope of the Software Architecture at some later time must also be described here, if necessary.

    Examples: Technical operation of the users' communication via a client-server network on the basis of a Novell network; technical solution for the access of selected users to the Internet; technical support of the signature tracing via e-mail.

    3. Realization

    3. 1. Solution Proposals

    Solution proposals may refer to freely selected sections of the architecture. They are neither to be limited to a level of the generic product structure nor to individual elements of a System.

    Solution outlines for the structure of the System or system parts describe the architecture idea and the decomposition of the System or system part. The User Requirements are in every case the basis for the system outlines.

    When generating solution proposals, the possible use of off-the-shelf products must be taken into consideration.

    3. 2. Feasibility Studies

    The solution proposals are evaluated in such a manner that the advantages and disadvantages with regard to feasibility can be illustrated.

    The results of the market analysis with regard to the availability of appropriate Off-the-shelf-products have to be documented.

    The following aspects may be considered within the scope of the feasibility study:

    The selection decision for the solution proposal must be documented in a comprehensible way.

    4. IT Security Concept

    This chapter describes the IT security strategy and, on this basis, justifies the system measures and the measures in the system environment which, by means of their interaction, cover the IT security requirements.

    The tasks of the measures and the responsibility during realization must be documented. The efficiency of the overall measures, their compatibility with regulations and rules, the cost/benefit ratio and the residual risk have to be justified.

    5. IT Security Model

    In case an IT security model is required it is necessary to prove that the IT security requirements are consistent and that the objectives of the IT security concept will be adhered to by means of the modeled IT security functions and its external interfaces.

    Product Flow

    Chapter Activity From to Methods Tool Req. Ext. Norms
    No. Title Activity State Activity State
    2.1.1 Technical System Structure SD2.1 - - SD2.2
    SD2.3
    SD2.4
    being proc. COM
    CRC
    PRODIAG
    SSM
    SSD22
    SSD23
    SSD25
     
    2.1.2 Identification of Interfaces SD2.1 - - SD2.2
    SD2.3
    SD2.4
    being proc.      
    2.1.3 Requirements Allocation SD2.4 - - SD1
    SD2.5
    SD2.6
    SD3
    SD4-SW
    PM4
    PM5
    submitted ER SSD01
    SSD09
     
    2.2 Explanation of the Cooperation of Technical Elements SD2.1 - - SD2.2
    SD2.3
    SD2.4
    being proc. IAM SSD28  
    3.1 Solution Proposals SD2.1 - - SD2.2
    SD2.3
    SD2.4
    being proc. COM
    CRC
    FCTD
    SSM
    SSD22
    SSD23
     
    3.2 Feasibility Studies SD2.3 - - SD2.1
    PM5
    being proc. BA
    SIMU
    SSD18
    SSD19
     
    4 IT Security Concept SD2.1 - - SD2.2
    SD2.3
    SD2.4
    being proc.      
    4 IT Security Concept SD2.2 - - SD2.1 being proc.      
    5 IT Security Model SD2.1 - - SD2.2
    SD2.3
    SD2.4
    being proc.      
    Existing SD2.1 SD2.2 being proc. - -      
    Existing SD2.1 SD2.3 being proc. - -      
    Existing SD2.1 SD2.4 being proc. - -      

    Links to the V-Model Mailinglist

    Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)
    Mail 0594 - Unterstützung der Betriebseinführung (594)
    Mail 0524 - Mehrere Fragen zum V-Modell (524)
    Mail 0197 - IT-Sicherheitskonzept (197)
    Mail 0156 - Re: SE 2, Systemarchitektur (156)
    Mail 0148 - SE 2, Systemarchitektur (149)

    Previous Next This page online  •  GDPA Online  •  Last Updated 06.Mar.2003 by C. Freericks