Hi everyone,
I’m working at the System level, operational activities were transitioned to System function and I’m now refining functions and for some of them I have a lot of leaf functions (>10). Are there any rules or recommendations about the maximum number of leaf functions ? I’m confused on how to manage these functions: Do I have to split the operational activity in two or does it mean some leaf functions overlap with LA ?
Many thanks
Its very easy to perform a functional decomposition past what is necessary for that layer. I would look at your functions and consider if they are really “Black Box”. Ask yourself, is it value added to break these down at this layer? Or can it be left to the layer below.
The more functions you have in the SA then LA, the more workload/model management is required. Improper functional breakdown can create a lot more work than necessary.
Josh
Hi
Josh is right about work load: in LA you divide your system in behavior components that allocate divided functions… and in PA, some more division may occur when trying to implement behavior components in nodes.
But more than work load: if we think about what is a function: a requirement made to allocating component to use received items to produce other items. Then having functional exchanges internal to the same component is trying to make white box with a black one: how and why specify this internal exchange, specify the conveyed exchange items?
Still, even avoiding this, we may have many functions relating to many modes, states or variants. From my point of view, system modes should support use phases (one mode may support several phases). A use phase is a combination of actor states. So I try to contain actor state number, and even actors. Then, minimum activity modes are set from when are required the missions, and exploited capabilities (during which use phases). Then, for each scenario shall start with a set of active functions, which gives a relation between availability of capabilities during phases and function activity. Modes are reasonable combinations that enable the scenario to run.
The way I see the transition operational analysis to system analysis leeds more to fusion than refining: Operational analysis represents the universe that runs the service we want to offer while our system is not there. Or if the service is a new one, the most existing entities possible with some more missing to complete the operations. This shall represent the user experience and full scenarios. Then we decide to include some of the operational entities in our system: all entities fuse in the system. Because we have selected a system, all the other entities are now a context. Some have a direct exchange to system, some not: then we can combine them with one of those being in the chain to system. This enables combining several activities in one system function. The aim is reduce useless description of distant exchanges which will not lead to product design. The final target of system division is to have the SA layer (expected product) for a purchased design product or an individable system (Requirements cannot be declined to component, component desgn have too much mutual action in splitting their contribution to functions)
Thierry