К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 

In order for the system to be complete, all the requirements must be incorporated

into the architecture and the design, and the ‘‘data trail’’ must be identifiable.

Frequently, at the architectural level, issues appear that are too complex to

be addressed at that level or are not defined enough to create an architecture to

drive them. This is particularly true in R&D programs. As the design unfolds,

these deferred items must be kept up with and referred back to the architecture

element from which they were deferred in the first place. Making additions to

the RTM, in reverse order, is a good way to accomplish this task.

52e (NO) The design is not partitioned into manageable segments.

The design is not partitioned into manageable segments when the segments

are either not logical, cannot be defined, cannot be tested, cannot be scheduled,

or cannot be costed. The purpose in partitioning is to create groupings for the

Work Breakdown Structure (WBS) and thus distribute the workload among the

resources available. If this cannot be accomplished, the task cannot be efficiently

worked—if it can be worked at all.


Decompose the requirements into logical groupings. The groupings can be

by subsystem, physical grouping, functional grouping, time ordering, data flow,

control flow, or some other criterion. Grouping forced by resources available

can be used but should be the last item on the list, not the driving factor.

Remember that the next step will be the allocation of requirements into the

groupings you have established. In some cases, the groupings may need to be

adjusted to make all the requirements fit as in Figure 5-1.

F i g u r e 5 - 1 — R e q u i r e m e n t s A l l o c a t i o n

A major rule for partitioning is to minimize interfaces across partition elements.

These interfaces are the most challenging technical issues on most projects.

Does this box belong in this tree or the other tree? You must answer this

question by establishing a ‘‘clean’’ line of division between both the grouping

criterion and the allocation of requirements. Don’t distribute part of a grouping

in one WBS box and the remainder in another box. Try not to distribute part

of a requirement in one WBS box and the remainder in another. If you must

do this, you must create a ‘‘budget’’ to allocate those parts and to document

where you put them. Even when the lines are clean, you may well still need to

interface one element with another. In this case, ensure that a reasonable and

usable Interface Control Document (ICD) exists or is created. See Cause Description

51c/51c (NO) for more detail regarding ICDs.

52f (NO) The design does not account for supportability, Life Cycle

cost/total cost of ownership, and future expansions.

The design does not account for supportability, Life Cycle Cost (LCC), total

cost of ownership, and future expansions whenever all these factors are not

taken into consideration in the design, production, implementation and operations,

and maintenance alternatives.


If you are at or near the very beginning of your project, you are in a position

to achieve the objectives of LCC, that is: Choosing the most cost-effective approach

to the entire life cycle/total cost of ownership system, product, or unit

within the available resources. Sometimes this can include planned or estimated

future expansions as well. The analysis must cover the entire lifespan of the

system, product, or unit. The LCC process provides a systematic methodology

for evaluating and quantifying the cost impacts of alternative courses of action.

It can be used to support trade-off analyses between several product design

configurations, or the sensitivity of a specific design to changes. The LCC can,

and probably will, affect the distribution of costs between up-front design or

production costs and field operation and maintenance costs. Care must be taken

to involve the entire life span of the system, product, or unit. Frequently, only

design or production costs are considered, leaving operation and maintenance

costs to be added later. If the specification calls for a Design To Cost approach,

its result may well be different than the Life Cycle Cost. Be certain to check with

the customer regarding intent. The customer could have intended Life Cycle

Cost but said Design To Cost or some similar term. The results will probably

be different.

If you are at a point other than the very beginning of your project and are

confronted with LCC issues, you are starting a long uphill battle. The LCC

program should be started before design is begun, indeed, before parsing of the

system has begun. Usually, LCC begins with trade-off analyses first on various

designs, then on various production methods and techniques, and finally on the

planned operations and maintenance approaches.

Nevertheless, you are here and must make the best of what you have. If you

are in the design phase, you could stop and conduct trade-offs and then reenter

the design phase. If you are beyond the design phase and into the production

phase, chances are that it will be too expensive to go back. At this point, it is

probably prudent to stop the project and to concentrate on the production

phase and beyond. Consider alternatives that not only make production more

efficient and less expensive but alternatives that make operations and maintenance

more efficient. This is the point at which you need to consider spare

parts. It is much more efficient to turn out spare parts during the production

phase than to retool at a later time and gear up to produce those parts. Remember

the $800.00 hammer? That’s what happened. The proper alternative is to

provide Pre Planned Product Improvements (P3I) during the planning cycle

and phase these improvements in over time.

If you are beyond production, the only alternatives you have are installation,

operation, and maintenance. Here, you simply look at trade-offs for those aspects

of the project.

52g (NO) Technical Performance Measures (TPMs) such as data

retrieval time, weight, error rate, etc., have not been defined

or accommodated.

Technical Performance Measures (TPMs) such as data retrieval time, weight,

error rate, etc., have not been defined or accommodated whenever the TPMs

are not fully understood or do not appear in the related WBS sections or the

related test procedures.