Requirements Management in TFS: Part 4 (of 4): Summary
Every organization approaches the concept of "requirements" differently. Factors include general history, skill set, complexity, and agility. Many development organizations are adopting Team Foundation Server to help improve team communication & collaboration, project control & visibility, and generally a more integrated experience across the various actors in the application lifecycle.
The more pervasive TFS becomes in an organization, the more I'm asked about managing requirements within the confines if Team System. Some shops want to know about how to integrate more RM-specific applications into the platform, while others want to leverage TFS as much as possible and wait until Microsoft releases a requirements management solution (I know, I know, Word is the most widely-used requirements tool in the world - but I think you know what I mean by now!).
If you're trying to choose which path to take (TFS-only or a partner integration), here are a few basic considerations:
Benefits | Drawbacks | |
TFS Only |
|
|
Partner Integrations |
|
|
Some requirements-related resources (other links can be found in the various parts of this series):
- Requirements Management on Wikipedia (also see Requirements Engineering)
- Karl Weiger's "Software Requirements"
- Requirements Template for SharePoint
Well, I hope you at least found this series worth the time it took you to read it. I welcome any comments and feedback as this topic is always shifting in perception, intention, schools of thought.
Series:
- Part 1: RM in TFS - Overview
- Part 2: RM in TFS - Out of the Box
- Part 3: RM in TFS - Partner Integrations
- Part 4: RM in TFS - Summary