Requirements Traceability by using TheBrain

Last time (March 22^nd) we discussed kicking off the project and getting the requirements gathering started off on the right foot. There are a lot of great books out there for detailed Requirements gathering, one that I enjoyed reading was Software Requirements, Second Edition by Karl E. Weigers. However I don’t want to re-hash the great material covered in books like Karls.

As I mentioned last time, I would suggest that you break free from preconceived notions of what a requirement, a change request, a use case, user story have been traditionally and look at the problem fresh.  For this installment I am going to look at tracing the requirement through its lifecycle.

The one item that tends to show up late in the project and normally during QA or Customer review is a traceability.  Traceabilty is tracking where a requirement came from, where it is going, its lifecycle of changes/modifications and then proving that it is there in the final.  Why does it show up in the end?  Customer asks, “How do I do feature request A?” Product team happily opens the appropriate area of the application and says, “Ta-da”.  The customer analyzes what they see and then puzzled says, “What about being able to do ?” Now it is the product teams turn to look puzzled…hmmm…developer speaks up about then and rattles on about some work around that might be possible, 10 minutes later, it has become obvious that somewhere in the requirements trail, something went off track and the required feature was not fully implemented and it is going to be tough to get it back in by the due date.
YUCK!
So is there hope to get around the problem?

Run to Google real quick and look up requirements traceability and you get back a few hundred thousand hits. So obviously this is a problem more than one group has struggled with this. Definition of this area is pretty good on Wikipedia (http://en.wikipedia.org/wiki/Requirements_Traceability)

By mind mapping out all your requirements you can visualize complex requirements and pieces of a process that can otherwise feel overwhelming. Furthermore, if requirements or other variables change you can instantly see what’s connected and therefore what impact these changes will have. This will help you anticipate any complications with changes and make more informed decisions about the future direction of the project.

In the last installment I mentioned using Xmind or other mind mapping software to get things organized. I really think this is an area that traditional tools for requirements tracking fall down.
Visualization of the relationships between them, see groups and how the are realized in the product.  By mind mapping out the requirements it is easier to visualized the complexity of the requirements and the pieces of the a process or feature that can get lost in the overwhelming complexity.  Getting it all understood by the team is normally possible right prior to development kickoff, but then in comes the changes, technical hurdles, timeline adjustments etc, and now how do we understand the impact these changes will have.

I have found a slightly better mind mapping tool than Xmind for these types of challenges. (Thank you Bill Deweese for showing it to me!!!)
It is called the PersonalBrain from TheBrain Technologies (http://www.thebrain.com).
Of course there is a FREE version or I probably would not have tried it out!!! (Not open source but at least free for personal use :)

So let’s see what a simplistic example might look like. Here is the scenario depicted below.
We have a small project to develop a Resume Tracker for HR. TheBrain diagram below does not show the whole project, but shows the part of the requirement related to parsing the resume into the database and populating the persons biographical information. The part of the project team depicted below has a Project Manager (PM1), Lead Developer (LD1), Developer (D1), Developer (D2), and a Database Administrator (DBA1).

The above shows an expanded view....here is a more typical view that shows the ResumeImport function centered and the related items to it:


Try it on your agile project and see if it works for you.  So far so good in my limited trials.  I like the visual-ness of using TheBrain to see the relationships.  If I drop a developer from the project, I can quickly see what requirements and modules are impacted or add a requirement for additional fields it impacts both the D1 and DBA.

I will continue to keep track of my thoughts on this huge subject and occasionally post my ideas.
Good Luck on all your endeavors!