I do have maximum respect for them.

That said, they had many problems due to their "old fashioned"
"intuition-based" methods
so I try to teach them
the power of modeling and complete documentation
+... that's why they pay me for (well).

Regards

Agree, but with one additional comment.

Each methodology includes practices that have different value in
different situations.

The programmers who developed the practices generally knew what they
were good for, and when to do something different. In the middle of a
methodology cycle its practices get pushed for all situations. If a
practice that is part of a methodology push does not work well in one
situation, it does not necessarily mean it is a bad practice. It may
just be being misapplied.

As far as the original problem is concerned, I would suggest documenting
the requirements for some test project in UML and in whatever way the
developers like.

Compare the two representations, and the work involved in producing
them. Which did better at bringing out issues? Which gives the clearer
view? Fewest pages to cover the whole requirements? Easier to edit?
Bring in a developer who is not part of the class to evaluate readability.

If UML use-case diagrams really are a better technique for documenting
their requirements, it should become apparent.

Patricia

Well said that man.

To which I would add: it's not new that managing software development is
hard. Frederick Brooks 'The Mythical Man Month' may be more than thirty
years old, but it's still one of the most thoughtful (and in my opinion
best) books on the subject.
http://www.amazon.com/dp/0201835959/

The core of the issue is that the best programmers are an order of
magnitude more productive than average programmers. It's seductive to
believe that if you could encapsulate the methods of those best
programmers into a methodology, you could raise the standard of the
average very significantly. Sadly, this turns out not to be true.
Consequently Brooks recommends not trying to develop methods which would
try to smooth out the difference between the best and the average, but
instead to build 'surgical' teams around the best, where the team
comprises

* one 'surgeon' - the recognised highly productive programmer, who does the
 majority of the actual code-cutting work, and is boss to the rest of the
 team
* one 'co-pilot' - a less experienced programmer who is being groomed to
 become a 'surgeon' and who sits with the surgeon, discussing the work and
 methods as required
* one 'administrator' - an office manager type person, reporting to the
 surgeon (NOT the other way around) whose job it is to handle all
 organisational problems relating to the team and its resources
* one 'editor' - responsible for generating and maintaining
 documentation of the code and of design decisions
* two secretaries, one each reporting to the administrator and the editor
* one 'program clerk' - responsible for maintaining all project files
 including released deliverables

Brooks also advises 'plan to throw one away' - in other words, rapid
prototype. Note that this has quite a lot in common with modern XP
methodologies.

I have to say that in my twenty years of personal experience as a
programmer and manager of programmers, and as technical director of
software companies:

(1) Brooks' recipe as described above definitely works (very well),
although these days with improved office support software and version
control systems you can probably do away with the secretaries and roll the
program clerk job description into either the co-pilot's or the
administrator's. Obviously, if you appoint the wrong people as surgeons,
this approach fails; but if you appoint the right people, it is hugely
productive.

(2) If, as an organisation, you are promoting your most productive people
away from the code face to become 'managers' or 'analysts' or
even 'designers', your productivity will fall, not rise. If, on the
contrary, you promote your less competent people to become 'managers'
or 'analysts' and give them more status than programmers, then your most
productive people will leave, and your productivity will plummet.
So 'managers' _must_ be junior to 'programmers' in a software
organisation, or else you might as well close the doors.

(3) Any system which tries to divorce design from implementation will fail.
Consequently, any methodology which uses a formal language to communicate
between 'designers' or 'analysts' or 'specifiers' on the one hand,
and 'developers' or 'programmers' or 'implementers' on the other, is
highly suspect. If the person doing the requirements analysis and the
architectural design is the senior surgeon on the project, then he has his
own way of making the design notes he will use and will get the editor to
document. And if the person doing the analysis and design is not the
senior surgeon, you might as well start putting your CV round the
agencies, 'cause your project is going to fail.