I need examples of how you use the QC requirements module. Our BAs are on the verge of agreeing to use the requirements but have a couple questions and I figured I might get some input from the group.
1. Do you use the Req module as the primary requirements repository? If so, how do you organize or assemble the many individual requirements into a format (Word Doc or excel for example) that can be presented to the business or to a developer that summarizes the complete requirement in a meaningful way? The requirements reports seem to be a simple listing of the individual items.
2.What level of detail do you take requirements to? Some think that a single high level req should be adequate - with detail being added through the test cases. Others feel that the requirements should be detailed so that the testing results can be better analyzed.
1. Yes, use it as you one and only source of Reuirements. Diluting the module by storing other requirements elsewhere is one of the biggest sources of confusion when working with QC and testing in general.
Because QC is configurable you can create user groups that have ReadOnly ability, or give some users access only to edit requirements etc. This enables you to dictate what can happen within the module.
If you think of a Word document being a doco that holds a number of chapters covering specific areas (like functional, regression, change requests) and each of those chapters is broken down into sections and sub-sections, then you have the logic of how you would address your requirements set-up.
You create requirements that are the chapters, sub-requirements that are the sections, and sub-sub-requirements that are the sub-sections.
Exporting requirements can then be easily done through either the Document Generator or the Report area. The report you chose may have been a simple overview only, not a complete run through. If you have more data in the module you can report on it. Nothing is hidden unless you choose for it to be.
2. The level of detail to include in the requirements is up to you, but the more refined requirements will always give better testing results. I opt for as much detail as possible and break down the requirements into sub reqs so that testers can test thoroughly.
While I have been working for Businesses that are Vendor partners with HP, IBM and Microsoft, my opinions and advice is my own.
The solutions provided are either sourced from my own scripting libraries or from a quick Google Search.
One of the reasons why we didnt use the Requirements module in QC was because we had several types of requirements - business, technical, design etc. Our process required all of the technical & design requirements to be mapped back to the business requirements to ensure appropriate coverage. This detailed Requirements Traceability cannot be accomplished through QC (at least as far as I know). Perhaps this is not the case with you.
I always stressed on our architecture team to break down the technical requirements to such detail that they became testable and thus measurable. This way the testing team can ensure that the test coverage is adequate. IN CASe of generic requirements, this becomes very difficult.
I agree with your statement regarding the separation of requirements to a detailed level in order to assure coverage. Did you consider using the traceabilty of the requirements to tie a functional requirement back to a business rule - created in another folder in the req module? If you dont use the QC req module, how do you track coverage?