Written Report on Model (Testing): Difference between revisions
No edit summary |
|||
| Line 4: | Line 4: | ||
# Ubiquitousness of Splits, | # Ubiquitousness of Splits, | ||
After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions. Though the current application gives the impression that it's | After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions. | ||
Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.). | |||
Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this. | |||
But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the Report for View (Testing) section. | |||
== Testing == | == Testing == | ||
Revision as of 14:44, 20 October 2009
Model Analysis and Testing
Model Analysis
- Ubiquitousness of Splits,
After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.
Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).
Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.
But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the Report for View (Testing) section.