SWE.3
Software Detailed Design and Unit Construction
Linked Knowledge Nuggets: arrow_forward "Software Detailed Design and Unit Construction"
personAuthor: Process Fellows
SWE.3 – Software Detailed Design and Unit Construction focuses on translating software architecture into detailed, testable unit designs and implementing those units accordingly. It ensures structural clarity, consistency, and traceability within the software.
school
PF_SWE.3_Software Detailed Design and Unit Construction_Extract.pdf
# PROCESS PURPOSE
The purpose is to establish a software detailed design, comprising static and dynamic aspects, consistent with the software architecture, and to construct (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) consistent with the software detailed design.
# PROCESS OUTCOMES
O1
A detailed design is specified including static and dynamic aspects.
O2 (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) as specified in the software detailed design are produced.
O3
Consistency and bidirectional traceability are established between software detailed design and software architecture; and consistency and bidirectional traceability are established between source code and software detailed design; and consistency and bidirectional traceability are established between the software detailed design and the software requirements.
O4
The source code and the agreed software detailed design are communicated to all affected parties.
# BASE PRACTICES
BP1
Specify the static aspects of the detailed design. (
O1 )
For each (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.) specify the behavior of its (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.), their static structure and relationships, their interfaces including
valid data value ranges for inputs and outputs (from the application domain perspective), and
physical or (Measurement = “The activity to find the size, quantity or degree of something”.) units applicable to inputs and outputs (from the application domain perspective).
Note 1: The boundary of a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) is independent from the (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.)’s representation in the source code, code file structure, or model-based implementation, respectively. It is rather driven by the semantics of the application domain perspective. Therefore, a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) may be, at the code level, represented by a single subroutine or a set of subroutines. Note 2: Examples of valid data value ranges with applicable physical units from the application domain perspective are ‘0..200 [m/s]’, ‘0..3.8 [A]’ or ‘1..100 [N]’. For mapping such application domain value ranges to programming language-level data types (such as unsigned Integer with a value range of 0..65535) refer to BP2. Note 3: Examples of a (Measurement = “The activity to find the size, quantity or degree of something”.) unit are ‘%’ or ‘‰’. Note 4: A counter is an example of a parameter, or a return value, to which neither a physical nor a (Measurement = “The activity to find the size, quantity or degree of something”.) unit is applicable. Note 5: The (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-software-interface (HSI) definition puts in context the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) design and therefore is an aspect of system design (SYS.3).
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP2
Specify dynamic aspects of the detailed design. (
O1 )
Specify and document the dynamic aspects of the detailed design with respect to the software architecture, including the interactions between relevant (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) to fulfill the component’s dynamic behavior. Note 6: Examples for behavioral descriptions are natural language or semi-formal notation (e.g, SysML, UML).
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP3
Develop software units. (
O2 )
Develop and document the (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) consistent with the detailed design, and according to coding principles. Note 7: Examples for coding principles at capability level 1 are not to use implicit type conversions, only one entry and one exit point in subroutines, and range checks (design-by-contract, defensive programming). Further examples see e.g, ISO 26262-6 clause 8.4.5 together with table 6.
intacs® Certified Mechanical SPICE
Sponsored
The official intacs® Certified training for Mechanical SPICE.
BP4
Ensure consistency and establish bidirectional traceability. (
O3 )
Ensure consistency and establish bidirectional traceability between the software detailed design and the software architecture. Ensure consistency and establish bidirectional traceability between the developed (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) and the software detailed design. Ensure consistency and establish traceability between the software detailed design and the software requirements. Note 8: Redundancy should be avoided by establishing a combination of these approaches. Note 9: Examples for tracing a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) in the detailed design to a software requirement directly are communication matrices or basis software aspects such as a list of diagnosis identifiers inherent in an Autosar configuration. Note 10: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP5
Communicate agreed software detailed design and developed software units. (
O4 )
Communicate the agreed software detailed design and developed (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) to all affected parties.
# OUTPUT INFORMATION ITEMS
13-52
Communication evidence (
O4 )
All forms of interpersonal communication such as
e-mails, also automatically generated ones
tool-supported workflows
meeting, verbally or via meeting minutes (e.g., daily standups)
podcast
blog
videos
forum
live chat
wikis
photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Management of Products for Reuse
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Performance Management
13-51
Consistency Evidence (
O3 )
Demonstrates bidirectional traceability between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g.,
tool links
hyperlinks
editorial references
naming conventions
Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain, e.g., by
performing pair working or group work
performing by peers, e.g., spot checks
maintaining revision histories in documents
providing change commenting (via e.g., meta-information) of database or repository entries
Note: This evidence can be accompanied by e.g., Definition of Done (DoD) approaches.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
04-05
Software Detailed Design (
O1 )
Elements of a software detailed design:
Control flow definition
Format of input/output data
Algorithms
Defined data structures
Justified global variables
Explanatory annotations, e.g, with natural language, for single elements or entire diagrams/models
Examples for expression languages, depending on the complexity or criticality of a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.):
natural language or informal languages
semi-formal languages (e.g, UML, SysML)
formal languages (e.g, model-based approach)
Used by these processes:
SWE.3 Software Detailed Design and Unit Construction
11-05
Software Unit (
O1, O2 )
Can be
a representation of a (Software element = Refers to software component or software unit) at the lowest level in a conceptual model, which is decided not to be further subdivided and that is a part of a (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.), or
a representation of a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model.
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.) under (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) such as commented source code, auto-code, an object file, a library, an executable, or an executable model as input to (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.)
Used by these processes:
SWE.3 Software Detailed Design and Unit Construction
SWE.3
Software Detailed Design and Unit Construction
