Previous Next V-Model Official Homepage by IABG  
Header  
SD 2.1: Technical System Design  

  SE2.1 - System technisch entwerfen

Contents  
  • Product Flow
  • Handling
  • Roles
  • Methods
  •  
  • Tools Requirements
  • External Norms
  • Pre-Tailoring forms
  • Links to the V-Model Mailinglist
  • Product Flow

    From Product to Methods Tool Req. Ext. Norms
    Activity State Chapter Title Activity State
    PM2 accepted Existing Offer Evaluation (1) - -     /ISO IEC 12207/

    Devlp. Proc.:
    Sys. Arch. Design

    SD1 accepted Existing User Requirements - -    
    SD2.2
    SD2.3
    being proc. Existing System Architecture - -    
    - - 2.1.1 System Architecture.
    Technical System Structure
    SD2.2
    SD2.3
    SD2.4
    being proc. COM
    CRC
    PRODIAG
    SSM
    SSD22
    SSD23
    SSD25
    - - 2.1.2 System Architecture.
    Identification of Interfaces
       
    - - 2.2 System Architecture.
    Explanation of the Cooperation of Technical Elements
    IAM SSD28
    - - 3.1 System Architecture.
    Solution Proposals
    COM
    CRC
    FCTD
    SSM
    SSD22
    SSD23
    - - 4 System Architecture.
    IT Security Concept
       
    - - 5 System Architecture.
    IT Security Model
       
    - - All Operational Information:
    User Manual
    Diagnosis Manual
    Operator Manual
    Other Application Information
    SD2.6 being proc.    
    - - All Technical Requirements SD2.6
    SD3
    being proc. COM
    CRC
    PRODIAG
    SSM
    SSD01
    SSD05
    SSD22
    SSD23
    SSD25
    - - All Interface Overview SD2.5
    SD4-SW
    CM4.3
    being proc. COM
    DFM
    SSM
    SSD07
    SSD22
    SSD23

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

    Handling

    * Setting up the Solution Proposals

    The solution proposal for a possible technical structure of the System (System Architecture) is set up on the basis of the User Requirements. In case several alternative solutions are required, one is selected and refined with the participation of the project management. In case the selection of the solution is not realized at that time or several variants are still open, the following activities have to be realized for each variant of a solution. Attention has to be paid to consider the possibilities of using off-the-shelf-product. The assessment with regard to the availability of appropriate off-the-shelf products realized within the scope of activity SD2.3 - Investigation of Feasibility may result in a change of the design decision.

    The solution proposal is formulated on the basis of the fields defined or referred to in activity SD1.5 - User-Level System Structure. This way, separable problem definitions at user-level are considered and evaluated in the subsequent feasibility studies.

    * Definition of System Architecture

    The selected solution proposal is refined. Those system parts realized by off-the-shelf products or in which off-the-shelf products are used, must be identified. In case off-the-shelf products have already been selected they must be mentioned here. Provided that the use of off-the-shelf products requires additional development activities these must be documented as well. The knowledge gained during the offer evaluation within the scope of activity PM2 - Project Monitoring must be refined accordingly.

    The definition of the System Architecture comprises the representation of the technical system structure and the identification of the interfaces between the elements of the architecture and the overall System to the outside. All interfaces identified in the System Architecture must be included in the Interface Overview.

    To do so the elements of the System ought to be technically characterized now, if possible, in order to position appropriate off-the-shelf products as early as possible.

    The representation of the system structure is supplemented by the description of the technical operation (interaction between the elements of the architecture). The architecture description must be reconstructable and plausible so the user-level requirements and the marginal conditions defined within the scope of the User Requirements can be covered by the technical solution described.

    The definition of the System Architecture has to be realized by applying approved off-the-shelf products, if possible. If necessary, a modification/reduction of the User Requirements can be realized via the requirements controlling.

    In this case, the System Architecture is generated in one step. The System Architecture is completed on a step-by-step basis within the scope of the segment design.

    * Determining the Technical Requirements

    The overall picture of the requirements results from the User Requirements and the Technical Requirements derived from that.

    As far as this is possible and as far as it can be derived from the User Requirements, Technical Requirements for the functionality, the interfaces, the quality, and the development and SWMM environment of the elements of the System Architecture have to be defined. The criticality of the architecture element must be specified.

    Requirements for the development and SWMM environment have to be defined at system level. In case separate requirements exist for the individual elements they must be mentioned also, within the scope of the Technical Requirements for these elements. Provided that technical requirements cannot be allocated to any element of the System Architecture, they have to be specified as general requirements.

    The Technical Requirements are supplemental and interpreting requirements that are demanded from the technical point of view for an element of the technical architecture. User Requirements should not be repeated here. Requirements concerning the mechanisms they are to be realized with have to be made for the IT security functions. They are the required mechanism strength and the E-level of the implementation.

    Dependent on the criticality of the critical functions/components, the concept of the realization and the quality of the implementation (E-level or safety integrity level) has to be determined.

    * Documentation of Operational Information

    Based on the System Architecture and the User Requirements, the system-related details for the Operational Information (User Manual, Diagnosis Manual, Operator Manual, Other Application Information) have to be generated.

    * Observing the IT Security Aspects

    In order to cover the requirements for the IT security in particular, possible solutions are proposed by appropriate IT and non-IT measures (e. g. organizational or building-technical measures) and the residual risk is defined for each proposal. The security portion of the IT system is defined by the total of all IT measures. Based on the results of the feasibility study, the suitable solution is documented, together with the corresponding justification as IT security concept.

    An IT security function can either be covered by an already available off-the-shelf product or else it has to be developed as SW Unit or HW Unit.

    Portions realized in hardware are relevant for the evaluation. If necessary, certain criteria must be fulfilled before applying for an evaluation, dependent on the desired evaluation level (e. g. presentation of the hardware design drawings).

    All those requirements for system security that are covered by the IT security portion must be identified. If required, an IT security model that grossly simplifies the cooperation of the IT security-relevant functions must be generated which still precisely and completely represents the functions.

    During the refinement of the IT security functions, new elements are usually introduced and additional interfaces are created, which means there may be additional weak points. Provided that the new weak points can be exploited to harm the specified IT security objective, further measures preventing this must be included into the IT security concept. It is also possible that weak points in the form of undesired dependences and relationships occur during the refinement process (error propagation, single point of failure, inheritance of a high criticality to too many components). This may require an iteration of earlier activities, as for example activity SD1.6 - Threat and Risk Analysis.

    * Planning and Realization of Infrastructure Measures

    All required infrastructure measures have to be identified and to be planned. The realization of the planned measures must be arranged. The documentation of the infrastructure measures to be realized is not regulated in the V-Model.

    * Separation of the IT Security Portion

    A clear separation of the IT security portion (security-specific and security-relevant functions, including functions of high criticality) from the other elements of the System Architecture is required. The number of interfaces between IT security portion and software that is not critical with regard to security should be kept as small as possible.

    Based on the interactions between the selected architecture, newly created interfaces in the IT security portion as well as the additional interfaces between the refined IT security portion and the remaining software must be included in the Interface Overview.

    The Interface Overview must also contain a justification for the necessity of each interface from the IT security portion to the other elements in the System Architecture and the necessity of each interface within the IT security portion.

    The interfaces to the application environment must be exactly described. For example, in levels according to ITSEC, the requirements for the description forms are increased.

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

    Roles

    Role Participation
    Project Leader cooperating
    System Designer responsible
    Technical Author cooperating
    IT Representative cooperating

    Methods

    Product Methods Allocation Use
    Chapter 2
    System Architecture.
    Technical System Structure
    COM - Class/Object Modeling (2) Generate
    CRC - Class Responsibility Collaboration (2) Generate
    PRODIAG - Process Diagrams (2) Generate
    SSM - Subsystem Modeling (2) Generate
    Chapter 2.2
    System Architecture.
    Explanation of the
    Cooperation of
    Technical Elements
    IAM - Interaction Modeling (2) Generate
    Chapter 3.1
    System Architecture.
    Solution Proposals
    COM - Class/Object Modeling (2) Generate
    CRC - Class Responsibility Collaboration (2) Generate
    FCTD - Functional Decomposition Generate
    SSM - Subsystem Modeling (2) Generate
    Chapter 5.x.2
    Technical Requirements.
    Overall Function of Element
    COM - Class/Object Modeling (2) Generate
    CRC - Class Responsibility Collaboration (2) Generate
    PRODIAG - Process Diagrams (2) Generate
    Chapter 5.x.3
    Technical Requirements.
    Technical Requirements for the Interfaces
    COM - Class/Object Modeling (2) Generate
    SSM - Subsystem Modeling (2) Generate
    Chapter 2
    Interface Overview.
    System-External Interfaces
    COM - Class/Object Modeling (2) Generate
    DFM - Data Flow Modeling Generate
    Chapter 3
    Interface Overview.
    System-Internal Interfaces
    COM - Class/Object Modeling (2) Generate
    DFM - Data Flow Modeling Generate
    SSM - Subsystem Modeling (2) Generate

    Notes
    (1) In case off-the-shelf products are to be used.
    (2) The methods have to be applied in object-oriented developments.

    Tools Requirements

    Product Functional Tools Requirements
    Chapter 2.1
    System Architecture.
    Representation of the Technical System Architecture
    SSD22 - Supporting Class/Object Modeling
    SSD23 - Supporting Subsystem Modeling
    SSD25 - Supporting Process Diagrams
    Chapter 2.2
    System Architecture.
    Explanation of the Cooperation of Technical Elements
    SSD28 - Supporting Interaction Modeling
    Chapter 3.1
    System Architecture.
    Solution Proposals
    SSD22 - Supporting Class/Object Modeling
    SSD23 - Supporting Subsystem Modeling
    Technical Requirements SSD01 - Recording Requirements
    Chapter 5.x.2
    Technical Requirements.
    Overall Function of Element
    SSD05 - Supporting Function Structure
    SSD22 - Supporting Class/Object Modeling
    SSD25 - Supporting Process Diagrams
    Chapter 5.x.3
    Technical Requirements.
    Technical Requirements for the Interfaces
    SSD22 - Supporting Class/Object Modeling
    SSD23 - Supporting Subsystem Modeling
    Chapter 2
    Interface Overview.
    System-External Interfaces
    SSD07 - Supporting Modeling of Information Flows
    SSD22 - Supporting Class/Object Modeling
    Chapter 3
    Interface Overview.
    System-Internal Interfaces
    SSD07 - Supporting Modeling of Information Flows
    SSD22 - Supporting Class/Object Modeling
    SSD23 - Supporting Subsystem Modeling

    External Norms

    Norm Process Chapter Obs.
    /ISO IEC 12207/ Development Process System Architectural Design (s. Part 3 - ISO 3.2.1)

    Pre-Tailoring forms

    Pre-tailoring Forms SD Products Implementing
    Conditions
    Small Administrative IT Projects   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Medium Administrative IT Projects   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Large Administrative IT Projects   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Small/Medium Technical-Scientific IT Projects   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Large Technical-Scientific IT Projects   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Selection, Procurement and Adjustment of Off-the-Shelf Products   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          

    Matrix Entries:

    Always required
    Always required under given circunstances
    Not required
    Description of data or database only

    Links to the V-Model Mailinglist

    Mail 0617 - Erstellen von Programmierrichtlinie (617)
    Mail 0246 - Re: Umfang von SE 1.2 bei inkrementeller Entwicklung (246)
    Mail 0197 - IT-Sicherheitskonzept (197)
    Mail 0156 - Re: SE 2, Systemarchitektur (156)

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Feb.2003 by C. Freericks