5 Part 5: V-Modell Reference Work Products

5.3 Products

5.3.10 System Design

5.3.10.1 System Architecture

Responsible: System Architect (when using process module System Development)

Participating: Software Architect, Hardware Architect, Logistics Manager

Purpose

The System Architect is tasked with designing a suitable system architecture based on the functional and non-functional system requirements. The architectural products will be used as guideline and for documenting the design decisions.

In the first step, significant architectural principles will be specified, and possible design alternatives will be examined. In accordance with the selected design alternative, the system will be decomposed into »Segments, hardware, software, and »External Unit. Relations and interfaces between the elements and to the environment will be identified and summarized. In addition, joint system charactistics like safety and security concept, transaction concept and logging concept, will be specified.

The suitability of the selected architecture for the system to be developed will be assessed. Open questions may be answered, e.g., within the scope of a prototype development.

The main responsibility for the architectural design is vested in the »System Architect, who will be supported by various specialists, e.g. for hardware development, software development, logistics, safety and security or ergonomics.

The architecture is the central document for the preparation of additional products. It specifies all segements, hardware, software and external units for the system. Based on the overall architecture, an architecture will be developed for every hardware or »Software Unit, and specifications will be prepared for the respective elements.

Is generated by

Overall System Specification (see product dependency 4.26)

Generates

Evaluation Report Usability, Evaluation Specification Usability, Evaluation Report Usability, Evaluation Specification Usability, Hardware Architecture, Hardware Unit, Hardware Specification, Hardware Implementation, Integration and Evaluation Concept, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.4)

Evaluation Report Usability, Evaluation Specification Usability, Software Implementation, Integration and Evaluation Concept, Software Architecture, Software Unit, Software Specification, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.15)

Evaluation Report Usability, Evaluation Specification Usability, Market Survey for Off-the-Shelf Products, External Unit, External Unit Specification, Make-or-Buy Decision, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.20)

Evaluation Report Usability, Evaluation Specification Usability, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Segment, System Specification, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.23)

Depends on

Logistic Calculations and Analyses, Enabling System Architecture (see product dependency 5.22)

Overall System Specification, Legacy System Analysis (see product dependency 5.59)

Example Work Products

»FWD:System Architecture

5.3.10.1.1 Architectural Principles and Design Alternatives

Normally, there are several architectural solutions for every system or »Enabling System, each of which has advantages and disadvantages. The description of the underlying architectural principles and possible design alternatives document the decision process for the finally selected architecture and provide the basis for its assessment.

Architectural principles are standards which are decisive for the the architectural design, e.g., due to the system type or other system characteristics. At system level, these principles may include, e.g., the application domain (embedded system, information system) or the decision for a distributed system.

Design alternatives describe the different possibilities for the »System Decomposition into »Segments, hardware, software and »External Units. For every alternative, the advantages and disadvantages will be identified, and the solution will be assessed based on a criteria list to be defined. At system level, e.g., model architectures may be used for searching possible design alternatives.

Conditions for architectural principles and restrictions for possible design alternatives are particularly due to the requirements of the »System Specification or the Overall System Specification.

5.3.10.1.2 System Decomposition

The decomposition specifies the static structure of the system or »Enabling System. The static structure describes the dissection into »Segments and units. The design result will be documented as graph depicting the segment types and unit types to be realized and their interrelations.

Every unit identified during the decomposition will be defined as hardware, software or »External Unit.

The decomposition is based on the requirements posed in the »System Specification. The framework conditions for the decomposition will be specified by the architectural principles defined in the system architecture or »Enabling System Architecture and the design decisions.

5.3.10.1.3 Overall System Characteristics

The characteristics of a system or »Enabling System may be subdivided into specific system element characteristics and common system characteristics. Solutions for specific system element characteristics will be described in the specification for the respective system element. Solutions for common system characteristics will be described in this subject.

Typical common characteristics of software systems include, e.g., transaction requirements, persistence of data or logging and tracing requirements. For hardware systems, joint characteristics may include, e.g., uniform connector assignments or common safety and security requirements. The overall system characteristics to be taken into account will be determined in this subject.

5.3.10.1.4 Interface Overview

The summary of interfaces of the system architecture or »Enabling System Architecture provides a survey of the system interfaces and the interfaces of the system elements. For the summary of interfaces, only the communication at one level will be described :

At the level of the system or »Enabling System, the interfaces between the systems and the interfaces to the environment will be described.
At »Segment level, the interfaces between the segments within the system or enabling system will be described.
At unit level, the interfaces between the units within a segment will be described.

Interfaces to the environment may exist between a system or enabling system and the user (user interface), logistic systems (documentation) or various enabling systems (measuring and test equipment, spare parts). The interfaces are described in detail in the specification of the respective system element.

5.3.10.1.5 Overall Data Catalog

Systems and system elements communicate by exchanging data. At hardware level, data are exchanged as signals, at software level, they are exchanged as serializable data transport objects. The Joint »Data Catalog of a system or »Enabling System describes all data structures and signals exchanged at the interfaces and any possibly assigned values.

Data and signals of the system are used as preset values for the data catalog for »Software Units and for the »Data and Signal Catalog of the »Hardware Units.

5.3.10.1.6 Design Evaluation

If an architectural design has been selected and developed down to unit level, it must be ensured that the selected design implements the requirements in a suitable manner. This will be tested and documented by a design verification.

The Subject Design Evaluation specifies the methods to be used for design verification and the critieria for testing whether the design fulfills the requirements. The development of prototypes is a method which is frequently used for verifying the design. If this method is employed in a preliminary project, the user can also use the prototype in order to check the requirements for completeness.

The design verification will be based on the functional and non-functional requirements of the »System Specification and the identfied architectural principles. Execution and results of the verification will be documented. They may lead to a re-evaluation of the design decisions and a review of the architecture.

5.3.10.1.7 System Elements to be Specified

The preparation of a specification for a system element is expensive and not always required. In order to adapt the specification effort to the requirements of individual projects, the »System Architect can - based on the specifications in the Project Manual and the requirements - determine which system elements need a »System Specification.

Critiera for the necessity of a specification may include the following: safety and security of the system elment, complexity of the requirements posed on the system element, test requirements specified in the »QA Manual and the respective implementation, integration and evaluation concept. In any case, a system specification shall be prepared for system elements to be tested since this specification will be the basis for the »Evaluation Specification System Element .

If system elements are classified as not to be specified, a rationale shall be included.