As per our understanding, the purpose/Usage of the App is as following -:
Q: Are we correct upon this ? Also did we miss anything ?
The app resolves three main purpose -:
Usage of the app -
Daily Routine -:
Additional Feature (apart form daily routine) -:
Q: How much the hawkers [users] can scale up to ?
Q: Is the password to be set for auto-generated user-email?
Assumption: The users here can only be hawkers.
As in we don't have any kind of role management for cases such as shop-login or administer-login.
Are we correct to assume this ?
Assumption: Multiple/simultaneous login with same number is NOT allowed.
Are we correct to assume this ?
Assumption:
Are we correct to assume this ?
[Screen will be prepared shortly]
Q: From where do we need to lookup for retailers data.
Q: Which field shall we use for uniquely identifying retailer records.
Q: Does the App requires max login attempts validation ? [To prevent kind of DOS attack]
Q: Does the App requires max re-send attempts validation ?
After successful login, hawker lands here.
Q: On what basis do we segregate the shops into Buy/Sell categories ?
As in does a scenario exist where a shop behaves as a dealer [buy from] and retailer [sell to] both ?
Clicking upon Buy/Sell this screen pops up.
Q: Do we need to show the nearest shop in a particular radius?
Q: How and by whom the shops-delete / update will be maintained ?
Suggestion - soft-delete
Q: Do we need to manage a Race Condition for hawkers ?
[user scenario -: when two hawkers select the same shop to buy/sell]
Capacity [buying/selling] of each shop
Q: Should we have a measure of shop size ? [Does the hawker needs to know the same before selecting a shop to buy/sell ?]
OR
Should we look into trends for that ?
One time data collection
User Case Scenario -: Sell
Q: How will a hawker get to know about a product order?
OR
If we are dealing in daily targets [to sell] then where and by whom would that be managed [added/edited] for each hawker ?
User Case Scenario -: Buy
Q: How will the hawker know that his demand will be fulfilled by the nearest shop [or which shop] ?
OR
This doesn't matter at all, as in the hawker has to visit various shops to try his luck!
Q: Does the shop existence and business-of-the-shop needs to be validated ?
Selecting any shop and searching for a product via text-code/scan-bar-code, this screen pops up.
Q: How and by whom product properties [create/update/delete] will be maintained?
Q: Do we have an initial data seed for available products ?
Q: How much the products can scale up to ?
Q: Can the price of the product vary as per shop ? How is price modification to be handled ?
Q: Does the selling-price for a product remains fix ? Are we correct to assume that the hawker strictly sticks to the mentioned price ?
Needs Clarification
Are we correct to assume the above ?
PS-: The same concept is to be used when managing the product quantity in cart screen as well
User Case Scenario -: Sell
-> While increasing the count of product [to be sold], the app should validate the same with max-capacity. [from total hawker-inventory details]
User Case Scenario -: Buy
-> This operation might be triggered after the actual purchase is done, so there shouldn't be any checks on product-quantity [to be bought] evaluation.
Assumption:
Disclaimer:
Are we correct to assume this ?
User Case Scenario -:
In case after the checkout-splash screen the transaction failed [uncertain reason].
Q: Do we need a transaction confirmation option ?
Q: Do we need a revert option ? [To sync up the inventory]
Assumption:
Opening inventory will be empty for first time users and
will be last-days closing inventory for regular users.
Are we correct to assume this ?
Q: Inventory update is to be done on checkout or at the time of scanning ?
Optimal use of trends
Q: Do we need a way by which the hawker may leverage the use of trends optimally.
Suggestion -:
User can view/edit his profile
If the user modifies registered phone-number -: