security per use case

1.1: addx/security per use case:
. know your users, the security book advises?
a corollary is:
 make it clear in both the code's logic
 and in the user's doc's,
what you expect of users .
. it was talking about the problem of
making security a hassle for users,
when, if you thought it out better,
you could find just the security measures you need
 for their use case, and then bake just that in .
. one thing I recall hating
is not knowing all the dead ends upfront .
. there's all these things that can't be done,
and you can't know about it because
"(this app is so easy, intuitive, no thick manuals, etc ).
...
. sometimes you might not know what your users expect;
so then the menu's should have a search box
in addition to the menu hierarchy;
and, if a search returns nothing,
 you ask them to explain what they want that is missing .
for touchscreen users,
and for those not familiar with terminology,
use a set of menus for identifying how features are
grouped by what kinds of things they do,
and by what the feature is called .
. let the users pick a place in that tree,
and optionally give a sentence for detailing
what's missing from the tree .
. a google app engine site could
merge all these requests and build the tree;
the tree will also be offline but not always uptodate .