David O'Leary's original question was "In Rose 2001 they've added a Name
attribute which allows you to summarize the requirement which is really
nice. From Rose, I want to be able to use that Name when I associate a
Use Case with a Requirement as right now, many of my Requirements are
too long for the use case diagram. Anyway to do this?"
Whether you think of requirements as chickens or eggs, I really don't
understand the question. Does it mean that updating the Name in a
requirements document would update the name in the Rose model, and
vice-versa? That sounds like Soda. Can you do it without Soda?
Automatically generated documents that I've known were just reams of
profoundly useless boilerplate at best, and developers avoided them like
stink, but this particular bit could be cool.
...The rest of this reply purposely evades David O'Leary's original
question:
It's kinda spooky agreeing with Les Munday, but I do. We worked on the
big space station robotic arm "together", and experience shows that
agreement between us is probably a sign of the apocalypse. The arm was
a series of simple, impossible steps -- not because it was so inherently
complex, but mainly because it was space-qualified, and the requirements
analysis was both anal and paranoid.
At the least, you should use scenarios to shake out raw requirements
from the domain experts, write use case flows of events (or
descriptions, or whatever) answering to the scenarios, analyze the use
cases to see what additional scenario coverage you need, do "firm"
scenarios with the domain experts, fix the use cases as needed, and pass
the complete set off as requirements. Oh yeah, almost forgot: use
childishly simple sequence diagrams starting as early as possible.
Testers and QA will love the use cases, the scenarios, and the coverage
analysis to pieces.
One of the big advantages of introducing object technology is that the
management often doesn't know what the hell you are doing, and that
gives them a blistering hard time stopping you from using good
methodology. Perhaps less satisfying, but probably better, some
managements introduce OO because they actually *mean* to improve.
Either way, buy-in from QA probably helps you to get this through.
Anyhow, I think I'm agreeing with Les pretty much, but on second look it
seems that Les is eliminating branching and such from use case FOEs
(which I wouldn't like), so the end of the world probably isn't due just
yet.
-Eric
[EMAIL PROTECTED] wrote:
>
> 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.
************************************************************************
* 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
*
*************************************************************************
