What I would look for in a requirements management tool

While looking through my RSS feeds I caught a glimpse of JRequisite. From the web site, it looks like a very far cry from any other requirements management tool you may have used at work (aside from Excel, Word and e-mails that is). That being said, it is still a good start. I wouldn't use it just yet, but it did get me to thinking what I would want in a requirements management tool -- for Eclipse that is. Here's a quick run through of the requirements I would have for my requirements management tool:

• Integration with the Eclipse Team API for versioning the requirement documents.
• There are requirement document types:
• General -- which is the catch all and contains an ID field, a title field, a tags field and one big entry field plus a list of attachments.
• Roles and Responsibilities -- A list of possible roles in the project and the task they are required to perform.
• Glossary -- an alphabetical list of business terms used to provide a common language.
• Each requirement is in its own text file and a zip file containing any attachments that the requirement may have.
• Requirements are linked together by levels of refinement. So if I modify a parent of a requirement the other requirements are tagged as needing review.
• Modifications are just tracked by the date/time stamp of the requirements file set.
• The general requirement editor is Wiki based so non-developers can have an easier time hyperlinking requirements to each other.
• Copying and pasting a picture in the editor field should paste a link to the picture. The picture is saved in the attachments zip.
• Holding down Ctrl and hovering a word that is in the glossary will show a hyperlink that links to the glossary entry.
• There is only one Glossary, but each entry is its own file.
• Modifications to glossary entries will trigger a scan (or can be done manually or skipped altogether) on any document that has a word that is written in the modified glossary entry and flag them as needed for review.
• Hovering over a word that is in the glossary shows a tooltip containing the definition.
• History of the requirement is tracked through the Eclipse Team API.
• A way to export the requirement tree to a PDF or HTML or as an Eclipse Help Plugin for external reviewers.
• For performance a local database (may be derby or hsqldb) is used to hold all "index" data that needs to be looked up. Any changes to any of the Requirements documents trigger an update to the database. This is easier than having to create a custom database backend to do this for us. And we can use standard SQL queries to the database and create new ones if needed.
• No access control as that should be handled by the Team API implementation.
• To keep things simple, requirements is a project nature and requirements documents are not usable outside of a requirements project.
• The editor form would have 3 tabs: Edit, Preview, Change History
• Preview should be a rendered HTML containing images and links as necessary. Links will open up other requirement documents in a new editor view.
• The Preview embeds the change history at the bottom as part of the document.
• Cycles are not allowed between requirement documents.
• Saves should be quick, scans may be triggered, but are run in the background using the Eclipse Job API.
• An ID clean up function to help reorganize the documents. Basically set the ID to a defined format e.g. [primary tag] [number] == UCS 1.1
• IDs normally do not get changed though so a warning is shown.
• Open source

Of course this requirements list is going to be vastly different from what JRequisite will be doing anyway, since they are after non textual based information. It would be interesting to see.