Team Vision for Problem Definition Phase
Our team's goal for this phase was to prepare for system and sub-system design in future phases. This included interfacing with the customer to develop a set of customer requirements, and then defining a set of engineering requirements in compliance with those of the customer. Functions of these will be utilized in the design of system and subsystems in the next phase.
Everything that needed to be accomplished this phase was achieved within the desired time frame. These objectives were met by analyzing the Project Readiness Package for customer and engineering requirements, verifying them and receiving more from an interview with the customer, and creating a list of priorities and milestones to reach within this semester. In addition to this, we assessed via DISC and established a team dynamic, as well as assigned roles and a project manager in Lainey Celeste.
Project SummaryProblem Statement: Deliver a Remote Operated Vehicle, operable by a single user, for recreational underwater exploration in the Finger Lakes of Western New York. See the problem summary for additional information.
Primary Stakeholder: Dr. Jason Kolodziej -- Rochester Institute of Technology, Department of Mechanical Engineering
Project Goals and Key DeliverablesThe following deliverables are required by the end of MSD:
- All detailed design documents (analysis, drawings, schematics, BOM, etc.)
- A working prototype, capable of being demonstrated on Conesus Lake to our customer
- A technical paper
- A poster and a presentation to be made to our customer, RIT faculty, and the public
Customer Requirements (Needs)
PurposeDecompose the Problem Statement into functions of elements needed to satisfy the customer. The scale used to evaluate importance ranges from 1 - 5. For example, an importance of 1 denotes low importance or priority, 3 a medium priority, and 5 a critical project requirement.
A link to the live document may be found here.
Engineering Requirements (Metrics & Specifications)
PurposeCreate a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction
ConstraintsSystem level factors that limit design space.
|Weight||Easily handled by one user|
|Range||Limited to length of the tether|
|Power||Limited to batteries either on board or on launch platform|
|Weather||Only usable when there is adequate weather and water conditions|
ExclusionsFactors regarding the expectations placed on the customer at the conclusion of the project, that the MSD team will not be responsible for.
|Maintenance||Owner is responsible for system maintenance after final transfer|
|Additional Materials||Storage / transportation materials will not be provided. In the event the control terminal is a non-dedicated device (i.e. Laptop), such device shall not be provided by the team|
|Usage||Intended for freshwater usage only|
|Liability||RIT is not liable for any injuries that occur from ROV use|
House of Quality
- Confirm that satisfaction of the Engineering Requirements implies that all of the Customer Requirements are met.
- Facilitate design trade off decisions
The above is a screenshot of the House of Quality involving our Customer and Engineering Requirements. The full document can be viewed here.
From left to right: Joe Mantione, Scott Couwenhoven, Scott Mann, Trevor Sherrard, Harrison Keats, Lainey Celeste
Team Values and NormsTeam Values and Norms dictate an agreed upon code of conduct for all team members. Failure to comply with team norms will first prompt a verbal warning, followed by a team meeting to discuss and correct the issue. Guide intervention may be sought if prior methods fail to resolve the issue.
Design Review MaterialsPlease reference our problem definition design review document below:
Plans for next phase
As shown in the Project Plan below, our team has identified the key elements necessary to have a completed detailed design by the end of MSD1.
Over the next three weeks, our team will do preliminary research and a functional analysis to generate a list of alternatives for our design. Using these alternatives, a hybrid design will be established, leading to our high-level system design. In conjunction, a feasibility analysis will help establish any areas in our design that might require more attention. For individual team allocations, see the Gantt Chart for Phase 2, below.