Release 1 Documentation - CSC4790-Fall2024-Org/Grocery-Receipt-App GitHub Wiki

1. 360 Perspectives of Users/Stakeholders on Wiki

  • For Users, this app primarily targets students who routinely shop together for groceries and pay on one card.
  • Every user should have the capability to upload a receipt, add an unlimited number of users to split the receipt items across, and if possible connect their Venmo account to facilitate the process of sending the money that you owe.
  • Every user should have equal rights to select who paid for what or choose if an item is shareable.
  • Every user should have the capability to modify the item name or item price in the situation the algorithm incorrectly calculates the price.
  • In the testing phase, Developers should be able to see all user information, instances users they have scanned a receipt (if the scan was successful/with the receipt), the users they added to split the receipt with, and the final lists/price breakdown after the item delegation. So for each use of the app, developers can see the results of each component.
  • Closer to the final version of the app, Developers should have limited access to user information, see if a receipt was correctly scanned, and then some form of user feedback feature at the end of the process so developers can see if the app did what it was supposed to/failed to do so.
  • Stakeholders should be able to see # of receipts processed, total amount of money processed through the API, and current/new users accessing the app (on monthly basis. If enough time, potentially a feature where users can report bugs or make suggestions in the app.

2. Risk identification and mitigation plans

  • The main components of the app are the upload feature, the Amazon Textract API reading the receipt, the designation feature/splitting feature, and then if possible the Venmo connection.
  • A potential issue with the upload feature could be if the user uploads the wrong image, all users should have the ability to re-upload prior to sending it to the API to prevent unnecessary requests.
  • In the scenario the API reads in incorrect pricing information, all users should have the rights to manually edit the pricing, and the name of the item.
  • If the API fails to read in the receipt data consistently, potentially integrating the confidence interval feature within the API where the algorithm produces a numeric representation of how accurate it believes it was when reading in certain values/text found in the receipt. Taking this idea a bit further, we could potentially incorporate a flag feature where if the API produced a low confidence interval score for a specific price we could flag that item/price to let the user know to double check the receipt since the API could've read it in incorrectly.
  • If there is enough time to add this feature, our idea on how to prevent a lack of trust with the designation/splitting feature all the users should have access to another page within the mobile app to see a running list calculating all the items they are said to have bought for themselves with a visible representation of the items being added up.
  • If we were to connect Venmo, we would need some way to guarantee the name and price the app is intending to send during that stage of the app is correct. We might have to add like a Push verification feature where before a request is made saying X user owes Y money the user themselves can agree to it first via the push.

3. Documentation on Scope

  • The main concern that we have with scope currently is the implementation of a payment service. We aren't sure yet if it is within our scope to include connection to Venmo or Zelle to make the payment process easier. Our plan to address this is to gauge our possibilities as we develop our project and decide whether or not we will attempt the payment service connection later into our project. We believe that this is a good approach because we see this feature as additional, as our shallow trench stories don't require us to include this since we think that our app is still a complete product.
  • We hope to make the scope big enough to where this app works for all receipts from retail stores. We are approaching the app in a universal mindset hoping to create algorithms with Amazon Texttract where we can make our app functional for different formats of receipts, rather than just a few stores that have straight forward, easy to decipher receipts.

4. Modelstorming First Draft

image

5. Competing Products

  • "Tab - the Simple bill splitter" On Apple App Store: This app has similar functionalities where it reads a receipt automatically, bill is split, and venmo is used to pay. One difference is that Tab makes others join the same bill from their own phones, where our app would have it all done on one phone. Also, it is mainly used for restaurant bills where ours is for groceries.
  • "Splid" On App store: This, along with multiple other bill splitters, use credit card connection rather than receipt reading.
  • "Splyt" on App store: This app is the most similar to our idea. The only difference again is that they have the functionality to invite friends to join and choose themselves, whereas ours is all by one user. It is also mainly used for restaurants.
  • Overall, there are apps that have similar ideas/functionalities as ours, but are advertised for different uses. Many of these apps are advertised to restaurant bill splitting, whereas ours is going to be advertised towards grocery receipts. Also, we are not connected to credit cards like some, rather we are reliant on receipts.

6. Feasibility

The baseline resources needed for this app already exist, the challenge is combining them into a streamlined app. The OCR we are planning to use for text reading is Amazon Textract (https://aws.amazon.com/textract/). It is free for 100 pages per month, so beyond our testing phase we will need to either switch accounts to one of the other group members or consider paying for the API. For under a million pages in a month, it would be $65 which is not cost effective for our purposes, so avoiding this situation is for the best.

The uploaded photo and produced data will all be temporarily stored, so now database or authentication will be needed.

There is a potential for sending messages to the people you are sharing the receipt with, however that is a feature we will only add if we have time. That will use sms libraries already implemented in React Native.

7. Interview with Stakeholder

I interviewed Senior Economics and Communications double-major Carter Smith for his thoughts on design, feasibility, scope, and general thoughts and pitfalls of the application. The conversation was paraphrased with his answers/questions under the bullet points below.

What are you initial thoughts on an application like this?

  • Intrigued by the concept and sees the usage. First things that stand out are data collection and what the end production is.

Data will not be saved in the app and sign-in will not be necessary. No personal data will be required on the user side in the initial release goals.

  • What is the expected output of the app? Is it just a breakdown table, or a sharable breakdown, or a Venmo connection, or an alternate result?

In our initial release goals, the plan is for there to be a breakdown of how much each person owes and the associated items that will be shown within the app. If timing allows, the sharing aspect will be added into the app. How that will manifest is still in discussion. The most viable option that we see so far is a connection to sms and messages that can be sent to the people the receipt is being split with.

  • Integration with a sharing feature would make this app more useful for me. In a dream scenario some sort of payment integration as well, however that is much less important to me than just being able to share the price split and the items.