Question 1: What is the definition of the Functional Flow Block Diagram?

The Functional Flow Block Diagram (FFBD) is a graphical representation used in system
engineering to describe the functions of a system and how they relate to each other. It provides
a top-level view of the system's functions and the interactions between those functions, which
helps engineers to better understand the system and to identify potential design flaws. The
FFBD consists of a series of blocks, each representing a function, connected by arrows that
show the flow of inputs and outputs between them. The blocks can be decomposed into sub-
blocks to represent more detailed functions, and the arrows can also be labeled with the data or
signal that is being transferred between blocks. The FFBD is typically created during the early
stages of system design and can be used to guide the development of more detailed design
documents, such as the system specification and the detailed design specification. It is also
useful for communicating the system's design to stakeholders who may not have technical
expertise, such as project managers and customers.
Question 2: What is the purpose of this systems engineering process activity?
The purpose of the systems engineering process activity is to ensure that a system is designed,
developed, and delivered to meet the needs and expectations of its stakeholders. The systems
engineering process is a comprehensive and iterative approach that involves defining system
requirements, designing the system architecture, implementing the system, testing and
validating its functionality, and verifying that it meets the original requirements. The systems
engineering process activity involves several key steps, including:

● Requirements analysis
● System design
● Implementation
● Testing and validation
● Verification and validation
● Deployment and maintenance

Question 3: Why are System requirements allocated and defined in enough detail?
System requirements are allocated and defined in enough detail during the systems engineering
process activity to ensure that the system meets the needs and expectations of its stakeholders.
The allocation of requirements involves breaking down the high-level requirements into smaller,
more specific requirements that can be implemented at the subsystem or component level. This
helps to ensure that each subsystem or component is designed and developed to meet a
specific set of requirements, which are necessary for the system as a whole to meet its overall
goals. Defining requirements in enough detail is important due to following reasons:

