I am not particularly interested in what you do or do not have in the code listings but in the write-up you should have the following:

• an INTRODUCTION: a description of the problem, the purpose and significance of the project (why would I want to read/use this?) and problem statement (scope),

• definitions of terms and enough background to understand the problem (background of problem domain - just enough for reader to understand problem statement - not necessaily the solution)

  • These first two can be mainly what comprises Chapter 1. At the end of Chapter 1, one should include an outline (in paragraph form) of what will follow in the document. This allows the readers to know if they can skip chapters or what ones are of significance to them.

• BACKGROUND and/or RELATED RESEARCH on what others have done in this and related areas, (should be references in this and the previous background information section (and there may be some overlap)). Background information should include background material a reader may need to know in order to follow what you did (here the background is both the problem statement information AND the possibly background about solution techniques). This can also provide links to the reader for where they would go if they wanted to find out more (i.e., depending on the detail you provide, they may want a source to find out even more). Related research, gives a synopsis of related works, and comments on what was good (and/or missing) from these works. Also, the review of these works should contain how they differ from what you did. (I.e., how did you improve the area, what did you do different from what has already been done...or simply how does it compare.)(eg. Chapter 2) For more, see this

• then what you actually did (PROBLEM STATEMENT (eg. Chapter 3) )

  • Theory: describe your solution (more explicitly, describe your design: knowledge representation (data abstrations, object model) and general problem solving architecture and methodology)

  • Results: Demonstrate your solution (see below)

• in summary, what was accomplished along with any challenging road blocks you encountered and overcame or went around etc. (CONCLUSIONS (eg. Chapter 4))

• end with some suggestions on what one could do on the project with more time or if they were starting over. (FUTURE RESEARCH or RECOMMENDATIONS (eg. Chapter 5) - could also be in CONCLUSIONS)

About demonstrating your solution: Usually missing from first drafts is a clear and specific "demo" (basically it is a demo - you write up what you would tell someone if you were showing them how the system works). Now most people will have this, but it is usually all words. In this demonstration of your work you need *lots* *tons* of figures, screen dumps, tables, etc. so that the reader can see what someone would be able to see if they were actually sitting there. Granted, it can't be everything, but the old saying of "a picture is worth a thousand words" is very very true.

Walk the reader through a specific example. First drafts never have enough figures and explicit examples. By the time the author gets this far, they expect that everyone understands it perfectly. Not true. Explicitly describe in words what the figures are all about as well. You might understand every little thing in it, but if the reader already did, he wouldn't be reading it! Be kind to your reader.
As you write your document think of it as though you were trying to teach someone the material (or direct them to paths (references) to learn it).