Unformatted text preview: ilar functions, designs and tech nologies should
be grouped. Each portion of work should be
verifiable. Pieces should map conveniently onto
the organizational structure. Some of the functions
that are needed throughout the design (such as
electrical power) or throughout the organization
(such as purchasing) can be centralized.
Standardization—of such things as parts lists or
reporting formats—is often desirable. The
accounting system should follow (not lead) the
system architecture. In terms of breadth,
partitioning should be done essentially all at once.
As with system design choices, alternative parti tioning plans should be considered and compared
If a requirements-driven design paradigm is
used for tile development of the system
architecture, it must be applied with care, for the
use of "shells" creates a ten dency for the
requirements to be treated as inviolable con straints
rather than as agents of the objectives. A goal, ob jective or desire should never be made a
requirement until its costs. are understood and the
buyer is willing to pay for it. The capability to
compute the effects of lower -level decisions on the
quantified goals should be maintained throughout
the partitioning process. That is, there should be a
goals flowdown embedded in the requirements
The process continues with creation of a
variety of alternative design concepts at the next
level of resolution, construction of models that
permit prediction of how well those alternatives will
satisfy the quantified goals, and so on. It is
imperative that plans for subsequent integration be
laid throughout the partitioning. Integration plans
include verification and validation activities as a
matter of course.
Implement the Selected Design Decisions.
When the process of successive refinement has
proceeded far enough, the next step is to reverse
the partitioning process. When applied to the system architecture, this "unwinding" of the
process is call...
View Full Document