● Ensuring completeness
● Facilitating communication
● Facilitating design decisions
● Supporting testing and validation
● Managing risks
Question 4: Why do Systems Engineering practitioners think functional architecture is a
top-down decomposition approach?
Systems Engineering practitioners consider the functional architecture as a top-down
decomposition approach because it involves breaking down a system's high-level functions into
lower-level functions, in a hierarchical manner, to define the system's overall behavior and
functions. The functional architecture is created during the early stages of the system design
process and is used to identify the key functions and interactions between different subsystems
and components of the system. This approach enables the practitioners to identify the system's
most critical functions and requirements and allocate them to appropriate subsystems or
components for further design and development. The top-down decomposition approach of the
functional architecture involves starting with the system's high-level functions, which are then
decomposed into more specific functions, and these are further decomposed into lower-level
functions until the desired level of detail is achieved. This approach enables the practitioners to
clearly define the system's functions and requirements and to ensure that each subsystem or
component is designed and developed to meet a specific set of requirements, which are
necessary for the system as a whole to meet its overall goals.
Question 5: . What is the purpose of the functional flow block diagram (FFBD)?
The purpose of the Functional Flow Block Diagram (FFBD) is to provide a graphical
representation of the functions performed by a system and how they are interrelated. The FFBD
is used in Systems Engineering as a tool to help engineers better understand the system,
identify potential design flaws, and communicate the system's design to stakeholders who may
not have technical expertise. The FFBD consists of a series of blocks, each representing a
function, connected by arrows that show the flow of inputs and outputs between them. The
blocks can be decomposed into sub-blocks to represent more detailed functions, and the arrows
can also be labeled with the data or signal that is being transferred between blocks. The FFBD
is typically created during the early stages of system design and can be used to guide the
development of more detailed design documents, such as the system specification and the
detailed design specification. It is also useful for communicating the system's design to
stakeholders who may not have technical expertise, such as project managers and customers.
Question 6: When we describe system requirements in functional terms what is that
procedure development called?
When we describe system requirements in functional terms, the procedure development is
called Functional Requirements Development. Functional Requirements Development is the
process of defining the system requirements based on the functions that the system must
perform to meet the needs and expectations of its stakeholders. The functional requirements
are typically described in terms of the inputs, processes, and outputs that the system must be
able to perform. During the Functional Requirements Development process, Systems Engineers
work with stakeholders to identify and define the system's functions and requirements, and to
ensure that the requirements are complete, unambiguous, and verifiable. The requirements are
documented in a Requirements Specification, which forms the basis for the system design and
development.
Question 7: This is the Systems Engineering Process. Please explain each step in this
process.
Problem Definition (Analysis):
Problem definition or analysis is the process of identifying and defining the problem that the
system is intended to solve. It involves understanding the needs and expectations of the system
stakeholders, analyzing the current situation, and identifying the gaps or problems that need to
be addressed. The problem statement serves as a foundation for the subsequent steps in the
Systems Engineering process, including requirements development, design, implementation,
and validation. The goal is to identify key issues and challenges to address in the system design
and development.
Conceptual Design (Synthesis):
Conceptual design or synthesis is the process of developing an initial high-level design for the
system based on the requirements defined during the problem definition or analysis phase. This
involves exploring alternative system architectures, conducting trade studies to evaluate
different design options, and selecting a preferred design concept. The output of this phase is a
Conceptual Design Report that describes the system architecture, key design decisions, and the
rationale for selecting the chosen design concept. The conceptual design or synthesis phase
provides a foundation for the subsequent detailed design and development phases of the
Systems Engineering process.
Preliminary Design (Evaluation):
Preliminary Design is the process of further developing and refining the design of the system
based on the conceptual design or synthesis. This involves creating more detailed designs for
each system component, conducting feasibility studies to assess the technical and economic
viability of the design, and evaluating the design against the system requirements. The output of
this phase is a Preliminary Design Report that documents the design decisions made and the
analysis performed to support those decisions. The Preliminary Design phase helps to ensure
that the system design is technically feasible, meets the requirements, and can be implemented
within the constraints of the project schedule and budget.
Design Decision (Decision):
In the Systems Engineering process, design decisions are the choices made during the design
phase of the system development. These decisions are based on a range of factors, including
the system requirements, the results of trade studies and analysis, technical feasibility, and cost
and schedule constraints. Design decisions may include selecting a specific design concept,
choosing the components and subsystems to be used in the system, and determining how the
system will be manufactured, tested, and maintained. Design decisions are documented in the
design documentation and serve as a basis for the subsequent development and
implementation of the system.
Detailed Design (Action):
Detailed Design is the process of creating a detailed description of the system components and
subsystems based on the preliminary design. This involves developing detailed designs for
each component, specifying the materials, dimensions, and tolerances, and documenting the
interfaces between components. The detailed design phase also includes creating a bill of
materials, selecting vendors, and creating manufacturing and test plans. The output of this
phase is a Detailed Design Report that provides a comprehensive description of the system
design, including all necessary specifications and documentation to enable the construction,
testing, and maintenance of the system.
Production, Integration and Test (Build & Verify):
Production, Integration and Test is the process of constructing, integrating and testing the
system components and subsystems according to the detailed design. This involves procuring
and assembling the necessary components, testing each component to ensure they meet the
specifications, and integrating the components into the system. The system is then tested as a
whole to verify that it meets the system requirements. Once the system passes all the tests, it is
delivered to the customer or user. The Production, Integration and Test phase is the final stage
of the Systems Engineering process and ensures that the system is fully functional, meets the
requirements, and is ready for operational use.
Question 8: How would you change the Systems Engineering Process to make it more
robust?
To make the Systems Engineering process more robust, several improvements could be made,
such as:
● Emphasizing the importance of risk management throughout the entire process.
● Incorporating more feedback loops to ensure continuous improvement and refinement of
the system design.
● Encouraging greater collaboration between all stakeholders, including users, developers,
and suppliers.
● Integrating more formal verification and validation activities to ensure that the system is
meeting the requirements at each stage.
● Implementing more agile and iterative development practices to allow for more flexibility
in responding to changing requirements and constraints.
Question 9: Please explain the following diagrams:
Diagram 1:
Functional analysis and allocation is a key step in the Systems Engineering process that helps
to define the functions that the system must perform and allocate those functions to specific
components or subsystems. In this block diagram, there are three inputs: controls, inputs, and
enablers. The controls are the criteria used to evaluate the system's performance, such as
safety, reliability, and efficiency. The inputs are the data, energy, and material required to
perform the system's functions, and the enablers are the resources required to support the
system, such as infrastructure, tools, and personnel. The functional analysis and allocation
block takes these inputs and applies a top-down decomposition approach to break down the
system functions into smaller, more manageable components or subsystems. Each component
is then assigned specific functions based on its capabilities and requirements. The output of this
block is a functional allocation matrix that shows how the system functions are allocated to each
component or subsystem. This process helps to ensure that the system is designed to perform
its required functions efficiently, effectively, and safely. It also helps to identify potential
problems or issues early in the design process, which can be addressed before the system is
built. Ultimately, the functional analysis and allocation process is critical to the success of the
Systems Engineering process and the development of a robust and effective system.
Diagram 2:
In this diagram, there are three blocks arranged in a top-to-bottom approach, and the next block
is intersected with the previous block. The top block represents the Requirement Analysis,
which is the first stage of the Systems Engineering process. It involves identifying and analyzing
the user and system requirements to define the system's functions and performance criteria.
The second block represents Functional Analysis, which is the process of breaking down the
system functions into smaller, more manageable components or subsystems. This block is
intersected with the previous block as the functional analysis is based on the requirements
identified in the requirement analysis. The third block represents Synthesis/Design, which is the
process of designing the system components or subsystems based on the functions identified in
the functional analysis. This block is intersected with the previous block as the design is based
on the functional analysis. The intersection of the blocks indicates that each stage of the
process is based on the previous stage and that the outputs of each stage are inputs to the next
stage. This helps to ensure that the system is designed to meet the requirements efficiently and
effectively. The FFBD diagram is a powerful tool that provides a clear and concise visualization
of the Systems Engineering process, enabling stakeholders to understand the entire process
from start to finish.
Diagram 3:
The exponentially increasing graph between project lifetime and cost to implement changes
represents the relationship between the two quantities. As the project lifetime increases, the
cost to implement changes also increases exponentially. This graph illustrates the concept of
the cost of changes over time in a project. The longer a project runs, the more difficult and
expensive it becomes to implement changes to the project. This is because the cost of making
changes increases as the project progresses. In the early stages of a project, changes can be
made easily and at a relatively low cost. However, as the project moves forward, more
resources are invested in the project, and it becomes more complex, making it increasingly
difficult and costly to make changes. This graph highlights the importance of good project
planning and management to minimize the need for changes and ensure that any changes that
are required are implemented early in the project lifecycle when they are less costly. Ultimately,
this graph serves as a reminder that changes are an inevitable part of any project, but their cost
can be managed by planning and making changes early in the project lifecycle.