6 Part 6: V-Modell Reference Activities

6.3 Activities

6.3.7 Requirements and Analyses

6.3.7.8 Performing and Evaluating Safety and Security Analysis

Purpose

The »Safety and Security Analysis will be made for those system elements that were identified to be safety-relevant in the related implementation, integration and evaluation concepts.

During the development the »System will be subdivided into subsystems ( »Segments, »Hardware Units, »Software Units, »Hardware Components, »Hardware Modules, »Software Components, »Software Modules ). Each of these subsystems, just like its parent system, will be associated with a risk. In each decomposition step this risk shall be determined and specified.

On the basis of the contractually specified safety requirements/risk acceptance a hazard and risk analysis shall be made to decide in the system development process which hazards will exist, what the resulting risk will be and how risk reduction measures can be used to reduce the risk to an acceptable level. In particular the following steps will be required for each system element:

• The hazards will have to be identified.
• Potential damage resulting from the hazards shall be determined.
• The risks connected with the hazards and damage will have to be assessed.
• The acceptance of the risks shall be determined on the basis of available criteria.
• For all risks that are classified as not acceptable risk reduction measures will have to be defined.

In this context it will also have to be checked whether for risk reduction technical measures - such as design changes - or organizational measures - such as changes in the planning - shall be preferred. If design changes are necessary, the desire to make a change shall be reported via a problem report or a change request. If several alternatives for risk reduction are available, this will be stated in the desire for change and incorporated in the change proposal. If no solution is found, a solution to this topic has to be found together with the acquirer.

6.3.7.8.1 Identifying Hazards and Classifying Damage

For each system element (architectural element or hardware/software component) the potential hazards that may lead to an occurrence of damage shall be determined. For each identified hazard the damage level shall be determined and the damage class - depending on the damage category concerned - shall be allocated.

6.3.7.8.2 Performing System Safety and Security Analysis

For each system-critical system element a »Safety and Security Analysis shall be made. For each identified hazard possible causes and their related risks shall be estimated and evaluated with regard to occurrence, importance and detection. If the result of the evaluation is a value that exceeds a defined threshold value or is outside of the accepted range, risk reduction measures shall be defined for the system element considered. The results of the analysis - causes, occurrence probabilities, risks and risk acceptance - shall be documented.

6.3.7.8.3 Identifying and Determining Risk Reduction Measures

For all risks rated not acceptable in the »Safety and Security Analysis, risk reduction measures shall be determined. These measures will influence on the one hand - in the form of engineering measures such as redundancy, identification, authentication and access control - the realization and on the other hand, when analytical QA measures are concerned, the testing procedure. The risk reduction measures shall be selected from the safety and security specifications of the project manual.

The identified measures shall be analyzed and evaluated with regard to their impact during the execution. In this process for example the degree of risk reduction or the effort required for implementation shall be determined. Beyond that also the impact on activation, operation, deactivation and the operating personnel can be determined. The results of this analysis and evaluation shall be documented and used as a basis for determining appropriate measures for the implementation of a risk reduction effort. The decision making process in turn also shall be documented.

If no suitable »Safety and Security Measures are found or if additional promising risk reduction measures exist or are conceivable, then negotiations shall be conducted with the acquirer, and the solution found this way shall be requested and documented in a problem report or a change request.