Table of Contents
This chapter contains a description on how ArgoUML should work and behave for the users.
These things might not be implemented yet and the solutions might not even be clear but it is a definition of the goal.
The fact that it is not implemented or doesn't work as stated here should be registered as a bug in the bug registering tool.
Every requirement has a number (REQ1, REQ2, REQ3, ...) that never changes, a revision (REVa, REVb, REVc, ...) that changes when the requirement change, a text that is the requirement text to implement, a rationale that is the description on why this is important, a stakeholder that is one of the stakeholders in the vision for who this is important.
This describes how the ArgoUML look and feel shall behave.
REQ1 REVa
Rationale: There is no way of telling where the user is looking while working with ArgoUML. For this reason he might be terribly confused if some other view that happens to show the same element is not showing the same thing.
Stakeholder: User of ArgoUML
REQ2 REVb
Rationale: If a user makes an update of a part of the model, an immediate feedback in all other parts that are currently showing might help him to get it right.
Stakeholder: User of ArgoUML
REQ11 REVa
Rationale: If a user makes an update of a part of the model, an immediate feedback in all other parts that are currently showing might help him to get it right.
Stakeholder: User of ArgoUML
REQ12 REVa
Rationale: If a text field requires validation there exists, by definition, a possibility that the text field is in an invalid state at any time during editing. Therefore the model cannot be updated until the field is completed in a valid state or rejected.
Stakeholder: User of ArgoUML. TODO: Is this the correct stakeholder?
REQ13 REVa
Rationale: It is a common feature of GUIs that a dialog displays a snapshot of its model at the time of creation and only updates that model on the user acceptance of the entire dialog. This is a familiar look and feel for users.
Stakeholder: User of ArgoUML.
REQ14 REVa
Rationale: Writing a correct syntax of anything is complicated. Good compilers are helpful in pinpointing where the problem is (what line and what token is in error). The text fields in ArgoUML are not developed in the same way as source code and we have no compiler step to verify it all. Instead this validation needs to be done while editing meaning that the user needs all the help he can get to as quickly as possible, get the syntax right. TODO: Is this the correct motivation for this?
Stakeholder: User of ArgoUML.
REQ3 REVa
Rationale: An exception in the log or on the screen is always the sign of a serious error in the application that should be reported as a DEFECT. If a mistyping generates such a problem the user might loose interest in ArgoUML as a tool because he percieves it as not working correctly.
Stakeholder: User of ArgoUML
As follows:
A tooltip that explains the data and format expected by the particular field.
This can be omitted when there is a header stating the data of the field and the format is obvious.
Pressing F1 or choosing help from the menu shall display a popup window explaining for data and format required by the current input field. Input focus shall be left on the field during any user interaction with the popup (dragging, scrolling or closing).
REQ4 REVa
Rationale: Throughout a complex application like ArgoUML there are lots of text fields. Unless there is a possibility to always get this kind of help the user might not be able to make out what he is actually supposed to do in that field.
Stakeholder: User of ArgoUML