My advice is to shy away from use case diagramming tools. To quote Martin Fowler, from UML Distilled, Third Edition, on the use of Use Case Diagrams:
Nothing in the UML describes how you should capture the content of a use case. What the UML describes is as use case diagram, which shows how use cases relate to each other. But almost all the value of use cases lies in the content, and the diagram is of rather limited value.
A use case diagram can be included in a requirements document to provide a high-level visualization of the relationships between actors and requirements. Typically, use cases are best captured in a textual form. This could be stored on a wiki, on note cards kept in the team space, or in a document that is easily accessible to the team.
My recommendation is to first choose how you want to manage your requirements. If you can, I would prefer a wiki - it's easy to keep up-to-date and it's incredibly easy to get the latest and most accurate documentation into the hands of the people who need it. If a wiki is not an option, I do recommend having the ability to version and track changes. Word has a change tracking feature built in, so encourage its use. Alternatively, something like SharePoint could also work, which can lock files during editing, and help track versioning.
If you want a use case diagram, include it in the image, but remember that it's one more thing that needs to be maintained (and out of date use case diagram is worse than not having one). Since a use case diagram is simple, tools such as Dia or Visio can easily be used to create the image. If you are using a word processor that has the capabilities, consider creating the use case diagram from inside the word processor. In the case of using Microsoft Office, you can always embed Visio artifacts into a document and easily edit them from inside Word.
I would not recommend using a separate document for each use case, especially if it's an offline document produced in a word processor, such as Microsoft Word. If you are going to be keeping them electronically, such as in a wiki, then a separate page per use case might be appropriate, especially from a change-control and revision history perspective, as long as they are linked to appropriately and it's easy to navigate the pages.
For additional resources, I not only recommend UML Distilled for all of your needs, but also Software Requirements and More About Software Requirements: Thorny Issues and Practical Advice by Karl Wiegers. All of these books cite Alistair Cockburn's Writing Effective Use Cases.