One problem with tracking progress and status through use cases is the invisible scope creep they allow.
Adding a single phrase to the textual description of a use case can add more functional requirements that need to be implemented. However, from a manager's perspective there are still the same number of use cases. It is only when a developer starts complaining that use cases are growing that the managers starts to see the problem and by then it could be too much of a task to quantify the scope creep.
In a features list adding new features is immediately visible to managers and Jeff's 10% rule can be applied.
Use Case Driven Development
I saw Steve Palmer's comment regarding use cases and scope creep. I agree completely that if a project does not have a good requirements-management process, adding a line to a use case can blow out a project schedule. However, when this occurs, this is not the fault of use cases. Instead it is the fault of an inadequate RM process and the project manager for tracking against use cases instead of a more meaningful and realistic work item. One of the biggest project management mistakes I see is that people manage against implementing use cases. You do not implement a use case. You implement and test a path through the use case - a scenario.
Features appear to be a nice thing to give this visibility, but they alone are not good enough either because they do not map properly to business processes (often they are too small). What is needed is a middle ground between the two. Tracking both features and scenarios is the key to solving the problem Steve mentions. (Scenario-driven development is so close to feature-driven development that it is not funny.)
A scenario is a single path through a use case from its start to one of its end points. In many ways a scenario is a functional decomposition of a use case and will often be at the same level or a little bit higher than the features you find with FDD. The key difference however is that scenarios always map right in to a business process and their value to the overall business process is immediately visible. Scenarios also enable you to reuse requirements (flows) that exist elsewhere in a use case. Features are often at too low a level.
The main reason use cases have fallen out of favor is that use cases have always been captured as documents in a word process. But the UML semantics associated with use cases do not work in a document-based paradigm. A classic example is the <> and <> relationships. Overuse of those is a path to oblivion. There is an interesting tool I have been playing with that is attempting to solve this problem. It introduces the idea that a use case needs a perspective (or view) that lets you filter out the flows that are not related to the scenario (feature) you are developing, but allows you to reuse the flows accross features - thereby allowing requirements reuse. The tool is called Use Case Studio, by Rewritten Software. The url is http://www.rewrittensoftware.com.
I have used this with the RequisitePro plug in and we are now able to trace from features directly to scenarios and out to our Microsoft Project plan. If an analyst touches a flow then the scenario is marked suspect and flagged in the plan. It really has solved the problem described by Steve.
Bryon Baker
bakerbr@empulsys.com.au