Hardware/software design requirements planning: Part 1 - Laying the ground work
Many design engineers complain that their system engineers fail to flow down the customer requirements to their level of detail in a timely way. Their solution is to begin designing at their level of detail without requirements because their management has imposed a drawing release schedule they dare not violate.
These engineers are often right about the failure of their system engineers but wrong to proceed in a vacuum as if they know what they are doing. The most common failure in requirements analysis is the gap between system requirements defined in a system specification given to the contractor and the component-level requirements in the performance requirements area. In organizations in trouble, the goal in the engineering organization is often stated as getting the system performance requirements flowed down to the design level or deriving design requirements from system requirements.
Unfortunately, no one seems to know quite how to do that, and avoidable errors creep into the point design solutions in that void that develops. Flow down is a valid requirements analysis strategy, as is boilerplate (which the author refers to as one form of cloning); they are just not completely effective tools across all of the kinds of requirements that must be defined, and particularly not effective for performance requirements.
Flowdown is composed of two subordinate techniques: allocation (or partitioning) and derivation. Allocation is applied where the child requirement has the same units as the parent requirement and we partition the parent value into child values in accordance with some mathematical rule. Where the child requirement has different units than the parent requirement, the value may have to be derived from one or more parent requirements through parametric analysis, use of mathematical models, or use of simulation techniques.
The problem in the flowdown strategy is that you must have a set of parent requirements in order to perform requirements analysis. One may ask, where did the parent requirements come from? This difficulty is solved by applying some form of modeling that leads to the identification of characteristics that the item must have.
The model should be extensible with respect to the problem represented by the system being developed such that it can be used to identify needed functionality and be iteratively expanded for lower tiers of the problem. Functional analysis (described later in this series) is an example of a means to identify performance requirements.
Once the physical hierarchy of the product structure is established through functional analysis and allocation, other models can be applied to identify design constraints and appropriate values in interface, environmental, and specialty engineering areas. In the latter two cases, requirements allocation can be very effective in a requirements hierarchy sense.
Our toolbox should help us understand what to write requirements about and what characteristics we should seek to control. Once we have this list of characteristics, we must pair each with an appropriate numerical value and weave words around them to make the meaning very clear.
We need to quantify our requirements because we will want to be able to determine whether or not a particular design solution satisfies the requirement. This is very hard to do when the requirement is not quantified. As we shall see, this is the reason why the author encourages simultaneous definition of requirements and the companion test and analysis, or verification, requirements for proving the solution satisfies them.
Our system requirements analysis process should clearly tell us what kinds of characteristics we should seek to write requirements about and provide a set of tools to help us add characteristics to our list. We also need to have the means to quantify them.
We seek a list of characteristics that is complete, in that it does not omit any necessary characteristics, and minimized, since we wish to provide the maximum possible solution space for the designer. We would like to have a more specific understanding of how this requirements analysis solution is characterized by completeness and minimization, but there is no easy answer.
The best prescription the author can offer is to apply an organized approach that connects specific models up with specific requirements categories and apply the tools with skill based on knowledge derived in practice or through training. Figure 1.3-1 below offers an overall taxonomy of every kind of requirement that one would ever have to write in the form of a three-dimensional Venn diagram.
Figure 1.3-1 Requirements taxonomy (To view larger image, click here.)
The top layer, Part I in MIL-STD-490A or the performance specifications in the context of MIL-STD-961E, corresponds to development requirements, often called design-to requirements, that must be clearly understood before design. The lower layer, Part II in 490A context or detailed specifications under 961E, corresponds to product requirements, commonly called build-to requirements.
The portion of the construct below the heavy middle line is for product specifications, in which we are primarily interested in this series. The requirements above this line correspond to process requirements captured in statements of work and plans. Many of the same techniques discussed in this series for specifications apply to process requirements, but most of the book specifically concerns product specifications and proving that the design satisfies their content.
Development requirements can be further categorized, as shown in Figure 1.3-1 above, as performance requirements and design constraints of three different kinds. Performance requirements tell what an item must do and how well it must do it.
Loading comments... Write a comment