Methods for Verifying Functional Architecture

6.5.4 Verify the Functional Architecture

The functional architecture is the FFBDs and the allocated requirements. The collection of all documentation developed during the functional analysis and allocation task is called the functional view. The final task in defining the functional architecture is to review all of the functional view documentation for consistency and accuracy. Check the functions defined for each mode and sub mode to verify that no functions are missing and that the requirements allocated to each function are appropriate for each mode and sub mode. An example of a matrix of modes to functions useful for verifying that all top level functions needed for each sub mode of a toaster in its In Use Mode are defined properly is shown in Figure 6- 29. This example only examines one system mode but the process for examining all modes and all lower level functions is just an extension of the matrix.

The methodology of verifying functional design by using two different tools to describe the same functional requirements also applies to mode transitions. Figure 6-30 is an example of a matrix used to define the allowed transitions among modes of the In Use mode as previously defined with a mode transition diagram in Figure 6-11. Although this is a trivial example it illustrates the methodology.

Figures 6-29 An example of a Functions to System Modes matrix that facilitates verifying that all functions are defined for all modes.

Figure 6-30 Allowable mode transitions can be defined in a matrix as well as in a diagram.

Revisit the documentation in the operational view to verify that the functional architecture accounts for every function necessary to fulfill the operational requirements and that no unnecessary functions have been added. Verify that every top level performance and constraining requirement is flowed down, allocated and traceable to lower level requirements and that there are no lower level requirements that are not traceable to a top level requirement.

Tools for Defining and Verifying Functional Interfaces

6.5.3 Define and Verify Functional Interfaces (Internal/External)

Logical interfaces with external elements are defined in the context diagram and the FFBDs and internal interfaces are defined in the FFBDs. Both types of interfaces must be analyzed to verify that all interfaces are properly located and defined. Examine each external interface and verify that the information coming from or going to the interface matches the information being handled by the parent function in the chain of lower level child functions. Similarly examine each function and verify that all information coming from or going to the function is accounted for; that no function has an output that doesn’t go to either another function or to an external logical interface; and that no function requires information that is not coming to the function from another function or external interface. This task is made easier if the links in a process-oriented FFBD are labeled. An example of a simple process-oriented FFBD of a toaster with internal and external interfaces is shown in Figure 6-26.

(Apologies to experienced designers of toasters for any mistakes by the authors who have limited domain knowledge of toaster design. We use the example of a toaster because it is simple enough that diagrams and models fit on a page and everyone has  some idea of what a toaster does and how it might work. To those “virtuous and pure” engineers whose response is “toasters don’t apply to my work so these examples are useless to me” we remind you that the authors have used these same methods on systems costing hundreds of millions of dollars to develop. Learn the methodologies illustrated by these examples and don’t be put off by errors or incompleteness in these examples or the fact that your systems are much more complex.)

Figure 6-26 An example of a FFBD for a toaster showing the internal and external interfaces for each function of the Operational mode.

A “from” “to” matrix of functions in a particular mode is an alternate tool for defining interfaces for functions. An example is shown in Figure 6-27 for a toaster in its operational mode.

Figure 6-27 A Matrix of Functions to Functions is an alternate tool for defining internal and external interfaces among functions.

N-Squared diagrams are useful tools for analyzing interfaces for systems with functions having many internal interfaces. This tool also provides verification of the grouping and sequencing of lower level functions. It’s much easier to detect sequencing problems in an N-Squared diagram than on a FFBD. An example of an N-Squared diagram used for defining internal and external interfaces is shown in Figure 6-28. The advantages of the N-Squared diagram aren’t apparent in this simple case but imagine if the functions were more randomly sequenced along the diagonal. Then there would be arrows on the left of the diagonal indicating poor sequencing.

It is good practice to develop two different tools for defining internal and external interfaces; for example a FFBD and an N-Squared diagram. The two are then compared to verify that all interfaces are defined, grouped and sequenced correctly and consistent with the definitions of functions in the data dictionary. The small amount of time it takes to verify functional interfaces via two different tools is sound risk mitigation against making a mistake that isn’t discovered until system or subsystem testing when correcting the error is very costly.

Figure 6-28 An N-Squared diagram is an excellent tool for defining, grouping and sequencing interfaces.

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.

Functional Flow Block Diagrams

