Overall Approach and Purpose:

The objective of the approach described herein is to establish the "preference
structure" for a hypothetical "consensus client."  Ie, to establish a
hierarchy that describes the likes and dislikes of a representative or
average user of the system to be designed.  This heirarchy is probably not
optimal for any single client, but is acceptable to all interviewed.  A
hierarchy is established both for the *performance* demanded of the system,
and for the *cost* the user is willing to pay in order to achieve that
performance.  Weights will be assigned to each of the nodes in the hierarchy
to indicate their relative importance to the client in his acceptance of the
system as "successful."  Ultimately, this hierarchy can be entered into a
spreadsheet, and a single number can be computed describing performance of
the candidate system, with an associated one describing its cost.  Since
performance and cost are often competing objectives, it is necessary to
state beforehand how they will be traded off.  This permits a *single number*
to be generated to describe the system, such that higher is better -- giving
us an objective method to judge one candidate solution against another.
If this sounds too good to be true, the reader should realize that *assigning
the weights* is *subjective*.  It is their use, once assigned, that is
objective.  However, this approach does provide a repeatable way, using
*measurements* to select one system instead of another.  Perhaps more
importantly, it provides a way to document *why* the system was chosen
instead of the others.  And perhaps *most importantly*, it provides a way
to perform sentivity analysis which can be used to *tweak the design*,
potentially offering synthesis of even better solutions (designs) than
those originally proposed.

  Users and System Requirements:
System requirements are stated by potential *users* of the system.  A user
is defined to be anyone who has the right or the responsibility to impose
requirements on the system to be designed.  Users include those paying for
the system, those using it, those building and designing it, those
maintaining it, and the potential beneficiaries and victims of it.  A
requirement must be capable of being *measured* relative to the degree
to which it is, or is not, met.  Otherwise, it really is not a requirement!
Requirements may have thresholds.  If a requirement's measurement is above
(or below) its threshold, the system is rejected as unacceptable.  In effect
the existance of the threshold states that the requirement is mandatory at
at least the prescribed level.  Requirements are stated *functionally*; ie,
they describe what the system must *do*, without regard to the technology
that will be used to do it.  This approach is necessary because specifying
technologies to be used limits the potential solutions that may be employed
to solve the problem!  Experience has shown that for technical persons this
is amazingly difficult, but amazingly possible to accomplish.  The only place
it is permissible to discuss *technology used to solve the problem* is in
reference to the technology the system to be designed must interface with.
That implies a limitation on potentially acceptable solutions that will be
imposed on the eventual "winner" regardless of how open the design is kept.

  System Performance and Cost Hierarchies:
The performance and cost requirements are arranged into performance and
cost hierarchies.  At the top of the performance hierarchy is the system's
"top level system function" (TLSF).  The TLSF is the system's reason to exist,
it's purpose in life, or why it is being created.  The TLSF is decomposed
into major system functions, which are themselves typically too broad to be
met.  Each of these is composed until the resulting requirements become
simple enough to be met.  This forms a hierarchy or tree, with the "leaves"
(extremities) of the tree being directly achievable, and how well each is
achieved is directly measureable.  Ultimately the leaves are the requirements
of the system.  In the example below, you would specify how you would measure
"starts and runs dependably."  If you cannot measure it, it must be either
decomposed into things that you can measure, or dropped from the list of
requirements.  Requirements are things that would cause you to select one
system over another, all other things being equal.

  A Trivial Cost and Performance Hierarchy Example:

PERFORMANCE
TLSF: Provide Transportation for the Meyer Family
       |-- Get Chuck to Work
       |    |-- Starts and Runs Dependably
       |    |-- Small enough to Park in the Lot
       |
       |-- Get Andy to School
       |-- Get Virginia to the Grocery Store
       |-- Get the family to Church
       |    |-- Adequate passenger space
       |
       |-- Transport the family on Vacation
            |-- Adequate passenger space
            |-- Adequate luggage space

    COST
      Provide Transportation at the Lowest Cost
       |-- Initial Cost
       |-- Maintenance
       |-- Fuel
       |-- Comfort
       |    |-- Air Conditioning
       |    |-- Comfortable Seats
       |
       |-- Ease of Operation
            |-- Automatic Transmission
            |-- Power Steering & Brakes


  Assigning Requirement Weights:
Let's use the example above to discuss assigning weights to my performance
requirements.  If Chuck doesn't get to work the family has no income.  That
one should get a relatively high weight!  Andy can ride the bus to school,
he'd just prefer not to.  There are three grocery stores within two blocks
of home.  While Virginia's requirement is a little more urgent than Andy's,
not meeting it every time still does not have extremely dire consequences.
The family is devoutly religious and will get to Church if at all possible;
however, the church is five blocks away, and they can walk occassionally if
necessary.  It is pretty important to the family that they be able to take
vactions, but that is only two weeks out of the year, and they are pretty
flexible about the time.  So, a reasonable assignment of weights might be:
Chuck's work 50%, Church 20%, Grocery Store 15%, Andy 10%, Family Vacation 5%.
Note that the weights were assigned by Chuck using his estimate of the
family's overall longterm satisfaction with their transportation, if the
various needs were *not* met.  It is entirely possible, even likely, that
Virginia and Andy would assign somewhat different weights.  Ultimately the
desired result is a set of weights that all three agree they can live with.

  Providing Normalized Scores for the Requirements:
In the above trees, if I have weights assigned to each of the nodes
(requirements), and can provide a score describing how each requirement
is met, I can roll them up into a single number describing the suitablity
of the system's performance, and the cost required to achieve it.  The
scores all need to be "more is better", so a higher overall score means
a more desirable system, but they also need to be normalized so we can
compare "number (or percent) of failures to start" with things like
"parking lot footprint", "number of people seated", and "cubic feet of
luggage space."  A way to normalize scores is through use of *scoring
functions*.  A scoring function simply provides a way to project a measurement
onto a linear scale, typically from zero to 100.  Scoring functions can
be linear, such that any measurement below 10 is worth nothing, and anything
above 90 is worth 90, and for the values in between twice as much is
twice as good (40 is twice as good as 20).  More typically they are
S-shaped assymptotic curves.  Scores can be "more is better" (typical of
performance) or the reverse "less is better" (typical of cost).  Scoring
functions can also be step functions.

  Some Subtleties and Related Thoughts:
Things that appear to be performance requirements are often actually
cost requirements.  For example, a requirement for 25 miles per gallon
may initially seem to be a performance requirement because the better
the system performs, the better the fuel economy will be.  In reality
it is a cost requirement because it implies that the fuel cost will
be held below a certain level.  It is not as important to determine
exactly where the requirement should be included, as to ensure that it
is included.

Some things that seem not to be measurable may actually be.  If the
potential requirement seems to be something that would influence one
solution over another, all other things being equal, it should be
included.  Some obsure things can actually be "measured" by the
responses received on a user survey.  It is not important that the
user be able to take a measurement to give his response, but that
you be able to measure his response.  So questions like, "On a scale
of zero to 100, where would you rate this system's ease of use?"
actually provide a number (measurement) of the client's subjective
feeling about ease of use.