Contents

What this page provides

Shamelessly taken From Michael Ocean, this page outlines what is expected of a completed Thesis I document, as well as a completed Thesis II document. You should use these as guides.

(Back to top)

Thesis I

Thesis I Document Structure
  • Title Page
  • Abstract (summary of the report)
  • Table of contents
  • Motivation and Introduction (remember to reference properly)
    • Explain the domain and lead up to the problem (you're motivating your work as the solution)
    • Hypothesis—the problem statement and proposed solution
  • Related Work (remember to reference properly)
    • This is the bulk of your document. A description of all the stuff out there that you could find related to your problem. You will have subsections for each related project; they should be organized in a natural way (it shouldn't come off as a random list). There is certainly more than one way to organize them (by category, chronologically, by similarity, etc.)
    • This section should start or end with a table that is ultimately a summary of the related work, organized and categorized in some sensible way so the reader knows that you have not only considered the related work, but you bothered to present them in an easy to digest manner. The rows (or columns) of the table should be the related work, and the columns (or rows) should be the features that you've determined are the most important or relevant in the existing solutions.
    • Consclusions/Results/Discussion: a conclusion about the related work, something that leads to your rationale for the need to do something. This is where you hint for the need to create your project (e.g., "All fail to address X" or "There's nothing that does both X and Y", etc.)
  • Proposed Solution
    • Required Features
      A list with descriptions of the features, components, aspects, etc. of the solution you will design and build (which should follow naturally from your related work section).
    • Metrics for Assessment
      The specific means by which you will determine if your project is successful and a description of how you will collect the data to establish success (with caveats). This must be more descriptive than "it works". It should be broken down into a definition of what it means for your solution to work and what it means to say that your solution works better than other solutions.
    • Materials/Technologies Required
      What languages will be used? Is a web server needed? Databases? What kind of database? etc., etc.
    • Expected Results
    • Timeline for Completion
  • Bibliography (references)
  • Appendices (observations, notes, etc.)
(Back to top)

Thesis II

Thesis I Document Structure
  • Title Page
  • Abstract (summary of the report)
  • Table of contents
  • Motivation and Introduction (remember to reference properly)
    Hypothesis, background, and purpose. Create a concise problem statement in three or four sentences, like: "Here is the problem.... Here is why it's a problem.... Here is why it is important to solve this problem....". You will need to explain those pieces in more depth after this concise summary. You should also sprinkle in some related work as necessary to help motivate.
  • Related Work
    This consists of other people's work that either tried to solve your problem (or a very closely realted one), or that used your solution, perhaps for a different problem or in a different domain. It helps convince the reader that the problem is real and/or the solution you're going to propose is legit. You must organize this related work in a specific way. Come up with categories and criteria to assess them so you can group them. You are ultimately showing why none of the existing solutions are good enough and why you will ultimately create what you are proposing.
  • Methodology
    • Requirements
      Should be motivated by your related work section. This must include the metrics/measures by which you will determine if your project is successful.
    • Design Decisions
      This should include the set of design decisions you made (e.g., server-side vs. client-side) and a justification for each. It is also important to indicate when something was arbitrary vs. based on a evidence or a hunch you had. Justifications should include a discussion of the cost-benefit trade-off for that decision. The Technologies Used section may be embedded here.
    • System Architecture
      A data flow diagram or similar outline of your solution. Be clear where it fits into the bigger picture (i.e., if your flow chart illustrates a specific use case). Include pseudo code and flow charts for algorithms implemented.
  • Results
    What happened? Include a description of what you actually implemented (include screenshots and code snippets when appropriate). Describe how your solution turned out. Include quantitative and qualitative results where appropriate (e.g., the metrics/measures you said you would report). Did it work based on the criteria you set earlier? How does your solution compare with other work? You should also list any work you didn't get to here.
  • Conclusion/Future Work
    This section should be about 1–2 pages and should recap what the problem was, how your project addressed it, and what, if anything, you plan to do with this information in the future. Try to imagine the implications of your work and suggest further research to improve on it. List any conclusions or insights gained from your work.
  • Bibliography (references)
  • Appendices
    Include your source code, research authorizations (if any), consent forms (if any), instruments / questionnaires, transcripts of interviews, etc.
(Back to top)