SWE.3 Software Detailed Design and Unit Construction
Process ID SWE.3
Process Name Software Detailed Design and Unit Construction
Process Purpose 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.
Process Outcomes

As a result of successful implementation of this process:

  1. a detailed design is developed that describes software units;

  2. interfaces of each software unit are defined;

  3. the dynamic behavior of the software units is defined;

  4. consistency and bidirectional traceability are established between software requirements and software units; and consistency and bidirectional traceability are established between software architectural design and software detailed design; and consistency and bidirectional traceability are established between software detailed design and software units;

  5. the software detailed design and the relationship to the software architectural design is agreed and communicated to all affected parties; and

  6. software units defined by the software detailed design are produced.

Base Practices

SWE.3.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 nonfunctional software requirements. [Outcome 1]

SWE.3.BP2: Define interfaces of software units. Identify, specify and document the interfaces of each software unit. [Outcome 2]

SWE.3.BP3: Describe dynamic behavior. Evaluate and document the dynamic behavior of and the interaction between relevant software units. [Outcome 3]

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

SWE.3.BP4: Evaluate software detailed design. Evaluate the software detailed design in terms of interoperability, interaction, criticality, technical complexity, risks and testability. [Outcome 1,2,3,4]

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

SWE.3.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. [Outcome 4]

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.

SWE.3.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. [Outcome 4]

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

SWE.3.BP7: Communicate agreed software detailed design. Communicate the agreed software detailed design and updates to the software detailed design to all relevant parties. [Outcome 5]

SWE.3.BP8: Develop software units. Develop and document the executable representations of each software unit according to the software detailed design. [Outcome 6]

Output Work Products

04-05 Software detailed design [Outcome 1, 2, 3]

11-05 Software unit [Outcome 6]

13-04 Communication record [Outcome 5]

13-19 Review record [Outcome 4]

13-22 Traceability record [Outcome 4]

NOTE: For software and system test documentation, the IEEE-Standard 829- 2008 might be used.

 

Process capability levels and process attributes

Process capability Level 0: Incomplete process

Process capability Level 1: Performed process

Process capability Level 2: Managed process

Process capability Level 3: Established process

Process capability Level 4: Predictable process

Process capability Level 5: Innovating process