|
Tigris.org
Open Source Software Engineering Tools
|
|
|
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 of why the requirement is important, and a stakeholder, i.e. a person or group that the requirement is important to. 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 anything in the correct syntax 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, as quickly as possible, to 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 lose interest in ArgoUML as a tool because he percieves it as not working correctly. Stakeholder: User of ArgoUML As follows:
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 |
|||||||||||||||||||||||||||||