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
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!
