Well David,
I seem to be the only one to tackle your question so far, let me start by
saying that the following is my preference, it works for me and may not be
for everyone.
My use cases are my requirements. They don't start that way, but that's how
they look when I publish them.
I start by describing a scenario - lets take logging in as a simple
example.
I create a use case showing a user interacting with the system the system
querying a database and a textual description of how the user enters a
username and password, presses 'Logon', the Username and Password are
validated against the information in the database and the user is logged in
or not, as the case may be.
Looking into more detail, and using the rule that a requirement has
stimulus, precondition, postcondition and time, I realise that this use
case is actually two requirements.
1) The user enters a valid Username and Password and logs in.
2) The user enters an invalid Username and Password and fails to log in.
So now I describe my initial use case as two use cases, and also indicate
on the use case diagram, the stimulus, input and output flows.
I realise that my use case diagram starts to resemble a traditional data
flow diagram, but there are differences.
1) A bubble represents one and exactly one requirement.
2) There are no data flows between bubbles, but I can still use the
'includes' and 'extends' relationships.
Why would I want to do this to my use cases?
Because of the audience. This comprises:
1) Analysts - maybe the analyst feels that I'm overstepping the mark into
their domain. Well seeing as how I am nearly always my own analyst, I don't
have problem with this and if the use cases are produced by someone outside
of the software group, they will generally resemble the traditional use
case. I then sit down with the engineer(s) and help turn them into my
preferred use case notation.
2) The Testers - who are the most overworked and underrated (in terms of
importance of their work) employees in a development process. I want my use
cases to be of most benefit to them and so I try to write them in a form
that closely resembles test cases. This means specifying input, output,
stimulus and time for every test.
Once I have my requirements I tend to throw the scenario use cases away. I
haven't yet found it necessary to maintain them, instead I use sequence
diagrams if I feel the need to reconstruct the original scenario.
Hope this helps,
Les.
Also, while were on the subject of associating a Use-Case with a
Requirement, I find that the language I want to use for a Use Case is quite
different from the language I use for a Requirement (i.e. UseCase= View
list
of Employees, Req= Ability to View List of Employees). How do people handle
this?
Dave
************************************************************************
* 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
*
*************************************************************************
