Large organizations tend to shy away from "loosey-goosey" agile methodology techniques (such as UserStories) as they fear losing control of the project. These types of institutions prefer a Waterfall based approach. Of course, imposing such rigidity hinders collaboration and curtails flexibility. Johanna Rothman touches on this in her blog entry "How Many Process People?", where she says Agile can work, so long as there is traceability around the requirements. Great advice.
We are currently working with a client in a regulated industry. We proposed describing the functionality of the system using "Use Cases", hosted on a secured Wiki. Now, the client has a consultant. Consultants like to "add value" so they can justify their pay, so I guess we should of seen this coming but the term "Use Case" got hijacked and in its place was something that took me back to the COBOL programming days at the Department of Finance in Oz. You know, where you sit around for six months waiting for an assignment to write a sort routine. Data input is PIC 99999. Output must fit in a 80 column wide report. Blah, blah, blah... What ended up happening is we abandoned our collaborative efforts, and the dev team started a new internal Wiki. Such a pity, as the other business users and the dev team were really starting to gel nicely.
In retrospect, the inputs from the consultant were valid, but not in the Use Case format. What got lost is the notion that there are other artifacts that can be used to capture different aspects of the end system - for example a Data Dictionary. The key though, is to describe these facets in separate documents (pages), then create links between them where appropriate. Wikis are great for this, especially if you have one that tracks versions of the pages.
A good software architect will create layers of concern in a system to reduce coupling - requirements management is the same. Mix it all up and you run the risk of ending up with "spaghetti requirements" - no one can read or understand them.