/public/

Problem Definition

Table of Contents 1 Team Vision for Problem Definition Phase 2 Project Summary 3 Use Cases 4 Project Goals and Key Deliverables 5 Customer Requirements (Needs) 5.1 Purpose 5.2 Inputs and Source 5.3 Outputs and Destination 6 Engineering Requirements (Metrics & Specifications) 6.1 Purpose 6.2 Inputs and Source 6.3 Outputs and Destination 7 Constraints 8 House of Quality 8.1 Purpose 8.2 Inputs and Source 8.3 Outputs and Destination 9 Design Review Materials 10 Plans for next phase

Team Vision for Problem Definition Phase

Our team has determined the scope of the project from not only our customer, but by comparing it to last year's scope. There will be many refinements and changes to the project as a whole. In addition went over the customer requirements and goals again with our customer to really narrow down what is essential. The team also planned to turn in all deliverables and update EDGE with required information on a regular basis. This is not only for our benefit but also to provide a clean followable template incase another group were to follow suit.

During our problem definition phase, our team had many discussions with the customer and discussed the areas in which our needs may differ from last year. From this the team was able to determine that there was little deviation of the needs and goals. This allowed for a very similar problem definition as compared to the previous years. However, this time the team wanted to make sure that the deliverables were turned in, and EDGE was maintained.

Project Summary

Project Description

• Phones are something that require full attention to interact with, causing people to be distracted when using them. If the person is walking while using their phone this can be a problem. The idea of this device is to allow the user to be paying attention to their surroundings and have their hands free while still be interacting with their phone through a device worn on one hand that is used to input commands through certain motions.

Current State

• Prototypes that were created in previous years that are too large, uncomfortable, and do not work very well.

Desired State

• The device should be small, comfortable, and respond well to the inputs it is given without being too distracting to the wearer.

Project Goals

• Decide on a sensor type
• Going through the older model and seeing what is usable

Project Summary

Use Cases

Use Cases

Project Goals and Key Deliverables

The goal of this project is to build a device that can be worn on the hand that will be able to connect to a device, most likely a mobile phone, and connect via bluetooth. Hopefully the project will adequately provide a technologies that can be perfected to provide the world with devices that are less distracting and less cumbersome.

At its completion our key deliverables is a final working prototype and to be able to bring this to Imagine RIT. Additionally, we will also be sure to include documentation of concepts investigated, analysis, drawings, and test results. This way if a future senior design group wants to improve upon the device, they will have the necessary materials to do so. Lastly, a technical paper and a poster will also be prepared, hopefully to present at Imagine RIT.

Customer Requirements (Needs)

Purpose

Decompose the Problem Statement into functions of elements needed to satisfy the customer.

Customer Requirements

Inputs and Source

1. PRP.
2. Problem Statement.
3. Customer Interviews. (Interview guidelines and expected outcomes are available for your reference)
4. Customer's customer if possible.
5. Standards, regulations, or other industry guidelines (e.g., ADA, EPA, OSHA, IEEE, ASME; IRB approval; etc.) that your customer or your customer's organization is required to address. The RIT library maintains an infoguide with links to standards databases
6. Template and Example.
7. Guide & other stakeholders.

Outputs and Destination

A completed form matching the supplied template to be used as input to define the Engineering Requirements.

Engineering Requirements (Metrics & Specifications)

Purpose

Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction

Engineering Requirements

1. References:

https://edge.rit.edu/edge/PTemplate/public/Establish%20Engineering%20Requirements

1. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

1. Customer Requirements
2. Customer
3. Phase I benchmarking
4. Standards, regulations, or other industry guidelines (e.g., ADA, EPA, OSHA, IEEE, ASME, etc.) The RIT library maintains an infoguide with links to standards databases.
5. Selected concept list
6. System Design
7. Template and Example
8. Guide & other stakeholders

Outputs and Destination

1. Function Decomposition.
2. Concept Generation & Development.
3. HoQ.
4. System & Detail Design.
5. Test Plans.
6. Poster & Final Report.

Constraints

Risk Management

House of Quality

Purpose

1. Confirm that satisfaction of the Engineering Requirements implies that all of the Customer Requirements are met.
2. Facilitate design trade off decisions

Inputs and Source

1. Template and Example.
2. Customer Requirements.
3. Engineering Requirements.
4. Benchmarking Data.

Outputs and Destination

Provide input to the risk management process.

Design Review Materials

Presentation

Plans for next phase

• As a team, where do you want to be in three weeks at your next review?

• As an individual on the team, what are you doing to help your team achieve these goals? (Use the individual 3-week plan template for this)

---

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation