What tool(s) do you use when writing use cases? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

What tool(s) do you use to write use cases and why?

Do you use a common word processor (Word/OpenOffice), a Wiki, a开发者_如何学运维 specialized tool (f.e. Visual Use Case), or something else?

---

I've written use cases with a common word processor, using a simple template. This was sufficient for me since I don't see any benefit in drawing oval and stick figures, so just plaint text is enough for me. I also tend to keep the text short. Personally I prefer writing user stories instead of use cases, although there is a relation between the two.

Even Mike Cohn himself recommends using a word processor.

---

Visual tools are good for communicating ideas: I used Umbrello because it's very simple to use, quick and does the job, although the diagrams are all you get (it's not likely you'll get diagram validation, sensible code analysis or generation etc.)

I find that an issue tracker is a good way to, well, keep track of issues, including use cases. If you tako on the task of implementing something and don't want anything to slip through the cracks, you need to maintain a TODO list somewhere, preferably shared between all members of the team. A diagram is all but useless here, but a tracker with a touch of discipline in using it is gold.

---

Here at work we use Rally (http://www.rallydev.com/). It's a online User Story writing and tracking tool. The commercial version has several features such as iteration planning, estimation points, and velocity burn down charts. From what I understand it's expensive, but worth the money in the long run.

Rally also offers a free, watered down, version if you want to kick the tires a bit before committing to it: http://www.rallydev.com/agile_products/editions/community/