RE: [ucuml] I really need some type of answer - OK, here's a long one!

[Ed Manley <EManley -at- Solutionsplus -dot- com>]

I think, Paul, that I would put them either on the intranet web site (if you
have one) or on a shared drive where they can see the use case diagrams and
text as you create them. That way they know what you know when you know it,
and may be willing to help you extend and maintain that knowledge as well.

As far as the level of knowledge to put in them - the developer's can't
deliver what you want unless you explicitly tell them what you want. If you
don't prototype every screen and document the functionality of every button
they will not give you what you expect to get.

The fact that it takes time to get to that level of detail is the problem. 
Management will just about always propose the Ready, Shoot, Aim way of doing
things because they rarely see value in the Aim part of the process.

That's where you have to get management to trust you enough; to believe that
the time you spend in analysis and documentation before the coders ever get
their grubby little mits on it will pay for itself in helping deliver
quality software on time and in budget.

Good Luck,
Ed


-----Original Message-----
From: Sienkiewicz Paul [mailto:seaduspx -at- yahoo -dot- com]
Sent: Tuesday, January 29, 2002 2:27 PM
To: Ed Manley
Subject: RE: [ucuml] I really need some type of answer - OK, here's a
long one!


Thank you very much for the information.  Here is more
to the problem.  

The developers are told that we will give them a use
case diagram - showing all of the relevant use cases
for the system.  They are aware that these may or may
not be all of the use cases. As you said, some may be
merged, some may be split into more, and so on.  I
also inform them that the "initial" use cases will not
have ALL of the detail that they need at this point -
that the use cases themselves will grow as the
discussions grow.  Then when I give them the stripped
down requirements, they ask why I haven't given them
more detail.  My question is this.  Should I just
write as much on the use case as I can possibly can
about the subject at hand - including business rules,
validation rules, etc... OR should I help them along
and give them the use cases one iteration at a time. I
don't want to spend 3 weeks writing down all of the
information for one use case, while I could provide
them with an overall look at the process.  Sorry for
the rambling.  It's difficult for me - someone who has
just learned about use cases in the past year try and
write and present them to developers who know nothing
about them.

Thanks again!

Paul

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.