Original project requirements

[kbuffardi]

Here are the original project requirements that motivated the MVP implementation
OriginalProject.pdf

[kbuffardi]

And its extension (that was for the final exam in the original semester)
OriginalFinal.pdf

[reembot]

I reviewed the original project requirements from the pdfs above and outlined them here. Please check off any existing and completed requirements or edits/concerns here by the end of this Sprint (Friday 4/21). We can discuss strategy and create issues out of the remaining ones for next sprint:

QUERIES:

• Check individual item availability - Check individual item availability & Adding item quantity #175
• Check individual item quantity - Check individual item availability & Adding item quantity #175
• Report all donations by provider / individual / anonymous donor showing:
  • number of transactions - Donor Lookup and Add Donation at Checkout #193
  • quantities of donations - Donor Lookup and Add Donation at Checkout #193
• Auto Daily report generation showing:
  • food due to expire in the next 2 days - Issue 81, PR 173 : backend completed, PR224 : frontend completed
  • food already expired specifying quantity - Issue 81, PR 173 : backend completed, PR224 : frontend completed
• On-demand report generation for:
  • total amount of food donated measured by quantity/weight - Issue 223, Backend PR
  • total amount of food checked-out by students - Issue 223, Backend PR
  • total number of different students who checked out food - Issue 223, Backend PR
  • total number of checkouts - Issue 223, Backend PR

---

In order to complete the above, we'll need our data structured something like the below. A lot of this is redundant to what's already been handled, and obviously not all-encompassing to what's needed to be operational; I'm just laying out all of the requirements defined in one place here. We can create an updated UML if/when needed:

TRANSACTIONS:

• Transaction ID
• Type:
  • a. Donation
    • account ID
    • expiry date
  • b. Purchase
    • cost
    • expiry date
  • c. Check-Out
    • account ID
  • d. Disposal
  • e. Rental
    • account ID
    • due date
  • f. Return
  • account ID
  • Original Transaction ID
• Item ID
• Quantity
  • a. count
  • b. weight

ACCOUNTS:

• Account ID
• Type:
  • a. Student (no name to remain anonymous)
  • b. Donor
    • b1. Provider (organization)
      • name
    • b2. Individual
      • name
    • b3. Anonymous (same ID for all)

ITEMS:

• Item ID
• Name
• Type:
  • a. Produce
    • PLU code
  • b. Packaged
    • UPC code
  • c. Equipment
    • count rented out (unavailable)
• Quantity
  • a. count
  • b. weight

[reembot]

Please comment on anything that looks incorrect or needs changing!

[parthpandey1]

While this is a very thoughtful layout, it would require significant code refactoring to incorporate these changes in the models at this point, given the progress that has already been made in the project.

[jayrevolinskyjr]

While this is a very thoughtful layout, it would require significant code refactoring to incorporate these changes in the models at this point, given the progress that has already been made in the project.

Many of the original project requirements work with our database schema in a way that preserves the higher-level functionality of the original project. So, refactoring of the database is not and has not been required, as @reembot made a point with:

A lot of this is redundant to what's already been handled, and obviously not all-encompassing to what's needed to be operational; I'm just laying out all of the requirements defined in one place here.

However, the features that were present in the original project do require implementation in the current project as shown by the labelled issues aboves with #81, #175, #193, #223.