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.

One More Use for Use Cases

I attended an interesting presentation, "From Use Case Diagrams to Operational Profiles: Using QFD (Quality Function Deployment) to Find the High Traffic Use Cases in Your System" by Richard Denney.

Denney presented a neat use for your list of use cases. Once you've identified your actors and use cases, get a group of stakeholders together and estimate the number of actors who will use a use case in a given time period, and the number of times each actor will use the use case.

From this analysis, it becomes very clear which use cases are most used. This is excellent for prioritizing effort and scope control. If you're developing, it's an indicator of where to put most of your development dollars. For third party software evaluations, it helps you determine relative weights for features.

One of the reasons for determining usage in a group is that it promotes discussion about the assumptions around the use cases--a great additional benefit. Where needs such as health and safety are involved, there may be some seldom-used use cases which are also critical, so keep that in mind as well.

This analysis can be done before you even write the use cases. Limited on time? It helps you determine which use cases are the most critical to write.

Denney's book, Succeeding With Use Cases: Working Smart to Deliver Quality is definitely on my reading list.

Getting by without requirements

I travel a lot for work. Travel, despite the implications of movement, actually involves a lot of waiting around, either in lines or in airline lounges. Waiting around with a bunch of business travellers often leads to some interesting conversations. I spend a lot of time talking about software requirements with my fellow travellers, and there's an interesting distinction between the way that people think about requirements.

Software companies are actually pretty good at requirements. When I talk to managers of companies who sell software as part of their business, they're generally very in tune to the necessity of having good requirements. They're in tune to this, because if software is your living, you become good at it or you go out of business.

But lots of companies create software in support of their business, not as the core of their business. This is an interesting and fertile ground for a guy who's trying to sell requirements consulting. The people who work for this type of company have taught me a lot about selling requirements.

These companies face a few obstacles:
1. They often (but not always) don't get top software engineers, because top software engineers tend to like to work for top end software engineering firms. This creates a potential talent shortage in the people who are doing the development work.
2. Management in non-software companies tend to view software divisions as cost centers, not profit centers. This means that management is generally looking to try to reduce costs in these areas.
3. Management in non-software companies don't typically understand the software development lifecycle. This means they are less willing to spend money on "weird stuff" like requirements.
4. Since software isn't the core business, the core business is typically not crippled by late or poorly functioning software. A grocery store chain is still going to be able to sell bread even when an IT accounting project is delivered 4 months late and over budget.
5. There's often no "culture of requirements" in these companies. They solve problems by throwing smart people at problems and hoping they get solved.

This second class of companies are generally the ones who most need the help of professional requirements engineers, because they are also the ones for which management most believes they can get by without spending money on requirements. For those trying to sell requirements services, the sales emphasis becomes working to sell ROI analyses that measure the impact of building the right software, with requirements analysis being sold as a follow-on service.