Allocating Performance Requirements

6.5.2 Allocate Performance and Other Limiting Requirements

It is important not to get caught up in the process of developing the various documents and diagrams and lose sight of the objective that is to develop a new system and that a primary responsibility of the systems engineers is to define complete and accurate requirements for the physical elements of the new system. Having decomposed the top level system modes into their constituent modes and the top level functions of the system into the lower level functions required for each of the decomposed modes the next step is to allocate (decompose) the performance and other constraining requirements that have been allocated to the top level functions to the lower level functions.

The primary path is to follow the FFBDs so that requirements are allocated for every function and are traceable back to the top level functional requirements. Traceability is supported by using the same numbering system used for the functions. Requirements Allocation Sheets may be used, as described in the DoD SEF, or the allocation can be done directly in whatever tool is used for the Requirements Database. Other useful tools are the scenarios, Timeline Analysis Sheets (TLS) and IDEFO diagrams developed during requirements analysis and functional decomposition. If the team followed recommended practice and began developing or updating applicable models and simulations these tools are used to improve the quality of allocated requirements. For example, budgeting the times for each function in a TLS on the results of simulations or models is certainly more accurate than having to estimate times or arbitrarily allocate times for each function so that the time requirement for a top level function is met.

Another example is any kind of sensor with a top level performance requirement expressed as a probability of detecting an event or sensing the presence or absence of something. This type of performance requirement implies that the sensor exhibit a signal to noise ratio in the test and operational environments specified. Achieving the required signal to noise ratio requires that every function in the FFBD from the function that describes acquiring the signal to the final function that reports or displays the processed signal meets or exceeds a level of performance. Analysis either by models or simulations is necessary to balance the required performance levels so that the top level performance is achieved with the required or desired margin without any lower level functions having to achieve performances that are at or beyond state of the art while other functions are allocated easily achievable performances.

Functional trees are very useful for budgets and allocations, particularly con-ops timelines and software budgets since physical elements don’t have time, lines of code (LOC) or memory requirements but functions do. Transforming the FFBD into an indented list of numbered and named functions on a spreadsheet facilitates constructing a number of useful tables and diagrams. Consider a timeline analysis sheet (TLS) for a hypothetical system having two functions decomposed as shown in Figure 6-24.

Figure 6-24 A hypothetical TLS for a system with two functions decomposed into its sub functions.

The TLS illustrates both the time it takes to execute each sub function in a particular con-ops scenario and the starting and stopping times for each time segment. If the functions were to be executed sequentially nose to tail then just the numerical time column would be needed and the total time would be determined by the sum of the individual times.

The same function list can be used for software budgets or allocations. An example is shown in Figure 6-25.

Figure 6-26 Software lines of code and memory can be budgeted or allocated to a list form of the system functions.