Hey all,

We have a set of requirements for the current capstone


Ignoring the ambiguity and imperfection of these, i'd like to say
something about what they mean and what they're for.

What follows is abstract, somewhat hard to read, and slightly fluffy.
You have been warned ;)

Observations on Design

A design is specified by what is supposed to be accomplished, the
function of the design, and the operating conditions, over which the
performance of the function takes place.

The operating conditions are necessarily an abstraction of the real
world in which finished designs exist. The trick in specifying the
conditions is to adequately capture the true envelope of operations
without excessively complicating the design or exaggerating certain
parts of it.

This leads to a balance between asking for what might be possible and
what can be reasonably done given the constraints. The tendency is to
try to make specific requirements near the minimum everywhere so that no
single detail prevents completion of the design.

The problem with this tendency is that if the design follows the minimum
requirements everywhere, it probably will perform poorly. Alan Shepard,
was famously quoted after completing an early space flight, "I wasn't
scared, but I was up there looking around, and suddenly I realized I was
sitting on top of a rocket built by the lowest bidder."

What people trying to realize a design actually want is to find the best
possible tradeoffs between the competing factors. Often, the tradeoffs
seem easy to state, at least initially. "Build a rocket that weighs one
ton and costs under $100,000 to lift as much weight as possible to an
altitude of 200,000 feet." But in a system of any complexity things
rapidly become messy. Unexpected things happen, top level requirements
shift, and particularly, finer grained requirements are derived from the
top level requirements.

On implementation

When specifying a design, the envelope of operating conditions is
estimated and a boundary is defined just outside of it. Within the
boundary the design must be functional.

When implementing a design, nominal values are chosen so that worst case
performance doesn't violate the specified boundary, at least with some
reasonable probability. Thus a design is implemented by working for
performance beyond the specifications, even if only slightly.

The natural tendency in implementation is to work well above the
specification unless doing so becomes costly. A common trap is to
maximize some particular aspect of performance, or minimize a cost, at
the expense of the overall design.

When implementing any design 3 things are always in short supply, time,
money, and brain power, these are the design resources, and they are to
an extent interchangeable. They are spent to achieve performance, first
theoretical performance, then actual performance.

An implementer must first understand the upper levels of the design.
What task is being accomplished and how do the functions achieve that
task. This understanding is needed to make performance tradeoffs.
Sometimes some of the performance tradeoffs will be explicitly stated,
but often not, and never all.

Usually there will also be specific requirements. These must be compared
to the upper level goals to determine if they are consistent. If not
they must be made consistent or the specification will not be

The requirements must also be sufficient to specify the design. The
requirements are sufficient when any design choice can be made to either
maximize performance, or minimize cost.

For any realistic set of specifications there is more than one possible
design to satisfy them. Designs are not required to maximize every
possible performance parameter but merely be feasible under the
specifications, though such designs are not optimal. However, for any
real-world design problem, no design will ever be entirely optimal, and
even theoretically there will be more than one (unachievable) optimal

The Advice Section

Design is chaotic, not linear. We linearize it to fit it in our tiny,
though also chaotic, brains. It's unrealistic to expect things to go
smoothly in sequence. Trying to get them to go smoothly in sequence is
still a worthwhile effort.

Somewhere near the beginning of the process is the right time to nail
down the requirements. Sometimes a designer knows where to go, but can't
yet get there. This is merely an obstacle. If a designer doesn't know
which way to go, the problem lies around the requirements.

Production in design is measured by achievement of performance.
Theoretical accomplishment is perhaps less significant than physical
accomplishment, but both represent design progress and can be
quantified. Production can therefore be measured against cost to gage
the dynamic performance of the design process. In this way weak spots
that need attention are found, or conversely areas of significant design

design, v.:
        What you regret not doing later on.

psas-avionics mailing list

Reply via email to