Final Presentation / Oral Defense

Here are some of the subjects/ items to expect in your final presentation and review of deliverables by your Capstone Instructor (Utara or Flanigan):

There are 3 primary aspects you'll be graded on:

1.     How well do you know Systems Engineering

2.     How well you know your own project

3.     How well you developed your system architecture (completeness)

• Before continuing with these tips: DO NOT read these tips verbatim back to CJ during the oral defense! 

  • You must know these answers without reference.

  • He's well aware of this page and familiar with its contents, so he'll know you're reading these pointers. Not good!

• Don't be nervous. Be positive and confident.

• The Instructor's purpose if not to scrutinize and try to pick your project apart They'll be prodding you for how well you know your project and how well you know Systems Engineering. 

• Talk about yourself up front. Hobbies, interests, profession, how you'll apply SE at work, etc. This is both to get to know you and to help ease the nervousness.

• Know the fundamentals. This is VITAL! We cannot award a master's in Systems Engineering to a student that cannot describe what SE is, what the Life Cycle is, how SE fits into the life cycle, and other very basic intro-level knowledge. 

Things to know

Life Cycle & Systems Engineering Processes

• To demonstrate your general knowledge of Systems Engineering, it's essential to understand the fundamental concepts, particularly the SE life cycle stages and the phases within each stage. According to Kossiakoff, there are three main stages, each with three phases, except for the production/deployment stage, which has two phases. While Kossiakoff's model is a common reference, it's important to recognize that the SE process is iterative and repeats throughout the system life cycle.

• Below are the Life Cycle Stages broken down into their phases from the Kossiakoff Textbook.

• Below is an illustration of the generic Systems Engineering activities. You can activate and use the SE process at any point, for any element across the lifecycle and down into the hierarchy. You MUST know the names and order of these SE activities!

• You will apply these SE activities multiple times, starting from the overall system level and gradually working down to subsystems, components, and further details. This iterative process is like "peeling an onion," where each layer represents a different level of detail. You should be prepared to discuss how many times you applied the SE process in your project. 

• See illustration below showing the link between the SE activities (above) with the Life Cycle. 

  • What you must know and be able to explain: 

    • The names of the 3 stages (top of illustration)

    • The names of the first 3 phases in Concept Development (Needs Analysis, Concept Exploration, Concept Definition)

    • The fact that Systems Engineering is performed iteratively and recursively across the life cycle (bottom of diagram). Notice each set of SE activities is tailored for each phase (zoom in or consult the textbook).

Be able to answer the following questions

• It's actually best/better to answer these questions in your presentation!

  • This will significantly cut down on the amount of Q&A you'll undergo.

• Why is iterating the SE process important? (Top down is the best approach toward developing & managing complex system designs, and can be best approached in small (iterative) steps).

Proposal

• Know what a system context diagram is the primary items found on one: Sources, destinations, the system itself, inputs and outputs.

• What is the source of your context diagram(s)? (A: Scenarios, mission descriptions & use cases)

• What are the typical sources of requirements? Did you use these sources for your project? (A: stakeholders & need statement(s) but the CONOPS scenarios & use cases are by far the largest source.)

Requirements Analysis Report

• Do you have a hierarchy of requirements? (e.g., Needs to Capabilities to performance, functional, constraint requirements)

• Defend how you will be able to verify your requirements. (A: Quantify using MOP Thresholds (T) & Objectives (O)).

• Defend how you came up with your operational requirements and how you derived your performance requirements from them.

• What is the purpose of the CONOPS? How is it used throughout the development of a typical system? (big hint: You used it to pull requirements out of and to help shape your functional domain)

• Explain what a Key Performance Parameter is to a layperson unfamiliar with SE? Why did you choose the ones you chose? (Guaranteed to be asked)

• If you can't meet a particular KPP even by a very small margin, how will you go about managing this? What are the consequences? (hint: As an SE you should never compromise or negotiate a KPP)

