nus-se-script
commented
7 months ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Inconsistency with roles
Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.
One diagram shows the person with role attribute but the other does not.
[original: nus-cs2103-AY2324S1/pe-interim#179] [original labels: severity.Low type.DocumentationBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Good catch, thank you tester.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [x] I disagree
Reason for disagreement: I must express my disagreement with the decision to mark the issue of the "Random Address field" as a duplicate of the "Inconsistency with roles in diagrams" bug. While both issues pertain to discrepancies in documentation, they are fundamentally different in their nature and the aspects of the documentation they affect.
The "Random Address field" issue is related to the content of the application - specifically, a field in the user interface that is not accounted for in the application's functionality. This directly impacts the user's understanding and interaction with the application, as it presents a discrepancy between what is seen in the interface and the actual functionality. On the other hand, the "Inconsistency with roles" issue is a matter of inconsistency in diagrammatic representation. It pertains to the roles being represented in one diagram but missing in another.
The implications of these two issues are different for the end user or developer. An unnecessary field in the application interface (such as an address field) can lead to misunderstandings about data entry requirements or application functionality. In contrast, inconsistency in roles within diagrams primarily affects the understanding of the system’s architecture or data model among developers or technical analysts.
Addressing these issues would require different approaches. Removing or justifying the random address field would involve changes to the application interface or user documentation. Correcting the inconsistency in roles within diagrams would involve updating the technical documentation to ensure consistent representation of system components.
Since one can be fixed independently of the other, they are not duplicates (as per the module website).
Prof has also justified this in the forum that this should not be duplicates as fixing one does not automatically fix the other (Removing address field from the diagram does not address the inconsistency of the role field in the other diagram) .
Moreover, your team decided to mark this as a duplicate without any justification, especially with my description of the bug stating "No address field in your application".
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I respectfully disagree with the decision to classify the severity of the issue as low. This issue are more impactful than currently acknowledged and should be regarded as having medium severity. The presence of a random address field in the application interface, which does not align with the application's functionality, can lead to significant user confusion towards the DG. This is not a mere inconvenience; it directly impacts the user's understanding and interaction with the application. Users may spend unnecessary time trying to understand the purpose of this field, leading to frustration and a degraded user experience (hindering the user significantly). Accurate and consistent documentation is essential for understanding the system's architecture and for future maintenance or development work, especially for UML diagrams which are vital in understanding the product by future developers. Inconsistencies in such documentation can lead to misunderstandings or misinterpretations about the system's design, which is a significant concern for developers or technical analysts. This issue has the potential to cause more than minor inconveniences. The random address field could lead to misuse or incorrect data entry by future developers, affecting the application's overall data integrity. This can result in incorrect implementation or future modification to the application by future developers due to confusion from the extra address field in the diagram.
No address field in your application