Functional DecompositionInitial analysis should be a “pure” analysis of system function divorced from any implementation.
Figure 1, pure This is never the case; we always have at least a notional architecture within which to understand and discuss the functions. The process always iterates with notional implementations traded at an appropriate level of abstraction and feeding back into the functions problem space to be captured in the specification. One of the most difficult tasks of the Systems Engineer is to remain at the appropriate layer of abstraction. By definition this ends at SFR.
Figure 2, iterative functional decomposition Design is the implementation of functionality. A design has physical, logical performance and behavioral aspects. A Systems Engineering Design Document can be used to capture the Systems Engineering artifacts; Conops, Use Case Model diagram, Context diagram, Interface diagram, Scenario Sequence Diagram and component diagram. When created AT THE APPROPRIATE LEVEL these, along with the system specification, are helpful in understanding and communicating the system. Together the specification, Conops and Design documents capture the essence of the system; Requirements, behavior, architecture and Performance. Requirements — Contractual statements of what the delivered system “shall” do. Behavior — How the system must behave to achieve the desired functionality (conops). Architecture — HW, SW and Human implementation of design. Performance — Quantifiable parameters within which the system will perform. Ideally all four of these should be aligned and of “excellent” quality. It’s acceptable to have a “weakness” or lesser attention to one or two of these, f the others are exceptionally robust. |