Functional analysis in systems engineering: from requirements to allocated functions

What functional analysis is

Functional analysis describes a system by what it does, before deciding what it is made of. Its result is a functional architecture: a set of functions, arranged in a hierarchy, with the order in which they run and the items they exchange. Each function traces back to the requirements it meets and, once the design takes shape, forward to the component that performs it.

The work answers four questions:

• What must the system do to meet its requirements?
• How does each function break down into smaller functions?
• In what order do the functions run, and what does each one need from the others?
• Which component performs each function, and is anything left uncovered?

The technique is old and still current. Functional flow block diagrams (FFBDsFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths.) and N2N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. charts came out of aerospace programs decades ago and remain the standard way to show functional flow and functional interfaces. Model-based tools keep the same ideas and store them as one connected model rather than as separate drawings.

Where it fits in the systems engineering process

ISO/IEC/IEEE 15288 describes the technical processes of a system's life cycle. Functional analysis sits between two of them: it starts from the output of system requirements definition and feeds architecture definition. In practice the order is:

1. Stakeholder needs and system requirements. The problem is stated and the requirements are written and reviewed.
2. Functional analysis. The requirements are turned into functions, a flow and functional interfaces. This is the logical view of the solution, still free of hardware and software choices.
3. Physical architecture. Components are chosen and the functions are allocated to them. Interfaces between functions become interfaces between components.
4. Verification planning. Each requirement gets a way to show it is met, recorded in a requirements verification matrix, and the function and component that meet it tell the test team where to look.

The steps are not strictly one after the other. The INCOSEInternational Council on Systems Engineering The professional society for systems engineering. It publishes the Systems Engineering Handbook. Systems Engineering Handbook describes the loops between them: analysing functions exposes missing or vague requirements (the requirements loop), and allocating them shows when a function is impossible or too costly for any candidate component (the design loop). Expect to revise the requirements while doing functional analysis, and revise the functions when the physical design changes.

Functions versus components

A function is a transformation: it takes inputs and produces outputs, or changes the state of something. A component is a physical or software element that does the work. Keeping the two apart is the point of the method: it lets you compare different designs that perform the same functions, which is what a trade study does.

Good function names are solution-neutral. Store Payload Data leaves room for flash memory, a solid-state recorder or a buffer in the camera; Write to Flash Card has already chosen the hardware. A useful test is to ask whether two quite different designs could both perform the function as named. If only one could, the name contains a design decision.

The top-level function and decomposition levels

Functional analysis starts with one top-level function that states the system's purpose, such as Perform EO-1 Mission. It is decomposed into first-level functions that together do everything the top-level function promises, and each of those can be decomposed again. The result is a function tree, numbered by level: F0 at the top, F1 to F11 below it, then F3.1, F3.2 and so on.

Some rules of thumb for the tree:

• Three to seven functions per level. Fewer suggests the level adds nothing; more makes the flow hard to read and usually hides a missing grouping.
• Each level is complete. The children of a function together do all of what the parent does, and nothing else. Anything a parent does that no child covers is a gap.
• One level at a time. Finish the flow and the interfaces of one level before going down. Detail at level three is wasted if level one is about to change.
• Stop when a function can be allocated. Decompose a function until it fits inside one component, or until the next level would only describe how that component works inside. Below that point the work belongs to the component's own design.

Functional flow: sequence, parallel, alternatives and loops

The function tree says what the system does; the flow says in what order. A flow is drawn for one parent function at a time and shows only its children. The FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths. notation uses a small set of constructs:

An OR branch may be empty: if no target is in view, do nothing is a valid alternative. A loop usually comes from a requirement that sets a rate or a repetition, such as repeat the imaging cycle each orbit. Label the return arrow with what drives the repetition, so a reader does not have to guess.

The flow is also where timing questions start. Once functions have durations, the same flow can be simulated to check whether a cycle fits in its time budget, which is one way functional analysis feeds performance requirements (the Monte Carlo guide shows how to treat those durations as distributions rather than single numbers).

