Share →
Buffer
Steven Borg (Mugshot)

I was recently confronted by a customer wanting to know if Team Foundation Server (TFS) could support Product development, not just Project development. That left me a bit confused, as TFS is a general tool, and supports pretty much any process, good or bad. She had been exposed only to agile demonstrations, and she was seeing user stories being created for a sprint, and then new user stories created for the next sprint. She was wondering if TFS supported requirements, as well. After some time, I finally had the A-ha moment.

With agile, there are rarely change requests. Each sprint is a new effort, and has its own set of user stories. If an organization wants to change the functionality provided by a user story in a completed sprint, the general process is to simply create another user story that specifies the changes desired. From her perspective, this was a failure to properly track requirements. She asked a very simple question: “Even with all these user stories, where can I look to see the current behavior of the system.” And that’s when the light went on, and I understood her original question.

Requirements are used for different things in software development. Sometimes they define the work that needs to be accomplished, and sometimes they are used to define the behavior of the system. From a work perspective, whether you call the work description a requirement, a user story, or a feature makes no difference at all, especially to a tool like TFS. It is simply a representation of what needs to be created. However, when viewed as the definition of the current system, a collection of work requests can hardly be considered definitive.

Thus, the conundrum. They wanted to use TFS, but feared that using work items to simply track requested work would result in not being able to definitively answer the question “What does my system do, right now?”

Of course, Team Foundation Server can easily handle this issue. But it does require being very clear about what you’re trying to accomplish, especially when using the Agile or Scrum process templates. Interestingly, by looking more closely at the CMMI process template, you can see shades of what the person was looking for. There are both Requirement and Change Request work item types. But even in this template, it takes careful use of the artifacts to ensure that the collection of requirements defines the system behavior. The process guidance provided by Microsoft does not support this model cleanly, as it misses a clear step. (The guidance can be found here: http://msdn.microsoft.com/en-us/library/dd997574.aspx)

In order to ensure that requirements map to current system behavior you need to do the following (or something like the following):

  1. Define the initial behavior using Requirement work item types.
    1. When completed they should be Closed, by reason of Validation Test Passed.
  2. Create Change Request items for any changes that are linked (with an Affects link) to the affected Requirement work item.
    1. Once a Change Request has been approved (moved to Active, by reason of Accepted), then the linked Requirement work item should be moved back to Active (Reintroduced in Scope), and edited to reflect the approved new behavior.
    2. When work is completed against the Requirement, it should be Closed (Validation Test Passed).
  3. If the behaviors specified by a Requirement are no longer needed, a Change Request should be submitted that requests the functionality be removed.
    1. Once the Change Request has been approved (moved to Active, by reason of Accepted), then the linked Requirement work item should be moved back to Active (Reintroduced in Scope), and the application modified to remove the functionality.
    2. When the functionality has been removed, the Requirement can either go through the Resolved (Code Complete and System Test Passed) state, or moved directly to Closed (Abandoned). Note: this is slightly unsatisfactory. My preference is to go directly to Closed (Abandoned) so that these requirements can easily be filtered out of the query that returns the current system requirements. However, this means skipping the Resolved phase that would traditionally be used by testers to validate that the functionality was removed. Another option would be to edit the process template to add a new state transition reason (from Resolved to Closed) like “Functionality Removed”.

So, is it worth it? Do you track requirements as work requests, or as behavior definitions? It depends on your needs. For this organization, requirements specified behavior and were audited for FDA compliance. Having requirements track against current system behavior was important.

I’d argue that for most firms, especially agile ones, the overhead required is likely not worth the effort. But I could be persuaded otherwise. Am I wrong?

Print Friendly
Tagged with →  
  • bsktcase

    I wouldn’t use Requirements to do what she’s trying to accomplish in the first place (in TFS or anywhere else). Better solution is a robust collection of test cases that not only document, but actively validate, the current behavior of the system.

    Tests add value, which combats the problem of overhead and motivates the org to actually maintain them. Even better, of course, automate them to guarantee they’re up-to-date and telling the truth!

  • That’s a great point! Andrew Clear also makes it below. A great collection of well constructed, currently executing test cases provides an excellent set of artifacts describing the state of the system.

  • Arco Witter

    This is an old article, however, I do have a question and that question is the same as the customer’s:
    How exactly can we use TFS to show the current behaviour of the system and how can we make a backlog of proposed changes?
    I didn’t find the answer given very useful, because it really only refers to the standard CMMI template and a few items to (maybe) do. It tells nothing about the way of documenting the system within TFS.

    I have searched for an answer, but I only find TFS to be used for changes (development), but not for changes in a within TFS well described system.

  • Arco, the customer does currently use the existing framework noted above to describe their system. They don’t use CMMI, but a modified process template that adheres to the need to get a Requirements-based documentation of the functionality the describes the current system. They also took Cheryl’s approach (bskcase, in the comment below yours) for much of their regulatory compliance proof by mapping test cases to existing requirements.

    So, your direct question, if I understand it: How do you document the system in TFS? The simplest answer is by querying all Closed Requirements at their latest state – that should define the system in its entirety if the above process is followed, and incomplete Requirements are not shipped to production. If a more readable output it desired, then you could use a tool like SmartWord4TFS or TeamSpec to generate a relatively clean Word document that would have the output.

    Then, to track the backlog of changes, you can use a combination of new Requirements and new Change Requests. These can be prioritized, just like any other type of user story, and delivered incrementally. (Although delivering them iteratively might be somewhat complex unless the Requirement and Change Request are kept open until the Requirement is pushed to production.)

    Do I recommend this system? Not really. It seems like un-needed overhead for most development teams. An agile approach, where the current functionality is described by the passing regression test suite, is a more actionable (and I believe, more believable) approach. However, there are definitely cases (health care, CFR 21 Parts 11 and 820, and both external and internal audit demands) that may require a definitive list of Requirements that define the current behavior of the system be kept.

    Arco, does that help? Or just confuse things worse?