nus-se-script
commented
1 day ago Team's Response
EventManagerCLI is a CLI application that allows organisers of small-scale events to track of the participants and logistics of such events.
Realistically, our application is meant to be planning for events in the future and keeping track of participants and items of it. Of course we will take into consideration allowing adding of events into the present for our future versions of the program.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: Firstly, the team mentions that the application is meant to be planning for events in the future, however, given that this is not explicitly mentioned in the UG or DG, more specifically the target user profile, value proposition or user stories, this makes it rather hard to believe, especially given that events in the past are allowed to exist within the list and still be manipulated, as mentioned in issue #8.
Although intending the application to be used for future events is a valid design decision, it would require more explicit mentioning in the UG to be feasible. Marking the issue as Not In Scope does not address the current ambiguity of the user guide, as while the application’s design may align with its purpose, the UG specifies that events cannot be added in the past but does not explicitly state that adding events at the present time is also restricted. This creates confusion for users and makes the issue more significant than the team acknowledges.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** This is better classified as a "FunctionalityBug" than a "FeatureFlaw, as the behaviour contradicts user expectations and is not clearly documented. Marking it as a "FeatureFlaw" minimises the actual impact of the problem. Users would naturally expect that adding events at the current time is allowed unless explicitly stated otherwise. The lack of clarity in the UG creates an expectation that this should work, making it a functionality issue. By definition, a Functionality Bug arises when a feature does not work as specified in the documentation or as reasonably expected. In this case, the UG only specifies restrictions for past events and omits restrictions for the present. Since the UG’s incomplete explanation misleads users about the intended behaviour, this is a problem with the implementation not aligning with the documented expectations, characteristic of a Functionality Bug. A Feature Flaw occurs when a feature is incomplete or missing essential functionality for its intended use case. For example, if the application were unable to handle future events (its core purpose), it would qualify as a Feature Flaw. However, the functionality to add events is present and works for the future. The issue lies specifically in the inability to handle a narrow case (events at the current time), which is more of a limitation than a core functionality gap. The behaviour does not represent a missing "normal use" capability that renders the feature incomplete for its primary purpose (planning future events). It represents a discrepancy in expected behavior based on incomplete documentation. Marking this as a Functionality Bug focuses on fixing the discrepancy, while marking it as a Feature Flaw would incorrectly imply that the ability to add events at the present is an essential feature missing from the application's design.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** While the UG specifies that events cannot be scheduled in the past, it does not mention any restrictions for the current time. This creates a situation where users might frequently attempt to add events at the current time, especially during impromptu planning scenarios. Event organisers often work with real-time scheduling needs, and restricting current-time event additions could cause confusion or inconvenience on a more than rare basis. For users needing to track or log immediate events (e.g., creating a meeting or event as it happens), this limitation forces them to modify the time (e.g., by setting it a minute in the future), which introduces unnecessary friction. This behaviour can disrupt the normal workflow of users who rely on real-time scheduling, making it more than a "minor inconvenience" and likely to cause occasional inconvenience, which aligns with severity.Medium.
UG only specifies events cannot be added in the past, but present time is not allowed as well.