Inputs, outputs and the N2 view

Functions exchange items: data, material, energy or signals. Each item is an output of one function and an input to one or more others. Naming these items is what turns a list of functions into an architecture, because every item that crosses between functions becomes an interface once the functions are allocated to different components. Those interfaces are what an interface control document later defines in detail.

The N2N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. chart (read "N-squared") shows these exchanges as a matrix:

• The functions sit on the diagonal.
• An item in row A, column B is produced by function A and used by function B.
• Cells above the diagonal carry items forward in the flow; cells below the diagonal are feedback.
• An extra row and column show items that come from outside the system or leave it.

The chart makes several problems visible at a glance: a function with an empty row produces nothing anyone uses, a function with an empty column needs nothing (rarely true), and a dense cluster of cells marks functions that belong in the same component. Feedback cells deserve a second look, because each one is a loop in the design that someone has to stabilise or schedule.

Allocation: requirements to functions, functions to components

Allocation runs in two directions, and both are traceability links in the model (the requirements traceability guide covers how such links support change impact):

• Requirements to functions. Each functional requirement is met by a function (in LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. terms the requirement is satisfied by the function). Performance requirements usually attach to the function whose output they constrain: resolve 4.5 m ground sample distance belongs with Capture Images.
• Functions to components. Each lowest-level function is performed by one component. A parent function is then performed by the components that perform its children.

Aim for each function to be performed by one component. A function shared by two components hides an interface inside it; decompose it until each piece has one owner. The reverse is fine: one component usually performs several functions.

Not every requirement maps to a function. Constraints such as operating temperature, mass, cost or a mandated standard apply to the system or to particular components, and they are allocated there directly. Mark them as constraints, so that a review does not count them as missing functions.

Checking completeness

A functional architecture is ready for review when these checks pass:

• Every functional and performance requirement is satisfied by at least one function, and every constraint is allocated to the system or a component.
• Every function traces to a requirement, directly or through its parent. A function with no requirement is either unnecessary or a sign of a missing requirement; decide which and act.
• Every lowest-level function is performed by a component.
• Every function appears in its parent's flow, and every flow starts and ends.
• Every input has a producer (another function or the outside), and every output has a consumer.
• Each level is complete: the children cover the parent.

The first three checks are mechanical and a modeling tool can list the gaps. The last three take judgment, and a review with the N2N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. chart and the FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths. side by side is the quickest way to make them.

Common mistakes

Worked example: functional analysis of a CubeSat

The example is EO-1, a fictional 6U Earth observation CubeSat in a 500 km sun-synchronous orbit. It carries a four-band push-broom camera, stores images on board, downlinks them over S-band and has them processed into products on the ground. It is the same system the end-to-end MBSE example project follows from stakeholder needs to verification, so the functions here connect to the requirements, interfaces and tests described there. Everything below is taken from that model as it stands; nothing was added for this page.

A spacecraft is a good test of the method because its functions fall into two kinds. The mission thread does what the customer pays for: receive commands, capture images, store them, transmit them and turn them into products. The support functions keep the spacecraft alive so the thread can run: power, attitude control and fault handling. A functional architecture has to show both, and how they depend on each other.

Download: EO-1 functional decomposition and allocation (Excel) or the same table as CSV. One row per function: ID, name, parent, inputs, outputs, allocated component, traced requirements and description, plus a second sheet with the five coverage gaps discussed below. Use it as a template for your own function list.

The requirements

The EO-1 System Requirements Specification (SRS-001) has 32 requirements in six sections: mission imaging, attitude control, electrical power, command and data handling, communications, and ground operations. Of these, 13 are labeled functional and 19 performance; seven more entries are section headings and an orbit assumption, which are not allocated. These are the requirements the rest of the example refers to:

