A PaperModel is simliar to a PaperPrototype; except that it has a different audience.  The PaperPrototype is developed and shown to the customer, to validate requirements.  The PaperModel is strictly for the programmer; to help him/er clarify his/er thinking.  It's a form of LittleDesignUpFront.

Key characteristics of a PaperModel:

* Produced very informally--in a notebook, on the BackOfAnEnvelope, etc.  It may be produced with a CASE tool, word processor, etc. but the production is still informal.  Choice of the medium is up to the producer and for his/er convenience.

* Reviewed informally, or not at all; review of the PaperModel is often not a requirement.  When review occurs it is informal and done by those close to the programmer; the purpose of the review is to catch obvious boo-boos; ''not'' to sterilize the document and make it bullet-proof.

* Does not constitute requirements.  The programmer is free to change things if implementation/test finds that the paper model is inaccurate.  It's intended as a ''starting point'' for the programmer, not an iron-clad specification.

* Often, thrown away once the system in question is sufficiently working.  Or it might be kept as VOE, theory-of-operation documentation, etc... but if you keep it, be sure to either a) make it consistent with the system, or b) mark it as "early design documents" so maintenance programmers won't think that it's an accurate description of the system.