Have you heard of requirements traceability? This was a new concept for me in 2009 when I was studying the BABOK® and it was something I learned just in time. I was the Lead Business Analyst on a project to transform Capital One Canada into a bilingual business. In Canada, to do business in the province of Quebec, your business needs to provide services in French. The project was so large, I led a team of six Business Analysts to cover over 100 systems that needed to be changed to support the French language. I put my new-found knowledge of requirements traceability to use immediately.
Requirements traceability is a control measure. A way to ensure that all requirements are addressed and to prevent project scope creep. Does that sound like something you could use? Here’s how it works:
When the high-level business requirements are developed to define the scope and obtain executive stakeholder alignment, each high-level requirement is assigned an ID (for example, CFL1, CFL2, etc.)
When the detailed requirements are documented, each one must tie back to a high-level business requirement. If the requirement can’t be aligned with one of the high-level requirements, you’ve got scope creep… this is a great way to ensure the subject matter experts your working with don’t slip in some requirements that aren’t related to the project
In addition to capturing the corresponding high-level requirement for each requirement, there are other attributes that are important to capture:
Requirement ID
Source (who provided the requirement, used to seek clarification in the future if needed)
Priority
Once the requirements are documented and approved, you now have a library of requirements that are identifiable by the ID for use in solution design and testing. As the BA (Business Analyst), it’s critical to track that each requirement is satisfied in the solution. When the testing is conducted, each test result is traced back to a requirement to ensure the requirement is satisfied.
As a Lead BA on a large project, I implemented a template with the requirements attributes above so everyone on my team was working in unison. After the requirements were approved, the requirements IDs became part of our daily language as we worked with the systems teams to ensure the solutions satisfied the requirements. I tracked these IDs in a spreadsheet to ensure that every single one was satisfied and successfully tested. It was quite a long list, but it gave me confidence that I had control to ensure no requirements were left unmet.
If, for example, there was an issue in testing, we had the ability to look back at the requirement related to the functionality. In some cases, we reached back to the person who provided the requirement (Source attribute) to seek clarification and validation. The requirements ID’s were also used to reference and communicate changes during the life cycle of the project, which is a topic I’ll cover off in an upcoming blog.
In 2010, the project successfully completed, and I passed the CBAP exam. Our project was awarded the company’s highest honor and to this day I consider this the best project I’ve ever been a part of. I earned a promotion that year, making me a BA manager. Would the project have been successful without using requirements traceability? I am confident to say no, it would not have been 100% successful.
https://www.iiba.org/iiba-analyst-catalyst-blogs/success-with-requirement-traceability/