nus-se-bot
commented
1 week ago Team's Response
This should be a documentation bug instead of a feature flaw. The DG outlines these NFRs, but the implementation does not meet them, this indicates a discrepancy between what was documented as the intended design and what was actually delivered. The issue lies in how the documentation sets unrealistic or unfulfilled expectations for the current version, not necessarily a missing or broken feature. The role of the DG is to clearly specify the intended system behavior and requirements. If the NFRs are listed but not practically achievable or realistic given the project scope and implementation constraints, the documentation should have been updated to reflect what was realistically achievable for the release version. This failure to update the DG to match the current implementation is a flaw in the documentation process rather than the software's feature set.
This should have a severity of low instead of medium. The unmet NFRs do not directly affect the core functionality of adding, viewing, or deleting expenses. Instead, they pertain to how well the product performs under certain conditions (like speed, error handling, and customization). While they are important for overall user experience, they do not make the product unusable. The risk of data integrity issues from direct raw file editing is an edge case and not a regular scenario for the average user. The lack of extensive customization options for categories is a minor inconvenience rather than a critical problem. Missing automated tasks like budget resets might be a nice-to-have feature but does not prevent users from manually managing budgets. Usability concerns with index locations are more about user experience and less about breaking the application.
Items for the Tester to Verify
:question: Issue type
Team chose [type.DocumentationBug]
Originally [type.FeatureFlaw]
- [x] I disagree
Reason for disagreement: I think that since the DG sets goals, the actual implementation needs to achieve this goal. That's the point of having a goal in the first place: to implement a software that reaches that goal; you don't just edit the DG to lower your goal if you don't meet these goals. Furthermore, we're talking about non-functional requirements - requirements that "specify the constraints under which the system is developed and operated", which requires calculation from the stage of product design (i.e. when designing the system, you have to think forward to make these goals possible). The current implementation is hindering these requirements' fulfillment, so I have to flag this as a feature flaw.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Here are the counter-arguments that I have with respect to your response: - **"they (the unmet NFRs) do not make the product unusable"**: this only means the severity is below `High` (i.e. can be Medium still). - **"The risk of data integrity issues from direct raw file editing is [...] not a regular scenario for the average user."**: Based on the tP constraints, raw file editing is expected from the user's side, hence corrupt data handling mechanisms need to be developed accordingly. - **"The lack of extensive customization options for categories is a minor inconvenience rather than a critical problem."**: I think NFR `#4 - Customizability` is a critical requirement to the software's success - something that users look forward to and sets this product apart from other expense trackers. The severity doesn't come from how much inconvenience it causes, but how fundamental this requirement is to the whole product. - **"Usability concerns with index locations are more about user experience and less about breaking the application."**: The bug report only gives an example of the issue - there are much room for improvement, and these issues don't take much effort to rectify. When dealing with feature flaws, it's not about whether the software breaks - it's about the user's experience and sentiments towards the product. I think your team is emphasizing on the fact that the product doesn't crash, hence give the issue a low severity.
Here is a breakdown of some NFRs that are not met by the product's implementation:
2. Data Integrity: Data format can be compromised via editing the raw file.4. Customizability: As of v2.1, the only information associated with expense categories is a limit. This does not provide much room for customizing expense categories.5. Automated Tasks: Has not been achieved as of v2.1.6. Accessibility: The interface can be cluttered and hard to read. Parts of the UI arrangement is counter-intuitive (e.g. the location of expenses' INDEX).