Hardware/software design requirements planning: Part 3 - Performance requirements analysis

Jeffrey O. Grady

November 08, 2011

Jeffrey O. GradyNovember 08, 2011

Performance requirements define what the system or item must do and how well it must do those things. Precursors of performance requirements take the form of function statements or functional requirements (quantified function statements). These should be determined as a result of a functional analysis process that decomposes the customer need as noted earlier using an appropriate flow diagramming technique.

Many organizations find that they fail to develop the requirements needed by the design community in a timely way. They keep repeating the same cycle on each program and fail to understand their problem.

This cycle consists of receipt of the customer’s requirements or approval of their requirements in a specification created by the contractor, followed by a phony war on requirements where the systems people revert to documentation specialists and the design community creates a drawing release schedule in response to management demand for progress. As the design becomes firm, the design people prepare an in-house requirements document that essentially characterizes the preexisting design.

Commonly, the managers in these organizations express this problem as, “We have difficulty flowing down system requirements to the designers.”

The problem is that the flowdown strategy is only effective for some specialty engineering and environmental design constraints. It is not a good strategy for interface and performance requirements. It is no wonder these companies have difficulty.

There is no one magic bullet for requirements analysis. One needs the whole toolbox described in this series. Performance requirements are best exposed and defined through the application of a structured process for exposing needed functionality and allocation of the exposed functionality to things in the product entity structure. You need not stop at the system level in applying this technique. It is useful throughout the hierarchy of the system.

Performance requirements are traceable to (and thus flow from) the process from which they are exposed much more effectively than in a vertical sense through the product entity structure.

They trace to the problem or functional plane. Constraints are generally traceable within the physical or solution plane. This point is lost on many engineers and managers, and thus they find themselves repeating failed practices indefinitely.

Given that we have an effective method for identifying valid performance requirements as described under functional analysis above, we must have a way to associate them with quantitative values. In cases where flowdown is effective, within a single requirement category, such as weight, reliability, or cost, a lower-tier requirement value can be determined by allocating the parent item value to all its child items in the product entity structure.

This process can be followed in each discipline, creating a value model for the discipline. Mass properties and reliability math models are examples. In the case of performance requirements, we commonly do not have this clean relationship, so allocation is not always effective in the same way.

Often the values for several requirements are linked into a best compromise, and to understand a good combination we must evaluate several combinations and observe the effect on selected system figures of merit like cost, maximum flight speed of an aircraft, automobile operating economy, or land fighting vehicle survivability.

This process can best and most quickly be accomplished through a simulation of system performance where we are allowed to control certain independent parameters and observe the effects on dependent variables used to base a selection upon. We select the combination of values of the independent variables that produces the best combination of effects in the dependent variables.

Budget accounts can also be used effectively to help establish sound values for performance requirements. For example, given a need to communicate across 150 miles between the Earth’s surface and a satellite in low Earth orbit, we may allocate gain (and loss) across this distance, the antenna systems on both ends, connecting cables, receiver, and transmitter. Thus the transmitter power output requirement and the receiver sensitivity requirement are determined through a system-level study of the complete communications link.

< Previous
Page 1 of 5
Next >

Loading comments...

Most Commented

  • Currently no items

Parts Search Datasheets.com