Susan,
I have not used Caliber either, but here is what works for me:
1. Create a high-level package in your EA project (think of it as a "Chapter" in your documentation). I call it "Objectives and requirements", but use anything that applies to your situation.
2. Create sub-packages, as appropriate (think of these as "subchapters"). I use "Legal and normative framework", "Objectives", "Requirements").
3. Create object diagrams under each subpackage. These enable you to use hierarchies and dependencies.
4. Populate the diagrams with stereotyped objects (for example, <<goal>>) and requirements. Requirements are nice because you can drag and drop them into classes, use cases, tables..., and EA automatically creates a Realization relationship. Objects are nice because you can stereotype them (and they conform to Ericksson-Penker modelling). If in doubt, use requirements.
During JAD sessions, just create or copy new requirements and objects. They will be automatically grouped under your packages.
5. Create sub-sub packages as approriate: Planning requirements, Standanrds, General requirements, Security...
After your JAD session or interviews, refine your diagrams, subpackages, sub-subpacks...
6. Generate an RTF document with the whole high-level package, and see if this what you are looking for. After a couple of cycles, a nice requirements model will begin to apprear.
I used Doors about ten years ago, and I don't know how the product looks today, but it certainly was a great product then. However, today I would not use anything but EA, because I can assign to my classes, use cases, tables... the responsibility of fulfilling the requirements, and assign to business processes the responsibility of fulfillilng goals.
7. Create a relationship matrix to trace whether you have assigned all your requirements to use cases, classes...
As long as you create a good structure, I see no problem in handling a large number of requirements.
Jaime
