How do you determine the optimal level of decomposition for a systems engineering process?

1 Why decompose a system?

Decomposing a system is a way of breaking down a complex problem into simpler and more understandable parts. By doing so, you can reduce the risk of errors, conflicts, and inconsistencies, as well as improve the clarity, traceability, and verification of the system requirements and design. Decomposing a system also allows you to allocate resources, assign responsibilities, and coordinate activities among different teams and stakeholders. Moreover, decomposing a system enables you to reuse, modify, and integrate existing components, which can save time, cost, and effort.

2 What are the criteria for decomposition?

When determining the optimal level of decomposition for a systems engineering process, there is no single or universal rule to follow. However, some general criteria can be used as guidance. For example, the size and complexity of the system, the purpose and scope of the system, the stakeholders and users of the system, and the lifecycle and evolution of the system can all influence how you decompose it. The larger and more complex the system, the more it needs to be decomposed into smaller and simpler components. The purpose and scope of the system define the objectives, boundaries, and constraints of the system. Stakeholders and users have different needs, expectations, and preferences that can affect decomposition. Lastly, the lifecycle and evolution of the system determine its phases, stages, and changes that can impact how you decompose it to support its development and maintenance.

3 How to decompose a system?

When decomposing a system in a systematic and consistent way, there are various methods and tools available. Functional decomposition is a method of decomposing a system based on its functions, activities, or processes. It involves breaking down the main function into sub-functions until the desired level of detail is reached. A functional flow block diagram (FFBD) is a common tool for this method, which shows the logical sequence and interaction of the system functions. Structural decomposition is another method that focuses on physical components, elements, or modules. It involves breaking down the main component into sub-components until the desired level of granularity is reached. A block definition diagram (BDD) is usually used for this method, showing the composition and classification of the system components. Lastly, behavioral decomposition concerns behaviors, states, or modes. It involves breaking down the main behavior into sub-behaviors until the desired level of specificity is reached. A state machine diagram (SMD) is usually used for this method, showing the transitions and actions of the system behaviors.

4 What are the challenges of decomposition?

Decomposing a system is not a simple task, as it involves a variety of challenges and trade-offs that need to be taken into account. Finding the right balance between too much and too little decomposition is essential; too much can lead to fragmentation, duplication, and over-engineering, while too little can lead to ambiguity, confusion, and under-engineering. Additionally, it is important to maintain the consistency and coherence of the system, as decomposing it can introduce inconsistencies and incoherences among its components. Furthermore, managing the dependencies and interactions of the system should be a priority; decomposing it can create dependencies and interactions among its components such as shared resources, common data, or coordinated actions.

5 How to evaluate and improve decomposition?

Decomposing a system is an iterative and dynamic process that necessitates constant evaluation and improvement. To evaluate and improve decomposition, you should review and validate the system decomposition to ensure it meets the criteria, methods, and tools used to create it, as well as the system purpose, scope, and requirements. Additionally, test and verify the system decomposition to check that it functions as intended and expected, as well as its performance, functionality, and quality. Finally, update and refine the system decomposition based on feedback from the review, validation, testing, and verification processes.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?