Cornell Cup

(4.5)
(35 Reviews)
Overview

Whether you’re developing a software stack or engineering bridges, the need for leaders who can design, develop, and manage complex solutions and systems over their lifecycle is rapidly growing. Drawing on an interdisciplinary systems design approach that can be applied to any field, this program will guide you through the process of developing documentation for any system, from initial scoping through detailed design. You’ll learn to define the challenges you are trying to solve, define functional requirements, and objectively measure the value of any potential solution. After understanding the purpose, intent, and audience for the project, you will utilize fundamental systems architecture techniques to develop a deeper understanding of how all of the components of the solution work together.

You will come away with not only a practical understanding of how to meet the most stringent requirements for design documentation and manage risk across potentially complex projects, but will have a more profound understanding of the big picture, including how each system tool that you invest time in can provide the maximum benefit throughout the design process. Appropriate for engineers, technology leaders, and anyone with a desire to lead a product or systems design process, the concepts learned will help you successfully manage team interactions, client relations, and your own solutions architecture workflow.

Modules

How do you take a fresh new idea for a product, service, or whatever your system might be, and define that idea so others understand? To begin this first stage of design, you need to define the scope of your system.

In this set, as you explore and define your system’s scope, you will also begin to identify what your system is responsible for. And you will also explain what your system must interact with in order to be a success.

For the first part of defining your scope, you will use a graphical tool called a context diagram to identify what elements interact with your system. For the second part, you will consider all the different kinds of scenarios that your system might need to handle in order to meet the project’s needs. In determining these scenarios, you will conduct some initial use case analysis, create a use case diagram, and design a scope tree. Once you have worked with these tools, you will have a solid start to your system design because you will understand the scope of your project, and you will have a beginning definition of your system.

What Your Students Will Do:

  • Define interrelationships between your system and other factors by creating a context diagram.
  • Capture in use cases the set of functionalities that any system must have to meet the needs of the challenge you are addressing.
  • Create a shareable use case diagram that organizes the relationships between use cases.
  • Document all tasks and sub-deliverables necessary to produce a project end deliverable.

Includes:

  • BuildingtheDeliverableTree.pptx
  • ContextDiagramExample.pptx
  • CornellCup_Defining_Deliverables.docx
  • Defining_Your_System_Part_1.docx
  • DeliverableTreeGeneralFormExample.pptx
  • UseCaseDiagramBuildingGuide.pptx

You have identified the scope of your system. You know what your system is responsible for and what your system must interact with in order to be a success. Now you need to discover and flesh out the responsibilities of your system, and capture these responsibilities as formal functional requirements.

In this set you will build a Use Case Behavioral Diagram (UCBD) for a specific use case. The UCBD will help you articulate all the functions your system must be able to achieve successfully throughout that use case. You will also use this tool to develop an understanding of the difference between functional and structural requirements. With a clear understanding of requirements, you will have defined what any valid solutions must be able to achieve throughout your use cases. You will also convey the information found in a Use Case Behavioral Diagram using a SysML Activity Diagram. Experience with this alternative format will expand your options for communicating use cases’ requirements with your team.

What Your Students Will Do:

  • Determine all the functions your system must be able to achieve throughout each use case.
  • Develop Use Case Behavioral Diagrams to define formal, verifiable requirements for a system.
  • Use an Activity Diagram to create a SysML variation of a Use Case Behavioral Diagram.
  • Develop an understanding of the difference between functional and structural requirements.

Includes: 


  • Defining_Your_System_Part_II.docx
  • UseCaseBehavioralDiagramExample.xlsx

Tools that support meaningful team collaboration are the lifeblood of the engineering design process. Effective tools spark more in-depth conversations, which help the team recognize the complexity of everyone’s tasks. When used to their potential, these tools also keep team members in the loop about progress and interactions between their own work and others’ work.

