I've been using this line more and more at work. For every artifact fill in:
"_____ reads _____ to learn _____ so they can _____"
Then once you know who needs what, see if the artifact in the second blank is the very best way to communicate.
If you have an audience with a need for permanent documents use cases can be pretty neat.
We had some terrible experiences with use cases for estimating, assigning and tracking work because they were too big. If you're filling in the blanks with giving developers tasks to do, something smaller like stories would be better.
We often find a use case author puts in everything they can possibly think of from the mission critical features to the least necessary gold plating. This is largely because they think they only have one chance to get every last requirement into the
doc before sign-off and the onset of change prevention, er, control.
If you break a use case into many stories the customer can usually identify some that you have to do first and some that you can put off forever. We never tell our customers "no" on a goofy story. We write it up and let them prioritize it for some time in the next century.
Many teams find that they don't need the permanent use case record. They can develop a story and throw away the card and go on to the next. My team won't give use cases up any time soon so I encourage the people who think they are important to write them and leave the developers to work with story
cards.
Any of that help? Raise more questions?