SWE.3 – Software Detailed Design and Unit Construction - The first knowledge sharing application in Vietnam

Welcome,
to my series about A-SPICE and its related processes. Today we want to take a deeper look into SWE.3 – Software Detailed Design. In the last post we covered the software architectural design and prepared all relevant project development data for this process.

Shall we begin?

ID: SWE.3
Process name: Software Detailed Design and Unit Construction
Process purpose: Documenting and producing a evaluated detailed design for the software components to produce software units.
Process outcomes: You succeed if:

a detailed design that documents the software units is developed
the interfaces to each software unit are documented
the dynamic behavior of the software units is defined
in between the software requirements and software units consistency and traceability is provided. The same applies for software architectural design and software detailed design, as well for software detailed design and software units
the software detailed design and their links to the software architectural design are approved and communicated to all relevant parties & stakeholders
the the by the software detailed design, defined software units are produced

Base practices:

SWE.3-BP.1: Develop software detailed design
As the practice title already suggests we need to develop a detailed design for every software component defined in our software architectural design, which documents all software units with regard to functional and non-functional software requirements.

The results are stored within:

04-05 Software Detailed Design

SWE.3-BP.2: Define interfaces of software units
Now we need to identify, specify and document all relevant interfaces for each software unit.

After this we will provide a updated:

04-05 Software Detailed Design

SWE.3-BP.3: Describe dynamic behavior
Asses and detail the dynamic behavior of relevant software units. Also the interaction in between must be considered. Not every software unit have a dynamic behavior to be detailed.

This again is being stored within:

04-05 Software Detailed Design

SWE.3-BP.4: Evaluate software detailed design
Check the software detailed design for following areas:

interoperability
interaction
criticality
technical complexity
risks
testability

The outcome can be used as a new input for software unit verification.

Following Work Products need to be generated/updated:

04-05 Software Detailed Design
13-19 Review Record
13-22 Traceability Record

SWE.3-BP.5: Establish bidirectional traceability
Our next task is to provide bidirectional traceability between:

Software requirements and software units
Software architectural design and software detailed design
Software detailed design and software units

If possible try to avoid repetition by creating a combination of those approaches, which cover the project and organizational demands.
The traceability also supports coverage, consistency and impact analysis.

The results are stored in:

13-22 Traceability Record
13-19 Review Record

SWE.3-BP.6: Ensure consistency
In this case we need to ensure consistency between:

Software requirements and software units
Software architectural design, software detailed design and software units

As in the traceability BP, following WP´s (Work Product´s) are relevant:

13-22 Traceability Record
13-19 Review Record

SWE.3-BP.7: Communicate agreed software detailed design
In one of the final steps we need to contact all relevant parties with our agreed software detailed design and its updates.

These need to be provided via a:

13-04 Communication Record

SWE.3-BP.8: Develop software units
Now the fun begins. Develop and document the design/code of each software unit based on the software detailed design