What exactly do you men by "using Atlassian JIRA for requirements management"? You could just take your requirements document (word file) and attach to a JIRA. Would that mean you manage them in a JIRA? I don't think so.
Anyway the only idea specific for JIRA (compared to any other defect tracking system) that I could recall is that it is better to store all your requirements (content) in confluence and only refer them from JIRAs because confluence has better version control (i.e. if you change a single word JIRA counts it as whole field update).
?:the art of a constructive conflict perceived as a destructive diagnose.
We use Tortoise SVN (Subversion) as our requirements document repository and JIRA as our method of team communications for the requirements documents. Members receive email notification through JIRA (Confluence Enterprise Wiki) of any new documents or changes to existing documents and then can update their local copies using Subversion. None of our documents are "stored" on JIRA and as Ainars said you would not manage your requirements documents on JIRA. Hope this helps!
Intellectuals solve problems.
Geniuses prevent them.
Sorry for not making myself clearer earlier. The broad proposal would be to store discreet requirements for our system as unique, distinct entities in JIRA. This way we can link tasks, issues and bugs to these discreet requirements.
So I'm interested in hearing from anyone who has tried anything like this before - did this work, what kind of issues were encountered etc.