What does MS use for Requirements Management?

Jason, if you've ever heard the parable about "seeing the elephant", you'll know the advantage in a nutshell.

Basically, while we often break out work items for specific, targeted scenarios or requirements (or subdivisions of them), you still often finding yourself wanting to "get the context":

"What is the big picture of which this requirement is a small part?" , or
"What other scenarios does this scenario touch on?", or
"How should feature ABC interact with feature XYZ?"

So, that's why we (often) *start with* documents that describe "the vision" and then work on breaking the problem down into discrete, actionable parts from there. You have to have that unifying scenario or vision or whatever-you-want-to-call it, or you'll end up with a bunch of pieces that, while all meeting their specifications, fail to produce the whole product as expected. You just can't ever describe the subcomponent so completely that you don't at least sometimes find yourself needing that original frame of reference.

I think sometimes people try very hard to get there - to write requirements as if they were "software blueprints" - but (in my very personal and humble opinion) you just can't do it - we almost invariably have (and need) the kind of flexibility that prohibits requirement work items that are truly self-contained.

CRathjen-MSFT at 2007-9-9 >

"VSTF" is still too high level to go turn directly into requirements work items, (at least IMHO).

I think each major component team (Version Control, Work Item Tracking, etc.) will define their vision and high-level scenarios (and, somewhere in there, key features/improvements/deliverables/enhancements/whatever you want to call them), and *then* maybe you'll go from there to work items. There may even be subordinate docs to those where it makes sense.

As far as whether we'll all use the Agile process, I couldn't say. I know some feature teams will use scrum (either they have before and liked it, or they want to try it); and of course our approach may vary over time and due to circumstances (our test team used a very scrum-like approach for a couple months awhile back, and took lessons learned from it back to our "regularly scheduled programming" :).

CRathjen-MSFT at 2007-9-9 >

Based on a suggestion from one of the Microsoft PMs on the TFS Team (who uses MindManager for requirements gathering), I built this in 4 days earlier this month:

New TFS Integration: Mindjet Requirements Manager

Mindjet has a cool new integration with Team Foundation Server that enables software development teams to quickly turn requirement maps created in MindManager into work items on Team Foundation Server. Once published to TFS, the requirements map becomes a bi-directional interface for those requirements.

We are looking for software development teams to try this out and give their feedback.

The integration is a FREE MindManager Pro 6 Add-in (with source code) that connects directly to the Team Foundation Server and can be found at http://www.mindjet.com/labs/mjrm.html. Take a look at the flash demo on that page to see the integration in action.

Michael S. Scherotter

Business Solutions Architect

Mindjet Corporation

mscherotter at 2007-9-9 >