Jean Claude,
It's getting a little bit more complicated:-)
(1) Amount of Scenarios
As you mentioned, projects start using use cases wiht the danger
of drawing too many scenario diagrams. This is a normal thing, if you're
new to this technology.
As a rule of thumb, the analyst should ask 'Does this scenariodiagram
add new relevant dynamic behaviour to the system?' If not, the scenario
diagram is not a must.
As you can see in the question above, there is a 'fuzzy' area:
- What does relevant mean?
Well, that is the good ol' Analysis-Paralysis problem, where no concept
(nor language like UML) can help upfront. Here's where your creativity goes!
(2) Level of detail
The detail you describe is more a design level of detail, as it tries
to give the complete and design-feasible amount and quality of information
needed for the designer.
For a good example, you should look into Craig Larmans book about UML
and design patterns (e.g search '+Larman +UML +pattern' on amazon).
(3) Evolution of use cases
Many books about use case have been published recently, and it's more or
less a matter of cultural preferences which method you want to use.
The most important thing is, that the 'final' use case can be desribed
in the way you suggested - but it should NOT be your goal for the first
'release' of a use case.
As the RUP (Rational Unified Process) suggests an iterative development
based on use cases, you won't get your iterations handled with this
'we want to get _all_ infos before we continue'...
Example
Iteraton 1:
- Use Case 'Take Order'
- Basic scenario
- 2 (of 20) alternitive scenarios
- Use Case 'Manage stock'
- Basic scenario
=> the above are desribed in more detailed levels. The 'rest' of the use
cases
is just named. Also, the scenarios are choosen after their importance
(and
risk exposure).
Iteration 2:
- Use Case 'Take Order'
- Basic scenario
- 7 (of 20) alternitive scenarios
- Use Case 'Manage stock'
- Basic scenario
- 3 (of 30) scenarios
(4) some references:
- Book of Philippe Kruchten: an introduction to the Rational Unified Process
- Book of Craig Larman about UML and Design Patterns
- Rational Unified Process itself (read Philippes book before!)
- Larry Constantine - Software for Use
-> This is not exactly the Use Case thinking of Rational:-) But it helps
a lot if you have a high expectation about useability
Best regards,
Volker
-----Ursprüngliche Nachricht-----
Von: Antonio Jean Claude [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 15. Februar 2001 10:26
An: 'Kopetzky, Volker'; [EMAIL PROTECTED]
Betreff: RE: (ROSE) Test scenarios
Thanks for your answer,
This was very helpful.
Tell me if I am wrong: a UC scenario is a instance of a UC. UC scenarios
should cover all main and alternative flows and their variations. These
artifacts are created by the analysts.
How detailed should these UC scenarios be?
Should they be as detailed as :
SCENARIO 1:
Message 1
Attrubute 1 = A1
Attrubute 2 = A2
Expected results:
Object1 created with AttributeA = A1
Object2 created with AttributeB = A2
Link created between Object1 and Object2
Message 2
....
plus a written description of the UC scenarios.
In which case, for one use case the analysts can end up with an incredible
amount of UC scenarios.
Or should they only focus on the written description of the UC scenarios and
leave the testers to draw the actual messages?
Cheers,
Jean-Claude
-----Original Message-----
From: Kopetzky, Volker [mailto:[EMAIL PROTECTED]]
Sent: 14 February, 2001 9:06 PM
To: Antonio Jean Claude;
"'=SMTP:[EMAIL PROTECTED]'"@ns2.cargolux.com
Subject: AW: (ROSE) Test scenarios
Jean Claude,
well, everyone should provide input for the testers!
It's more the thinking about who owns the requirements that are to be
tested.
Every role in your team provides/influences requirements:
- analysts (e.g. business rules, 'boundary' requirements, ..)
- designers (e.g. RDBMS mechanisms, Messaging requirements, ..)
- developers (e.g. coding conventions, implementation requirements, ..)
My suggestion would be that every role provides specific requirements.
Every (testable) requirement type has an attribute 'Test: yes/no'.
The testers then can filter the requirements and implement the 'requested'
tests. With some integration, empty test scenarios can be 'precreated', and
the tester also has access to further needed documentation (e.g. a
UC-scenario
can be used to navigate to the use case document).
With best regards,
Volker
TIPS & TRICKS:
Try 'Help:Extended Help' in any Rational Tool
********************************************************************
Volker Kopetzky
Senior Systems Engineer/Expert Phone: +49 / 89 - 62838 - 293
Rational Software eFax: +49 / 89 - 62838 - 593
Keltenring 15 Fax: +49 / 89 - 62838 - 269
D-82041 Oberhaching MailTo:[EMAIL PROTECTED]
Germany URL: http://www.rational-software.de/exp/vzk
********************************************************************
Rational...
-> Suite:
http://www.rational.com/products/rs/index.jtmpl
-> Requisite Pro:
http://www.rational.com/products/reqpro/index.jtmpl
-> Unified Process:
http://www.rational.com/products/rup/index.jtmpl
-> Rose - unoffical website:
http://www.rationalrose.com
-> Upgrades:
http://www.rational.com/sitewide/support/upgrades/
-----Ursprüngliche Nachricht-----
Von: Antonio Jean Claude [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 14. Februar 2001 11:11
An: [EMAIL PROTECTED]
Betreff: (ROSE) Test scenarios
Hi all,
This is more a question of organisation than a Rose question.
Our project is divided into 4 groups:
- analysts
- designers
- developpers
- testers
The analysts are working on Use Case description and Conceptual Diagrams
(Class diagram representing Domain concepts). They describe use cases with a
flow or events.
Should they take care of the creation of the Test scenarios?
If not, who are the best candidates to create them?
Thanks,
Jean-Claude
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
