This project has moved and is read-only. For the latest updates, please go here.

Management of Changes to Requirements in TFS

Jan 25, 2011 at 10:25 PM
Edited Jan 25, 2011 at 10:27 PM

What are people’s thoughts on this change/versioning scenario (not covered in detail in the document on this site) where requirements are stored in TFS as Requirement Work Items under the CMMI Process Template (where possible), rather than external documents. That is, TFS is treated as a single central repository/source for the SDLC. It would be great if we could store diagrams inline in the TFS Requirement Descriptions as well!

 

Scenario:

  1. Create Requirement A
  2. Create Task A
  3. Assign Task A to Requirement A
  4. Code Task A
  5. Check in code against Task A
  6. Set Requirement A Status to “Closed” (after transitioning through states in between)
  7. Deploy the code for Requirement A into Production
  8. Raise Change Request A which impacts Requirement A (i.e. a change is required in the Description field in Requirement A)

 

Options:

Option 1 – Inline Requirement Changes

  • ·         Steps
  1. Set the Status of Requirement A back to “Active” with Reason “Reintroduced to Scope”
  2. Link Requirement A to Change Request A
  3. Modify the Description in Requirement A
  4. Create Task B
  5. Assign Task B to Requirement A ...
  • ·         Cons
    • o   How do you determine which Work Item information (e.g. associated Tasks and other information such as “Integrated In”) was for the original Requirement A and what was for the modified Requirement? History would help a little, but would require some trawling
    • o   How do you manage Deleted Requirements? e.g. Deleted flag against the Work Item

Option 2 – New Replacement Requirement

  • ·         Steps
  1. Create a new Requirement B which is a copy of Requirement A
  2. Link Requirement B to Requirement A and Change Request A
  3. Modify the Description in Requirement B
  4. Create Task B
  5. Assign Task B to Requirement B ...
  • ·         Cons
    • o   Need to reassign all relevant existing test cases for Requirement A to Requirement B
    • o   Have to control some of the versioning manually (e.g. Title suffixed with a number) rather than using the built-in Work Item History
    • o   How do you get “latest” requirements (i.e. ones which have not been superseded, e.g. Requirement B rather than Requirement A) out of TFS, say for printing out as a Specification for signoff/upskilling? e.g. a custom Active flag against the Work Item perhaps (e.g. Requirement A would be set to Inactive, Requirement B would be Active)?

 

Option 3 – New Delta Requirement

  • ·         Steps
  1. Create a new Requirement B which contains only the changes required to Requirement A
  2. Link Requirement B to Requirement A and Change Request A
  3. Create Task B
  4. Assign Task B to Requirement B ...
  • ·         Cons
    • ·                     Difficult to read (particularly if extracted and printed for signoff) requirements as they would be quite disjointed e.g. one requirement overrides certain items in another one

 

Which option do people prefer? 

Mar 12, 2011 at 5:10 PM

Your question does not have a simple answer, though I'll try to be as simple as possible.

First:  The section on Change Management and Approvals of the guide goes into great depth on how to manage changes to requirements using TFS.  That would be a starting point.

Second:  My opinion is that requirements should be changed directly on the work item, not by creating a new work item.  The only problem is that you want to be able to track changes efficiently and make comparisons of them as they are evolved.  It leads to the measurability of requirements changes, or Requirements Volatility, which is a great thing to have.  It is a key indicator of how well your development team communicates with and understands its stakeholder.  It also gives you a defensible position when your customer puts unrealistic changes on your development team.

So, here is the dilema... you need to make changes, but TFS doesn't afford you everything I described above just on work items.  In order to do it effectively, you need to determine what constitutes a formal change.  Day to day changes to requirements are natural, especially early in the analysis effort.  and those types of changes don't need to be tracked rigorously.

Changes at key milestones, however, are very important to track.  For example on an agile project, you would want to keep track of the changes to the product backlog at every iteration boundary.  On a waterfall project, you would want to track them at the end of the Functional Spec milestone, Technical Design milestone, and subsequent development and test milestones.

The way to do it is to extract all of the work item data at the end of a milestone into a format that can allow you to snap a baseline of the data.  I use Excel, because it is easy to do and you can store the file in the Team Project SharePoint portal.  I set up milestone folders for it.  In addition to the extract of work items, you can extract Excel versions of all of your reports as well, so a snapshot of the state of everything in your team project can be stored for later comparisons (all of this is documented in the Change Management and Approvals section of the guide).

Third:  There is a concept that you indirectly indicate that I'd like to make note of.  Enhancement requests and regression testing.

I have a lot of customers that ask me about "Requirements Reuse".  I am a firm believer that requirements are not reusable.  During a project, the description of the application needs to be hardened as well as all of the code of the application.  Many people think that the product documentation is its set of requirements.  It is not, it can start with them, but needs to be cleansed to show the current state of the product, not its multiple changes.  Most teams do not do that, which is why they want to "reuse" requirements.  Business Requirements, once implemented are disposable.  User Stories and Use Cases, however, should be cleansed as part of the documentation set of the product.

So, when an enhancement to an application is to be made, a requirement can be written that either describes a change to a user story or use case, or an extension to one.  (i.e.  On the stock securities selection list, when a user selects a stock for purchase, our security administrators would like brokers to be prompted a dialog that requests their authorization credentials as  a double measure of security. ---> this is an extension to the original use case as a requirement; a NEW requirement, not a change to an existing, functioning requirement that was already implemented.)  If you maintained the integrity of your test cases linked to user stories and/or use cases that describe the product, then the new enhancement should be easy to implement along with a scrubbing of the product documentation that describes the old functionality.  Identifying those user stories or use cases is a natural part of the analysis work for implementing the new requirement.

 

That is how I would do it.

-- Mike Schimmel (MCS Solution Architect)

Mar 12, 2011 at 5:11 PM

One more thing:  Yes, it would be nice to embed graphic images in our work item details.

Aug 11, 2011 at 5:03 AM

Mike, say my BA makes a late change to an existing requirement defined in a requirement task on TFS. Are you relying on the change management process to ensure the developer is informed of that change or is there some way of setting up TFS so that the developer is aware/informed of any changes made?

Aug 11, 2011 at 3:58 PM
RichardLorenz wrote:

Mike, say my BA makes a late change to an existing requirement defined in a requirement task on TFS. Are you relying on the change management process to ensure the developer is informed of that change or is there some way of setting up TFS so that the developer is aware/informed of any changes made?


The Change Management process described in the Topic: "Change Management and Approvals" is a starting point for establishing your own change management practices using TFS.  We've given example of a workflow where you snap a baseline image of all of your relevant requirements, source code, and links and other data as well as how to use SharePoint to lock down approval workflows on those assets.

That said, you could easily build notifications into the process. Some notifications are built into TFS and are easily configured so that they can be triggered by a change to a work item.  This is not my preference in that you'll get inundated with more change notice e-mails than you'll have time to monitor.  A simpler approach would be to build a work item query that lists all work items that have change history since a specific data (say, "ChangeDate <= @Today-1", which would be changes since yesterday).  You could further filter it to work items that you are assigned to and make it a generic query called "My Work Items that Have Changed" using "assigned to = @Me".  Even in an agile implementation, where you are only assigned to current work that you've assigned to yourself, you'll know when someone else makes a change to that current work.

Relying on the process to ensure that the developer takes action is like relying on baby food to automatically feed a baby.  You have to have a champion for the process that will keep a running list of who needs to know about which changes and track it on a daily basis.  The best candidate on most projects to perform that due diligence is the project manager.