6.5.1.1 Functional Flow Block Diagrams - Graphical models are used to define and depict the sequence of functions making up a higher level function necessary to fulfill requirements. Functional Flow Block Diagrams (FFBD) can be process-oriented models that represent functions as nodes and objects as the connecting links. Nodes are typically labeled but links are typically unlabeled in process-oriented FFBDs. Figure 6-21 is a FFBD for two of the functions of a digital camera. Here only one external interface is identified, i.e. the interface with light from the scene.

Figure 6-21 A FFBD developed as a process-oriented model has named and numbered functions as nodes and objects as links.

Part of the task of functional design is to decompose high level functions into the lower level functions necessary to carry out the action implied by the high level function. For example, the function “image scene” can be decomposed as shown in the FFBD of Figure 6-22. In this example the objects linking the four lower level functions are also labeled. Note that nodes are numbered as well as named with the numbers indicating the level of the functions in the overall hierarchy of functions. The numbers are selected to provide traceability; e.g. sub functions decomposed from a function 1.1 with n sub functions are numbered 1.1.1 to 1.1.n.

Figure 6-22 The function Image Scene 1.1 from Figure 6-18 can be decomposed into four lower level functions.

Notice that functions 1.1.2 and 1.1.3 in Figure 6-22 could be interchanged in the sequence and still be a logical sequence. This is a simple example of having more than one logical sequence of lower level functions. The “best” sequence is determined by conducting design trade studies when these functions are allocated to physical elements. Note also that the functions 1.1.1 and 1.1.2 are easily grouped whereas 1.1.1 and 1.1.3 or 1.1.2 and 1.1.3 are not easily grouped. Therefore the sequence shown is likely to be the preferred sequence, at least until design trade studies are complete.

An alternative to the process-oriented model of a FFBD is an object-oriented model with the nodes and links reversed. An example of an object oriented model is shown in Figure 6-23.

  Figure 6-23 An example of a FFBD as an object-oriented model of two of the functions of a digital camera with named functions as links and named objects as nodes.

The decision to develop process-oriented or object-oriented models depends upon the experience of the systems engineer and the details of the system being designed. A comparison of the two approaches resulting from an analysis of both approaches is shown in the table.

Table 6-1 Selecting an Object-Oriented or Process-Oriented model depends on the details of the specific system design. From the paper Cognitive Fit Applied to Systems Engineering Models by Larry Doyle and Michael Pennotti, Conference on Systems Engineering Research, 2004. 

As with context or domain diagrams it is helpful to have pattern diagrams for all levels of FFBDs representing the class of systems that includes the system being designed. This saves considerable time compared to having to generate the FFBDs for all the levels of a new system under development. The objective is that the pattern diagrams contain all possible functions, sub functions and external and internal interfaces of the entire class of systems. Then the task becomes examining each top level function and interface to determine if it belongs to the new system. If a functions does not belong it is deleted along with all sub functions decomposed from the unneeded top level function. After deleting all unnecessary functions and interfaces from the top level and the sub functions and interfaces traceable to the deleted top level functions and interfaces it is necessary to examine the sub functions in each level to ensure that only necessary ones are kept. The system being designed may include a top level function from the pattern but may not include the entire set of sub functions decomposed from the top level function.   It is also necessary to examine the partitioning and grouping of functions as the best choice is likely to be system design specific and not necessarily that captured in the pattern diagrams.

6.4 Functional Analysis and Allocation

Figure 6-5, the list of 15 tasks in the post of December 29 titled Requirements Analysis, shows that Functional Analysis and Allocation is necessary to accomplish subtask 10, Define Functional Requirements. Functional analysis decomposes each of the high level functions of a system identified in requirements analysis into sets of lower level functions. The performance requirements and any constraints associated with the high level functions are then allocated to these lower level functions. Thus the top level requirements are flowed down to lower levels requirements via functions. This decomposition and allocation process is repeated for each level of the system. The objective is to define the functional, performance and interface design requirements. The result is called the Functional architecture and the collection of documents and diagrams developed is the Functional view.  