In this set you’ll design a diagram to represent the flow of your system and show how the different system functions operate together. In exploring these kinds of interactions, you will provide a clear way to communicate to the whole team the cohesive vision of your system’s functions and show how your system truly provides a solution to the targeted challenge’s needs.

The Functional Flow Block Diagram, or FFBD, is the tool you will use to create this clear communication. The FFBD is a simple and flexible tool that is commonly used in a wide variety of areas, from large industries and government to smaller entrepreneurial and academic efforts. It is also a helpful tool to get all of your team on board with a general plan so they at least recognize how their different parts relate.

What Your Students Will Do:

  • Map the operational flow of functions
  • Identify system interfaces
  • Identify areas of uncertainty within the operational flow

     

Includes: 


  • CornellCup_FFBD_Guide.docx
  • FFBD_Example.pptx

Once you feel you have established well-defined needs that your system will meet, you have to determine and formalize how any potential solutions for those needs will be assessed. What you are looking for is the value your system offers and how that value, or effectiveness, is being assessed. By being able to objectively measure your system’s performance in a way that can be agreed upon, you will be able to inform planning, justify decision trade-offs, and prove your system’s value to your customers.

In this set, you will focus on developing performance metrics. These performance metrics will allow you to objectively determine the value of any potential solution to a challenge. You’ll then develop a decision matrix around these metrics by applying justifiable weights. Then, you will refine these metrics to account for the needs and priorities of specific customers. By providing well-defined performance metrics through a decision matrix, you will show measurable value of your solution and greatly improve the decision-making process within your team.

What Your Students Will Do:

  • Determine criteria necessary to measure value (e.g. evaluate effectiveness).
  • Determine objective means (often a set of conditions) to measure the criteria.
  • Establish relative importance (weighting) for criteria.
  • Combine all factors into a Pugh decision matrix.
  • Interpret the results of the decision matrix to measure performance.

     

Includes: 


  • CornellCup_DecisionMatrixGuide.docx
  • Decision-matrix-template5.xlsx
  • PerformanceCriteriaTipsfoDeliverablesAndDecisionMatricies.docx

One of the most challenging aspects of system engineering is figuring out how best to manage system performance trade-offs. Time, budget, and other limiting resources force you to prioritize aspects of your design so your system provides the maximum benefit. You can manage these trade-offs efficiently and effectively by implementing a process known as Quality Function Deployment method, or QFD.

QFD is also sometimes referred to as “house of quality,” and the document that is created during QFD does in fact look like a house. The house of quality provides a crucial visual link between your emerging system design, the needs of your customers, and competing designs in the marketplace. With QFD you’ll build intuition about your system, make decisions about resource allocation, communicate development priorities, and establish design targets, all in a way that ensures you are creating the best-performing solution possible. Design teams of all types use QFD, and it’s one of the most established and recognized systems design tools today.

In this set, you’ll be led through a detailed, step-by-step process to build a house of quality for your own project. This process begins with identifying what your system must do for customers (performance measures) and which of these performance measures matter most to the customer. You’ll relate each of your system’s engineering characteristics to those performance measures. After this, you’ll complete the house of quality by considering each engineering characteristic in terms of importance, difficulty, associated cost, the current competitive benchmarks, and minimum or maximum requirement thresholds. This process will lead you to performance targets that consider both what is desired and what is feasible. The collection of design targets will give you a good working estimate of the best performance you can expect your system to achieve.

What Your Students Will Do:

  • Define key engineering characteristics.
  • Determine impact of each characteristic.
  • Benchmark against competitors.
  • Determine initial targets for each engineering characteristic.

     

Includes: 


  • QFD_Guide_Final.docx
  • QFD_RoboticVehicleExample.xlsx
    QFD_Template.xlsx

