Specification by example with SpecFlow in TFS and the question of traceability

This is the second post talking about how to integrate the use of Team Foundation Server (TFS) in a Specification by example (BDD, ATDD call it what you want) workflow. You can read the first post here for some background, but I will include some background here too, as I have thought about it some more.

Background

Specification by example is not only a way to write executable specifications (red. those words still gives me the chills) but in the way it’s used in projects lies some kind of agile methodology hidden. The early and frequent communication and documentation (in a commonly understood format, Gherkin) it fosters really get the way you work in a very agile way. More on that later.
Cucumber is a very well known tool in the Ruby world, where projects often create web applications. I think that this inheritance has influenced the process above, which states quick and rapid movement and very agile ways.
This doesn’t sit to well with big organizations where maintainability and traceability from requirements through bugs and change requests are very important.
After my last blog post I got some feedback from Hugo Häggmark and Håkan Fors that suggested different approaches to how the TFS work items could be used in this workflow. Since I haven’t use the different work item types much I got together with Hugo (who is now my colleague!) and tried to flesh things out. This is our findings.