Now that we have looked at and thought about requirements traceability and managing requirements at a high level in my traceability series part 1 post, let’s move on to some more requirements traceability details. The BABOK® Guide recommends that you trace your requirements at one or more levels, as you deem appropriate. The four suggested levels for traceability in a project are:
You will have to decide your approach to traceability as part of your requirements management plan. Defining your traceability approach should really occur before your requirements development work actually begins. According to the BABOK® Guide, tracing could and should be performed for:
It is important to decide the level of traceability and the types of relationships to be traced ahead of time. That allows your business analysis team to do this work concurrently with developing the requirements. Remember that all project requirements must be linked back to a business objective. Otherwise, a requirement is not necessary to meet the business need and deliver the solution scope. Extra requirements that are not necessary to deliver the solution scope are often referred to as “gold plating”.
Implementing traceability for your project requirements demands additional work efforts from the business analysis team. I believe that requirements traceability is almost always worth the effort. After all, requirements traceability can be used for many things on your project. Let’s run through a few of those important areas right now.
Impact analysis: Traceability allows the business analyst to thoroughly evaluate the impacts of a change request to both the requirements and the solution components.
Requirements coverage: Tracing requirements back to the business objectives shows the business analyst how those objectives will be accomplished. This also allows the business analyst to confirm that all of the business objectives are included in the solution scope and the solution components.
Requirements allocation: Traceability allows the business analyst to trace the subset of requirements that are allocated to each of the solution components.
In my opinion, your requirements are considered traceable if they pass my simple checklist. You can find this checklist if you would like to link to my traceability checklist post. In my next post of this four-part traceability series, we will look at the key dependencies and relationships you should be looking for as you trace your project requirements.
If you are considering sitting the CBAP or CCBA certification exams for business analysts, check out our new study guide that can help you prepare to pass the test, the CBAP / CCBA: Certified Business Analysis Study Guide by Susan Weese and Terri Wagner! It’s a great place to learn more about each of the 6 knowledge areas and everything else you need to know to successfully pass the certification exam.
Learning Tree also offers the following certification courses to help you prepare for your exams: