4.1 - Functional Analysis & Allocate Requirements

Functional Analysis

Functional analysis is the next step in the Systems Engineering process after setting goal and requirements. Functional analysis divides a system into smaller parts, called functional elements, which describe what we want each part to do. We do not include the how of the design or solution yet. At this point we don't want to limit the design choices, because it might leave out the best answer. In later steps we will identify alternatives, optimize them, and select the best ones to make up the complete system. The name Function comes from mathematical functions, which act on an input value and produce a different output value. Similarly, in the Systems Engineering method, functions transform a set of inputs to a set of outputs.

Functional Diagrams

There are different ways to record and display the functions which make up a system design. A Functional Flow Block Diagram is a popular graphical method. It uses a rectangular box to represent each function (Figure 4.1-1). Arrows represent flows or states of any type to and from the function. The flows connect to other functions or to outside the system. By convention, inputs are shown on the left, and outputs are shown on the right. The function box itself transforms the inputs to the outputs. Mechanisms are the entities which perform the function, but which are not themselves transformed. They are normally shown by arrows at the bottom, and typically represent use of a device. Controls are inputs which command, limit, or direct the operation of the function, and are normally shown at the top. Function names are typically made up from an action verb and noun, like "chop wood", which summarizes the task, and are shown inside the box. A function number is usually included to uniquely identify it, since similar names may end up being used in different places in a project. The most common numbering method takes the number of a parent function, and adds a digit to that number for each sub-function. Thus 2.2 has sub-functions 2.2.1, 2.2.2, etc. This allows tracing where a function is in the overall system simply by looking at its number.

The diagrams can be sequential, such as showing the steps of a production process; parallel, where different activities can happen at the same time; or looping, where there is feedback or iteration. More generally, the output of any function can lead to an input to any other function.

Top Level Diagram - In designing a factory, we are generally concerned with the production function. The placement of the system boundary for design and analysis purposes, however, can be different. Figure 4.1-2 shows a top-level block diagram for a complete location from the MakerNet example. It includes a Production function, where most of the manufacturing takes place, a Habitation function, which are the homes and other buildings the owners live and work in, and a Transport function that moves physical items from place to place. In this case the factory delivers products to a network of people who own and operate the equipment, and their associated community. It may also take wastes from them to be reprocessed. Since the owners of production are the same group as uses the habitation and transport, this is a sufficiently integrated situation that it makes sense to place a system boundary around all of the relevant functions. A factory which only produces products for sale does not have as strong a link to the end users, so in that case you can exclude anything outside the production function. The inputs and outputs from outside the selected system boundary are shown to the left and right of the diagram, and are broken down by type. Logically this diagram is identical to one at an even higher level, where all the inputs to the location are represented as a single flow arrow, like in Figure 4.1-1, and the entire project is reduced to a single box with no internal details. Showing all the details of a project at once in a single diagram makes it too large and complicated to understand. Instead the complexity is reduced by presenting multiple levels of detail, where a box at one level represents a more detailed diagram at the next level. In this way, systems with any level of complexity can be described.

Flow Arrows - Flow arrows represent a state of an item or the movement of any kind of resource between functions. A raw metal casting from a foundry process and a machined part made from that casting are different states of a part being made. The casting would be an input and the machined part would be an output from a "Machine Parts" function that converts one to the other. Resources are things like energy and human labor which get used up as inputs, or created as outputs from functions. Flows may divide and merge between endpoints, but it should be understood that mathematically both sides of the junction are equal. Otherwise you have spontaneous creation from nothing, or an unaccounted for source or disposition of some item. When flows on lower level diagrams show more detailed components, the combination should therefore be identical to a single flow that represents them on a higher level diagram. Flows, like functions, are given names and unique numbers to identify them. Both the flows and the function boxes will be further broken down into more detail as the design progresses.

Representing Functional Relationships - Figure 4.1-2 does not show all the interior flows connecting the function boxes for two reasons. The first is that we have not defined them at this point of the design. The second is it would make the diagram unreadable because there would be too many lines. Higher level diagrams tend to have more flows because they are showing more of a system at once. One way to handle this complexity is to use large drawings with multiple sheets. It is understood that each sheet only shows a subset of the flows to the same functions, to make it more readable. Another way to deal with complexity is to track the flows in spreadsheets and data tables, which can have as many entries as needed, one for each flow. Whatever method is used to display and track the functions and flows, they represent the same relationships between parts of a system. Block diagrams are just a convenient visual starting point to understand and analyze a system.