For any system of reasonable complexity, it’s essential to recognize and keep in mind that there are many parts, or subsystems, that make up the whole. Your approach to design needs to account for the many ways in which these subsystems might interact. And you need to ensure that the subsystems will remain compatible in these interactions. Documentation and communication about system interactions, or interfaces, are both critically important, especially for a design team where there’s shared responsibility for subsystem design.

In this set, you’ll practice the art of discovering and documenting subsystem interfaces. You’ll see that there are many ways to think of interfaces and that multiple teammates’ perspectives on a system interface need to be accounted for. Your goals throughout the process will be good subsystem integration and clear, complete, and concise documentation. The benefits of meeting these goals will extend throughout the design, development, and deployment phases of your project.

What Your Students Will Do:

  • Identify and document interfaces between subsystems.
  • Track interfaces throughout the design process.
  • Assign responsibilities and estimates for delivery dates.

     

Includes: 


  • CornellCup_InterfaceGuide.docx
  • CornellCup_InterfaceMatrixAdvSample.xlsx
  • CornellCup_InterfaceMatrixBasicSample.xlsx

The systems design process seeks to develop a functioning system that meets the stakeholders’ needs and performs optimally under the broadest range of conditions. This is not the same thing as saying that a system will work perfectly all the time. Some risk always exists that the system will not perform as it’s needed or expected. After all, there are inevitable tradeoffs in design, and no system can function optimally in every imaginable scenario. As a result, a healthy design process incorporates the notion of failure, defines it carefully, and examines the impact of a range of failures on overall system function. By carefully considering during design how a system might fail, you can both reduce risk and quantify any remaining risk that’s inherent in system operation.

This set introduces a design tool known as Failure Modes and Effects Analysis (FMEA). FMEA is an industry standard procedure for analyzing system failures, with a focus on identifying potential causes and effects. In the set you’ll develop an FMEA for a system. For each failure mode you will examine such factors as effects, causes, likelihood, severity, and detectability. Ultimately you will translate this information into a quantitative value that represents risk.

What Your Students Will Do:

  • Identify potential system failure modes and their causes
  • Complete a formal assessment of likelihood, impact, detection, and overall risk
  • Propose corrective actions
  • Track mitigation efforts throughout and after the design process

     

Includes: 


  • BrainstormingRiskSample.xlsx
  • CornellCup_BrainstormingRisk.docx

You can have the greatest idea in the world but if can’t communicate to your team and stakeholders the potential of your idea will never be realized. This set offers two versions of a sample presentation on a team’s progress for a semester long project: a 1 hour version and a 10 minute version so students can see what to expand/cut as time allows. Each version also includes full text and presentation strategy explanations. An additional guide is provided on practical, easy to implement tips and tricks including how to control your audience’s attention and how to handle questions including even potentially difficult audience members.

Includes: 


  • CornellCup_SampleLongPresentation.pptx
  • CornellCup_SampleShortPresentation.pptx
  • PresentationTipsTricks.docx
  • SampleGraphSlides.pptx

A task on a timeline may be written as “Research various approaches to solving a problem”, but “research” to one person could mean spending years of dedicated effort, while to another it may mean spending 5 minutes in ChatGPT. Miscommunication in deliverable expectations is one of the most common reasons for scheduling delays and frustration across teams. This set walks students through a step by step process of creating their first work breakdown structure with an emphasis on determining dependencies and setting deliverables. It also emphasizes that developing timelines should involve multiple perspectives from across the team and the importance of making trade-offs that serve the overall team’s goals.

Includes: 


  • CornellCup_TestOftenTestEarlyTestingGuide.docx
  • CornellCup_TimelineGuide.docx
  • CornellCup_TimelineSample.xlsx
  • ProgressTrackingTemplate_CornelCup.pptx
  • ProgressTracking_CornelCup.docx

