3. The ASPICE-Processes (VDA Scope)

3.5 SWE.3 – Software Detailed Design and Unit Construction

What is the purpose?

The software detailed design is the link between the software requirements, software architecture, and the implementation. This is done in iterative steps:

  • The software architecture describes how the software is organized into components and how they interact.
  • The software detailed design fully details each component and describes the structure and behavior of the software units.
  • The software units are created according to the detailed design
    specifications.

What is the benefit?

The detailed design provides a complete specification for the software developer to construct the required software unit. This specification helps to ensure that only high quality and traceable tested software units are being developed.

What is the content?

  • Based on the software architecture the detailed design for each software component is created and documented. It describes the required logic and algorithms, internal and external interfaces, dynamic behaviors, and error conditions. (BP1, BP2, BP3)
  • The detailed design is evaluated and verified, ensuring it supports the
    software architecture (BP4)
  • The traceability between the software requirements and software units, software architecture and the software detailed design, and the detailed design and software units are ensured and checked for consistency. (BP5, BP6).
  • The detailed design and any changes to it are agreed upon and communicated to the relevant parties. (BP7)
  • The source code of a software unit is created according to the detailed
    design specifications. In model-based development it will be generated from the model. (BP8)
Methods of unit verification
Methods of unit verification

Experiences, problems and hints

  • How the software architecture and the detailed design are structured: The architecture consists of “elements” which can be broken down into lower-level elements. The elements on the lowest level are called “components”. Detailed design starts with these components and breaks them down into “units” which have atomic character.
  • What a unit is, is often not clearly defined or consistently used. For example, is a unit a C file, a method or function, or an atomic element in a model?
  • A detailed design specification for software component usually includes the algorithms used, defined interactions and interface specifications with input and output variables as well as description of the program structure. Often we see flow and state diagrams, message sequence charts, UML diagrams, and natural language descriptions used to help describe portions of the detailed design.
  • Source code comments are an essential part of the unit.
  • Development must be carried out taking into account the coding guidelines and standards. Compliance is ensured by static code analysis and code reviews.
  • Historically, detailed design is often over-simplified or skipped entirely. Teams have tried to document the design through the use of markup languages in the source code. This may have the problem of not properly considering and reviewing the design ahead of implementation.
  • The traceability between detailed design and software units is often ensured through naming conventions.
  • Redundancy in the traceability is not required. However, it the links run from requirements to architecture to detailed design to the single unit, care must be taken that no information gets lost in between.

Automotive SPICE text of Software Detailed Design and Unit
Construction (SWE.3)

The purpose of the Software Detailed Design and Unit Construction Process is to provide an evaluated detailed design for the software components and to specify and to produce the software units.

BP1: Develop software detailed design. Develop a detailed design for each software component defined in the software architectural design that specifies all software units with respect to functional and non-functional software requirements.

BP2: Define interfaces of software units. Identify, specify and document the interfaces of each software unit.

BP3: Describe dynamic behavior. Evaluate and document the dynamic behavior of and the interaction between relevant software units.

NOTE 1: Not all software units have dynamic behavior to be described.

 BP4: Evaluate software detailed design. Evaluate the software detailed design in terms of interoperability, interaction, criticality, technical complexity, risks and testability.

NOTE 2: The results of the evaluation can be used as input for software unit verification.

BP5: Establish bidirectional traceability. Establish bidirectional traceability between software requirements and software units. Establish bidirectional traceability between the software architectural design and the software detailed design. Establish bidirectional traceability between the software detailed design and software units.

NOTE 3: Redundancy should be avoided by establishing a combination of these approaches that covers the project and the organizational needs.

NOTE 4: Bidirectional traceability supports coverage, consistency and impact analysis.

 BP6: Ensure consistency. Ensure consistency between software requirements and software units. Ensure consistency between the software architectural design, the software detailed design and software units.

NOTE 5: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

 BP7: Communicate agreed software detailed design. Communicate the agreed software detailed design and updates to the software detailed design to all relevant parties.

BP8: Develop software units. Develop and document the executable representations of each software unit according to the software detailed design.

Output Work Products

Software Detailed Design, Software Unit, Communication record, review record, Traceability record.

If you wish to continue to the next chapter click here: