I wrote a requirements database 6 or 7 years ago to handle this. Each requirement record has a short description, a "definition" memo, and a "notes" memo (both rich text, with ability to embed screen shots, etc). There are other fields too, for project, deliverable, sequence number (so they can be ordered logically), use-case/feature it's related to, time estimate, a field for the person handling it, if someone has selected it for implementation, etc.
There's also a "Status" - "Entered", for while we're designing the features; "Approved", set once a group of requirements are reviewed and determined to be ready to implement; "Implemented", set by the programmer once they think the requirement is done, and "Validated" once the QA tech agrees with the programmer. (If the QA tech disagrees, he can set it back to "Approved" so the programmer gets it back.) Requirements can also be "Deferred", "Rejected" or "Questioned" (meaning the Change Control Board needs to look at it.)
The trick to doing this well is reasonable granularity. It can sometimes make sense to have one sentence requirements (e.g. "the problem described in issue 12345 is fixed"), but in general, requirements should describe all the important aspects of a whole feature (or a big chunk of one). For example, a typical "new report" feature will have a requirement for a report format (what the output looks like), and a requirement for the options dialog (explaining the fields, validation, etc.) There might even be a third if there's a complex generator crunching the data, rather than just an easy query or something. In addition, we'll create a "Help" requirement for the corresponding help topic.
There are huge advantages of keeping this stuff in database records rather than a big document. Multiple programmers can be working on requirements at the same time. Individual records are locked so only one person can edit at a time, but they can be opened and read while somebody else is editing. The biggest advantage though is that it provides easy to search documentation of both what the requirements were, and notes about how they were implemented. We have over 25,000 requirements in there now, and we can easily find all the requirements with specific words in all the fields, or the definition, or notes, or whatever, in under 10 seconds. (Try that with 6+ years worth of Word documents.)
I can see why people might say it's a bad idea to do requirements in a "bug tracker", but my guess is that's because the tools suck, not because keeping requirements in a searchable database is a bad idea.