This could be 2 questions but they are related:-

I have a client that wants to document a Sales Order Processing system (surprise, it is currently undocumented!) with regard to functional specs (of what is required) and Use Cases of how it is done in the application.
I am looking at Quality Center, given we are reverse engineering and I was thinking of laying out all the basic functional requirements (in QC Requirements Management section):-

Add product
Get availability of product
Schedule product against a Sales Order
etc. etc.

Against a physical view of how these are tested (test plans in QC), a kind of variation of Design by Test (where the test cases specify the design, instead of the use case).

I have not used QC (since Mercury owned the Test Director) so any advice on:-

The level of specification (Product Functional) and suitable hierarchy in the Requirements Management section. I am thinking atomic functions and then relate scenario's (New customer with poor credit etc.) above the functions.

How to specify test cases so that they can be reused. I did see a parameterize capability for data into 'test designs' and I am thinking of table driving this (again I am only look at manual test cases). I am OK with the Requirements Traceability Matrix (RTM and the basic operation of QC).

Automation comes later with QTP.

Is there anyone that has done a similar reverse engineering approach and any best practices for reusing test case description (manual) to cross reference the product functional requirements, in QC, any and all comments welcome.