I am currently trying to capture the requirements for an application that can have hundreds of widget enable/disable scenarios for one screen.  Has anyone ever tried to tackle something like that?  If so, how did you tackle it?

I tend to agree.  something that dense isn't well articulated by a use case.

However... what is a user doing in front of this screen?  Monitoring stock prices for example?  Playing a game?

A use case may be a starting point.

But there will be layers.

K Robert wrote Thanks for the info & sorry for the vagueness.  I support a decision-support app that derives it's content from policy(govt).  Each procedure in the policy is a use-case in which we create a screen and present the user with a decision-support path.  Since the procedure contains many if/then clauses, the user is presented with a screen that enables/disables functionality based on this.  So, depending on the functionality of the screen, there can be hundreds of combinations of enabling/disabling screen-widgets based on the previous/current widget value. (i.e. Clicking a check-box can disable/enable other widgets on the screen). Hope this helps.

Since your application is policy driven you should not "hard code" the policy logic in the use cases.  Let the use cases capture the functional behavior which is less likely to change and capture the actual policy logic in a separate repository.  It almost sounds like you need to treat your policy logic as business rules or some other form of metadata.

You should design your app in such a way so that you can easily modify the policy logic without having to modify the actual application.

I would not include all those hundreds of in a use case!

At least consider capturing that type of information in a spreadsheet if you do not have a rules engine at your disposal.

- Adrian