Re. How to document multiple user roles?

[SIANNON -at- VISUS -dot- JNJ -dot- com]

Writer Whirler wonders: 
<<I am writing a user guide for an application whose users can have one of  
three levels of permissions: A, A+B, or A+B+C. The business wants me to 
write one user guide that incorporates all functions, instead of three 
separate guides, which is fine with me... How much should I explain the 
three roles a user can have?>>

And Geoff Hart responds:
<<As in any other place where you create separate roles, you need to 
define
these roles somewhere.>>
[--snip a good deal of helpful advice and examples--]
<<And yet another: In this case, A, B, and C tasks may be all closely 
related. Consider, for example, file management: everyone should be able to 
see the files (A), only some people can modify and copy files (B), and only 
administrators (C) can delete files. In this case, you might have a single 
topic (files) with three subheadings: things everyone can do (A), things 
only the creator of the file can do (B), and things only network
administrators can do (C).>>

Here's where my problems emerge (I'm in the same boat as the original 
poster).  Scenario:
-- Internally developed and used software (the end customers are our own 
people) covering multiple functions in one interface
-- A, B, C, D and E are roles that allow the user to complete different 
(sometimes complex) functions. Role A is "view only" access that everyone 
using the system must have. Role E is a function that everyone can access, 
regardless of their responsibilities, because it does not require special 
security access (performs action with output, but does not change data). 
The other roles address the ability to do things that will change the data 
in the system.
-- Users Q, X and Z can have different assortments of these roles assigned 
to them, depending on their responsibilities. These responsibilities may 
not always directly map to a specific assortment of functions.
-- Furthermore, roles C and D apply to a function that can be used for two 
different areas' products (which must be differentiated due to different 
proccessing constraints across the two areas), and thus the function 
operates differently (including the prompts and options available) 
depending on which of these types of products are entered.

So, with the following combinations, how would you structure a single-doc 
training manual?  (I'm honestly seeking feedback on different and preferred 
approaches here.)
User Q: A, B, E
User X: A, C(1), D(1), E
User Z: A, C(2), D(2), E

I am currently pushing to use an online Help format instead of the paper 
manuals, to allow smoother "if-then" navigability and one-stop-shopping for 
updates.  However, at the moment I'm having to do this with a paper 
manual.

Currently One with the Knotwork,
Shauna Iannone
---------------------------------------
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X       HELP CURE HTML MAIL
  / \

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Planning to attend IPCC 01, October 24-27 in Santa Fe?  Sign up by
October 3 and get a substantial discount!  Program information, 
online registration, and more on http://ieeepcs.org/2001/

  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.