Agile and Requirement Traceability

If you had the chance of working in an organization which has received SEI-CMMi certification then you would definitely be familiar with the concept of:

  • Requirement Baselining
  • Requirement Traceability Matrix (RTM)

If you are not familiar with these terms then the best place to look is Wikipedia.

Basically, the idea is to clearly write down what the software should do and freeze it. This process is called baselining. Then you create a matrix (RTM) which indicates how each individual requirement is addressed in the design document and then in the code.

Requirements Management (REQM) – A Process Area in CMMi Level 2

As you are aware that CMMi has five levels of maturity, 5 being the most mature. Requirement management is fundamental to CMMi as you need to master it even to achieve a maturity level of 2. RTM is an integral part of REQM.

So, if you are trying to use agile in such an organization, how would you do it?

The user stories can be treated as requirement but would you freeze it, version it and formally track the changes?

Would you be able to create an RTM without losing agility?

More Reading

6 Responses to “Agile and Requirement Traceability”
  1. Udayan Banerjee says:

    “Working software is the primary measure of progress!”

    How do you mix this philosophy with the need to need RTM updated?

    • Gene Hughson says:

      While working software may be the primary measure, it’s not the sole measure. If maintaining an RTM provides value in ensuring that the software is working according to the client’s expectations, then the effort is not wasted. It’s a similar case with emergent architecture – no Big Design Up Front is not the same as no design up front. Assessing practices, keeping those that deliver value and discarding those that don’t makes sense to me. Blindly following platitudes (like YAGNI, sometimes you really are going to need it) lacks robustness to uncertainty in my opinion.

      • Udayan Banerjee says:


        But the questions are:
        1. When would you deem a RTM to be necessary?
        2. To what detail should you maintain it?
        3. Would you always want to update the requirement document first?
        … and many others.

      • Gene Hughson says:

        I have to give the standard architect’s answer to the first two questions; it depends. 🙂

        For a team working on embedded software for a medical device, the answers would be different from those of a team working on the next “Angry Birds”. In between, depends on the context.

        For the third, my bias is to always start with the requirements and work from there.

        As you noted, there are lots of questions. An organization’s process must be architected in the same way that their systems are – tailored to the context at hand.

  2. Gene Hughson says:

    To the extent that an RTM is kept current, it can serve to enhance agility via providing a quick picture of what would be affected by a given change. In a corporate environment, I can’t imagine a scenario, agile or not, where failing to version and track changes to requirements would be acceptable. The process around that may differ, but the basic need is the same.

    What would affect agility is how “hard” the requirements are frozen. Longer periods between identifying the need for a change and getting it into the pipeline would infer a lesser degree of agility.

Check out what others are saying...
  1. […] Agile And Requirement Traceability Share this:LinkedInTwitterFacebookStumbleUponPinterestEmailLike this:LikeBe the first to like this. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: