requirements:informelle_anforderungen
Table of Contents
Funktionale Anforderungen
Allgemeine Anforderungen
- die App besteht aus einem Kern (“core”)
- der core darf zu keinem Zeitpunkt network-permission bekommen
- das sollte auch beworben werden
- geplant sind Zusatzmodule für erweiterte Funktionen
- diese Module können auch network-permission bekommen
- die Module sollen sich über den Play-Store nachinstallieren lassen (wie z.B. die App “TaskBomb”)
- UNKLAR: wie bewirbt man neue Module ohne network-permission?
Datenbank
- für die persistente Datenhaltung speichert die App Informationen in einer Datenbank
- die Datenbank hält Tabellen bereit für
- Lebensmittel
- Rezepte
- Statistiken
- Benutzerdaten
- die Suche nach Werten in der Datenbank muss mit AutoCompleteTextViews oder vergleichbaren UI-Elementen passieren
- die Datenbank kommt mit zentral moderierten und manuell ergänzten default-Einträgen
- VISION: Benutzerinteraktion:
- Benutzer können über ein Zusatzmodul Rezepte austauschen oder irgendwie zentral hochladen
- wenn ein Rezept zentral hochgeladen wurde, darf ein Rezept erst nach Moderation freigegeben werden
- die Datenbank kann durch den Benutzer durch Eingabe Lebensmitteln, Rezepten und Benutzerdaten
Lebensmittel
- Benutzer kann Lebensmittel (“food”) eingeben und speichern.
- ein Lebensmittel hat Angabe über
- kcal
- Protein
- Kohlehydrate
- Bezugseinheit
- die Maßeinheit, auf die sich die oben genannten Werte beziehen, z.B. 100 g)
- default ist “Portion”
- EAN
- die Angaben der Lebensmittel müssen erweiterbar sein (für den späteren Gebrauch, z.B. Angaben über Vitamingehalt → evtl. sogar für Benutzer einstellbar?)
Rezepte
- Benutzer kann Rezepte (“recipes”) eingeben und speichern
- ein recipe besteht aus
- einem Namen
- >1 Zutaten, die wiederum Lebensmitteln (“food”) oder anderen recipes entsprechen
- UNKLAR: Was passiert, wenn ein food eingegeben wird, das bisher noch nicht als food gespeichert wurde?
- gewichteter Mittelwert aller Nährstoffangaben
- Bezugseinheit
- jedes Rezept hat als Grundeinheit “portion”
- Idee: Benutzer die Möglichkeit geben, die default-Anzahl an Portionen in Settings einstellen zu können (“Ich koche in der Regel immer für 2 Personen, also ist der default auf “2 Portionen”)
- wenn ein Rezept über eine gemeinsame BasicUnit verfügt, dann wird als alternative Einheit diese BasicUnit angegeben
- andere BasicUnits (Gramm, Milliliter) können als Alternative zu den Portions angegeben werden
- wie bei food. Wenn eine gemeinsame Einheit gefunden wird, dann wird auf diese Einheit Bezug genommen. Ist keine gemeinsame Einheit vorhanden, wird ein default “Portion” verlangt (“das Rezept ist für 4 Portionen”)
Tagebuch
- die App hat ein Tagebuch
- das Tagebuch besteht aus Einträgen (“entries”)
- ein Entry besteht >=1 Mahlzeiten (“meals”)
- ein meal besteht aus einem food, einer Portion eines Rezepts oder einer Portion einer “temporären Recipes”
- ein Entry kann ein “temporäres recipe” sein
- ein temporäres Recipe ist ein generisches Rezept, dass sich häufig ändert (“Butterbrot mit XY-Belag”)
- Idee dahinter ist, dass einige entries merkwürdig erscheinen können, wenn sie einzeln und nicht summiert erscheinen: z.B.: “66g Brot, 5g Margarine, 16g Salami” → das ergibt zusammen “ein Butterbrot”, ist aber kein dauerhaftes Rezept
- für ein temporäres Recipe ist ein optionaler Titel möglich. Ist der Titel leer, werden in der Tagesansicht die Grundzutaten angezeigt, bis der Anzeigeplatz aufgebraucht ist.
- Beispiel: Ein temporäres Recipe sei das o.g. Butterbrot. Ohne Angabe des optionalen Titels ist dann in der Tagesansicht der Eintrag mit dem Titel “Brot, Margarine, Sal…” zu sehen (Anzahl der Zeichen wird auf verfügbare Darstellungsbreite beschränkt)
- besteht ein Entry aus mehr als einem food, dann wird es als “recipe” angesehen. In der View wird, sobald mehr als ein food in einem entry eingegeben wird, wird eine Checkbox “als Rezept speichern” angezeigt. Ist der Haken der Checkbox gesetzt, ist die Angabe eines Titels Pflicht.
- das Tagebuch zeigt die neusten Einträge oben
- jeder neu eingefügte entry muss zuverlässig gespeichert werden
- jeder entry summiert alle Nährstoffe in einer Übersicht, die sowohl in der Detail-Ansicht des Entries, als auch in Kurzform in der Tagesübersicht zu sehen ist
- jeder entry vergleicht die summierten Nährstoffe mit einem Tagessoll
- ein Tagessoll ist z.B. die maximale Menge an kcal, die ein Benutzer am Tag zu sich nehmen möchte
- dieser Tagessoll muss vom Benutzer festgelegt werden
- es müssen für unerfahrene Benutzer hier Vorschläge über durchschnittliche Werte angegeben werden (eine erwachsene Frau im Alter von 30 Jahren benötigt im Durchschnitt 2000 kcal/Tag, um nicht zuzunehmen)
- Vision: es gibt solche Rechner im INet zuhauf, aber vielleicht integriert man einen einfachen Schätzer, der durch Fragen an den Benutzer (Welche Tätigkeit üben sie aus → sitzend, vorwiegend sitzend, leichte körperliche Arbeit…; wie viel Sport treiben Sie…) einen zirka-Wert für die Sollwerte berechnet
- UNKLAR: Was passiert beim Unterschreiten oder Überschreiten? Da müssen Toleranzwerte festgelegt werden
Statistiken
Benutzerdaten
- Benutzerdaten sind Daten, die für einen Benutzer individuell angelegt werden und diesen beschreiben
- Bestandteil der Benutzerdaten sind
- Angaben über Zielwerte der Nährstoffe (kcal, Protein,…)
requirements/informelle_anforderungen.txt · Last modified: 2013/09/19 15:13 by martin