Best practices for Requirements Management in QC
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):-
Get availability of product
Schedule product against a Sales Order
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.