I'm in Phase III of my 3 to 4 phase project. I'm using QC as the system of record and this is really a pilot for this organization. There's a lot of process improvement going on internally.
Okay - my initial compromise with the "Functional Specifications" document that I was given to work with as "Requirements" was to assess the outline level down to which I logically felt represented discreet functionality to which specific test cases could be linked.
It's not unusual, particularly in the midst of internal process change, the document has some challenges. =0
For Phase I I picked out some sections of the document that could be legitimately linked to the functionality being released.
Phase II was more complex, and less covered in the FS doc, but I followed the same logic.
Now it's Phase III and I really need to demonstrate in the months to come that you can show requirements coverage etc using Quality Center - effectively.
I can call it anything I want but I'm not sure what to call a requirement that is not a requirement. Here's some obvious stuff: the glossary and the document purpose summary sections are not testable requirements. What should I select as the right word for their "Direct Cover Status"
They are loaded into QC to allow an over view of all sections of the document in outline order and demonstrate that nothing was left out arbitrarily. But I don't know what to call them.
Any ideas, other than I may have lost my sense of direction?
The Glossary shall list all technical and non familiar terminology contained herein.
1.) Terminology shall be listed in alphabetical descending order in plain English and the term itself shall be emboldened.
2.) Arial 14 script shall be used except for headings which shall be Arial 18
And just keep on extracting requirements. My first job in software testing for the Navy was extracting requirements.
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~