How to manage requirements traceability?

Development and release has happened based on your requirements. Now, there may be changes / enhancements on that original requirement.

It is a very good practice to keep a note of changes happening on requirements as a result of such enhancements.

You will be surprised how many business & product teams do not do that. This is more valid in the following situations:

• You have an outsourced development team, OR
• There are multiple development teams & business teams working on the same product, OR
• You are following waterfall methodology for development and Go-LIVE

An example is shown in the below diagram:

Few pointers to consider while keeping track of original software business requirements:

1) Any enhancements should be tracked in a tool (like JIRA), and given a unique ID (like Enh-647). If you do not have a tool, then create that in a word document.

The enhancement should have the following details:

     a) What is the change?

     b) Which area / feature(s) of the product it will impact?

     c) Why this change is being made?

2) If you had the original requirement like a user story in a tool (like JIRA), then put a comment on that original requirement by giving the ID of this enhancement, so that a reference has been created for that original requirement. There are various features in JIRA for ‘linking’ the user stories.

3) In case you have a word document where all requirements had been written originally, then add a comment in that document by giving a reference to this Enhancement ID (e.g. Enh-647). Then update the version control page of this word document with the details of the change you have made to this requirements document.

4) In case you do not have a tool to raise enhancements, then, create a **section for listing ‘Enhancements’ in the original requirements word document**. Create an ID system to add the details of the enhancement under this section. Mention this ID against the original requirement and update the version control page with these details.

This is of less concern in the Agile world of ‘continuous development / continuous integration (CI/CD) i.e. you do not have to keep track of how ‘X’ feature changed to ‘Y’ feature in the later release, because that is the understanding of a product evolving through forthcoming releases of the product.

If you have any question on digital product management – be it related to career, expertise, skills, projects, or ‘How to’ stuff, drop me a line at: support@myjobmyrules.com.

I would be happy to help.