Possible too much UI and implementation details here

[nseah21]

There is too much detail here, which should not be the case for use cases.

Other developers might choose to add other fields for a customer, which will then contradict with the existing use case and require updating.

[nus-se-bot]

Team's Response

Thank you for submitting this report! For the implementation detail issue in this user case, we would like to refer to this user case below in the textbook (week 7 topics),

This user case is regarded as a good example of user case in the textbook, and the implementation detail: name is mentioned in the 3rd point. Our user case learn from this point, and simply adds in several common personal fields similar to name, such as phone number, email, etc. Therefore, we think the implementation details in this user case is not an issue.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I would like to reiterate that adding implementation details in the use case can decrease maintainability of the use case. This is because each time an additional modification is made to the feature, such as adding a new field to the existing customer fields, it will require the developer to update the use case with the additional field.

Furthermore, the specification of the implementation details of this use case could be too detailed, causing the developer to have less flexibility when implementing the feature. For example, he might decide that it is more feasible to replace a customer's date-of-birth with their age, but would be constrained by the details in the use case.

I would also like to highlight the difference between the team's use case in their DG and the textbook example provided by the team in their response.

In the textbook's "UC02 -- play a game" (refer to screenshot provided in the team's response), the player only enters his name because the system requests for the player name. In another example (UC23) below, we can see in point 2 and 3 that the behavior of the user is different when the system does not specify the particular details in its request to the user. As a result, there is no need for the user to specify what details he is entering to the system.

For the team's use case for adding a customer, however, the implementation details seem to be specified based on the user's initiative, which does not seem consistent with the examples provided in the textbook.

For the reasons mentioned above, I believe that this is a valid documentation bug. This bug will hinder the other developers who are referring to the use case, and hence it is of severity.Low.

---