Whether you’re developing a software stack or engineering bridges, the need for leaders who can design, develop, and manage complex solutions and systems over their lifecycle is rapidly growing. Drawing on an interdisciplinary systems design approach that can be applied to any field, this program will guide you through the process of developing documentation for any system, from initial scoping through detailed design. You’ll learn to define the challenges you are trying to solve, define functional requirements, and objectively measure the value of any potential solution. After understanding the purpose, intent, and audience for the project, you will utilize fundamental systems architecture techniques to develop a deeper understanding of how all of the components of the solution work together.

You will come away with not only a practical understanding of how to meet the most stringent requirements for design documentation and manage risk across potentially complex projects, but will have a more profound understanding of the big picture, including how each system tool that you invest time in can provide the maximum benefit throughout the design process. Appropriate for engineers, technology leaders, and anyone with a desire to lead a product or systems design process, the concepts learned will help you successfully manage team interactions, client relations, and your own solutions architecture workflow.

Modules

How do you take a fresh new idea for a product, service, or whatever your system might be, and define that idea so others understand? To begin this first stage of design, you need to define the scope of your system.

In this set, as you explore and define your system’s scope, you will also begin to identify what your system is responsible for. And you will also explain what your system must interact with in order to be a success.

For the first part of defining your scope, you will use a graphical tool called a context diagram to identify what elements interact with your system. For the second part, you will consider all the different kinds of scenarios that your system might need to handle in order to meet the project’s needs. In determining these scenarios, you will conduct some initial use case analysis, create a use case diagram, and design a scope tree. Once you have worked with these tools, you will have a solid start to your system design because you will understand the scope of your project, and you will have a beginning definition of your system.

What Your Students Will Do:

  • Define interrelationships between your system and other factors by creating a context diagram.
  • Capture in use cases the set of functionalities that any system must have to meet the needs of the challenge you are addressing.
  • Create a shareable use case diagram that organizes the relationships between use cases.
  • Document all tasks and sub-deliverables necessary to produce a project end deliverable.

Includes:

  • BuildingtheDeliverableTree.pptx
  • ContextDiagramExample.pptx
  • CornellCup_Defining_Deliverables.docx
  • Defining_Your_System_Part_1.docx
  • DeliverableTreeGeneralFormExample.pptx
  • UseCaseDiagramBuildingGuide.pptx

You have identified the scope of your system. You know what your system is responsible for and what your system must interact with in order to be a success. Now you need to discover and flesh out the responsibilities of your system, and capture these responsibilities as formal functional requirements.

In this set you will build a Use Case Behavioral Diagram (UCBD) for a specific use case. The UCBD will help you articulate all the functions your system must be able to achieve successfully throughout that use case. You will also use this tool to develop an understanding of the difference between functional and structural requirements. With a clear understanding of requirements, you will have defined what any valid solutions must be able to achieve throughout your use cases. You will also convey the information found in a Use Case Behavioral Diagram using a SysML Activity Diagram. Experience with this alternative format will expand your options for communicating use cases’ requirements with your team.

What Your Students Will Do:

  • Determine all the functions your system must be able to achieve throughout each use case.
  • Develop Use Case Behavioral Diagrams to define formal, verifiable requirements for a system.
  • Use an Activity Diagram to create a SysML variation of a Use Case Behavioral Diagram.
  • Develop an understanding of the difference between functional and structural requirements.

Includes: 


  • Defining_Your_System_Part_II.docx
  • UseCaseBehavioralDiagramExample.xlsx

Tools that support meaningful team collaboration are the lifeblood of the engineering design process. Effective tools spark more in-depth conversations, which help the team recognize the complexity of everyone’s tasks. When used to their potential, these tools also keep team members in the loop about progress and interactions between their own work and others’ work.

In this set you’ll design a diagram to represent the flow of your system and show how the different system functions operate together. In exploring these kinds of interactions, you will provide a clear way to communicate to the whole team the cohesive vision of your system’s functions and show how your system truly provides a solution to the targeted challenge’s needs.