Representing Time - Within a given diagram, a flow connecting two functions indicates the second function logically follows the first one. As a minimum it means the second function cannot start any earlier than the start of the first one. They can, however, start at the same time. For example, a portable generator and whatever equipment it powers may be started together, but the equipment can't be started before the generator, because one of it's necessary inputs, namely electricity, is not available until the generator is working. Sometimes a series of function boxes represents a strict time order, where one has to be completed before the next can start, but this is only necessary when flows include states of the same item. For example, for an airplane, the function "Take Off from Runway" has to be completed before "Fly to Destination" and "Land at Destination", because the inputs and outputs are the same airplane, in the states of "Airplane at Departure Airport", "Airplane in Flight Leaving Departure City", and so forth. When there is a loop in flow diagrams, such as a water treatment unit that takes dirty water from homes and sends back clean water, the start-up sequence should be accounted for in the design. In this case, since there is no dirty water to process at first, a starting supply of clean water must be fed into the loop at some point.

A different representation of time is required when the system as a whole evolves from one stage to another, and new functional elements and flows are added. One way to do this is to prepare different versions of the same diagrams for each stage, and marking the new items that were not present in the previous stage. This can be by highlighting or coloring the new items. More complex system representations, like simulations, can have the new items appear at the appointed time.

Beyond Flow Diagrams - A function or flow name used in a diagram is not enough to describe exactly what the item is supposed to be. It is merely a label for a part of the design. As additional details are worked out, they can be included as notes to the diagram, or in a variety of separate documents or files. Any amount of additional data about the function can be linked to it by using the same identifying name and function number. The unique tracking label helps organize all the data for a project in a consistent system. Functional Descriptions expand on the diagram labels, and are often included on the diagram sheet itself, or supplementary sheets along with the diagrams. Descriptions can be as long as necessary, but are typically a few sentences to a few paragraphs. Mathematical models, design drawings for different options, or any other data that relate to the function are also marked with the same name and number to identify them.

Analysis Process

The purpose of functional analysis is to divide a complex system into smaller and simpler parts, so that eventually they can be individually designed. One way to divide into parts is along the time axis. A large project can be divided into phases that are sequential in time, where each phase adds new capabilities or hardware. A common example is developing real estate, where each phase develops different parts of a property. Technical projects are often divided into several design phases, production, testing, and delivery, where milestones for a given phase must be completed before going on to the next phase. Within a part of a system, some tasks must happen in a sequence or process in time order. So each step in the sequence can be identified as a function. Another way to divide functions up is when they do different things at the same time, but have inputs and outputs that connect them. So the control electronics for a robot arm may send power to the motors, and read joint angles from a sensor. The electronics is different enough from the motor and joint bearings that they can sensibly be treated as different functions, with different design issues to solve.

There is no single answer for how best to divide up a system. Often different alternative designs will require different functional breakdowns. The designer should use good judgement to break up a system into elements that have internal relatedness, and that follow a logical flow from one to the next. A function should contribute to meeting some part of the overall system requirements, or else you can question the need for that function. In our MakerNet example, the three top functions serve different purposes: changing things (Production), moving things (Transport), and using things (Habitation). The owners/end users, who are the reason the MakerNet is built, are included in the system design because they are strongly connected. They are expected to be the human operators of the system, their waste products are intended to be recycled, and the homes and commercial buildings may be physically connected to power sources and other utilities from the Production function. An Industrial Production type factory which is only designed to make items for sale would have less interaction between production and the customers. In that case you can reasonably draw the system boundary around only the production portion, and leave the end users and delivery as external flows.

The functional analysis, like all parts the design process, is not done once and then finished. It will evolve and be revised as the design progresses. Diagrams and their related records represent the current state of the design at some point in time. Version numbers and dates help identify the most current state, and change histories explain why it was changed. In a small project or early stage of a larger one such formal tracking is not as necessary. In a large project, where each person can only be familiar with the parts they are working on, formal tracking helps keep the overall work coordinated, and is much more important.

Functions do not have a one-to-one relationship with hardware. A given hardware item may perform multiple tasks, and a given function may need multiple hardware items in different places to be completed. Rather, functions are mental abstractions. They represent pieces of the intended purpose the system is built for. When carried to a sufficiently detailed level, the pieces are then simple enough to design individually.

Analysis Example

We will use as an example of next-level detail the Provide Production Capacity function for a MakerNet location.

