Open OVReader opened 1 year ago
We acknowledge that this is a very subtle discrepancy as not all rental managers are NUS students. But this product is still relevant as NUS students managing rental businesses on campus still deal with money and need a good way to track these transactions
Team chose [severity.VeryLow
]
Originally [severity.High
]
Reason for disagreement: The discrepancy should not be perceived as subtle as claimed by the dev team as it can be potentially lead to failure of Quality Assurance for Validation as shown in picture below.
To begin, NUS students and rental managers are two very distinct and different set of entities.
NUS students: Learning/dealing with small transactions within a very confined environment such as school setting
Rental Managers: Required to adhere to business-related law, environment is stricter and transaction limits are higher.
The following is an example "The end-user records customer's name as some nickname." to portray their difference.
For NUS students, this poses no issue at all. However, for rental managers, this may lead to failing a government audit (not adhering to compliance) which can result in the loss of license/restricted business.
In the DG, based on the descriptions provided in Target User Profile
and Value Proposition
, the end-user of this product is probably a "NUS student learning/dealing with small transactions within a very confined environment such as school setting".
With this discrepancy, it would cause problems to both stakeholders and end-users.
From a stakeholder's perspective, the end product is expected to be fit for the target user specified in the DG. However, when the product is released along with its UG, the UG now says that it is for rental business managers which is for an entirely different set of target user who are working in an entirely different environment such as actual/practical business environment.
Also, a big difference in expectation of feature will appear for end-users. According to the dev team, the application is designed for NUS students. However, for example, as a user who does not know anything about DG, while reading the UG it says the product is for rental business managers, it might be expected for the product to handle maybe higher values of transaction depending on the nature of items.
Thus, with multiple parties who can be led to confusion, along with the possibility of failure of Quality Assurance for Validation due to ambiguity of actual target user, it is arguable that the severity for this bug should be set to High
.
In UG, the app is targeted at rental business managers which are handling large number of transactions yet in DG the target user are NUS students staying at hall handling borrowed items (which does not involve any monetary transaction), making the basis for the product irrelevant.