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!

BigDog Robot

If you have not seen the Boston Dynamics BigDog robot, you must go to their website and watch the video. It is uncanny how agile this remote controlled bot really is. The quadruped walks across ice, slips, but catches itself and does not fall! It climbs over rocks, through snow, up hills etc all while carrying 340 pounds of supplies. This amazing 3 foot tall tool is going to dramatically help out our soldiers in places like Afghanistan.
While you are on the site, check out their other machines...one of them climbs walls like a spider!!!
Speaking of things that are Agile, check out the Agilistas group on LinkedIn....some great discussions going on :)

Requirements

Project Kickoff...excitement is in the air. We are going to really do a good job on this project. How will you, the business system analyst, developer, project manager and the business subject matter experts (SMEs) determine what the system should do when you are finished? There are many people involved. Everyone person hasdifferent expectations and needs. How do you deal with these difficulties, gather reasonable requirements quickly, and be agile?
There are some real common sense things to do which basically come right out of the PMBOK.

Identify stakeholders - Who is it that we are really going to listen to on this project? Who is vocal and who is knowledgable and really who owns it...these are the stakeholders.

Find a Vision Statement. This can come from senior management or the stakeholders. It must capture the essense of the project. On some of my projects, it has been almost like a second verbose name for the project. The team identified with it.

Now comes the hard part...them pesky requirements. The "Software Requirement Specification", the "User Stories", the "Use Cases"...oh...and are they Business, User or Functional requirements.
The excitement is quickly wearing off...this is where projects reach a real make or break stage. Successfully navigating requirements obstacle course and ending up with requirements that a developer can code to and a quality assurance specialist can test to is paramount to overall project success.

So the real point of this entry in my blog...how do we do that hard part. What tools? How verbose? Are little index cards sufficient? Do we need an inch or two of paper? How do we keep them up to date? Is this just a stage and once we finally get past it we can get to the fun part of doing the project?

I would suggest that you break free from preconcieved notions of what a requirement, a change request, a use case, user story have been tradionally and look at the problem fresh.

I came up with using a mind manager (XMind or FreeMind) as the tool of choice. It captures requirements in a lightweight fashion...I will blog more on the success of this tool next time...

Outlined below are important items to keep in mind for successful requirements capture and recording:

1. There are three levels of requirements.
1. Business Requirements - High level objectives of the project which are recorded in the Vision and Scope Document
2. User Requirements - Task and facilities available to the end user recorded in the Use Cases
3. Functional Requirements - Detailed listing out of each behavior that the software must exhibit. This along with the quality attributes and other non-functional requirements is documented in the Software Requirements Specification (SRS).

more to come soon...