EatFit

EatFit is a project I built as a full requirements specification: vision, scope, stakeholders, system boundaries, technical approach, and quality attributes. The goal was to design a product that’s useful to real people and credible in a regulated environment— not just a nice UI.

The app targets home cooks who want to understand the nutritional content of meals they prepare, using verified USDA nutrition data and flexible input options (recipes, ingredients, photos, and voice).

Problem the Product Solves

Nutrition tracking is easy when you scan a barcode on a packaged item. It becomes messy the moment you cook. Home-cooked meals often combine packaged components (oil, bread, meat) with fresh ingredients—so users end up guessing or giving up.

EatFit’s purpose is to make nutrition tracking practical for home cooking by supporting multiple input methods and translating ingredients into clear nutrition insights and trend monitoring over time.

Core Capabilities

• Ingredient + recipe analysis with USDA data integration.
• Flexible logging via ingredients, saved recipes, photo input, and voice input.
• Nutritional breakdown with suggestions and visualizations (macros/micros).
• Multirole support (users, nutritionists, admins) with different needs and controls.

Scope Boundaries

This is where a lot of student projects fall apart: they try to be everything. EatFit has clear boundaries.

• In scope: ingredient/recipe analysis, USDA integration, nutrition breakdown + suggestions, data visualization, voice/photo input.
• Out of scope: medical advice/clinical diagnosis, in-depth fitness tracking, advertising/promo features.

Technical Approach

The spec includes a practical stack and deployment mindset that fits the product’s risk profile:

• Frontend: React Native for cross-platform delivery.
• Backend: API services hosted on Microsoft Azure.
• Data: Cosmos DB for user and nutrition data, with row-level security considerations.
• Compliance posture: designed around HIPAA and GDPR expectations for sensitive health-related data.

Quality, Security, and Operational Readiness

The requirements go beyond features. They include quality attributes and operational controls— the stuff that prevents “it worked in dev” disasters.

• Reliability and recovery: targets for uptime, backups, and recovery objectives.
• Scalability: measurable performance expectations under load.
• Auditability: requirements for log retention, tamper evidence, and suspicious access alerts.
• Platform coverage: portability across web, iOS, and Android.

How I Worked

I structured the document to align with OpenUP principles: collaborate to align interests, balance priorities using MoSCoW, focus on architecture early, and iterate with continuous feedback. The point wasn’t methodology worship—the point was building a repeatable way to reduce risk early.