-
Notifications
You must be signed in to change notification settings - Fork 0
Use Cases
Use cases for lepta are specified here. Use cases are separated into the following categories:
Information about current bills and debts is displayed. Included are:
- number of bills submitted by that user
- how many of those bills are unassigned
- total (currently) spent
- total (currently) owed
If there are no bills, "No data available" is displayed instead.
Preconditions: -
Postconditions: Account Overview is displayed.
Normal flow: User logs in and lands on Account Overview. The user is provided with information how much he/she owes his partner currently. This information updates when the partner makes changes using Distribute Items
.
Alternative flow: User clicks Back
- Button and returns to Account Overview.
Error flow: -
User needs more data about current bills and opens the Detailed Information View. Included information:
- total number of bills submitted by the user (including archived ones)
- number of non-archived bills submitted by the user
- how many of those bills are unassigned
- total (currently) spent
- total (currently) owed
- number of items submitted (including archived ones)
- number of non-archived submitted items
- number of unassigned items (submitted by the user)
- how many times have debts been paid?
Preconditions: User is logged in, Account Overview is displayed
Postconditions: Detailed Information View is displayed.
Normal flow: User clicks Extras
and selects View Details
. Detailed Information View opens.
Alternative flow: -
Error flow: -
A user wants to use other parts of the program or log out / leave the website. They close the Detailed Information View.
Preconditions: User is logged in, Detailed Information View is displayed.
Postconditions: Detailed Information is closed.
Normal flow: User clicks Back
- Button. Detailed Information View is closed.
Alternative flow:
User logs out / is logged out via timeout. Detailed Information View is closed and will not be displayed at the next login.
Error flow: -
A user wants to log in.
Preconditions: The user is not logged in.
Postconditions: The user is logged in.
Normal flow: When the user is not logged in he/she is presented with two text input fields. Upon entering the correct user name and password, he or she is logged into the platform. The password should not be viewed.
Alternative flow: The user may select to stay logged in. In this case, he/she will not be prompted to enter user name/password upon visiting the site the next time.
Error flow: When entering a user name or password that is not valid, an error message is shown.
A logged in user logs out.
Preconditions: The user is logged in.
Postconditions: The user is logged out and presented with the login screen.
Normal flow: A logged in user is presented with a button that enables logout. Upon clicking this button the user is immediately logged out of the platform and is presented with the initial login screen.
Alternative flow: -
Error flow: -
The first user visiting should be able to create the initial two user accounts.
Preconditions: -
Postconditions: The users specified are available on the server, and login
for those users is possible. Initial user colours have been set.
Normal flow: When visiting the site, if no users have been created to date,
the user is presented with a screen prompting him to create accounts for
him/herself and his/her partner. The user then can enter a user name and password for himself/herself, and for the partner. This should happen while the partner is sitting next to the initial user. After confirming the input the user is logged in.
Alternative flow: -
Error flow: When setting an invalid user name or password, and error message is shown.
A logged in user can change account data (e.g. user name, password, colour).
Preconditions: The user is logged in.
Postconditions: User data is changed.
Normal flow: By clicking a button the user is taken to a view where he/she can view their account data, e.g. user name. Upon clicking a button an edit mode is activated where data such as user name and password can be changed. After changing user name, password or colour the changes may be saved by clicking a "save" button.
Alternative flow: If changes were already made, the user can choose to cancel the process. If changes were made, the user is provided with a confirmation message providing information that already made changes will be lost.
Error flow: When setting an invalid user name or password and clicking the
save button, an error is shown. The user has to change his/her data before he/she can proceed.
A logged in user adds a bill manually.
Preconditions: The user is logged in.
Postconditions: A new bill has been added.
Normal flow: The user adds a bill manually. He/she can specify the name of the bill, the date, and the items on this bill. Per default, the current date is selected. When adding items to the bill, the user may specify name and price.
Alternative flow: The user may specify the date when the purchase was made manually by selecting the date from a date box. The user may also choose to cancel the process by clicking a cancel button. In this case, no confirmation message is shown and the user is taken to the previous view.
Error flow: If an invalid amount, name, or date was entered, an exception message is shown. If no items have been added to the bill, also an exception message is shown.
A logged in user adds a new receipt image.
Preconditions: The user is logged in.
Postconditions: The receipts and receipt items have been added and a review view is shown.
Normal flow: The user may add new receipts by taking pictures of them and uploading them. By clicking a button, the user is provided with a view where he/she can upload one or more images of receipts. When clicking a import button or similar, the images of receipts are analysed and converted to receipts and receipt items. While the system is processing the receipts, the user is provided with a view showing the progress. When analysis has finished the user is provided with a view where he/she can confirm that the receipts have been correctly parsed.
Alternative flow: -
Error flow: If no images are provided, an error is shown. If a receipt could not be analysed the user is provided with feedback.
A logged in user may review imported receipts/images.
Preconditions: The user has imported receipts by providing images.
Postconditions: The imported receipts and receipt items are in the database.
Normal flow: After importing receipt images, the user is provided with a view where he/she can confirm that the imported data is correct. Here, the parsed receipts, and receipt items are shown side by side with the imported image. The user may change parsed data, such as date, price of individual items, and name of individual items. By confirming that all is correct the receipt items are saved.
Alternative flow: Imported receipts that could not be parsed are shown also. In the same side by side view, the user may add individual receipt items and such while viewing the imported receipt item. The user may add a date, and individual items with name and price.
Error flow: If imported items that could not be parsed exist and have not been edited the user is provided with a confirmation message. When editing items and providing invalid names and cost an error message is shown also.
A logged in user views all new bills
Preconditions: The user is logged in.
Postconditions: The user views new bills.
Normal flow: A user may choose to view new bills, that is, bills that have not been distributed or archived. By selecting My Bills - new
the user is presented with an overview over all new bills. Here, the user may choose to add new bills, distribute bills, or edit/delete bills. If no bills exist, the user instead sees a message telling him/her that no bills exist yet.
Alternative flow: -
Error flow: -
A logged in user deletes new bills
Preconditions: The user has at least one new bill.
Postconditions: The bill has been deleted.
Normal flow: A user may choose to delete a new bill. That is, a bill that is neither distributed or archived. When selecting this action, the user is prompted to confirm the action.
Alternative flow: -
Error flow: -
A logged in user edits new bills.
Preconditions: The user has at least one new bill.
Postconditions: The bill has been edited.
Normal flow: A user may choose to edit a new bill. That is, a bill that is neither distributed or archived. By changing some stuff and selecting "save" the changes are saved.
Alternative flow: -
Error flow: If changes are invalid (e.g. invalid names or price data) an error message is shown.
A user wants get information about old (already settled) bills. They open the program's Archive View, which contains data about:
- total money settled
- number of archived bills submitted by the user
- total cleared debt
If a user has not settled any bills yet, the Archive View is replaced with a short instruction about settling bills.
Preconditions: User is logged in, Account Overview is displayed
Postconditions: Archive View (of currently logged in user) is displayed.
Normal flow: User clicks Extras
- Button and selects Archive
. The Archive View is opened.
Alternative flow: Users clear current debts. When they are notified that the process was successful, they click Archive
.
Error flow: -
A user removes archived bills
Preconditions: The user views archived bills.
Postconditions: The archived bills have been removed.
Normal flow: A user may choose to remove bills from the archive by selecting archived bills and clicking delete
. The user is prompted with a confirmation message. Items removed by a user are still visible for the other user.
Alternative flow: The user may click the clear archive
button. He/she is then prompted with a confirmation message. By confirming all archive items are deleted. The items are still visible for the other user.
Error flow: If no items are selected, deleting is not possible.
A user wants to use other parts of the program or log out / leave the website. They close the Archive View.
Preconditions: User is logged in, Archive View is displayed.
Postconditions: Archive View is closed.
Normal flow: User clicks Back
- Button. Archive View is closed.
Alternative flow:
User logs out / is logged out via timeout. Archive View is closed and will not be displayed at the next login.
Error flow: -
#Balance
A logged in user distributes receipt items from receipts he/she paid for.
Preconditions: The user is logged in and has some receipts and receipt items imported.
Postconditions: The bills the user edited are marked as "worked on".
Normal flow: The user reviews each receipt with it's receipt items, as well as individual receipt items, and distributes them into one of two pots: I shared this with my partner 50/50 or "this belongs to my partner". If none of those pots where chosen that means that the item was bought for the user him/herself. The user may navigate between individual receipts. The user may confirm each individual distribution of a bill by clicking a save
button. The user is provided with information how many receipts have not been reviewed yet. When all new bills have been submitted to this process, the user is prompted with a message telling him/her that all items are done.
Alternative flow: The user may also view images for receipts if the receipts were imported.
Error flow: -
Users want to clear their current debts. They use the "Pay Debts" - Functionality to display their balance and archive currently assigned bills after the debt has been paid. Both users need to approve.
Preconditions: User is logged in, Account Overview is displayed, there are unpaid debts, the second user clicks all necessary buttons as well.
Postconditions: All assigned current bills are archived as they are no longer relevant.
Normal flow: User clicks Pay Debts
- Button. A new view opens and tells them how much to pay / how much money they are owed. The may choose to display details, e.g. all relevant bills where a distribution has been set. When they are done, they click the Done
- Button and have to wait for their partner to do the same. When both users are done, all currently assigned bills are archived. Users are told that the process was successful and they get to choose between 2 Buttons, Home
and Archive
.
Alternative flow: -
Error flow: There are two error cases:
-
One user clicks
Done
, but the other one does nothing or clicksPay Debts
and thenBack
instead ofDone
:
No new bills can be added and no unassigned bills can be assigned until the process is either finished (because the second user clicks the correct buttons) or aborted (the first user clicksAbort
). -
User clicks
Pay Debts
, but notDone
:
Nothing special happens. The user can either continue (Done
) or return (Back
)