Hopefully it goes without saying at this point, for this section and those that follow, and all reporting (written, slides, etc.) in your future career, you should include well thought-out graphics (plots, photos, CAD renderings, schematics, tables, etc.), initially storyboarding your message to determine the graphics you need/want, and then writing your presentation “script” and document text “around” the graphics.  With the exception of one table explicitly called for later, it is time for you to exercise your judgment and maturity in this regard.  Examples and guidance of the past was to bring you to this point where now you should be able to (no… you can), do it on your own.  Final reminder…  To help you place graphics in Google Docs with captions that remain attached, a link to a source having a figure+caption placeholder, a table+caption placeholder, and instructions for their use is available in the Figures and Tables Placement Template (FTT) provided at the same time as and with the PTR-TM template.  Now…

This section should capture the audience’s interest, selling them on spending more of their time to read the remainder of this document.  When discussing elements and features of the solution, use present tense (these exist now).  For instance, “The solution includes a dingle-hopper to receive the input material.  The material enters the system from the supply station.  It is then shaken at 50 Hz to loosen the unwanted contaminants that then fall into the disposal bins.  The disposal bins are located for ease of removal.”  Use “includes” and “enters” and “is” and “are,” not “included” and “entered” and “was” and “were” that may be a tendency if you are describing it with a post-game play-by-play perspective, which you do not want here.  Imagine yourself walking someone through it in-person, right now, in the present.  If you include any statements indicating design intent, such as “The system was designed to…”, then past tense (“was designed” versus “is designed”) is appropriate in that you are describing a past activity/action; though, using the present tense (“is designed to”) can also be acceptable in that a statement like this can be considered a descriptor of a feature (“designed to have”) or function (“designed to”) that follows “to have” or “to.”  This is not difficult; it just takes a little thinking and even reading aloud can be helpful.

Continue with an annotated graphical representation, a photograph complemented with a CAD image(s), the latter to show hidden/obscured detail if appropriate/needed.  Include a paragraph providing a description of key features related to performance (including special materials, components, and subsystems), safety, manufacturability, and maintenance/serviceability.  Describe briefly the decisions made to control cost (project cost and/or as-produced product cost) in balance with meeting all other requirements.

Conclude this section with tables of engineering requirements with prototype verification results shown.  The results column should provide quantitative results.  It is a nice touch to color code those that meet the requirement in green (add the word “pass” in parentheses below it for non-color printouts).  Likewise, color code in red those results for requirements not met (and add the word “fail” in parentheses for the reason noted above).  For those requirements where verification results are not known (e.g., verification not in scope of the project anymore, or never was due to inability to verify given budget and/or time and/or capability), color code yellow simply using the word “unknown”.  A good way to color code is to make the cell in the table the noted color, then make the text a highly contrasting color (white-bold text on red or green background, black-bold text on the yellow background).  Include a brief paragraph clarifying any requirements not fully described by their names and measurement description.

_{Google Docs is a trademark of Google LLC.}