Hey all, We have a set of requirements for the current capstone
http://psas.pdx.edu/capstone2009/requirements/ 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 satisfiable. 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 design. 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 ability. ------------------------------------------- design, v.: What you regret not doing later on. _______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
