RE.3.3.2. System Architecture (SysArc)
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.
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
See schema 1. General Information.
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.
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.
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:
- the allocation of the requirements to the elements of the technical architecture, and
- information about the technical operation.
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.
- Every requirement must be allocated to at least one element of the technical architecture, ideally exactly to one architecture element.
- Each requirement is allocated to the lowest element in the refinement levels which makes it possible to meet the requirement completely. Normally, the total of the requirements has to be allocated to various refinement levels.
- Provided that a requirement is of general importance to elements, it must be considered within the scope of the allocation which individual architecture elements this requirement really has to fulfill.
- The allocation must be realized in such a manner that it will be possible to prove the fulfillment of the requirement by checking the corresponding architecture element.
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.
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.
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster