Two documents, two audiences
Documentation is produced once a system has been developed and tested. Technical documentation is for IT/technical staff who maintain, fix or upgrade the system and assumes programming knowledge. User documentation is for the end user who operates it, in plain language that assumes no programming knowledge. Purpose, limitations, hardware/software requirements and input/output formats appear in both, for different reasons.
Technical documentation components
Technical documentation holds what an IT professional needs to maintain the system: purpose and limitations; the program listing (source code) and programming language; flowcharts/algorithms showing the logic; hardware/software requirements; file structures (field names, data types, lengths); a list of variables with their meanings and data types; input/output formats; validation routines; and sample runs — test data with the expected results, so a change can be checked.
User documentation components
User documentation holds what an end user needs to operate the system: purpose and limitations; hardware/software requirements; how to load, install and run it; how to save, print and add/edit/delete records; input/output formats; error messages and what each means; a troubleshooting guide of common problems plus a helpline; an FAQ; and a glossary of on-screen terms with plain-English definitions. All in plain, everyday language, as no programming knowledge is assumed.
Drawn from real examiner reports.
Technical-only item in a user answer
Program listing, programming language, flowcharts/algorithms, file structures, a list of variables, validation routines and sample runs belong ONLY in technical documentation. An end user never needs the source code or the program's internal logic, so listing them under user documentation earns no mark — credit is only for the item in the CORRECT document.
User-only item in a technical answer
How to load/install/run, how to save/print/add/edit/delete records, error messages and their meanings, a troubleshooting guide, a helpline, an FAQ and a glossary belong ONLY in user documentation. An IT maintainer needs no FAQ page or step-by-step instructions on clicking Save, so listing these under technical documentation scores nothing.
Some items belong in BOTH
Purpose, limitations, hardware/software requirements and input/output formats appear in BOTH documents, for different reasons: a maintainer needs them to understand the system's design and constraints; a user, to know what to expect and what equipment is needed. Assuming every item is exclusive to one document throws away an easy mark.
"Instructions" is too vague
Writing "instructions" does not say what the instructions are FOR. "How to install the software", "how to print a document" and "how to add a record" are each a separate, specific item. A documentation question is usually one mark per correctly named item, so a vague word that cannot be matched to a specific mark point scores nothing where the precise item would score.
"Help" is four different items
"Help" does not identify which documented item is meant. The specification names four distinct items: a troubleshooting guide (common problems and fixes), a helpline (contact details for unsolved problems), an FAQ (frequently asked questions) and a glossary (term definitions). A bare "help" matches none of these named mark points, so it fails where the precise item scores.
Item described too loosely
When a question says "describe" an item, the loose version fails. A glossary is not just "a list of words" — it is technical terms with plain-English definitions for a user with no programming knowledge. A sample run is not "an example" — it is test data together with the expected results. State both required elements in the exact spec term, or it cannot be credited.
Apply the audience test
For each item, ask: would an IT maintainer need this, or the end user? Program listing, flowcharts and validation routines pass the first (technical); how-to-save, error meanings and an FAQ pass the second (user); purpose, limitations and hardware/software requirements pass both.
Use the exact spec term
Name items in the specification's own words: "sample run" (not "an example"), "list of variables" (not "a list of things"), "troubleshooting guide" (not "help"), "glossary" (not "definitions"). A precise name is unambiguous; a loose paraphrase risks matching no mark point.
"Explain" needs a because
If asked WHY two separate documents are produced, "one is for the programmer, one for the user" is not enough. Add the reason: the audiences need different information and language, so one combined document would be too technical for the user or omit detail the maintainer needs.
Compare = same feature both sides
To compare two items (e.g. a sample run vs a troubleshooting guide), match the SAME feature on both sides — purpose, then audience — not describe each separately. Name which document each belongs to and why. Treating them as interchangeable "checking" items caps the marks.
Full notes, flashcards, Q&A and the topic quiz for every premium subject.
Premium plans are US$8.99/month or US$49.99/year — first month free.
Studying with a parent's blessing? Show them this.
