Check out Part 1 of the series if you missed it.

As the project advances, the focus shifts from conceptualizing ideas to defining precise requirements—laying the groundwork for a minimal yet functional Proof of Concept (PoC).

Minimalistic Approach to Make it Work

In the quest for simplicity, I explore the most fundamental elements necessary to bring this concept to life in a PoC:

  • Sources: Initial implementation involves hardcoding news and weather location, and leveraging Google Calendar API and Google Tasks API for events. Simplifying the process by potentially hardcoding keys and settings in the backend.
  • Settings: Identifying essential settings—potentially hardcoded prompts at this stage to speed up development.
  • Content Generation and Audio: Striving for simplicity in content generation by feeding generated content to a text-to-speech API. Investigating the feasibility of incorporating background music or sound.
  • Setting the Alarm: With the right permissions, setting the generated audio as the alarm should be straightforward.

The Boring Yet Essential Part – Requirements

Despite the allure of diving straight into coding, defining requirements proves pivotal. It’s not about constraint but direction—a roadmap to ensure I don’t spend days chasing bugs in some arcane API (which I ended up doing anyway, but that’s a story for another day).

This isn’t about external mandates; it’s about channeling efforts effectively.

And these are the requirements that I managed to agree on (with myself, really). Following the RFC 2119 guidelines:

  1. The solution MUST:
    • Read data from external sources like Google Calendar APIs, Google Tasks APIs, The Guardian APIs and OpenWeatherMap APIs.
    • Generate an audio file comprising a concise summary of the user’s daily events, tasks, relevant news, and weather conditions.
    • Enable transfer of this generated audio file to the user’s Android phone.
  2. The solution MUST ensure:
    • The generated audio file is seamlessly integrated as the alarm ringtone every day without requiring any user intervention.

Allons-y!

1 thought on “Not-An-Alarm – Part 3/5 – From dreams to requirements

Leave a Reply