The Functional Flow Block Diagram, or FFBD, is the tool you will use to create this clear communication. The FFBD is a simple and flexible tool that is commonly used in a wide variety of areas, from large industries and government to smaller entrepreneurial and academic efforts. It is also a helpful tool to get all of your team on board with a general plan so they at least recognize how their different parts relate.

What Your Students Will Do:

  • Map the operational flow of functions
  • Identify system interfaces
  • Identify areas of uncertainty within the operational flow

     

Includes: 


  • CornellCup_FFBD_Guide.docx
  • FFBD_Example.pptx

Once you feel you have established well-defined needs that your system will meet, you have to determine and formalize how any potential solutions for those needs will be assessed. What you are looking for is the value your system offers and how that value, or effectiveness, is being assessed. By being able to objectively measure your system’s performance in a way that can be agreed upon, you will be able to inform planning, justify decision trade-offs, and prove your system’s value to your customers.

In this set, you will focus on developing performance metrics. These performance metrics will allow you to objectively determine the value of any potential solution to a challenge. You’ll then develop a decision matrix around these metrics by applying justifiable weights. Then, you will refine these metrics to account for the needs and priorities of specific customers. By providing well-defined performance metrics through a decision matrix, you will show measurable value of your solution and greatly improve the decision-making process within your team.

What Your Students Will Do:

  • Determine criteria necessary to measure value (e.g. evaluate effectiveness).
  • Determine objective means (often a set of conditions) to measure the criteria.
  • Establish relative importance (weighting) for criteria.
  • Combine all factors into a Pugh decision matrix.
  • Interpret the results of the decision matrix to measure performance.

     

Includes: 


  • CornellCup_DecisionMatrixGuide.docx
  • Decision-matrix-template5.xlsx
  • PerformanceCriteriaTipsfoDeliverablesAndDecisionMatricies.docx

One of the most challenging aspects of system engineering is figuring out how best to manage system performance trade-offs. Time, budget, and other limiting resources force you to prioritize aspects of your design so your system provides the maximum benefit. You can manage these trade-offs efficiently and effectively by implementing a process known as Quality Function Deployment method, or QFD.

QFD is also sometimes referred to as “house of quality,” and the document that is created during QFD does in fact look like a house. The house of quality provides a crucial visual link between your emerging system design, the needs of your customers, and competing designs in the marketplace. With QFD you’ll build intuition about your system, make decisions about resource allocation, communicate development priorities, and establish design targets, all in a way that ensures you are creating the best-performing solution possible. Design teams of all types use QFD, and it’s one of the most established and recognized systems design tools today.

In this set, you’ll be led through a detailed, step-by-step process to build a house of quality for your own project. This process begins with identifying what your system must do for customers (performance measures) and which of these performance measures matter most to the customer. You’ll relate each of your system’s engineering characteristics to those performance measures. After this, you’ll complete the house of quality by considering each engineering characteristic in terms of importance, difficulty, associated cost, the current competitive benchmarks, and minimum or maximum requirement thresholds. This process will lead you to performance targets that consider both what is desired and what is feasible. The collection of design targets will give you a good working estimate of the best performance you can expect your system to achieve.

What Your Students Will Do:

  • Define key engineering characteristics.
  • Determine impact of each characteristic.
  • Benchmark against competitors.
  • Determine initial targets for each engineering characteristic.

     

Includes: 


  • QFD_Guide_Final.docx
  • QFD_RoboticVehicleExample.xlsx
    QFD_Template.xlsx

For any system of reasonable complexity, it’s essential to recognize and keep in mind that there are many parts, or subsystems, that make up the whole. Your approach to design needs to account for the many ways in which these subsystems might interact. And you need to ensure that the subsystems will remain compatible in these interactions. Documentation and communication about system interactions, or interfaces, are both critically important, especially for a design team where there’s shared responsibility for subsystem design.

