Introduction

• The Functional Analysis Report is one of the most critical and challenging components of your capstone project. It involves decomposing the system's functions to a level where a developer can design and implement the system at acceptable risk.

• The FAR is an interim artifact during the execution of the Concept Definition life cycle phase (Kossiakoff SE P&P 3rd edition Chapter 7). 

• Below are key guidelines and common pitfalls to avoid as you work on your FAR.

• After your FAR is approved, assuming you are performing well against your initial plan, reach out to me to receive potential outbrief timeslots: colson8@jhu.edu 

Start with the Use Cases (CONOPS) and Context Diagram:

Your Use Cases and associated context diagram are the foundation for developing your functional domain. The Use Cases (CONOPS in your RAR) contains the scenario walkthrough steps your system performs as it executes one or more missions. Each of these steps contains functions (aka activities). We can pull these functions into the functional domain here in the form of FFBDs or activity diagrams. Use Cases also either directly state or imply the system's inputs and outputs during the walkthroughs. These inputs and outputs should be brought into the functional domain as well. The context diagram is the 'cheat sheet' for where these I/Os are: it shows all inputs and outputs to/from the system to/from the externals.

If You're Using Catia Magic:

Use Activity Diagrams to capture your functions and functional flow / interactions. Do NOT use Block Definition or Internal Block Diagrams to depict functional flow. You may use BDDs to capture the functional hierarchies and generalization relationships, but most of your work will be using activity diagrams.

Consistency Across Levels:

Ensure 100% consistency between parent and child functions. If the parent function shows three inputs and two outputs, these must be represented at the child level as well. This consistency is crucial for maintaining the integrity of the functional architecture.

The following illustration shows this consistency, focusing on Function 1.1 (color coded):

Inputs and Outputs for Every Function:

All functions must have at least one input and one output. In SysML, remember that control flows do not count as inputs or outputs—they are communication features for the engineering team. Only object flows are considered valid I/Os.

Verb-Object Syntax:

Functions should be named using verb-object syntax, such as "Provide Access," "Calculate Speed," or "Transmit Data." The object should not be a physical solution.

Functional Flow Block Diagrams:

Use functional flow block diagrams (FFBDs) or Activity Diagrams (SysML) to depict control logic, including decision points and parallel processes. These diagrams should be used to capture the sequence and flow of operations within the system.

Decompose to Appropriate Levels:

Decompose functions to a level where the system can be designed with acceptable risk. This typically means breaking down to at least the third level but can go deeper depending on the system's complexity. Ask yourself if a developer can take over from this point with minimal risk.

Tracing Back to Requirements:

