Parameter Diagrams Help Define Functional Requirements

6.3.2 Define Functional Requirements

The context diagram and the concept of operations provide an understanding of the static and dynamic interactions of the system with the external world. Identifying functional requirements requires that we begin to examine what the system does. This first involves looking at the system as a complete entity and then decomposing top level functions to lower level functions. It includes examining the modes that a system exists in throughout its life cycle. These analyzes set the stage for allocating functions to physical elements; the work of the design loop. A useful tool for examining function for the system as a single entity is the Parameter Diagram.

6.3.2.1 Parameter Diagrams - The Parameter Diagram (P-diagram) supports requirements analysis by determining and communicating the function of the system or any design element, defining those parameters that can cause undesired performance (noise factors) and defining the control factors the element has (or should have) whose values are selected to achieve the desired performance of the ideal function and to minimize the sensitivity to the noise factors. P-diagrams are useful at any level of product design, from mission level to part level. The form of a P-diagram is shown in Figure 6-9.

Figure 6-9 A P-diagram defines the ideal function of a design element and lists the noise factors and control factors that must be controlled in the design to achieve as close as practical the ideal function.

Defining the ideal input and the control factors is usually straight forward. The real work comes in defining the ideal response of a design element, the undesired responses and the noise factors that cause the undesired response(s). The design element, labeled “system” in the figure, is treated as a single entity and the control factors selected as appropriate for the level of the design element. Thus, if the design element is at a mission level the control factors relate to the various systems that interact to fulfill the mission. It isn’t helpful to list screw thread size as a control factor for a mission or complex system design element but screw thread size may be a control factor for a design element at the component level.

Consider the P-diagram for a pencil. The ideal response to the input of hand motion is a line on a writing surface of a uniform density and width. However, a pencil has another ideal response that is important to users. It should sharpen to a fine, uniform point in response to being sharpened. Undesired responses include skipping, tearing paper and the point breaking during sharpening. Control factors include parameters like graphite composition, hardness and diameter and the type of wood used for the casing. Noise factors include writing surface roughness, writing surface material, type of pencil sharpener, sharpness/dullness of pencil sharpener blade(s), temperature, humidity and aging. These lists aren’t meant to be complete but to illustrate the principles involved. Note that variations in composition or trace impurities are not listed as noise factors since the purity and composition are controllable. Sometimes it is difficult to decide whether a parameter is a noise or control factor. It’s best not to waste time trying to be to pure with definitions; capture the parameter as one or the other and ensure it is taken into account during the design.

Generating the P-diagram is a simple and convenient method for the engineer, whether a system engineer or a design engineer, to think about the effects of the environments the design element faces in its life of use, the types and influence of other elements it interacts with in test, use and storage; the ways in which the element is used (intended and otherwise) and the expectations of users. Thus the P-diagram complements the context diagram and the concept of operations and thereby supports requirements analysis as well as functional analysis.

The reason for listing the undesired responses of a design element is that the preferred method of controlling undesired responses is to optimize the ideal response in the presence of the noise factors. This is the essence of robust design practice discussed in the books of Clausing and Phadke previously cited. Design practices prior to robust design often attempted to reduce the undesirable responses directly. Directly minimizing one undesired response can result in redirecting the energy causing that undesirable response so that it causes another undesired response. In contrast robust design practices maximize the ideal response in the presence of the noise factors so that all the undesired responses are controlled.

One of the benefits of developing a P-diagram is that it defines the parameters to be considered in robust design. Another is its communication value. The P-diagram communicates essential parts of the design problem to both the design team and to any reviewers of the design work. If the design element is of the same family as something that the team has designed before then it takes little time to edit the pattern P-diagram from a previous design by adding any new factors and deleting any factors that don’t apply to the new design element. It is likely that the ideal inputs, ideal responses and undesired responses are very similar and take only minutes to edit. However, it is the differences between the new design element and those the team has designed before that are important to define at the outset. The P-diagram is a quick way to define and capture those differences.

If the design element is entirely new to the team then the P-diagram is critical to identifying all of the noise factors that must be accounted for in the design. Often the effects of noise factors on the performance of a design element are analyzed individually or in groups. Color coding the noise factors on a P-diagram is a quick way to remind reviewers of which noise factors are under consideration in a particular analysis, which ones have been previously evaluated and which ones remain to be analyzed. Using robust design practices such as Taguchi design of experiments noise factors can be grouped or compounded to speed the analysis. The P-diagram is again a good communication tool to describe the structure of a Taguchi analysis of variance experiment. (Taguchi design of experiments is described in detail in the book by Phadke cited earlier.)

 Examining the interactions on the context diagram leads to the identification of the functions performed by the system in addition to the ideal function and undesired interactions defined in the P-diagram. Each interaction on the context diagram is reviewed to define the inputs and outputs from the system. The transformations performed on the inputs, and driving the outputs establish the functions performed by the system. Functions should be defined following the classic engineering view that outputs are defined as a transform on one or more inputs. When defining system functions, the requirements must define every output that is produced from every combination of the legal set of inputs. The definition of the function transformations must be comprehensive and accurate. The functions must provide exhaustive definitions. Requirements often are not exhaustive by not covering all possible outputs that can be produced.

The concept of operations (Con-Ops) does not provide an exhaustive understanding of all operations of the system, so the identification of all functions must rely on the context and P-diagrams. Additionally, interactions on the context diagram may be involved in multiple functions. Involvement of the user in the function definition provides confidence that all system functions are identified. Con-Ops and P-Diagrams typically focus on the functions which produce the target outputs which the user desires from the system. However, there are often other functions that must be performed to support the operation of the system but that don’t directly produce the target outputs desired by the user. For example, data systems typically employ error correction algorithms to ensure the desired data performance is achieved. Users typically do not request an error correction function as part of the system. The system engineer must provide the broad vision, based on his understanding of the user needs, to recognize this is a necessary function which the system must perform in order to ensure the algorithm performance requirements are specified. This highlights an important value of the context diagram. Examining all interactions of the system with the external world usually identifies functions the system must perform that are not typically identified as requirements by the user.

 When examining the interactions on the context diagram, it is also important to remember that some of the interactions will map to a real physical interface. Data flowing in and out of the system usually represents a physical interface. However, some interactions, such as radiated EMI, are not mapped to a physical interface. It would be a lot easier to design a system if the radiated EMI interactions could be allocated to a specific connector but in this case, the functions need to be specified with the understanding that many mechanical characteristics have requirements that address this function. Functions that do not deal with explicit physical interfaces are often difficult to specify.

The detailed understanding of system interactions is translated into the final functional requirements. For each function, each individual parameter for performance, behavior, and visibility becomes an independent, unique requirement. Having identified functions, detailed understanding ultimately leads to functional requirements. The specifics of the performance, behavior, and visibility associated with the input, transform, and output must be included. Performance aspects include tolerances, uncertainties, response times, bandwidth, data structures, etc. Behavior includes considerations of how functions are affected by the operating state of the system, other functional results, and environmental conditions. Visibility defines how much knowledge is known about how the function is performed. For example, an error correction function may be required by the system. This error correction function may be defined simply by the ability to perform a specified level of error correction, or the system may need to implement a specific algorithm.

When all functions are defined, the customer must review and agree on the result at a System Requirements Review (SRR) or System Functional Review (SFR). Other tools and methods useful in identifying functional requirements include Quality Function Deployment (QFD), defining system modes and Kano diagrams. These are described in the following sections or chapters.