К оглавлению
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 

Quite clearly, what is needed is to list the requirements and the WBS elements

and ascertain the intersects. If you do not have an RTM or an RFM, use

the references shown above (Attachments 7 and 8) and create the necessary


Immediately after you have created the matrix, assess the actions and resources

necessary to accomplish the requirements in the matrix. It is one thing

to list the requirements and quite another to find the resources to get them


Key functions are usually easy to handle. They are explicit in the specification

and lend themselves nicely to the RTM, RFM approach.

Performance requirements are not usually quite so straightforward in that

there are frequently different ways and methods to reach a given performance.

Nevertheless, performance requirements are objective and can be treated

squarely with objective methods. If performance is to be distributed to more

than one WBS element, the usual method of allocating and accounting for performance

requirements is through the use of budgets. A budget allocates part of

the performance requirement to one WBS element and part of the performance

requirement to another WBS element and so on until the entire budget is satisfied.

Those responsible for each WBS element must meet the budget allocation

as if it were the entire specification.

Frequently, interfaces are not covered in a specification but must be inferred

or created. This is particularly true if you have the option of decomposing the

system into your own segments or software modules. In this case, you should

define the interface and all the parameters of the interface and document them.

Usually, these parameters and characteristics are documented into an Interface

Control Document (ICD). ICDs vary by the interface they portray, and each is

usually different. What must be covered in the ICD is a complete characterization

of both sides of the interface or the interface each side must meet. Such

characterizations might include voltage levels, accepted interfaces (such as

RS-232, etc.) the segment or module must meet. As you can see, this can go

on ad infinitum. Just ensure that the interface is adequately characterized and


51d (NO) All major elements (physical and data) are not described

and/or not justified.

All major elements (physical and data) are not described and/or not justified

when the system does not hang together or when there are obvious gaps in or


between components of the system or when the functions or physical attributes

of subelements are not clear.

Do not confuse this assertion with having a system ‘‘A’’ Spec (see Cause

Description 2a) which will only characterize the system at a functional level.


You must meet with the customer to determine the customer’s intent for any

element that is not characterized, no matter whether it is a subsystem or a

module. You must be cautious in this regard. If the customer tells you to characterize

it yourself, you can do that. But, do that just once. If you characterize the

elements and take them to the customer and the customer says, ‘‘No, that’s not

quite what I wanted, go back and recharacterize,’’ you are in a process called

‘‘Bring me a rock.’’ In other words, the creator of the requirement does not

know what is really wanted and will tell you to ‘‘Bring me another rock’’ until

the right rock is evidenced. This process will consume you and your team.

You must insist that the customer either characterize the elements and their

interfaces or give you complete latitude to do it, in writing.

51e (NO) All key aspects of user interfaces are not well defined.

All key aspects of user interfaces are not well defined when they do not follow

the accepted standards established for the industry.


If you are at this point, you probably did not get direction from your customer

(generator of the requirements) regarding what standards to follow.

Here, we are talking about color, size, look and feel, data rates, protocols, location,

and, to some degree, content.

The first step is to identify the user interfaces. The second step is to apply

the standards accepted by the industry for those interfaces. Probably 98 percent

of the characteristics of all known user interfaces have been defined in standards

of some sort.

Additionally, to ensure that the interface is thoroughly understood, each side

should simulate the other side of the interface for internal testing before integration.

This should illuminate incompletely specified aspects of the interface. Both

sides are likely to interpret ambiguous parts of the specification in different

ways, so comparison will bring to light any problems in the interface definitions.

Once all these steps have been accomplished, it is wise to sit down with the

customer and get agreement regarding the interfaces. The agreements should

then be documented and incorporated into the design requirements, reviewed

at the Design Reviews, and demonstrated and tested at every applicable level.

See also Cause Description 51d.

51f (NO) The Architecture does not hang together conceptually.

The Architecture does not hang together conceptually when the system specification

fails to describe the functional components of the system in terms of

their behaviors or to provide component-to-component interfaces.