Hardware/software design requirements planning - Part 2: Decomposition using structured analysis
We should now return to a previous discussion. Encouragement has been offered for a single process repeated each time a program is undertaken in the interest of repetition and personnel capability improvement over time. Yet, here is another chance for process divergence to add to the different development environments offered earlier.
We have our choice on the degree of flexibility we will permit our programs. We can lock them down into the code “functional flow diagramming or die” as a way of encouraging continual improvement.
Alternatively, we can permit them to select from a wider range of approved decomposition practices in the interest of program efficiency as a function of product type and team experience. Figure 1.3-3 below offers a diagram for decomposition practices with one possible preapproval marked up.
Figure 1.3-3 Sample decomposition tool approval matrix.
The reality is that in 1998, the system development process was not a static, unchanging entity. Now, this evolution continues. Improvements continue to be made, and they will continue into the future until unified modeling language (UML) merges with SysML, which was derived from it, into a universal model. Until then, we must be alert to opportunities to plug in proven new techniques and integrate them into our toolbox and the skills base of our people.
As in the case of development environments, it is not necessary, or even desirable, that we use exactly the same decomposition method throughout the evolving system product entity structure.
In the beginning, we may choose to apply functional flow diagramming. As we begin allocating exposed functionality to things, we may allocate particular functionality to software. At that point the assigned team or team leader may choose to apply the Hatley- Pirbhai model, knowing that this will have to be developed as real-time software.
Another team may select enhanced functional flow block diagramming, knowing that they will use a system engineering tool called CORE, which is coordinated with that model. Some of these techniques are more appropriate to hardware and others to software, but the adherents of most of them will make a convincing argument why their preferred technique will work equally well for either product type.
Doing functional analysis
Figure 1.3-3 earlier lists several techniques for decomposition of large problems, one of which, functional flow diagramming, has been discussed earlier. It is the author’s preferred approach for grand systems because of its simplicity and generality.
This process starts with the need as function F, which is expanded into a set of next-tier functions, which are all things that have to happen in a prescribed sequence (serial, parallel, or some combination) to result in function F being accomplished.
One draws a block for each lower-tier activity and links them together in a sequence using directed line segments to show sequence. Logical OR and AND symbols are used on the connecting lines to indicate combinatorial possibilities that must be respected.
This process continues to expand each function, represented by a block, into lower-tier functions. Figure 1.3-4 below sketches this overall process for discussion.
Figure 1.3-4 Structured decomposition for grand systems and hardware.
A function statement begins with an action verb that acts on a noun term. The functions exposed in this process are expanded into performance requirements statements that numerically define how well the function must be performed.
This step can be accomplished before allocation of the performance requirement or function statement to a thing in the product entity structure or after. But, in the preferred case, the identification of the function obligates the analyst to write one or more performance requirements derived from the function and allocate that performance requirement to an entity to which it is allocated.
This is the reason for the power of all decomposition techniques. They are exhaustively complete when done well by experienced practitioners. It is less likely that we will have missed anything compared to an ad hoc approach.
This process begins with the need and ends when the lowest tier of all items in the physical product entity structure in each branch satisfies one of these criteria:
(1) the item will be purchased from another company at that level
or
(2) the developing organization has confidence that it will surrender to detailed design by a small team within the company and that the corresponding problem is sufficiently understood in either case that an adequate specification can be prepared.
Loading comments... Write a comment