6 Part 6: V-Modell Reference Activities

6.3 Activities

6.3.9 System Specifications

6.3.9.6 Preparing Software Specification

Purpose

In the specification the requirements and interfaces for each respective software element (software unit, software component or software process module) to be described shall be defined and accurately described.

For the preparation of the software specification (see Figure 21) - analogous to the »System Specification - interfaces and non-functional requirements for the software element will be defined, followed by the parallel refinement and assignment of those interfaces and requirements on the basis of the parent software unit or software component. The design decisions shall be documented in the software specification. If the prepared realization proves to be workable, it will be possible to proceed to the requirement tracking survey. If this is not the case, the realization will have to be revised.

Requirements usually will be described in text form. The specification of the interface may be formalized in various ways. Usually this will be done by using graphic description methods in combination with explanatory text.

6.3.9.6.1 Identifying Interfaces and Non-Functional Requirements

Assigned parent interfaces (see the interface description) and non-functional requirements will have to be identified. At the level of the »Software Components the assigned interfaces and non-functional requirements of the super-ordinate »Software Unit will be adopted for example without refinement or change as a starting point.

6.3.9.6.2 Refining Interfaces and Non-Functional Requirements

The refining of the interfaces (see the interface description) and the non-functional requirements will include the following steps:

• With the identified interfaces and non-functional requirements, solutions will have to be defined. In this process the way of looking at the higher level of the architecture will be changed from considering it a "black box" to considering it a "white box". This will mean for example naming the »Software Modules in the specification of a »Software Component.
• On the basis of the "white box" the identified parent interfaces and non-functional requirements will be refined. In this process also additional, previously unconsidered interfaces and non-functional requirements may be defined. It must be possible to verify all interfaces and to assign them to the next lower hierarchy level.

At the respective hierarchy levels the refinement of the interfaces and non-functional requirements will lead to the following activities:

• If necessary, method calls wull have to be refined and assigned to several software elements.
• Parameter value ranges will have to be concretized and refined.
• Exceptions will have to be assigned to the methods of the subordinate elements.

6.3.9.6.3 Assigning Interfaces and Non-Functional Requirements

The refined and additionally defined interfaces and non-functional requirements shall be assigned to the software elements identified in the "white box". It is recommended to make this description in tabular form.

6.3.9.6.4 Preparing Requirements Trace Overview

Within the scope of the requirement tracking survey it will be made sure that all requirements and interfaces will be refined. It shall be checked whether

• for each requirement or interface of a »Software Unit there will be at least one representation at the level of the »Software Components,
• for each requirement or interface of a software component there will be at least one representation at the level of the »Software Modules,
• with a distributed assignment of a requirement or an interface this will be fulfilled to the full extent by the subordinate software elements.

In every hierarchical design step (e. g. from a software unit to software components) this requirement shall be tracked.