Our team is looking for a way to link “requirements” to “user stories”(US) and user stories to requirements. To do this we created a TFS tree that looks like this
Collection XYZ Project (Agile). Container to hold all of the User stories Project R (CMMI). Container to hold all of the requirements
We then can link a user story from “Project” directly to a requirement from “Project R” and a test case to each user story. This test case can then also be linked directly to the requirement in “Project R” to validate that when the test case passes the requirement has been completed.
The idea is that we can then pull all testplans at the end of a contract and in theory that is the master test plan that the customer could use to validate all requirements have been met.
Is this a bad practice to intermingle different sdlc type project level containers? And is it even possible to export a report in a format that would save the manual labor of typing out a new test plan document.
It's able to link work items across team project in the same project collection. But in my opinion, you don't have to do this in your case.
User Stories are the same as requirements, just different process template.
Link them across team projects make things and management complicated. You could consider "importing" the "Requirement" type into the Agile template. TFS allows you to import the Requirement type. With witadmin
tool, you can modify XML definition files to support the On-premises XML process model. Detail steps about how to do this, please refer this tutorial-- Import, export, and manage work item types
For additional customization options, see Customize your work tracking experience.
With start using this, it's easily keep track of more formal requirements (i.e. the acceptance criteria). And also makes it easy for reporting on larger projects.