Issue tracking for requirements
"What was that thing you were going to follow up on?
"I'm trying to remember... It must not be that important"
Ok, so you clearly wouldn't give up so easily, but what about all the other requirements issues and discussed items that no one remembers to take care of? These become the ghosts that haunt your project.
Most people think issue tracking should be used to track software bugs after a product is released. Some people use them to track bugs during testing of the software. Some brave souls may even use issue tracking to defects during software development. However we rarely, if ever, see issue tracking being used at the start of a project, during the requirements phase.
We have found that this is a time when issue tracking is absolutely critical. When you have multiple people in multiple sessions all generating tasks to follow up on with regards to the requirements, there is simply no way you can effectively track those issues without an issue tracking system.
Some of the benefits of an issue tracking system are:
1) Track the issues coming out of multiple review meetings so that no issue ever gets dropped
2) The current status of all issues is known by project management
3) Define a single owner who must resolve the issue (usually finding out how something has to work)
4) Track the history of discussion around an issue
5) Ability to enter the development phase earlier with a known set of issues rather than requiring a perfect SRS
There are many more benefits than these, but these are certainly enough.
When issues are tracked at all, the most common way we see issues tracked is through excel spreadsheets.
For small projects Excel spreadsheets can be a reasonable tool. However as the project size gets beyond 5 or 6 team members then using issue tracking becomes imperative. Either one person has to be responsible for collecting all the status information on issues or everyone writes to a shared file. In the first case, this creates a delay in pushing out information as it becomes a full time job just to do data entry on the issues. In the second case, the first time someone overwrites the master sheet or there is a merge conflict everyone will realize that there is a serious problem.
Integrating issue tracking into the requirements process is painless and actually saves so much time and energy it becomes a necessity. It is one of those applications that you wonder how you ever lived without. Depending on the ease of use of your issue tracking system, you may be able to enter the issues during a review session itself. Some of the issues may be with specific requirements, other issues may just be action items related to the requirements process.
As people get resolution on issues or have email conversations about an issue, those artifacts are attached to the issue so that anyone can see the status and a history of the issue is maintained.
One last thing, don't get too caught up in states, configuration, issue types and workflow. The key is to have the triggers to your memory that an issue even exists. Keep the process and workflow simple and use the issue tracking system simply as a list of overall requirements action items. If you do this, you will find yourself ensuring that nothing slips through the cracks.
"I'm trying to remember... It must not be that important"
Ok, so you clearly wouldn't give up so easily, but what about all the other requirements issues and discussed items that no one remembers to take care of? These become the ghosts that haunt your project.
Most people think issue tracking should be used to track software bugs after a product is released. Some people use them to track bugs during testing of the software. Some brave souls may even use issue tracking to defects during software development. However we rarely, if ever, see issue tracking being used at the start of a project, during the requirements phase.
We have found that this is a time when issue tracking is absolutely critical. When you have multiple people in multiple sessions all generating tasks to follow up on with regards to the requirements, there is simply no way you can effectively track those issues without an issue tracking system.
Some of the benefits of an issue tracking system are:
1) Track the issues coming out of multiple review meetings so that no issue ever gets dropped
2) The current status of all issues is known by project management
3) Define a single owner who must resolve the issue (usually finding out how something has to work)
4) Track the history of discussion around an issue
5) Ability to enter the development phase earlier with a known set of issues rather than requiring a perfect SRS
There are many more benefits than these, but these are certainly enough.
When issues are tracked at all, the most common way we see issues tracked is through excel spreadsheets.
For small projects Excel spreadsheets can be a reasonable tool. However as the project size gets beyond 5 or 6 team members then using issue tracking becomes imperative. Either one person has to be responsible for collecting all the status information on issues or everyone writes to a shared file. In the first case, this creates a delay in pushing out information as it becomes a full time job just to do data entry on the issues. In the second case, the first time someone overwrites the master sheet or there is a merge conflict everyone will realize that there is a serious problem.
Integrating issue tracking into the requirements process is painless and actually saves so much time and energy it becomes a necessity. It is one of those applications that you wonder how you ever lived without. Depending on the ease of use of your issue tracking system, you may be able to enter the issues during a review session itself. Some of the issues may be with specific requirements, other issues may just be action items related to the requirements process.
As people get resolution on issues or have email conversations about an issue, those artifacts are attached to the issue so that anyone can see the status and a history of the issue is maintained.
One last thing, don't get too caught up in states, configuration, issue types and workflow. The key is to have the triggers to your memory that an issue even exists. Keep the process and workflow simple and use the issue tracking system simply as a list of overall requirements action items. If you do this, you will find yourself ensuring that nothing slips through the cracks.
posted by Anthony C. at 11/14/2006 11:03:00 AM
3 Comments:
I agree, tying your defects to requirements is very important. It allows you to, first, determine if it is even a bug or an enhancement. Second, you'll hopefully avoid that requirement mistake the next time and third you might want to categorize whether it was a requirement bug or software bug. Another thought though, what if you tied your Issues/Defects/Bugs at an even higher level, like the problem statement?
Issues are trees, not rows. You might get away with rows if you are just dealing with a single stakeholder and there is only one way to do what that stakeholder wants. You won't get away with rows if you have many alternatives, if you have many layers, or if you have many stakeholders.
Traceablity should take care of bugs.
Traceability should take care of evolution. But, if a change has you revisiting an issue some 18 months later, why forget all the discussion that went on before? If you have a real issue management system that can follow the resolution and document not just the chosen solution, but all of the alternatives that had been discussed, you will save tons of time.
This comment has been moved to the messageboard
http://www.seilevel.com/messageboard/showthread.php?t=581
Post a Comment
<< Home