Function and Flow Numbers - A name and a number are what identifies a particular function or flow within a system design. The numbers are intended to be unique, and are made of a series of components, each containing numbers and letters, which are separated by periods. The components represent hierarchical levels in the system design. Our example uses a longer function number than is needed at the moment, to allow for future design work which may be needed at higher levels, without having to renumber things later. Renumbering is both extra work, and can lead to confusion. So a little thought and planning to reserve space in the numbering system is a good idea. The five component number "F.2.1.1.1" is used for the Provide Production Capacity function as a whole, and the initial F indicates it is a function. External Flows, Controls, Inputs, Mechanisms, and Outputs use E, C, I, M, and O as their first component label.

Continuing this example, the 2nd component indicates the project-level phase, with 1 for the Technology Development phase before the first full factory unit, and 2 for first generation units at actual locations. Higher numbers would be used for later generation designs. The third component in this case indicates the design environment, since the design will change according to the outside conditions. Here 1 represents a moderate operating environment. More difficult or extreme environments would get higher numbers. The fourth digit is a location serial number, which is 1 because this is the first project location to be designed. Other locations would get sequential numbers. So F.2.1.1 identifies the first full MakerNet project location. The location will expand in a series of construction phases. When we consider these phases, we will attach letters to the location serial number, thus phase 1A, 1B, etc. At the moment, we are considering the functions in general, without regard for construction timing, so the 4th component is just a 1. The final .1 represents the Provide Production Capacity function for the location. Note this is only an example of how a function number would be assembled, and not the actual components for a particular project.

Next Level Function Identification - Figure 4.1-3 shows the next level of sub-functions beneath Provide Production Capacity. The particular set of sub-functions is decided by the designer, so other versions are possible, but here we follow the division of the reference architecture. In general the set of sub-functions should be logical, and divide the larger function into different tasks which are internally related in themselves, and distinct from each other. In this version of the diagram they are laid out on a diagonal for convenience in drawing flow arrows between any two of them. However, The placement and numbering order of the function boxes can be whatever is clear and logical. Placing them more or less in the order the tasks are performed allows an output arrow from one task to connect to the input side of the next in left to right order, so that kind of layout is often used.

Function blocks may not occur strictly in time sequence. In fact, any cycle loops, such as when waste products are recycled to an earlier stage, means they cannot be put in definite time order. Therefore the layout on the diagram should be whatever makes the most sense in the circumstances.

Output Matrix - Figure 4.1-4 shows another way besides arrows to display flows between functions. This method works for situations where too many arrows would be confusing. The functions themselves are placed on the diagonal of a grid. Any grid rectangles above the diagonal indicate a flow from the function in the same row on the left to the function in the same column below. Rectangles below the diagonal indicate a reverse flow from the function in the same row on the right back to the function in the same column above. The grid method is not as good at showing outputs that return to the same function as they start, or the relationship of control and mechanism inputs. It is helpful as an organized way to consider the relationships among the functions. Each box in the grid can be examined in turn, with the question "Is there anything that goes in this direction between these two functions? If not, that box can be marked with an "X". If there is, the flows can be entered in that box, and worked out in more detail later.

Allocate Requirements

The third major step in the systems engineering process is Requirements Allocation. To ensure all the top level requirements will be met, they are assigned to one or more functions to implement. The assignment may be the whole requirement, or by dividing it into parts and then assigning the parts to separate functions. For example, US regulations require airline seats to withstand 16 g's of forward acceleration during impact. This may be allocated to the Restrain Passenger, Support Seat Loads, and Support Floor Loads functions, which are implemented by the seat belt, seat structure, and floor structure design elements. Time limits and other parameters are also passed down to lower tier functions. For example, an airplane may have a requirement that ground maintenance not exceed 4 hours on average per flight. This requirement may be allocated in part to Provide Propulsion (engines) and Support Flight Loads (structure) functions, even though those functions are not used during maintenance. The design of the airplane engines and structure must then meet the maintenance time assigned to them.

Allocated requirements are documented in lower level requirements documents or specifications that apply to parts of a project. Traceability is being able to trace the links between lower and higher level requirements and the logic of how they were generated. At the lowest level, a subset of the requirements are assigned to a particular hardware or software item, skilled staff, procedures, facilities, interfaces, services, or other individual elements of the final system. At that level, the subset of requirements and the system element are simple enough to actually design for. With a complex project, software tools become very useful for the requirements allocation and tracking process. They can help manage the mass of details, and ensure everyone on a project has the most current information.

Requirements allocation is not a one-time task, although it is weighted towards the early stages of a project. As design and testing make progress, they can provide feedback and adjustment to the assigned requirements. These changes propagate to higher levels, and by tracing back their impacts, you can determine how they affect the top-level goals of the project. Changes can also have sideways effects at the same level. For example, an increase in weight of one part of a system may require weight-saving efforts elsewhere to not affect top level performance.