nus-se-script
commented
9 months ago Team's Response
Our users are clearly narrowed down our users to hotel employees, which also can be administrators. Furthermore, Similar methods for writing user stories can be seen on the CS2103T textbook:
Moreover, it looks like your reference to the project restriction is as below which does not specify the user stories:
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Adding characteristics is to give more context to the user story. The functions should still be available for all users of that particular user role. In here, you are specifying an additional user role that requires a different level of access control. In a common role-based access control implementation, they will definitely be considered as different roles, normal hotel employee and hotel employees that are administrators. For example, the user story in your developer guide, as a admin, I want to set room rates so that i can ensure clients are charged appropriately is definitely not applicable to regular hotel employees which is your target users. Should the final target user be hotel admins instead of hotel employees, i would have accepted the argument. The example given in your screenshot is irrelevant to the discussion since a learning management system is not a application for a single user.
The second argument is quite a stretch as well, given that the application itself is a single user application, there is no reason for there to be user stories of additional users. Future developers reading this user guide may mistake the application for one that is meant for different users. For this reason, I think that this should be a severity.Low instead of a severity.VeryLow
user stories have both hotel employee and admin as users, but project restrictions states that there can only be 1 user. These user stories should have been removed