Some of these are deliberately weak. 2.5, 3.5 and 6.4 are drafts with vague words or a TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date., and they are kept that way in the example because functional analysis is one of the places where such requirements get caught.

Decomposition and allocation

The top-level function is F0 Perform EO-1 Mission, from separation to image delivery. Eleven first-level functions cover it:

• After separation: F1 Separate and Detumble, F2 Deploy Solar Arrays.
• Support functions: F3 Generate and Store Power, F4 Determine and Control Attitude, F10 Enter Safe Mode.
• The imaging cycle: F5 Operate Imaging Orbits, which repeats F6 Receive Commands, F7 Capture Images, F8 Store Payload Data and F9 Transmit Payload Data each orbit.
• On the ground: F11 Process and Deliver Images.

Two of them are decomposed one level further, because their work is split across parts with different owners. Power becomes F3.1 Convert Sunlight to Power, F3.2 Store Battery Energy and F3.3 Regulate Bus Power; attitude becomes F4.1 Estimate Attitude, F4.2 Compute Control Torques, F4.3 Drive Reaction Wheels and F4.4 Unload Wheel Momentum. That gives 18 functions in all. The others stay at the first level because each already fits inside one component.

Read the table for what it says about the design:

• Parents go to subsystems, children go to parts. F3 is performed by the EPSElectrical Power System The subsystem that generates, stores and distributes electrical power, such as solar arrays and batteries. and its children by the solar arrays, the battery pack and the power distribution unit. When the battery supplier changes, the model shows exactly which function and which requirement (3.2 Battery Capacity) move with it.
• A requirement with two owners is flagged. 2.3 Detumble is satisfied by both F1 Separate and Detumble and F4.4 Unload Wheel Momentum. Both claims are reasonable: F1 is the mission phase, F4.4 is the mechanism (the magnetorquers do the detumbling). Decide which one carries the requirement for verification, or the test team will plan the same test twice or not at all.
• The performer should match the subject of the requirement. F6 Receive Commands is performed by the UHFUltra High Frequency Radio frequencies from 300 MHz to 3 GHz, often used for spacecraft command links. transceiver, yet it carries 4.2, which says the C&DHCommand and Data Handling The spacecraft subsystem that runs the flight computer, handles commands and stores and routes data. shall execute stored commands on time. The radio receives commands; the flight computer schedules and executes them. That mismatch is the first sign of a missing function, and the N2N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. view below confirms it.

The flow

After separation and array deployment, power generation and attitude control start and run in parallel. The imaging cycle then repeats each orbit: receive commands, capture, store, and either transmit the data (nominal) or enter safe mode (fault). Products are processed on the ground. In the compact flow notation:

F1 -> F2 -> AND(F3 | F4) -> LOOP[F5, return="next orbit"](F6 -> F7 -> F8 -> OR(F9 | F10)) -> F11

Three modeling decisions are visible here:

• The loop is a function. F5 Operate Imaging Orbits is drawn as the dashed frame around the loop rather than as a block. It carries 1.6 Revisit Time and 1.7 Mission Lifetime, which are requirements on the repetition itself, not on any single step.
• Support functions have their own flows. F3 and F4 appear once at this level, but each has a flow inside: F3 repeats F3.1 → F3.3 → F3.2 each orbit, and F4 repeats F4.1 → F4.2 → AND(F4.3 | F4.4) each control cycle. Drawing them inside the imaging loop would suggest they stop between passes, which they do not.
• The fault branch has no way back. After F10 Enter Safe Mode the loop simply continues with the next orbit. Nothing in the flow brings the spacecraft out of safe mode, which is the functional side of the vague requirement 2.5.

A reviewer should also ask about F11. It sits after the loop, so as drawn the ground processes images once, when the mission ends. Requirement 6.2 asks for products within 6 hours of each downlink, so product processing belongs inside the cycle, or in a parallel ground-segment loop. A diagram this small is easy to read, and that is when errors like this are cheapest to fix.

