gistfile1.txt

= Project: Pad-based salespoint

== Intro: 
At my relief organisation there's a frige. Everybody is able to take out drinks an to pay using cash.
This happends on a "trust" basis: Everybody puts the right number of coins in a cup nearby  
 - OR - marks, that's he's going to pay later one. 

== Idea / Problem:
We don't know how many drinks are sold. People have outstanding credits for quite a while.
This makes buying drinks cumbersome.

To address this issue, we'd like to put an android pad in front of the fridge. Everybody 
buying drinks is using the pad. 

Please note, that all backend stuff (datebase, network, etc.) is far less important. We can basically mock it.
Let's focus on the user experience (GUI, workflow, etc.). The application has to feel sexy.

Note: Security is not an issue. Everybody can take out drinks, anyway.

== 1st Milestone: List of drinks
"Basic stuff"
Use-Cases: (informal :-) )
UC01: Buying
Desc: The tablet displays a list of drinks. Each drink has a picture, a description, and a price. A buyer chooses a drink and a number of units (bottles, etc.)
on the pad. The transaction is stored on the pad.

UC02 Refilling: 
Desc: We must be able to manage the frigde
- Edit master data of drinks (enter, change, remove drink definitions)
- Add Units (bottles, cans) to the fridge
- Display the sum of sold and added units (ie: 3-7 = -4, if -7 drinks has been sold, 3 were added)
Note: This value may become negative if somebody forgets to mark the adding or the fridge is full in the beginning.

== 2nd Milestone: Accounts
"Must have"
UC11: CRUD Accounts.
Users must be able to Create, Read, Update (pay debit) and delete their accounts

UC12: Buy using debit / credit. While buying, users are asked to pay using cash or an account. If they choose "account", an account is chosen and the balance is decreased.

== 3rd Milestone: Nice-To-Have
-> Update Accounts using Bitcoins
-> Idle Screen showing pictues, homepage, upcoming schedule