SMAD

78 Requirements Definition 4.1
4.1 Role of Requirements in System Development
79
difficult to implement in truly innovative space systems. In fact, well-intentioned
aPIm>aches early in the design cycle may result in serious cost growth later in design
and operation. But this difficulty in explicit cost control does not imply we should
avoid the challenge. The growth in cost from the early estimates performed during
Concept Development is typically driven by a few controllable problems. Frrst, not
fully accounting for all elements of cost in these early estimates is common. Frequently,
not consulting with designers and manufacturers who will develop the system
and the operators who will control the system results in misunderstanding cost or missing
elements of cost. Second. overspecifying the system inhibits trades which we can
focus on cost reduction. Fmally (and probably the most prevalent problem), heavy and
uncontrolled changes to requirements as the system proceeds through latter stages of
design can create major growth in cost due to constant redesign and related material
and time waste. Worse, the loss of a fully understood system baseline becomes more
likely and potentially very costly later in the program. The process of defining and
flowing down requirements affects cost more than any other program activity.
. Then, too, on several occasions, customer requirements accepted without rational
. challenge have led to unjustifiable project costs and. in two well-documented cases,
eventually caused cancellation. One of the authors once had the opportunity to
convince a customer that a new requirement that was inserted after program start
would not enhance the mission; millions of dollars were saved and the customer's
belief in our integrity was solidified.
Rg. 4-1.
Abbreviated House of Quality.
4.1.1 Quality Function Deploym.ent-A Tool for Requirements Development
While there are several structured approaches to developing requirements from the
customerluser needs, the most commonly used tool is Quality Function Deployment,
or QFD. Its application is not product limited; we also use it in developing of
requirements for processes and services.
Quality Function Deployment derives from three Japanese words or characters
meaning (1) quality or features, (2) function or mechanization, and (3) deployment or
evaluation. Symbolically we define the combination as "attribute and function
development. "It involves a series of matrices organized to define system characteristics
and attributes and can be applicable over multiple areas of decomposition. The
frrst level, connecting customer needs or requirements to technical attributes or
requirements, we often called the House of Quality and configure it in its simplest form
as in Fig. 4-1. We often call the left hand colunm the "Whati' (at this first level, this
is called the ''voice of the customer") and we call the horizontal attributes the "Hows."
This relationship will become apparent as the "Hows" define the means for fulfilling
the "Whats."
Weightings are applied to the "what" side of the matrix and are usually graded in
three levels to help establish priorities of needs and related technical attributes. While
of value in trading requirements, the primary use at this stage should be to define trade
space.
Figure 4-2 shows a simplified application to FrreSat. Referring to Table 1-5 and
illustrating with only a few of the identified mission needs, an abbreviated matrix
shows some five needs and six relevant attributes. Note the conflicts between competing
satellite orbits which could. potentially satisfy key requirements. This suggests
carrying out extensive analysis and trades. Note also the relative priorities emphasizing
technical attributes which assure timely coverage.
Rg. 4-2.
Da!Iy Coverage 9 9 9
30 min Response 3 3 3 3
98% AvalJabIJHy 9 9 9 9
LocatIon Accuracy 9 9 9 9 9
++
l: 12 12 21 21 12 18
++++++
WelghIIng:
9: HIghest Imporlam:e
3: Medium ImporIam:e
1: Lowest ImporIam:e
Simplified QFD for RreSat Mission. This limited set of needs and responding technical
attributes would be expanded significantly for the complete design process.
Recalling the discussion on constraints (at the end of Sec. 4.1), we understand that
the customer needs that the system cost no more than $20 million per year of 0peration;
that is a constraint and all needs and technical attributes must meet this criterion.
Thus, while it is a fixed requirement, we may leave it off the customer needs column
of the QFD so as not to overbalance weighted scoring. If it were stated as having a
target cost of $20 million or less, we might trade that figure and put it on the left hamd
side of the matrix. As a next stage.use of QFD, the technical attributes developed in
the top level would then become the requirements or "what" (left side) of the QFD