Requirements Traceability – Part 2 of 4: What to Trace and Why

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:

  • Individual requirements
  • Models
  • Requirements packages
  • Features

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:

  • Individual requirements
  • Graphical models of the requirements
  • Requirements packages
  • Requirements documents
  • Higher-level capabilities or features

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.

Happy tracing!

Susan Weese

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:

Preparing for the IIBA® CCBA™ Certification Exam

Preparing for the IIBA® CBAP® Certification Exam

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.