Project Technical Report Format



The appearance and overall organization of the report as well as its content will influence the grading.

The technical report should be "professional quality" because in a real setting they will be the first description of your project that management encounters – the thing upon which they base their first impression. A slick technical report help to "sell" a project. It's hard to overcome a bad first impression in your actual (in the real world) report.

Be sure to include each of the components listed on the project page. The technical report should be submitted as a pdf file. Word allows you to save as a PDF file.

An html version (web site) of the technical report is also required. The html version must be submitted via a zip file. You can use classweb to develop and host a live version, but the zip file is required as well.

Submission checklist:

  • High-quality PDF version of report
  • Web site version of report with image maps allowing easy traversal of DFD
  • Zip file containing files for the two items above (redundancy for safety)
  • Peer evaluations submitted individually by and for each team member

You must include each of the following sections, in the order in which they appear below.


(Click on any item in the table below to see a description.)

Required Sections in Technical Report
Cover Page arrow
Your report requires a cover page. It’s all about first impressions. There are a lot of things that go into a professional proposal, but we are talking about first impressions here. So, let’s see what should be included on the first thing the reviewers' eyes fall on – the cover page.
The why and wherefore is communicated through
  • a specific title followed by the subheading "Technical Proposal"
  • the names of the authors
  • the class or purpose for which the proposal is developed
  • submission date

You can dress it up with a slick graphic or related image. See this link for more ideas.

The following templates may help provide some design ideas.

Table of Contents arrow
The table of contents page sets out the sections and subsections of the report and their corresponding page numbers. It should clearly show the structural relationship between the sections and subsections. A reader looking for specific information should be able to locate the appropriate section easily from the table of contents.
Executive Summary arrow
Be sure to include each of the following, and label each clearly.
  • Goals
  • Problems (that you encountered during your study)
  • Results
  • Recommendations

The executive summary is a critical part of a proposal, and should always be the first text the reader sees.

  • An executive summary summarizes a longer report or proposal in such a way that readers can rapidly become acquainted with a large body of material without having to read it all.
  • It is provided to give an executive an overview of your proposal.
  • It is often used before you make a presentation to management, since management will often not find time to read your entire document – that's why it is critical.
Introduction arrow
Be sure to include both of the following, and label each clearly.
  • Company background
  • Problem (that made a new system necessary)
Current System arrow
Functional decomposition of current system (be sure to include grouping of processes)
  • Include a summary of all business functions.
  • Include the consolidation (grouping) of business functions.

Current Logical DFD
  • At least one process must be taken as far as Level 2.
  • Provide textual descriptions of low level processes.

Partial Physical DFD
  • Provide a physical DFD for the two specified subsystems in the current system.

Partial Data Dictionary
  • Provide a partial version showing the specified 3 flows, 3 stores, 3 elements and one data structure.

Partial System Structure Charts
  • Provide a structure chart for the two specified subsystems in the current system.

Process Specifications
  • Provide process specifications for a minimum of ten functional primitives.
  • Select from Structured English, Decision Tables, or Decision Trees.
    • Be sure to provide a process spec in the form of Structured English, a process spec in the form of a Decision Table, and a process spec in the form of a Decision Tree for the expanded Customer Returns Defective/Unwanted Equipment process.
Future System arrow
Functional decomposition of future system (be sure to include grouping of processes)
  • Include a summary of all business functions.
  • Include the consolidation (grouping) of business functions.

Future logical DFD
  • Your future logical DFD should include and expand upon the current logical DFD.
  • Expand or decompose your DFD down as many levels as your functional analysis requires.
    • Multiple processes must be taken as far as Level 2.
      • Rule of thumb: Stop when you can explain the process in one to two sentences.
  • Provide one to two sentence textual descriptions of every low level (primitive) process.
Partial OO Representation of Future Logical System arrow
Use Case Diagram
  • Provide use cases for the two specified subsystems in the future system.

Use Case Descriptions
  • Provide textual use case descriptions for the specified subsystems in the future system.

Activity Diagram
  • Provide activity diagrams the two specified subsystems in the future system.

UML Class Diagram
  • Provide a UML class diagram of the complete future system.
Conclusion arrow
This is your final chance to "sell" your project. Make it memorable!

Here is an Example Technical Report.