Functional interfaces

The N2 chart of a parent function shows what its children exchange. The power functions make a clear example:

• Array Power Output and Battery Discharge Power sit above the diagonal: both flow forward into F3.3 Regulate Bus Power, which is why the power distribution unit is the hub of the EPS.
• Battery Charge Power from F3.3 to F3.2 is below the diagonal: feedback. The battery is charged by the same regulator it feeds, a loop that the charge controller has to keep stable and that the 3.3 depth-of-discharge limit constrains.
• Safe Mode Commands enter from outside and Power Telemetry leaves. Both connect to F10 Enter Safe Mode at the level above: the power functions report the bus state, and safe mode sheds loads in response. That pair is a functional interface between two first-level functions, and because F10 is performed by the C&DH and F3.3 by the power distribution unit, it becomes the physical link between them (in the model, IF-09 Power Telemetry Link).

The N2 chart of F0 shows the mission thread the same way. Tracing items across the eleven first-level functions gives this:

Capture, store and transmit chain cleanly. The two breaks are the interesting part. Command packets leave F6 and a command schedule arrives at F7 with nothing in between: the step that validates the packets and loads the time-tagged schedule is missing from the function tree. It exists elsewhere in the model, as OPS.3 Load Command Schedule in the operations scenario, performed by the C&DH, which is also where requirement 4.2 belongs. Likewise the image data package leaves the spacecraft and raw image files appear at F11: receiving the pass at the ground station is not a function in the tree, although 5.4 Daily Data Volume, a requirement on the ground segment, is allocated to F9 on the spacecraft. In both cases the fix is the same: add the missing function (for example Load Command Schedule under F6 and Receive Downlink before F11), move the requirement to it, and allocate it to the component the requirement names.

Coverage

Every one of the 18 functions satisfies at least one requirement, so the second list is empty. The first is not:

Each of the five gaps has a different cause, and each needs a different fix:

Together with the two breaks in the N2 view, that is seven findings from one pass over a model that looked complete. Four point to missing functions (two of them behind vague requirements), two are allocation errors, and one is a requirement that is not a function at all. None of them needs hardware to find, and all of them are cheaper to fix now than at integration.

Try it in Holarch

Holarch is an MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. tool built on the Lifecycle Modeling Language (LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models.), where functions are Actions and components are Assets. The example above is the CubeSat EO-1 demo project: create it with Manage Projects → Project Files ▾ → New Demo Project, then open Behavior → Functional Analysis. To build your own:

1. Write the requirements in a requirements document and label them Functional Requirement or Performance Requirement, with each performance requirement under the functional one it constrains.
2. From the document, choose View ▾ → Open In ▸ Functional Analysis, then Extract by Rules… on the Functions tab. Review the proposed functions, set the top-level function's name, make sub-functions with Parent, and click Apply. See derive functions from a requirements document.
3. On Flow & FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths., arrange the flow with Wrap in AND, Wrap in OR and Wrap in LOOP, or type it with Edit as Text… in the notation shown above. Open FFBD draws the diagram.
4. Add the items each function generates and receives, then switch a parent function's diagram to N2N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. Diagram with the diagram type selector.
5. Link each function to its component with performed by in the inspector's Trace section, and tick Subsystem to show the components in the allocation table.
6. Open the Coverage tab to list unallocated requirements and functions without requirements, and export the tables (CSV, XLSX, DOCX) or the Allocation Report (Word).

The same flow opens as an Action Diagram, where Arrange ▾ → Generate Asset Diagram builds a first physical architecture from the performers and the items they exchange. The Functional Analysis docs cover every control.

Where to go next

• Behavior in Holarch: function hierarchies, FFBDsFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths., action diagrams and simulation.
• Architecture in Holarch: assets, allocation and the physical interfaces that follow from the functional ones.
• Functional Analysis docs: the page, the flow notation and the reports.