Requirements Traceability with TFS 2013

One of the key reasons to adopt an ALM solution such as TFS 2013 is to be able to standardize business processes and maintain project data in a single repository to facilitate information sharing. Some of our customers spend an enormous amount of time compiling data from multiple sources to produce reports for FDA submissions and project reporting. Whether it is design control, requirements or risk reports this process can take many hours or in some cases days and still contain numerous errors.

Out of the box TFS is missing some the functionality required to implement a full blown requirements and risk management workflow, but with some clever configuration it can cover most of the key aspects. This can prove to be a significant improvement if you are coming from an organization that is using Word or Excel to track requirements.

To get started we recommend working with representatives from the different departments in the organization to collaborate to define the configurations that will work best for the organization. Ideally we would want representatives from marketing, R&D, quality assurance and operations as their participation will help ensure the solution is accepted and adopted by the organization.

First off we need to identify the data elements (work items) that we want to capture along with the hierarchy and relationships. Sometimes determining the system outputs (reports) would be a good way to help facilitate the discussions. For example, we may need work item types for Customer Requirements Design Requirements and System  Requirements that would ultimately lead to a hierarchical requirements report.  Or perhaps a risk report that will identify all the Design Requirements that have the potential to cause harm.

Once we have the work items types identified and configured we can now start adding the requirement to the system. The important part to remember is to ensure that they are linked together with the appropriate type of relationship. For example, a Customer Requirement has a child Design Requirement which in turn has 2 children System requirements. With these relationships in place it becomes easy to extract a traceability matrix for the requirements.

Now take this a step further and add Test Cases and Risks to the system. We can establish that a Customer Requirement has been tested by or validated with “Test Case ABC”, or a System Requirement has been verified by “Test Case XYZ”. Furthermore, we can also establish the System Requirement “XYZ” has related risks with the potential to do harm or Risk “123” is mitigated by System Requirement “DEF”.

Over the long haul we will be building up an invaluable data source as part of our requirements management plan that will save countless hours of putting all the pieces of the puzzle together and allow us to focus on building quality product.

Thanks for reading. There will be more to come!

 

Neil Moffatt

Passionate about everything ALM and agile process/tools adoption into regulated organizations (FDA). Specializing in medical device companies.

More Posts - Website

Follow Me:
TwitterLinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *