Sustainable Design: Smart Water Bottle

Part I: Smart Waterbottle

Customer Requirements:

My sister Siera has a problem. She often forgets to drink enough water throughout the day. Why is this important? Well as a mother who is breastfeeding two children, it’s recommended that she increase her daily water intake to at least 10-12, 8 0z glasses per day. So to help remind her to drink more water throughout the day, she has challenged me to create her a smart water bottle. Now she could easily order a smart water bottle off of Amazon from various distributors and they might work well for her. In fact many smart water bottles are marketed to track your water intake throughout the day with an app that can sync directly to your smart phone or smart watch. But she doesn’t want that, instead she wants a water bottle to just remind her to drink a certain amount of fluids per day, which should make the product development process easier, right? Well, not really. She also wants to incorporate fruit, ice and potentially a filter in the water bottle. This proves problematic for a variety of smart water bottles that have weight-based sensors because now we have different densities of solids floating around the reservoir. But before we get deeper into the sensor design, lets take a look at her customer requirements:

  • A design similar to Voss
  • Glass container
  • A non-plastic, twist off cap
  • The ability to put ice/fruit inside without compromising the sensor
  • Minimal energy consumption
  • Battery-operated
  • Water filtration (maybe)
  • 32 oz carrying capacity


Siera's Customer Requirements

Operating Scenarios:

These are some pretty hefty customer requirements. Not only will the bottle be consuming energy to accomplish the task at hand, but it has to withstand some pretty serious Operating Scenarios:

  • The water bottle shall be operable in desert and beach conditions as defined in the functional requirements.
  • The water bottle shall be operable in snow and cold climate conditions as defined in the functional requirements
  • The water bottle shall be dishwasher safe (excludes cap):  temperatures: 110-170 deg F.
  • The water bottle shall be operable after dropped from a predetermined height as defined in the functional requirements.
  • The water bottle shall be operable if submerged into a body of water as defined in the functional requirements.


Operating Scenario: Submerged Bottle

Functional Requirements:

Now lets start mapping the functional requirements to help outline our conceptual design constraints:

  • The water bottle shall be reusable and recyclable to fulfill sustainability requirements –> what are these sustainability requirements that you speak of?
  • The water bottle shall have a lifetime of at least a year–>critical to electrical and mechanical component choices.
  • The water bottle shall have a twist off cap to facilitate easy handling during cleaning.
  • The water bottle shall be at least 32 oz to provide an adequate amount of water during situations the user cannot refill the bottle.
  • The water bottle shall be able to withstand temperatures between: -10 deg F to 170 deg F–> defines operating scenario temperature requirements.
  • The water bottle shall be able to withstand humidity between: 0-100% –> defines operating scenario humidity requirements.
  • The water bottle shall be able to withstand a quantified amount of shock loading if dropped or thrown –> need to add numbers to this requirement.
  • The water bottle electronics enclosure shall be rated to at least IP67 –> defines the electronics submergence requirement, but not the entire water bottle’s ability to be submerged. 
  • The water bottle electronics shall follow the proper RoHS compliance so as to not expose the user to harm.
  • The water bottle shall follow DFMA protocols for easy assembly and disassembly –> notice how I don’t even list the protocols. 🙂 
  • The water bottle shall have a visual indicator that reminds the user to drink the necessary amount of water.
  • The water bottle shall be able to sense the amount of water located in the bottle within a certain range of accuracy –> hah, no accuracy listed and sensor resolution wasn’t even attempted.
  • The water bottle shall use the least amount of electronics and energy possible to deter adding components into its life cycle waste stream –> this is subjective. 
  • The water bottle shall be battery-operated–> Uhh, voltage and power requirements?
  • The water bottle shall allow the use of solar panels to operate –> well this came out of nowhere!


Luna knows I glossed over my functional requirements.

Now to be honest, defining your functional requirements is tedious and time consuming, but it is necessary. Now others may disagree. But the overall idea is that the functional requirements aids the design process by providing constraints. No constraints and we could be traveling through the infinite space and time of rabbit holes simply because as Cady Heron once said, “The limit does not exist.” It’s pretty much a formal process we gloss over during our academics, but debate over all the time in industry.


I do not own this image.

As Luna pointed out, I didn’t do a great job with my functional requirements. For instance I’ve completely glossed over the predetermined height requirement when the bottle is dropped. Is it 2 ft high and falls on a carpeted surface? Or maybe 4 ft high and falls on wood floors?  I’ll have to do more research on this requirement (if there are any standard protocols I should be following) or maybe I will make this completely dependent on the bottle’s material strength and test it during the prototyping/quality control stage. Or what about my sensor’s accuracy? Or my power consumption? I’m completely glossing over my electrical requirements because I am still relatively new to electrical design.


Leo judging my electrical skills.

So I’m making the choice to keep some of these parameters undefined until I do the proper research on these various functions. If I were working on a cross disciplinary team of engineers and product designers, I wouldn’t have to leave these parameters undefined because the functional requirements/product design requirements would be split up and completed by their respective parties. Then we’d review, debate, review, debate and continue this process until the end of the product development stage. 🙂 But because I’m riding solo right now the decision has been made to move on wards due to my strict timeline. Oh! Timeline wasn’t defined, was it? And what about cost? Well lets just say that cost needs to be minimal (whatever that means) and timeline is to have a minimum viable product by November 1st (Yikes!). So lets move on in the interest of time.


Leave a Reply

Your email address will not be published. Required fields are marked *