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?
Can you provide more details on what you are trying to do... maybe try to come up with a similar example if you can't disclose the exact details your project.
My first instinct tells me that the use case format may not be the best way to document this. Some requirements do not lend themselves very well for use cases. Hundreds of options sounds like data to me so the use case probably should say something like "the system will present the user with all the available options for the ____, see table x for more details". You can then create a separate table to capture the hundreds of options of those are part of the requirements.
Do these options ever change or they are static (the scenarios and how many of them exist does not change)?
- Adrian
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.
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.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: