Fog Creek Software
Discussion Board

Tools for Managing Requirements

Tasked with assembilng the requirements for a technology migration of our product--Microsoft Access 97 to Microsoft .NET/SQL Server--I cracked open a copy of Managing Software Requirements (Leffingwell/Widrig) and started reading. Several weeks later, I cranked out a document template based on the one in the book, and started writing.

Now, approximately 500 pages later, I have documented about 30% of the system (the current system represents six years of development--it does a LOT) and am now faced with a bit of an issue.

On the positive side, our senior engineer--who has about ten years of experience in "shrink-wrap" software development--tells me, "these are the best requirements I've ever seen!" Feeling all happy, I proceeded to feed the developers the first of the requirements so they could get started on some framework issues. Within a month or two, however, we started running into a problem: how to keep track of the status for each requirement, especially since I am frequently either clarifying a requirement, or adding more detail to make the requirements more understandable. There's also the occasional added requirement because of a piece of "behind the scenes" functionality I simply missed in the current product.

I've been attempting a variety of methods, from tracking requirements status using Word, tracking using Excel, and tracking by sucking all of the requirements out of the Word docs into an Access database.  None of these solutions has the flexibility to handle changes in a graceful manner.

So, now I've decided that I need A Tool. I've taken a look at RequisitePro (which happens to be written by the guys who wrote the book) and it looks great. The only problem is the price tag. We are a small company with a small team (four) and we would have a tough time coming up with the required funds for multiple licenses.

My question to each of you PMs out there is this: what do YOU use for tracking the status of requirements, and how well does it work, considering the fact that there are always "little things that need to be added or changed" throughout the development lifecycle?

Tuesday, October 22, 2002

Use a bug tracking system. I won't mention any by name :) Let the engineers open bugs against requirements that aren't clear. I've been doing this for years and it works great.

Joel Spolsky
Tuesday, October 22, 2002

I am not a PM, but I will try to supply you with some useful information anyway.

The first place you can try and ask your question is at

This link will take you to a book web site. The author (Ben Kovitz - Practical Software Requirements) has a forum setup there to help answer questions about his book and requirements management in general.

A second place to try are the usenet forums.  I believe there is at least one forum devoted to requirements writing.

While some of the companies that sell requirements management tracking tools have a BBS on their web site, I doubt that you will get an unbiased answer to your question at these places.

Since you work for a small company you might want to look into the following:

* A web based product.
* An open source product (if one exists).
* Using CVS, Source Safe, or whatever version control software your company uses.
* Try to get a discount from a software vendor.

Charles Kiley
Tuesday, October 22, 2002

But how do you handle the following scenarios?

1. Requirement is added. Engineers need to be informed about it.
2. An engineer needs to track which requirements she has implemented and which she has not.
3. The project manager needs to know that all requirements have been implemented to ensure there are no "missing features."
4. QA needs to know that the requirements they are testing have actually been implemented.

I guess it's really a two-pronged question:
  1. How do I track the status of requirements?
  2. How do I track changes to the requirements?

Incidentally, we have been using the unmentioned product to track changes to the requirements, which I think handles #2 pretty well.

I think the real problem is #1. The problem is getting a handle on "where are we at," both for the developer who needs to know which requirements are complete and which are not complete, and for the project manager who needs to have access to the same information. It really boils down to a traceability issue.

Tuesday, October 22, 2002

Note: My previous reply was directed at Joel.

Tuesday, October 22, 2002

Open a "bug" for each requirement. Track it by getting the list of open bugs. When a programmer implements the requirement, they close it.

FogBUGZ 3.0 is actually designed for this, we have these things called "features" instead of "bugs". They look like bugs, they quack like bugs, but they are less insulting :) FogBUGZ even has an "estimate" field with current, original, and elapsed, so you can track the schedule with the data you gather.

For another alternative see my article "Painless Software Schedules." Big excel sheet, every requirement is a row, and programmers keep it up to date. Excel is multi-user so there is no problem with conflicts or anything.

Joel Spolsky
Tuesday, October 22, 2002

We are, in fact, using the spreadsheet in the manner outlined in "Painless Software Schedules." What we are tracking, however, are "features," that are divided into one to three day chunks. The problem is that each feature may have 20 to 50 individual requirements that need to be satisfied to make the feature work. In addition, there may be five to ten use cases that the feature invokes, which must be checked to make sure the use cases are invoked properly from each feature.

The level of tracking we're having a difficult time with is the thousands of individual requirements that make up all of the features. Today, each engineer uses the highlighting feature in Word to track which requirements they've implemented. It gets tricky, however, when they get an updated version of the requirements each month, which include small changes and additions. Word does have a merge feature, but it sometimes doesn't properly carry over the highlighting.

I guess RequisitePro was attractive because it coupled Word with a database, and allowed hierarchical grouping of the requirements. Each requirement could then be tracked and reports could be generated.

Tuesday, October 22, 2002

I too like tracking requirements with a bug tracking tool.  However, this tends to encourage people to see the trees and lose track of the forest. 

Joel (or anybody else), any advice on how to keep the big picture in focus while tracking things at such fine granularity?

Eric W. Sink
Tuesday, October 22, 2002


Like any tool, I expect your software will be used to assist end users with their activities. Each activity must have a desired outcome, a goal. And of course numerous undesired outcomes.

If you haven't already, classify the activities and their goals. You can then relate your requirements to the activities and goals.
You can write scenario's that explain the activities and how they lead to both the desired outcomes - the goals - and the none-desired outcomes.
And you can go on to explain the solutions you decided on to support the activities.
This way you trace back and forth between problem domain and technical solution.
And if you do it well, you can at any time focus on one of the elements to get the information you need. The goals for the very big picture, the activities and scenario's for a detailed explanation of the problem domain, and - ultimately - the code for the technical solutions.

That said, it is not as simple as a those few words, and I may not have explained it well.

Wednesday, October 23, 2002

Along with using source control and some bug tracking software you also need to communicate amongst yourselves.  Don't assume that because its tracked that its known.

One of the problems of documenting changes, as has been said, is that the detail can swamp any notion of the overall view.

I still use gannt charts to do this.  So long as you don't worry about resource levelling and junk you can use the folding editor mode of something like Microsoft Project to manage completions.  You could probably do the same in Excel I've just never seen the point of writing everything from scratch.

There's also the reporting benefit of something like a Gannt Chart, but I don't make any real attempt to manage resources that way because the unit of work isn't scaleable.

Simon P. Lucy
Wednesday, October 23, 2002

> "One of the problems of documenting changes, as has been said, is that the detail can swamp any notion of the overall view."

This discussion reminds me of the DOORS product from whose GUI lets you filter and drill-down and so on.

Christopher Wells
Wednesday, October 23, 2002

*  Recent Topics

*  Fog Creek Home