In this set, you’ll practice the art of discovering and documenting subsystem interfaces. You’ll see that there are many ways to think of interfaces and that multiple teammates’ perspectives on a system interface need to be accounted for. Your goals throughout the process will be good subsystem integration and clear, complete, and concise documentation. The benefits of meeting these goals will extend throughout the design, development, and deployment phases of your project.

What Your Students Will Do:

  • Identify and document interfaces between subsystems.
  • Track interfaces throughout the design process.
  • Assign responsibilities and estimates for delivery dates.

     

Includes: 


  • CornellCup_InterfaceGuide.docx
  • CornellCup_InterfaceMatrixAdvSample.xlsx
  • CornellCup_InterfaceMatrixBasicSample.xlsx

The systems design process seeks to develop a functioning system that meets the stakeholders’ needs and performs optimally under the broadest range of conditions. This is not the same thing as saying that a system will work perfectly all the time. Some risk always exists that the system will not perform as it’s needed or expected. After all, there are inevitable tradeoffs in design, and no system can function optimally in every imaginable scenario. As a result, a healthy design process incorporates the notion of failure, defines it carefully, and examines the impact of a range of failures on overall system function. By carefully considering during design how a system might fail, you can both reduce risk and quantify any remaining risk that’s inherent in system operation.

This set introduces a design tool known as Failure Modes and Effects Analysis (FMEA). FMEA is an industry standard procedure for analyzing system failures, with a focus on identifying potential causes and effects. In the set you’ll develop an FMEA for a system. For each failure mode you will examine such factors as effects, causes, likelihood, severity, and detectability. Ultimately you will translate this information into a quantitative value that represents risk.

What Your Students Will Do:

  • Identify potential system failure modes and their causes
  • Complete a formal assessment of likelihood, impact, detection, and overall risk
  • Propose corrective actions
  • Track mitigation efforts throughout and after the design process

     

Includes: 


  • BrainstormingRiskSample.xlsx
  • CornellCup_BrainstormingRisk.docx

You can have the greatest idea in the world but if can’t communicate to your team and stakeholders the potential of your idea will never be realized. This set offers two versions of a sample presentation on a team’s progress for a semester long project: a 1 hour version and a 10 minute version so students can see what to expand/cut as time allows. Each version also includes full text and presentation strategy explanations. An additional guide is provided on practical, easy to implement tips and tricks including how to control your audience’s attention and how to handle questions including even potentially difficult audience members.

Includes: 


  • CornellCup_SampleLongPresentation.pptx
  • CornellCup_SampleShortPresentation.pptx
  • PresentationTipsTricks.docx
  • SampleGraphSlides.pptx

A task on a timeline may be written as “Research various approaches to solving a problem”, but “research” to one person could mean spending years of dedicated effort, while to another it may mean spending 5 minutes in ChatGPT. Miscommunication in deliverable expectations is one of the most common reasons for scheduling delays and frustration across teams. This set walks students through a step by step process of creating their first work breakdown structure with an emphasis on determining dependencies and setting deliverables. It also emphasizes that developing timelines should involve multiple perspectives from across the team and the importance of making trade-offs that serve the overall team’s goals.

Includes: 


  • CornellCup_TestOftenTestEarlyTestingGuide.docx
  • CornellCup_TimelineGuide.docx
  • CornellCup_TimelineSample.xlsx
  • ProgressTrackingTemplate_CornelCup.pptx
  • ProgressTracking_CornelCup.docx

Curated by Arm

Curated by Cornell University
Duration: 1hr 20mins
Modality: Project Basis

Grade level

College

EduLabs Digital Certificate

Share on

Related Skills

Get to Know Your Instructor

James William

Instructor in Microdevices
5 Courses
4.7
(49 Reviews)
  • 20+ years of experience in microelectronics and semiconductor devices.
  • Taught numerous advanced courses with high recognition and feedback.
  • Known for simplifying complex concepts into practical insights.

Related courses based on your skills

[lifterlms_login redirect="/"]