a) Use case steps vs Use Cases (aka functional decomposition)
b) Scenarios vs Use Cases (e.g. forgetting that a use case includes alternative paths)
So, what’s the solution? First, we accept that use cases will change as our understanding evolves. They are a requirement solicitation technique. Second, we accept that the purpose is not to get them 100% right but rather to get 100% of the people to agree on them.
The best mechanism I’ve found is to actually hold off creating use case diagrams unless you’re in a workshop context. Use case diagram workshops can be a sharing and consensus gathering forum and provide an opportunity for constructive questioning and subtle coaching: Is this a scenario of another use case we’re discussing? Is this an end to end usage or a function in a use case? Does this use case have alternate flows? By starting with a blank page, we have an opportunity for sharing opinions and knowledge of the system we think is needed.
The danger with letting people do use case diagrams on their own is that they will turn meat into mincemeat by over working them. The gold dust is often to have fewer not more use cases. It sometimes requires art not science to everyone on the same page.