1) Why go through all those text details for scenarios, when you are going to model them in sequence diagrams (or, if you wish, in activity diagrams or state machines)?
2)How much detail should go into interaction diagrams?
In theory, a solid model should go down to the CRUD level (create, read, update, delete data items). In practice, however, you would get yourself bogged down if you try that level of detail, and your project will become prohibitively expensive, or worse...
Hi Jaime,
In response to your 2 questions above, the following is the way that I view use cases and so how I utilise them :
1) My use cases capture the *requirements* of my final system so -
(i) {Customer sees the Use Cases}
I can show my customer the FULL requirements of the system (including all scenarios). When they sign off on these requirements I know that they can not come back and say "Hey I never sanctioned that!".
The customer has confidence that the system will cover every eventuality.
CRUD operations usually appear as one of C,R,U,D as the Basic Flow and the others as Alternative Flows (alternate scenarios). These Alternative Flows are usually uncomplicated to write as variations of the Basic Flow. Therefore it does not take much effort to write them in text version.
If CRUD operations need to be split into separate use cases then the fact that they are so different means that the effort in writing a new use case will be worth it in the end.
(ii) {Test Cases derived from Use Cases}
All of my test cases are derived from the Use Cases (with maybe some information from the Supplementary Specification). If I write out all scenarios - then I know that my test cases will give 100% coverage of the system.
Not writing out all scenarios means that my test writers have to "discover" the unwritten scenarios that the Modellers will develop. This could lead to functionality which is not tested for, or new tests for functionality which is not included in the model / code.
(iii) {Modellers derive UML diagrams from Use Cases}
Experienced modellers will probably create CRUD UML diagrams automatically. If you have an inexperienced modeller, having ALL requirements specified in the Use Case means that there is no possibility of them 'missing' the unspecified scenario.
(iv) {User Documentation derived from Use Cases}
Most often when a user most needs to read the documentation is when they are doing something which is outside how they 'normally' use the system, i.e. alternative scenarios. If these alternative scenarios are not written in the Use Case, the tech writer will have to "discover" all of these to document them for the user.
Essentially you could rely on the "Head Knowledge" of experienced Test Writers, Modellers, Tech Writers for items (ii), (iii) and (iv) - but if one of these gets hit by a bus in the morning (all 3?) it could be difficult to retrieve this information.
2)
If you are using EA to generate code then the more detail you have in your UML diagrams the more complete your generated code will be.
If you are not using your UML diagrams to generate code then only put as much information into the diagrams as is required to communicate the idea.
Regards,
Fintan
