Linked Knowledge Nuggets: arrow_forward "Designing for maintainability from day one"
personAuthor: Process Fellows
Think maintenance when architecting. Clear structures, good naming, minimal duplication, and comments that explain why (not what). Maintainability isn’t added later — it’s built in.
arrow_forward "Systems Engineering - Why the heck do we need this?"
personAuthor: Alexander Feulner
The increasing complexity, shortened development times, distributed development, heightened cost pressures, technological change, and organizational transformations are just a few of the challenges facing the current development.
If these statements seem unfamiliar to you, we congratulate you warmly. For all those who are confronted with these challenges on a daily basis, we present the methodology of ‘Systems Engineering’ in our webinar and answer the question: "Why the heck do we need this?". This webinar is tailored not only for system developers but also for professionals in various domains including software development, hardware development, testing, project management and more.
school
Webinar recording and slides
arrow_forward "The role of the architect"
personAuthor: Process Fellows
Not a bureaucrat, but a facilitator. Someone who translates goals into structures, moderates conflicts, aligns toolchains, and keeps the big picture stable across sprints and handovers. By the way, this is true for product related architects as well for process architects.
# PROCESS PURPOSE
The purpose is to establish an analyzed (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture, comprising the static and dynamic aspects, consistent with the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements.
# PROCESS OUTCOMES
O1
A (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture is designed including a definition of the (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) with their behavior, their interfaces, their relationships, and their interactions.
O2
The (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture is analyzed against the defined criteria, and the special characteristics are identified.
O3
Consistency and bidirectional traceability are established between the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture and the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements.
O4
The agreed (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture and the special characteristics are communicated to all affected parties.
# BASE PRACTICES
BP1
Specify the static aspects of the system architecture. (
O1 )
Specify and document the static aspects of the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture with respect to the functional and non-functional (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements, including the external interfaces and a defined set of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) with their interfaces and relationships.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a functional system architecture, a logical system architecture and a physical system architecture?"
personAuthor: Process Fellows
There are various approaches available how to define a system architecture. One exemplary approach uses views like a functional architectural view, a logical architectural view and a physical architectural view.
Functional Architecture:
The functional architecture defines what the system must do. It describes the system’s functions, their inputs and outputs, and how they interact to fulfill the system’s purpose. This level is technology-independent and focuses purely on the capabilities and behavior of the system.
Example: A car’s functional architecture might include functions like “accelerate,” “brake,” “steer,” and “monitor speed.”
Logical Architecture:
The logical architecture defines how the system functions are logically grouped and interact. It introduces logical components and their interfaces, but still remains independent of the concrete physical parts. It serves as a bridge between functional needs and physical realization.
Example: In the car example, logical components might include “Powertrain Control Unit,” “Brake Control Module,” and “User Interface Module,” each responsible for a set of functions. So, it could be decided already that there is the need e.g. for a CPU, but this is more like a categorization and it is not about picking a concrete physical part!
Physical Architecture:
The physical architecture defines with what the system is implemented. It maps the logical components to real hardware, software or mechanical parts, including e.g. sensors, actuators, processors, and communication buses. This level is technology-specific and considers constraints like cost, space, and performance.
Example: The “Brake Control Module” might be implemented using a specific microcontroller, connected to wheel speed sensors and hydraulic actuators.
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 the dynamic aspects of the system architecture. (
O1 )
Specify and document the dynamic aspects of the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture with respect to the functional and non-functional (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements including the behavior of the (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) and their interaction in different (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) modes. Note 1: Examples of interactions of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.).
Linked Knowledge Nuggets: arrow_forward "What is the difference between a functional system architecture, a logical system architecture and a physical system architecture?"
personAuthor: Process Fellows
There are various approaches available how to define a system architecture. One exemplary approach uses views like a functional architectural view, a logical architectural view and a physical architectural view.
Functional Architecture:
The functional architecture defines what the system must do. It describes the system’s functions, their inputs and outputs, and how they interact to fulfill the system’s purpose. This level is technology-independent and focuses purely on the capabilities and behavior of the system.
Example: A car’s functional architecture might include functions like “accelerate,” “brake,” “steer,” and “monitor speed.”
Logical Architecture:
The logical architecture defines how the system functions are logically grouped and interact. It introduces logical components and their interfaces, but still remains independent of the concrete physical parts. It serves as a bridge between functional needs and physical realization.
Example: In the car example, logical components might include “Powertrain Control Unit,” “Brake Control Module,” and “User Interface Module,” each responsible for a set of functions. So, it could be decided already that there is the need e.g. for a CPU, but this is more like a categorization and it is not about picking a concrete physical part!
Physical Architecture:
The physical architecture defines with what the system is implemented. It maps the logical components to real hardware, software or mechanical parts, including e.g. sensors, actuators, processors, and communication buses. This level is technology-specific and considers constraints like cost, space, and performance.
Example: The “Brake Control Module” might be implemented using a specific microcontroller, connected to wheel speed sensors and hydraulic actuators.
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
Analyze the system architecture. (
O2 )
Analyze the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture regarding relevant technical design aspects related to the product lifecycle, and to support the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) management regarding (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) estimates, and derive the special characteristics for non-software (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
). Document the rationales for the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architectural design decisions. Note 2: See MAN.3.BP3 for (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) feasibility and MAN.3.BP5 for (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) estimates. Note 3: Examples of product lifecycle phases are production, maintenance & repair, decommissioning. Note 4: Examples of technical aspects are manufacturability for production, suitability of pre-existing (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) to be reused, or availability of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
). Note 5: Examples of suitable methods for analyzing technical aspects are prototypes, simulations, and qualitative analyses (e.g., FMEA approaches). Note 6: Examples of design rationales are proven-in-use, reuse of a product platform or product line), a make-or-buy decision, or found in an evolutionary way (e.g., set-based design).
Linked Knowledge Nuggets: arrow_forward "Analysis of an architectural design"
personAuthor: Process Fellows
The analysis of an architectural design is a substantive examination of the quality of an architecture.
It should never depend on the background knowledge or experience of a single person.
For this reason, the analysis must involve a (interdisciplinary) team of experts, be based on predefined criteria and the analysis method should be documented in a comprehensible manner.
Examples of analysis criteria can be found in the Automotive Spice Guideline, but please do not hesitate to define additional criteria that are appropriate to the task and the environment!
BP4
Ensure consistency and establish bidirectional traceability. (
O3 )
Ensure consistency and establish bidirectional traceability between the elements of the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture and the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements that represent properties or characteristics of the physical end product. Note 7: Bidirectional traceability further supports consistency, and facilitates the impact analysis of change requests, and the demonstration of coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent. Note 8: There may be non- (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.) that the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architectural design does not trace to. Examples are requirements that do not address, or represent, direct properties or characteristics of the physical end product. Such requirements are still subject to verification.
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 the agreed system architecture. (
O4 )
Communicate the agreed (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture, including the special characteristics, to all affected parties.
# OUTPUT INFORMATION ITEMS
15-51
Analysis results (
O2 )
Results of analysis of an object or (Task = A definition, but not the execution, of a coherent set of atomic actions.).Identifies:
Object under analysis
Analysis criteria
Selection criteria or prioritization scheme
Decision criteria
Quality criteria
Includes:
Decisions and selections performed
Assumptions and constraints
Evaluation criteria, for example correctness, completeness or consistency to a work product
Examples and references:
Verifiability analysis results, for example when a test machine becomes defective
Results of a feasibility analysis
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
MAN.5 Risk Management
MAN.6 Measurement
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
PIM.3 Process Improvement
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
13-52
Communication evidence (
O4 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
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 Reuse of Products
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 Process performance management process attribute
13-51
Consistency evidence (
O3 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
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
17-57
Special Characteristics (
O2 )
Product or process characteristics that impact safety, legal compliance, fit, function, performance, or further processing, and therefore require special treatment.Identifies:
Product characteristics
Production process parameters
Domain impact references, for example security.
References to regulations (compliance)
Conformity requirements
Includes:
Processing and performance requirements
Examples and References:
IATF 16949, VDA 6.x Guidelines, ISO 26262 ISO/SAE 21434
FMEA rating within FMEA can consider special characteristics.
Used by these processes:
HWE.2 Hardware Design
SYS.3 System Architectural Design
04-06
System Architecture (
O1 )
High level design and structure of a (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.).Identifies:
Overview of the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) structure
(System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
)
Behavior of (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
), for example operation modes, calibration sequences, performance.
Behavior with the environment
Interfaces between (System Element = System elements can be:
Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
) and environment
(Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-software interfaces, for example input-output pins of microcontrollers
Parameters, for example of resource and performance characteristics
Domain specific engineering references, for example mechanical engineering evaluations for thermal influence.
Includes:
Justifying rationale for the chosen architecture
References to underlying architecture, for example (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture (04-52), Software architecture (04-06), or an ML-architecture (04-51)
Examples and references:
Vehicle wiring overview with identification of wiring technologies, control units and wireless interfaces for connectivity.
SYS.3
System Architectural Design
