I use a simple checklist to implement traceability on my projects. I think it is important that all stakeholders understand what is needed on a project from a traceability perspective. Traceability begins in earnest with the requirements development activities on your projects. I believe project requirements are traceable if:
- The source of the requirement is documented. Common sources include people, other documents, or if a requirement has been derived from other requirements.
- Each requirement has a unique identifier so we can reference and locate it whenever necessary.
- The rationale for the requirement is available, telling us why that requirement exists.
- All requirements related to a requirement are documented, from parent to child and vice versa. This shows the derivation, allocation and relationships between requirements.
- How the requirement is met is documented, showing us how it is achieved later in the project life cycle. On IT projects, this traces from design to implementation and into any user documentation.
- The requirements can be tracked through development and on to test for verification purposes. We should always be able to prove we delivered the capabilities that we said we were going to deliver.
Well, that’s my list, written up while standing on the “traceability soapbox.” Hope you like it! Holler if you do and holler if you don’t, I am always interested in improving my set of minimum requirements for requirements traceability…
Successful Business Analysts: How They Avoid the Five Most Common BA Mistakes
Business analysts are increasingly becoming the critical liaisons between business and solution development (oftentimes IT), so they must communicate and relate with equal effectiveness throughout all levels of an organization. Download this free White Paper to see which five common obstacles business analysts face and how to address them to ensure success.