Are we using TFS 2010 incorrectly?
Our team is new to TFS2010. Historically, we have used our own Business Requirements Matrix (traceability matrix) Excel spreadsheet. It has typical columns like:
Requirement ID | Project | Rule Group | Business Rule | Type ...etc
Our Business Rule column reads something like the following:
- "The system shall provide a means to allow the actor to search for a Study."
- "The system shall provide a means to allow the actor to search for a Project."
- "The system shall generate a move activity for the inbound package."
- "To Import Barcoded Manifest, the system shall, with each sample placeholder, include a code stating the sample has been created by barcoded manifest."
Due to the rigor of our industry regarding documentation, audits, etc, we opted for MSF for CMMI instead of MSF for Agile as our Process Template choice.
We have had numerous discussions about the best way to go about implementing "the way we work" into the TFS 2010 world. The crux of our problems seem to come down to the following:
- It seems like we should follow the "parent/child" relationship between Requirement -> Task in the Implementation tab. However, this means that we have a task for every Requirement (which seems redundant and overly granular).
- We like to think of a Task as something less granular (i.e. "Develop an Outbound Console screen.")
- We would like for the developer to be able to look at the Tasks assigned to them, and easily see what Requirements (Functional and Non-Functional) are associated with those Tasks.
- Traceability is a high-priority, however, we don't necessarily need it to be extremely granular (down to actual lines of code). As we see it, doing so would make development extremely tedious and counter-productive. We want a sensible balance in this respect.
Is our approach really the round-peg into square-hole that it seems to be? Or, are we just misunderstanding/missing something? We feel like we have a sound understanding of the various Work Item Types.
To add a bit more context, our understanding is that Requirements of type "Feature" are the "parent" of more granular requirements such as Functional, Non-Functional, QoS. We understand that the Requirement type of Scenario is analogous to a Use Case.
So, we believe that TFS 2010 follows this hierarchy:
- Requirement (Feature)
- Requirement (Functional)
- Task
Obviously, the problem for us is that while we want the parent/child relationship between Requirement/Task in some respects...we almost see the need for a Task as the parent of Requirements at the same time.
We believe that we could skip the Implementation tab (and the parent/child relationship it enforces)...and just use the All Links tab. This allows us more flexibility to relate Requirements and Tasks via other Link Types such as "Related" or "Affects/Affected By"...but, the big catch there, is that it breaks the built-in TFS 2010 reporting (especially regarding tracking Requirement progress/hours).
Any insight is appreciated.