Subsystem Mapping
Systems engineering is a control process for a project. It’s a way to document design decisions, and make informed choices about design. Mapping the design requirements to functions, and functions to subsystems and ultimately stakeholders is important for traceability. If a design requirement changes, it is important to know exactly how this change will manifest through the design, and inform the appropriate stakeholders. In the reverse situation, if stakeholders change, it is important to know which subsystems are likely to be affected.
Example applications
This traceability should be flexible to your needs. We are looking at design requirements, functions, subsystems and stakeholders because these are the factors that we’ve examined. If your project has gone through an extensive design attributes or work breakdown structure phase, these might be useful considerations to map. The key idea is that you can trace your process backwards and forwards.
Steps
Described here is a generic process for the mapping. Adjust and apply as required for your project’s instance.
- List all the design requirements established during your Requirements Analysis (note: these may be customer requirements, secondary or tertiary attributes, engineering characteristics - whatever is more useful for your project. Put this in the first column of the table.
- For each requirement, list the functional groups that meet that requirement in the second column. There may be functions that are outside your scope, but include these in this process
- Then list the corresponding components that are responsible for delivering that function
- If appropriate, list the stakeholder or team responsible for delivering the component
Hints
- Where a function or component sits across multiple requirements, ensure that these are listed multiple times. A single requirement may have many important components - make sure that you keep the mapping at a useful level for its purpose.
- It may be easier to consider top-level requirements for the purpose of this exercise, as the documentation may get unwieldy as the number of requirements increase
- It may be more appropriate to use tertiary attributes rather than functional groups - this is what is done in the example readings. The functions should be relatively easy to substitute in, as you should already have them at hand.
- Ensure that you use the mapping to construct insights about your system - is there one crucial element that may cause a problem if it fails or is not delivered? Does one requirement determine the choices around too much of your system?
Core resources
SlalomTech, 2009, Attributes Cascade of an Instrumented Whitewater Slalom Gate System [PDF]