Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Requirements Traceability Matrix
Previous Previous
Next Next
New Post 7/9/2011 10:00 PM
User is offline InfoSmithy
3 posts
No Ranking

Requirements Traceability Matrix 

I'm new to the Agile methodology.  I've studied it and have an opportunity to work with it in the near future.  I'm curious where an RTM comes into play within a Scrum project.  I assume that when requirements are articulated during workshop sessions they are recorded either on cards on the wall or on a white board or something else.  I would think that these requirements would be recorded in some form of management tool (spreadsheet, database or formal RTM tool like IBM's ReqPro).  I hear that documentation is frowned on but there seems to be some need to capture the requirement in a backlog and therefore within some tool that manages the requirements.  Yet, when I do a search on traceability within this forum I only get one hit. So I would appreciate some insights to how others are managing their requirements witin an Agile / Scrum environment.

Thanks, EAS

New Post 7/11/2011 1:49 PM
User is offline anderson_analysis
4 posts
No Ranking

Re: Requirements Traceability Matrix 

Well, agile development projects try to avoid having a "requirements traceability matrix". Thats the kind of document you write once, then throw away after your requirement is implemented -- so it adds no value to the project.

What agile development projects use instead is a taskboard: the folks at Mountain Goat Software have a bunch of idealized diagrams and practical pictures here:

(You can also find numerous software implementations of the concept, or write your own, or use Excel.)

As you look at the idealized diagram, you'll see the leftmost column is labeled "Story" and the next column to the right is labeled "To Do". The cards in the "Story" column represent your user stories. The cards in the "To Do" column represent the tasks the team has decided it must do to implement the user stories. As you work on the tasks, you move those cards from column to column.

The practical upshot of this is if you get confused about why you're doing something on a card, you look at the leftmost column to see what this is doing for the business. This keeps you on track during the sprint, and the theory is that after the sprint, you won't care.

You may not agree with this theory. If you want to trace requirements down to the level of "this module does this thing for the business, so don't meddle with it" then I recommend including a reference to a user story in your code comments. That's much simpler than creating a second document for anyone writing code to look at before they look at the code.

New Post 8/21/2011 1:04 PM
User is offline Tony Markos
493 posts
5th Level Poster

Re: Requirements Traceability Matrix 


Agile is  about documenting the essential rigorously.  Agile is about minimal documentation and is not about poor documentation. 

Requirements tracability is essentially being able to see trace the lower level requirements back up to the higher level ones and vice versa.  This means it is based on an effective decomposition of requirements.   Usable decomposition on complex projects is tough to come by.   Therefore, forget about spreadsheets and databases and tools like IBM's ReqPro which do not guide you through an effective decompostion of requirements.  If the tool does not actually guide you through decomposition - which is by far the major problem at hand in establishing traceability, it only  hinders effective decomposition and is a waste of time. 

The only technique that leads to a logical, natural decomposition is data flow diagrams.  Create DFD's using a minimalist approach to effectively decompose downward to the level of detail necessary, and forget about all the unnecessary, time-wasting stuff.


New Post 9/4/2011 7:00 AM
User is offline Craig Brown
560 posts
4th Level Poster

Re: Requirements Traceability Matrix 

 As an agile practitioner I would say that traceability is a fairly common practice for most teams.  You may grow out of it over time, but tht means your whole value chain is getting leaner and you aren't carrying much requirements inventory.

(Does this make sense?)

Anyway, for most agile teams, requiremets traceability is occuring.  And it is occuring in two ways;

  • Work is being traced through the development lifecycle (often via task boards), and
  • Large high level requirements (epics?) are decomposed into more granular requirements (stories?)

I did a little presentation on it earlier agile traceability earlier year.  It may not stand up without the speaking, but the slide deck is here;

New Post 9/13/2011 10:32 AM
User is offline jvoris
1 posts
No Ranking

Re: Requirements Traceability Matrix 

Although we Agile-ists don't subscribe to the notion of a lot of documentation, we do spend a lot of time on the names of things - from the NOUNS that we use, and the high-level activities VERBS that we intend to achieve.  So rather than using technical terms like Collections, we actually use business terms like Order_Lines, and these terms are seen in in our code in what we are manipulating, searching through, and writing tests for. 

So we actually do build a lot of "identifiable artifacts" if not a traceability matrix.  You would see in the requirements "be sure to do x to y" and we will have tests that include y.x method being tested, and also "y.x given z when w" as a test, too.  This assumes that TDD or some stringent test practice is in place, which is where we place more emphasis, that what is built is top-notch.  From the viewpoint that did we satisfy the need in the requirement is now, the business had a need, and we built what we thought they wanted, and now it is the Business that comes back and tells us that they are satisfied with what was built.  That they have most of what they need to get their job done.  If not, then we re-work it and re-factor it until it is done.  (And to tell you the truth, it is rare that traceability matrices are adjusted to handle the nuance that is in this "conversation" between "the business, the software developers, and the software code-base".)

And since our TDD tests live on just as production code does, the tests in place are always still valid and kept up to date.  This is not the case for a history of traceability matrix, which is just a history-log of the backlog - what was requrested, but not how that requirement was reworked and re-worded when the database changed. . . .

You can see that this dialog of business usefulness outstrips a history log of "requests that were somewhat satisfied" which is what a Traceability Matrix is.

-John Voris

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Requirements Traceability Matrix

Community Blog - Latest Posts

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Analysis. I'm happy to share insights from my recent conversation with Kingsley T. Ihejirika, PhD, an ICT Business Analyst at the Ministry of Justice in New Zealand. Kingsley's unique blend of academic theory and practical expertise sheds light on the path t...



Copyright 2006-2024 by Modern Analyst Media LLC