5 Part 5: V-Modell Reference Work Products

5.3 Products

5.3.9 System Specifications

5.3.9.5 Software Specification

Process module: Software Development

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

Activity: Preparing Software Specification

Participating: Software Developer, Logistics Developer, Ergonomics Manager, Inspector, Safety Manager

Purpose

The »Software Specification describes all functional and non-functional requirements posed on a software element (software unit, »Software Component or software process module). In order to prepare the Software Specification, the requirements will be derived from the specifications of higher system elements or software elements. The specification provides standards and tools for designing and decomposing the »Software Architecture. If changes are required in the course of the development of the software element, the Software Specification shall be adapted at first. The »Evaluation Specification System Element defines the evaluation cases required for demonstrating the requirements of interfaces and specifications.

The Software Specification mainly describes the requirements posed on the software element and specifies the connected interfaces. In addition, requirements and interfaces will be refined and allocated to lower software elements.

The requirements tracing ensures that all requirements posed on the respective elements will be taken into account when the next hierarchy level will be refined. The Software Specification will be prepared together with the architecture design of the »Software Unit. The »Software Architect is responsible for the preparation of these products, thus ensuring the consistency between specification and architecture.

Requirements of the Software Specification may influence the Logistic Support Specification, just as logistic requirements may influence the Software Specification.

Is generated by

System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.15)

System Implementation, Integration and Evaluation Concept, Enabling System Architecture (see product dependency 4.16)

Software Implementation, Integration and Evaluation Concept, Software Architecture (see product dependency 4.17)

Software Implementation, Integration and Evaluation Concept, Software Architecture (see product dependency 4.19)

Depends on

Man-Machine Interface (Style Guide), Hardware Specification, System Specification (see product dependency 5.7)

External Hardware Module Specification, Hardware Specification, Logistic Support Specification, External Software Module Specification, External Unit Specification, System Specification (see product dependency 5.23)

5.3.9.5.1 Software Element Overview

The »Software Element Overview provides a brief survey of the software element to be realized. It outlines tasks and objectives of the software element. For a better understanding, the role of the element within the system, a »Enabling System or a »Software Unit will be described.

5.3.9.5.2 Interface Specification

An interface represents the boundary between a software element and its environment. It describes the data exchanged at the element boundary and their logic dependencies. Thus, the interface defines the services to be provided by the software element. One software element can have several interfaces.

The interface description collects all functional requirements posed on the software element, specifies all interfaces and presents them in their environment. Together with the non-functional requirements, the interface description defines the information required for developing the software element. The interface description describes the interfaces to other software elements and the interfaces to the environment, e.g. the graphical user interface or interfaces to »Enabling Systems.

The description of the functional interface is subdivided into the description of the static and dynamic behavior. The static behavior determines the structure of the calls, through which the services of the software elements can be used. The description is mainly based on method signatures and definitions of data types. The dynamic behavior determines the sequence of calls and the logic dependencies of the transmitted data. The description of the dynamic behavior is frequently based on flowcharts (sequence charts, message sequence charts) or state transition diagrams.

The interface description is based on the summary of interfaces in the architecture and on the interface realizations of the »System Specifications of higher system elements. The interface description should consider if a re-use of already existing software elements is possible. In addtion, it should be ensured that the interface is stable, thus allowing a long use of the software element.

5.3.9.5.3 Non-Functional Requirements

In addition to the functional requirements, a software element must fulfill several non-functional requirements. Frequently demanded non-functional requirements - especially for software elements - include, e.g., usability, response time, transaction rate, confidentiality, or data integrity.

The non-functional requirements will be described in detail and specified by the actually required values. The non-functional requirements relevant for the software element will be derived from the specifications of higher system elements or software elements.

5.3.9.5.4 Interface Realization

The interface realization refines the functional requirements of the interface description. Requirements and interfaces will be concretized, refined and allocated to the software elements of the lower hierarchy levels.

The interface realization is based on the »Hardware Architecture of the higher »Hardware Unit. »Hardware Components and »Hardware Modules of the different hierarchy levels will be identified within the scope of the decomposition process.

The interface realization is based on the »Software Architecture of the higher »Software Unit. »Software Components and »Software Modules of the different hierarchy levels will be identified within the scope of the decompositoin process.

5.3.9.5.5 Refinement of Non-Functional Requirements

Non-functional requirements are refined in parallel to functional requirements during the interface realization. The non-functional requirements will be concretized, refined and allocated to the software elements of the lower hierarchy level.

For example, a maximum rsponse time of 0.5 seconds, which was required in the interface description, may be refined by dividing it onto two software elements, each with a required maximum response time of 0.25 seconds.

The refined requirements remain in existence as autonomous requirements or will be integrated into the interface realization.

5.3.9.5.6 Requirements Tracing

The requirements tracing summarizes the allocation of functional and non-functional requirements posed on the software element to the refined requirements and lower software elements. It is based on the results of the interface realization and the refinement of non-functional requirements. The bi-directional trackability (i.e. from higher to lower software elements and vice versa) must be ensured. The data may be presented, e.g., in form of a matrix.