All functions should be traceable back to one or more requirements from the RAR. If they cannot, then now may be the time to ADD more requirments to your requirement set (draft A-Spec). In Catia, create a Dependency Matrix (it's in the Analysis diagrams section when you R click). Row = Requirement. Column = Activity.

Creating N2 Diagrams in Catia Magic

Catia Magic does not have a built-in N2 diagram, so we must execute a workaround by simply copying an activity diagram, removing the logic structure (decision, fork nodes, etc) and re-arranging the functions such that they are arranged diagonally. 

Recall the rules for N2 diagrams: 

1. All external inputs enter the diagram ONLY from the TOP. 

2. All external outputs exit the diagram ONLY to the RIGHT. 

3. Internal inputs enter a function either from the TOP or the BOTTOM. 

4. Internal outputs exit a function either from the LEFT or the RIGHT. 

See illustration below for the ATM. 

Common Pitfalls

Inconsistent Abstraction Levels:

Ensure that inputs and outputs are consistently represented at all levels of decomposition. Missing or misaligned I/Os between parent and child functions are a common mistake. See above.

Loose Coupling and Tight Binding:

Avoid creating a loosely bound and tightly coupled architecture where functions are grouped arbitrarily. This often leads to inefficiencies and difficulties in system integration. Be prepared to discuss this issue during your presentation if it occurs. At the very bottom of this page is the segment from an MBSE textbook that addresses loose coupling and tight binding. Also check out Kossiakoff Chapter 11.

Here is a link to a 2-page explanation of coupling and binding from an MBSE textbook.

Arbitrary or Solution-Based Functions:

Avoid functions that are not based on clear requirements or mission needs. Functions should not dictate internal system solutions unless absolutely necessary due to technological constraints.

Insufficient Decomposition:

Ensure that your functional architecture is decomposed to a level that provides enough detail for system development. Avoid stopping at a high level that leaves too much room for interpretation.

Ignoring Software Functions:

Don’t overlook the software components of your system. Even if the focus is on hardware, software plays a critical role and must be represented in the functional domain.

Decomposing Off-the-Shelf (COTS) Elements:

Do not decompose COTS elements. Focus on how these elements interact with your system rather than their internal workings.

Steve Biemer's FAR Checklist

1. A functional tree with at least two levels of detail. For high-risk or critical areas, decompose down one or two more levels as appropriate. These are areas in your architecture that are the primary purpose and focus of your overall system. For example, with an automated teller machine, the functionality of providing cash upon request autonomously should be the primary focus, and I would expect the functional architecture to dive down to Tier 3 or 4 for this primary function.

2. List (or table) of functions (in hierarchical order). As explained above, the hierarchy should be at least two levels deep—a top-level of 5-8 functions and then each function broken down at least one additional level. The upper tier in the functional domain typically reflects the sequence of functions that occur in a general mission: prepare for mission, conduct mission, and recover from mission. Then each of these can be decomposed. Remember syntax: simple verb-object. Once again, I recommend three or four levels depth for your high-risk and critical functions. Some Functions can remain at the upper tiers without being decomposed if they are relatively mundane or standard functions that a design engineer can easily resolve using their own best practices For example, with the ATM, receiving input from the user likely doesn't need to be decomposed, as this would be directly allocated to the user interface on the physical side and left to the design teams to figure out. 

3. Context Diagram, updated from the Proposal. This should include all external entities (human and non-human actors which interact with the system). All inputs and outputs should be labeled with what is passed into and out of the system and should include as much detail as is possible and reasonable. The context diagram at the system level acts as the starting point for your tier 1 function. The tier one function should be the primary purpose of your system. This is typically very generic and broad. With the ATM, the tier 1 function is to provide ATM services. As above, tier 2 would be to prepare for conducting transactions, followed by conducting transactions, followed by finalizing transactions.

4. Diagrams of functions. You should have one top-level diagram and one functional diagram for each top-level function. The diagram type is up to you—example types are Functional Flow Diagram, Enhanced Functional Flow Diagram, Functional Block Diagram, IDEF0 diagram, or the Activity Diagram. Overachievers: Include additional functional diagrams as needed to describe the behavior of your key system functions. What is important is to include logic flow\ sequence of events and labeled inputs and outputs (materials, energy, data, and signals).

5. Functional N2 diagrams are required for the top-level functions and for each Level 2 function. Functions are on the diagonal, and what is passed from each function to each function is in the cells. 

*Note-- functional interactions need to be understood beyond simply a one-word descriptor in a diagram! In other words, don't just put “energy”. Instead, what kind of energy is it? For the ATM, energy being supplied to the ATM would be labeled “external energy”. I would not call it “120 Volt AC energy.” This is too detailed and drives physical solutions. What if we wanted to deploy our ATM in other parts of the world? Now we just engineered it so it cannot; or requires special adaptors.

6. A Traceability matrix that maps functions to requirements. All level 2 functions need to be mapped/trace to requirements. Constraint requirements do not need to be mapped as they apply to the entire system. Overachievers: Make sure that you trace in both directions—functions to requirements and requirements to functions. 

7. System states and modes described (if applicable). See Wasson SEAD&D 2nd Ed Fig 7.12 and ATM example (below)

8. Overachievers: additional requirements, if any. Note: After thinking about the functions, do you need to revise, add, or update any of your requirements? 

FAR Checklist Credit: Steve Biemer