Interesting concept. The best I can think of is to start by rethinking the use case flows around some sort of validation model. In other words I think you need to include in your use case flows one
or more validation points where, given what the use case knows about its' environment, it can "throw an exception flow" and act accordingly.
So at a point in the main use case scenario you may have a situation where:
survive_iff( business_rule_set(x)_is_satisfied )In the case of "survival" the main flow will continue, elsewise some sort of alt flow occurs.
I can foresee a lot of complexity and problems being introduced by such a model
1. On the other hand it is an interesting idea at the conceptual level.
N.B. Also a lot of business rules would need to be expressed the other way up, which IMO is not a bad idea anyway, for example, instead of a constraint:
Rule_134.31e: "user must be 18 years old"Business_Rule_24: user proves age>=18 years
... extrapolating
Business_Rule_42: user proves eyes are blue
Business_Rule_631.2: user proves annual_income >= $USD2,300,000
So the use case flow is now dependent for survival on rules that must be "survived", rather then trying to include every alternate scenario.
hth
(whoever I am now

)
21. In fact, I'd be very careful about thinking about it2. OP ignore, it's just a personal problem I'm having with passwords