A function is an action necessary to perform a task to fulfill a requirement. Functions have inputs and outputs and the actions are to transform the inputs to the outputs. Functions do not occupy volume, have mass, nor are they physically visible. Functions are defined by action verbs followed by nouns; for example, condition power or convert frequency. A complex system has a hierarchy of functions such that higher level functions can be decomposed into sets of lower level functions just a physical system can be decomposed into lower level physical elements. A higher level function is accomplished by performing a sequence of sub-functions. Criteria for defining functions include having simple interfaces, having a single function each, i.e. one verb and one noun; having independent operations and transparency, i.e. each does not need to know the internal conditions of the others. There are both explicit and implicit or derived functions. Explicit functions are those that are specified or decomposed from specified functions or performance requirements. Implicit or derived functions are those necessary to meet other specified capabilities or constraints.

Sometimes inexperienced engineers ask why they have to decompose and allocate  functions for design elements at the subsystem or lower levels; they believe once they know the top level function, the performance requirements and any constraints defined in the requirements analysis task they can design the hardware and software without formal functional analysis/allocation. One simple answer is that items like time budgets and software lines of code are not definable from hardware or software; they are defined from the decomposed functions and sequences of functions. This is because hardware or software does not have time dimensions, only the functions the hardware or software performs have time attributes. Similarly the question of how many lines of code or bits of memory only have meaning in terms of the functions the software code is executing. Other reasons become more apparent as we describe functional design and design synthesis.

A diagram, simplified from Figure 6-4 and shown in Figure 6-19, helps understand both the question asked by inexperienced engineers and the answer to their question.

Figure 6-19 Developing a hardware/software system design is iterative and has multiple paths.

Figure 6-19 illustrates that although the primary design path is ultimately from requirements to hardware/software design; primary because when the design is complete the resulting hardware/software design fulfills the requirements, other paths are necessary and iteration on these paths is necessary to achieve a balanced design. The paths between requirements and functional design and between functional design and hardware/software design are necessary to:

• Validate functional behavior
• Plan modeling and simulation
• Optimize physical partitioning
• Facilitate specification writing
• Facilitate failure analysis
• Facilitate cost analysis and design to cost efforts
• Facilitate concept selection
• Define software budgets and CON-OPS timelines.

Although the path from requirements analysis to design synthesis isn’t formally shown in Figure 6-4 it is used when a team elects to design a product around a particular part, such as a state of the art digital processor or new and novel signal processing integrated circuit chip. However, having preselected a part doesn’t negate the need to define the functions performed by the part and verify that the performance requirements and interfaces are satisfied.

6.4.1 Decompose to Lower-level Functions – Decomposition is accomplished by first arranging the top level functions in a logical sequence and then decomposing each top level function into the logical sequence of lower level functions necessary to accomplish the top level functions. Sometimes there is more than one “logical” sequence. It is important to examine the decomposed functions and group or partition them in groups that are related logically. This makes the task of allocating functions to physical elements easier and leads to a better design, as will be explained in a later section. When more than one grouping is logical then trade studies are needed. Although the intent is not to allocate functions to physical entities at this point functions should not be grouped together if they obviously belong to very different physical elements. The initial grouping should be revisited during the later task of allocating functions to physical elements and this process is described in more detail in a following section.

The DoD SEF has an excellent description of functional analysis/allocation and defines tools used to include Functional Flow Block Diagrams (FFBD), Time Line Analysis, and the Requirements Allocation Sheet. N-Squared diagrams may be used to define interfaces and their relationships. Spreadsheets are also useful tools and are used later in various matrices developed for validation and verification. A spreadsheet is the preferred tool for developing a functions dictionary containing the function number, the function name (verb plus noun) and the detailed definition of each function and its sub functions. The list of function numbers and names in the first two columns of the functions dictionary can be copied into new sheets for the matrices to be developed in the design synthesis task.

Spreadsheets do not lend themselves to identifying the internal and external interfaces as well as FFBDs so the FFBD is the preferred tool for decomposition. Time Line Analysis and the Requirements Allocation Sheet are well described in Supplement 5 of the DoD SEF and need no further discussion here. Similarly the Integration Definition for Function Modeling (IDEFO) is a process-oriented model for showing data flow, system control, and the functional flow of life cycle processes. It is also well described in Supplement 5 of the DoD SEF. The collection of documents, diagrams and models developed using all of the tools is the Functional view. The functional architecture is the FFBDs and time line analyzes that describe the system in terms of functions and performance parameters.

Although the FFBD is discussed in the DoD SEF there are some additional important aspects of this tool that are covered in the next posting.

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.