Team 207

The repository for Team 207 of EGR314 for Spring 2024.

View project on GitHub

Product Requirements Document

Introduction

The use of weather sensors in objects can be useful in various applications such when precise data is needed. Most often these devices are responsive for useful output such as alternate positioning, or even relaying information. The users who benefit the most from these devices are meteorologists, farmers, or anyone who is in need of constant weather updates. Most users agree that such a device needs to be easy to use with hardly any learning curve. Another popular demand was the need of a user friendly interface that is able to log weather data for later study and use.

Objectives

Our vision is to make a device that is able to meet our users needs and communicate with useful information. This device should be aesthetically pleasing in terms of looks and should resemble an off the shelf product that is designed professionally. This project should provide the team with valuable experience on how to set up and use digital devices. Our team also has set a goal to garner the use of various stakeholders. We have also envisioned the product to be used by regular customers who have a general interest in weather technology, using the product to conduct data analysis.

Stakeholders

Target Group: Currently, the team has decided that the product should be advertised for people with a technical background, and would have a good use-case for weather forecasting.

Retailers: The product needs to be something that has enough visual appeal to be able to stock shelves if in stores, or be something eye-catching for a person browsing Amazon to think is neat.

Manufacturers: The product shouldn’t be too much of a strain to produce for manufacturing, especially if the group decides to go down a more mass-produced avenue in the future.

Customer Service: The product should have precise instructions for how to use it, as well as the ability to get help with use from a person should the need arise.

User Cases

User Story #1 - Scientist (Generated using ChatGPT)

One fine day, Dr. Meteorica received a mysterious package at her laboratory. Curiosity piqued, she eagerly unwrapped it to find an advanced weather sensor device. The package had no sender information, leaving her intrigued about the origins of this high-tech gadget.

Excited to put the weather sensor to the test, Dr. Meteorica decided to deploy it in various locations around Techville to gather real-time data. The sensor, equipped with state-of-the-art technology, could measure temperature, humidity, wind speed, and even detect impending storms.

As days passed, the sensor proved its worth. It accurately predicted a sudden temperature drop, alerting the local farmers to take precautions for their crops. The wind speed feature helped the townspeople brace for an approaching storm, preventing potential damage to property.

Word spread about the miraculous weather predictions in Techville, and soon the entire town was benefiting from Dr. Meteorica’s newfound tool. The sensor became an integral part of the community, assisting in planning outdoor events, managing energy consumption, and even aiding in emergency response efforts.

User Story #2: - Air Balloon Technician

On a particularly chilly morning the fall, Dave had a bad feeling about the weather. For the upcoming air balloon festival, the weather and wind speed needed to be under a certain point in order to guarantee as few issues as possible for the many air balloons that would be mobile in a month. In order to get a good idea of how the weather might be like during the festival, Dave purchased a mobile weather sensor.

He installed it in place and let it fly for about a week, before taking it back down and transmitting the data to his laptop. What he found was that the weather and wind speed were way, way too high for the kind of air balloons that had paid for a spot at the festival, and they had no sign of stopping. Using this data, he was able to convince the planners to set the festival back for another couple of weeks. By doing so, he was able to guarantee that no one got hurt.

Aspects

For these aspects, the team went back over the user needs list, and sorted through each need by the group it was filed under first, followed by the highest rank. Once done, each need was put in order in the following list. If there were similar enough needs they were consolidated into one aspect in order to maintain focus.

  1. Hardware/Product Design

    1. The product
  2. Software/Functionality

    1. The product
  3. Interactivity & User Experience

    1. The product
  4. Customization

    1. The product
  5. Manufacturing

    1. The product
  6. Safety

    1. The product

Open Questions

The team still had many questions at this point in the design process, so they will thus be mentioned in this section. If there were additional, less-important questions considered at this point they were added into the others for the sake of brevity.

  • How do we make this project more specialized towards a certain target audience? ANSWER: Ultimately, the user is given the choice of whether they would like to use the device as a mobile weather station that collects enviromental metrics or they could use the device to optimize plant growth.

  • What does it mean for the device to be ‘mobile’? ANSWER: Users would be able to travel with the device to collect data from around the world.

  • How intricate do we want this project to be going forward? ANSWER: As simple as possible

  • Will this project utilize more subsystems for the sake of user handleability, or will we keep it to the bare minimum in order to prioritize getting what we need for the project to be 100%? ANSWER: Prioritize what is needed for the project while keeping open room for adjustments if time is on our side.

  • How easy will this project be to be disassembled in case something goes wrong at a base level? ANSWER: Very easy.

Milestones

Setup Git/Github/Report: 01/19/2024 @ 11:59 PM

Design Ideation: 01/19/2024 @ 11:59 PM

Team Checkpoint 1: 01/26/2024 @ 11:59 PM

Component Selection: 01/31/2024 @ 6:00 PM

Microcontroller Selection: 02/07/2024 @ 6:00 PM

CATME Survey 1: 02/09/2024 @ 11:59 PM

Software Proposal: 02/14/2024 @ 6:00 PM

Hardware Orders: 02/14/2024 @ 11:59 PM

Subsystem Design: 02/19/2024 @ 11:59 PM

Hardware Proposal: 02/21/2024 @ 6:00 PM

Team Checkpoint 2 (Presentation): 02/26/2024 @ 6:00 PM

Hardware Implementation 1: 03/01/2024 @ 11:59 PM

CATME Survey 2: 03/11/2024 @ 5:00 PM

Team Checkpoint 2 (Materials Submission) 03/11/2024 @ 6:00 PM

Team System Prototype (Recommended): 03/15/2024 @ 11:59 PM

Innovation Showcase Information Submission: 03/25/2024 @ 11:59 PM

Team System Prototype (Hard Deadline): 03/29/2024 @ 11:59 PM

Hardware Implementation 2: 03/29/2024 @ 11:59 PM

Team Protocol and Controller Design: 04/03/2024 @ 6:00 PM

System Verification 1: 04/03/2024 @ 6:00 PM

Innovation Showcase Poster Submission: 04/12/2024 @ 11:59 PM

Software Implementation (Checkoff): 04/15/2024 @ 6:00 PM

Software Implementation (Turnin): 04/17/2024 @ 11:59 PM

System Verification Final: 04/22/2024 @ 11:59 PM

Team Checkpoint 3 Demo 04/26/2024 @ 12:00 PM

CATME Survey 3: 04/29/2024 @ 5:00 PM

Team Checkpoint 3 Report: 04/29/2024 @ 11:59 PM

Back to Home Page

Back to Report