Re: Re. Documentation for various security levels

[Karen_Mayer -dot- TOUCH_TECHNOLOGY -at- NOTES -dot- COMPUSERVE -dot- COM]

  Thanks for your input. The product is extremely confidential, but I can
  make an analogy.

  Let's say our company is really the CIA and the software we're developing
  is used to track and solve spy missions in other countries. On the one
  hand, we have "clerks" who are entering data about operatives, the
  supplies they will need, and their locations. Then we have the
  administrators who keeps track of the missions: who's being spied upon,
  who's about to get knocked off, etc. Of course, we have the data center,
  which is in charge of making sure the network operates smoothly, provides
  tech support to the clerks, administrators, and even the spies who are
  having trouble with their equipment.

  All this data is kept in a single database and accessed with a single
  piece of software. What I suggest is putting the clerk's instructions in
  one book, the administrator's instructions in another book, and the data
  center's instructions in a third. What you suggest is lumping them all in
  one manual.

  I can see the uses for lumping them, but I can see more advantages for
  separating them. The clerks will not necessarily ever become
  administrators, so they will theoretically never need to know what the
  administrators do. It's true that a true hacker will get past such weak
  barriers as not providing a given population with detailed manuals, and
  I'm not really concerned about that. What I'm mostly concerned about is
  ease of use.

  It's hard enough getting users to read the manuals. If we put in a whole
  lot of information that isn't applicable to what the user is doing, he
  has a harder time finding what he needs. Documents that are
  system-oriented won't readily tell a user how to order plane tickets for
  Joe Doe in Brussels. The user would have to hunt for that information
  amongst a bunch of stuff he doesn't -- and will never -- need.

  Comments?

  -- karen