Leadership

Ensure requirements are tracked throughout a project


Requirements tracking refers to the process of tracking (or tracing) requirements from the beginning of the project through implementation. It's a good practice for many projects – especially if you're building something from scratch. Requirements tracking is a good practice for two reasons.

  1. It ensures that all requirements are, in fact, implemented in the final solution. If you check at the end of the project to see whether they're all present, it might be too late to implement any that you forgot. Tracking ensures that you catch any missing requirements immediately in the lifecycle.
  2. It ensures that no features and functions are introduced outside of the requirements. For instance, if you add extra work in project design, it will be more obvious since you won't be able to track the design component back to a requirement. This will save you doing extra work that's not required.

In addition, a smaller benefit is that you may be able to track the requirement back to the source that it came from. This will help you know the right person to talk to if you have questions on the requirement.

Not all projects need to trace requirements. Smaller projects typically don't need to. If your have a set of ten requirements for an enhancement project, for instance, it's probably pretty easy to validate that they're all accounted for throughout the project lifecycle.

The easiest way to track requirements is through a simple Traceability Matrix. The Traceability Matrix provides a quick glance at all of the requirements and validates that they're being considered throughout the rest of the lifecycle. The simplest approach is to just validate that each requirement is accounted for in subsequent project phases. For instance, something like the following table might do.

Requirement

Design

Construct

Test

TAB-001

X

X

X

TAB-002

X

X

TAB-003

X

X

The "X" in each box validates that each particular requirement was accounted for in each phase.

There are other more sophisticated way to track requirements as well. If you have many requirements in a large project, you could even look for tools that will support this requirements tracking process.

If you're going to do requirements tracking, it must be enforced throughout the lifecycle or else it doesn't work. If the team assigns tracking numbers to the requirements in the Analysis Phase, but the numbers are not utilized in the Design Phase, the whole tracking scheme will break down. Likewise, if the Design Team follows up on the tracking, but the requirements are not tracked to the actual construct components, it will be difficult to track whether they've been tested or not and the scheme will break down. If you want to track requirements, you need to have a process to track and document them throughout the project.

This tracking can be tedious, which is probably the main reason it's not done on more projects today. However, if you want to make sure you're working on the right things throughout the project (no more and no less) then requirements tracking is the technique to know for sure.

 

8 comments
lsalazar
lsalazar

I think requirements tracking, in spite of it's importance, should (almost) never be done by programmers, I've noticed that it's usually boring for them (many times, technical people only want to code and are not interested in satisfaying the user's needs at all). Of course coding is probably the most important activity, but it's not everything in a software project.

ndsatya
ndsatya

This requiremnt tracing is in its simplest form. How do you trace requirement in a project where you have 15/17 features running. One solution which we have is to the back a backward tracability, i.e., in your DRD, HLD, DD, UT you have a matrix. Like a module in DD will correspond to 2 modules/sections in HLD, which in turn correspond to 4/5 requirements in your DRD. And UT can be place for the PM to look up. But again, if you have large number of features being handled, how you do it? Is there any other way? Thanks, Satya Narayan, Bangalore

SRRY
SRRY

I wonder if there is any post that provides guidelines on how to breakdown a requirement into small independant components. I need this to make sure that the testing phase takes care of producing test cases for each of these independant components.

velan_vs
velan_vs

The easiest way to track requirements is to have requirement->usecase->functionality mapping. This is to be updated continuously by the sys arch and be seen by all. By this every one will be aware about the basic requirements.

BALTHOR
BALTHOR

This is real world,hands on stuff.

CultOfTech
CultOfTech

Greetings, Subha. I believe you are searching for Tom's posts on WBS Decomposition. I do remember seeing such posts here before - will update with the link(s) once I come across them again... Edit - here is the link I mentioned earlier, Subha: http://blogs.techrepublic.com.com/tech-manager/?p=393 .. Hope that helps...

gihly
gihly

I have found that there can be a lot more information available from your matrix if you use the date of validation instead of an "X".

SRRY
SRRY

Thanks. We do WBS every day - though we still miss out from THE complete functional test plan by a long way.

Editor's Picks