SD 2.1: Technical System Design



		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

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	Methods	Tool Req.	Ext. Norms
PM2	accepted	Existing	Offer Evaluation ⁽¹⁾	-	-			/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

* 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 ⁽²⁾	Generate
	CRC - Class Responsibility Collaboration ⁽²⁾	Generate
	PRODIAG - Process Diagrams ⁽²⁾	Generate
	SSM - Subsystem Modeling ⁽²⁾	Generate
Chapter 2.2 System Architecture. Explanation of the Cooperation of Technical Elements	IAM - Interaction Modeling ⁽²⁾	Generate
Chapter 3.1 System Architecture. Solution Proposals	COM - Class/Object Modeling ⁽²⁾	Generate
	CRC - Class Responsibility Collaboration ⁽²⁾	Generate
	FCTD - Functional Decomposition	Generate
	SSM - Subsystem Modeling ⁽²⁾	Generate
Chapter 5.x.2 Technical Requirements. Overall Function of Element	COM - Class/Object Modeling ⁽²⁾	Generate
	CRC - Class Responsibility Collaboration ⁽²⁾	Generate
	PRODIAG - Process Diagrams ⁽²⁾	Generate
Chapter 5.x.3 Technical Requirements. Technical Requirements for the Interfaces	COM - Class/Object Modeling ⁽²⁾	Generate
	SSM - Subsystem Modeling ⁽²⁾	Generate
Chapter 2 Interface Overview. System-External Interfaces	COM - Class/Object Modeling ⁽²⁾	Generate
Chapter 2 Interface Overview. System-External Interfaces	DFM - Data Flow Modeling	Generate
Chapter 3 Interface Overview. System-Internal Interfaces	COM - Class/Object Modeling ⁽²⁾	Generate
	DFM - Data Flow Modeling	Generate
	SSM - Subsystem Modeling ⁽²⁾	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
Pre-tailoring Forms
Small Administrative IT Projects
Medium Administrative IT Projects
Large Administrative IT Projects
Small/Medium Technical-Scientific IT Projects
Large Technical-Scientific IT Projects
Selection, Procurement and Adjustment of Off-the-Shelf Products