• How did you determine what should be a KPP?

• How many qualitative requirements did you quantify through derivation?

• Are you ok with the number of qualitative requirements you have in your ASpec? How will these be quantified/tested later?

Functional Analysis Report

• How did you go about formulating functions? Is the path you chose the only path? (remember SE is an art and a science)

• Why do we perform functional analysis? What is its purpose? (A: To answer what the system needs to perform. It is used to link the mission descriptions & requirements to the physical solutions. We shouldn't jump from requirements to solutions before we understand the behaviors, actions and flow of events the system performs).

• What is a function? 

• ​How are inputs and outputs related to functions? (input(s) are ingested and converted by the function into the output(s))

• Can you have a function without either inputs and/or outputs? (noall functions require at least 1 input and 1 output!)

• Are there any functions you accounted for that are performed by an outside entity? (Outside of your system context)

• What is meant by "loose coupling" and "tight binding"? Are there examples of each throughout your project? Which is more preferred? This is discussed in the Kossi textbook in Ch 11 (Software SE Chapter Modular Partitioning section, pgs 417/18 hard copy version). Here is a 2-page extract from the Weilkiens MBSE textbook as well.

• Are you able to trace your functions or functional flows back to your requirements?

  • For the functions where you answer "no": you'll want to convert these functions into requirements and add to your A Spec for the appropriate physical element that performs it, e.g., "The ATM Cash Management Subsystem shall..."

Trade Study

• Are you able to trace your trade study criteria back to your requirements?

• Why did you choose the shape and scales you chose for your utility curves?

• Who, in the real world, defines the shape and scale of utilities? 

Concept Design Report

• How many functions were turned into requirements for a developer to include in the system they build? How many Components? (not exact number, maybe rough figures / percentage)

• Which is best/optimal: 1 function allocated to 1 component? (this is good for modeling) OR many functions to 1 component? (This is typical, think about your smart phone. 1 device that can perform thousands of functions) OR 1 function to more than 1 component? (This is NOT a good thing. This is forced redundancy & gold plating be able to explain why).

• Are there any functions that aren't being performed by any components?

• What is a HWCI and a SWCI? How are each important? What is a HWCI in relation to the components in your architecture?

• Are your functional interfaces (MEDS elements) and physical interfaces connected? Is this connection important? 

  •  In Catia Magic, these are «item flows» allocated to «connections» between «blocks» or «ports», depending on if you used ports or not.

• How do you know your architecture is complete? How far should you go? (A: project encompasses the conceptual development stage, we should decompose until risks are at acceptable levels for a developer to take over and implement, integrate & test the system). 

Risk Report

• What is the current risk level on your project? Will you need to let potential developers know the risk level? (A: uh…yes! They'll need to build mitigations into the plan/proposal).

• Do your mitigation plans bring the risk into the green (either here in the Concept dev stage or in a planned Engineering development stage)?

EVM

• Be able to defend your EVM. If anything your SPI should be 1.0 since your project is 'done', thus 100% complete (earned value). Be able to explain what each element in EVM is to a layperson.

• Be able to provide a definition/explanation for each of the EVM variables: BCWS, BCWP, ACWP, EAC, and BAC with a bonus: TCPI.

• See my EVM page to refresh your memory and check your work.

A-Spec

• What was / was not included in your ASpec? What's the difference between the ASpec and the requirements report? 

  • Your requriements should grow significantly between the RAR and the A Spec. Convert your functions into requirements and quantify where possible.

  • Don't forget to refine your 'ilities'!

Overall

• My biggest pointer is to identify and talk about mistakes made and lessons learned throughout your project. Be up front with these things and don't cover anything up. Sometimes we run out of time to update our project, but we know what we would do if we had more time these aspects are important to highlight. It's okay to know a thing but don't have the time to implement it (minor infraction) vs straight up not knowing the thing at all (major infraction).