1     Salutation

Begin with the salutation.  Replace the placeholder “Xxxxx” in the salutation with the name of your main/technical contact in whatever way you are referring to him/her — for example:

• Dear Mr. Smith (the formal default)
  – OR –     Dear Richard (if now on a first-name basis)
  – OR –     Dear Rich (if he also goes by a shared “nickname”)
  – NOT–     Dear Mr. Richard Smith (awkward, form-letterish)
• Dear Ms. Jones (the formal default)
  – OR –     Dear Susan (if now on a first-name basis)
  – OR –     Dear Sue (if she also goes by a shared “nickname”)
  – NOT–     Dear Ms. Susan Jones (awkward, form-letterish)

In other words, if you are not on a first-name basis and, thus, refer to him/her with Mr. or Ms. or Dr., etc. being a title of respect, then just use their last name, not first and last.  Note that professionally, Ms. is often used over Mrs. or Miss and eliminates the risk of inaccurately identifying her as married or unmarried, respectively.  Of course, Dr. is the appropriate professional title for someone, male or female, with a doctorate degree (Ph.D., D.Ed., M.D., D.O, D.D.S, etc.) and there are other more specific ones like Prof., Dean, Judge, Senator, … that may be appropriate.

2     Content

Your customer cover letter should briefly describe what documents are accompanying it, following the opening phrase “Enclosed please find” that is included in the template.  Note that this document (the FRD) is not a “technical memo,” rather it is a “final report.”  Include in a logical place/ordering in this short paragraph (1) the title of your project for the reader’s reference and (2) the most important achievement (e.g., a design that met all the requirements, a design that lowers cost, a design that…).

The cover letter should continue in a second paragraph (replacing “START SECOND PARAGRAPH HERE”) thanking your customer for the opportunity to work on the project with them, any other things you appreciate from their involvement, and any well wishes for them moving forward.

The entire letter (including the cc directives on the bottom) must fit on one page without change of formatting (single-line spacing).

If you cite any references in this document, copy the reference entry from your TAD reference list to here.  Select the text in the TAD, copy it, then, to retain the correct formatting in the FRD file, paste into the FRD file by right-clicking at the desired entry location and, from the popup menu, select Paste without formatting.

If you have no references cited in this report, which could happen but is sort of unusual, then delete the sentence “Those specifically cited in this document are also listed below.”  Also, delete the placeholders “[FML##]   Xxxxxx.

You now have a complete-draft of your FRD!

Here, acknowledge by name those who are not team members (organizations and/or individuals, with their organizational affiliation noted) who have contributed to the project, and provide a brief description of how each contributed.  Do not include logos as there is no certainty that permission is in place; for example, if you received steel through the Steel Warehouse program funded by Cleveland-Cliffs, acknowledge it/them, but do NOT use their logo.

This may be the most valuable outcome of your project.  This is also a very critical part of your report.  Here you describe recommendations for what could be done next to carry your work forward.  They are generally the proposed next steps one would take should more resources (time, money) be allocated.  In general, they may include, though not be limited to, continued testing, further engineering, redesign, changes, improvements, etc. that your customer could consider if they choose to take this project further.  In some cases, it could be recommended new ideas for an even better solution that evolved as you worked through testing and refinement, especially if you concluded (in rare cases and with great effort) your approach/concept is not a way to solve the problem.

Your recommendations in regard to the design are derived from the current, updated status of your DFMEA in your TAD (so you should reference the subsection in the TAD where they can find that).  Specifically, for any shortfall relative to expectations/requirements, make a recommendation for improvements.  However, even if all engineering requirements were met, you will have some recommendations.  For example, some teams find more efficient and/or effective design elements (methods, materials, etc.) too late to be incorporated into the final design and prototype but will suggest the customer consider them in the future.

Some of your recommendations have likely been mentioned earlier, but briefly note them here so all recommendations are consolidated in one place.

Close this section with a short paragraph stating what the expected outcome would be if one chooses to take these steps, following up on these recommendations.

Conclusions highlight the main findings of your efforts.  Note that this section is not a summary of your work.  Such a summary is included in the Executive Summary section.  Here, you will briefly highlight the main conclusive findings related to how well the results met the engineering requirements (engineering constraints and objectives) and/or FAILED to do so.

Almost all teams will have a conclusion in regard to projected production cost, projected replication cost, or projected refinement and implementation cost; this is NOT the project or prototyping cost.  If you have designed a “product” that is intended for eventual production, you would state your projected production cost per unit and the quantity of units produced per period (and what is the length of that period, e.g., month, quarter, year) that leads to that production cost.  If you have designed a “product” that is to be replicated just a small number of times by your customer for their own use, you would state your projected replication cost per unit and the quantity at which that cost was determined.  If you have designed a process or a one-off that will still need some refinements to take it from alpha/beta status to implementation readiness, you would state your projected refinement and implementation cost.

Continue with your other conclusions, in order from your strongest, most meaningful one down to your least strong and/or meaningful one.  There is no need to have many conclusions, so don’t “make them up.”  Also, note that conclusions are not summary items; they are what you have concluded as a result of your work.  This section may be very short; that is fine, make it meaningful, not fluff and length.

Remember, this is about your testing with the prototype.  For some projects, though very rare (e.g., very large-scale systems), the prototype is a high-fidelity virtual-world prototype in the absence of a physical-world prototype.  And for digital engineering tool projects the prototype is “physical” but in the form of software not hardware.  In any case, this is not verification activities at the design stage (math, analysis, etc.), rather it is verification using the prototype.  That is, you are writing about testing with the prototype, and driven by that, the refinements made and then further evaluated with further testing.

For those projects employing a virtual-world prototype, report on your findings that result thorough the simulations that have been done in lieu of a physical-world tests.  And, furthermore in this case, since others in your audience may not as easily accept the idea of a simulation model being a “prototype,” please do the following:

1. edit the headings of Section 4 as follows:
   1. Prototype Verification → Simulation Verification
   2. Prototyping-Driven Refinements → Simulation-Driven Refinements
   3. Production vs. Prototyping → Implementation Considerations
2. read Sections 1 and 2 then skip to Section 4 of these instructions.

1     Verification Testing and Data Analysis Subsection

In this subsection, in paragraph format, supplemented with bullet-list format, provide information regarding instrumentation and test methods used with testing your physical prototype, whether hardware or software tool, etc. (unless you don’t have a prototype as noted above in some virtual-world simulation-based projects).  Regardless of whether you have a physical prototype or simulation-based proof of concept, there is data analysis to then be covered.  The difference is only from where the data come — physical testing or virtual, simulation-based testing.  In either case, discuss data analysis.  Draw this information from the prototype-stage verification table, updated to reflect what actually happened.  Unlike that table, to avoid repetition, do not present this section on a requirement-by-requirement basis (since often times there are multiple requirements verified by a single test/method).  Though, each method noted should indicate by naming all the requirements it serves to verify.

2     Prototyping-Driven Refinements Subsection

In this subsection, in words and with complementary annotated graphics, describe all refinements made and the reason for making them.  You should consider a refinement anything changed after it had been realized in full system-level prototype form (beyond function-level concept MIP or physical feasibility trials).  This means, generally, anything made and then re-made/modified after about week 5 of Term-II.  Of course, if you did not manufacture a prototype, then your refinements to your design as described here are simulation-driven.

3     Production vs. Prototyping Subsection

There are two types of projects:

• Process-related projects require the development of a prototype as either a single final product, or as a model for replication in limited numbers and timeframe, to be used by the customer/end-user for their own use in one of their processes you have been addressing.
• Product-related projects require a prototype for development into a commercial product to be manufactured and/or sold by the customer.

By the way, do not call these out as formal “types” in your writing; this is just for discussion purposes here.  In either case, any physical prototype would be considered an alpha or beta prototype at best, meaning there is generally a next step needed to bring it to a beta and/or final prototype, or at least to incorporate improvements based on learning that took place in the prototyping work and testing you have completed.

Describe in words any differences between the intended manufacturing for which you designed and the actual methods used in your prototyping that took place (which often requires some adjustments in materials, components, subsystems, or manufacturing processes compared to what you ultimately designed for).  This should account for any learning that took place through the prototyping process.

4     Simulation-Based (No Physical Prototype) Projects

As noted above, instead of a “Production vs. Prototyping” subsection you will have an “Implementation Considerations” subsection.  In this case, focus here on considerations of how the system would be manufactured/implemented.

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.}

Given that your audience is your customer, and they understand the “why” behind the problem, the “Current Situation” narrative is not the right thing here.  Instead, this should be of a more technical flavor, and not a narrative or story.  So, this is likely a from-scratch section, though likely not from a clean sheet.  That is, there is useful content in the “Problem Understanding” section (latest version is in the PTR), though not all of it nor verbatim.  So, start with that, and flesh it out a bit.  This need not (should not) be long.  But, it is also important that you update it to present status of the project.  That said, when speaking about what the solution must do, or engineering requirements, keep in the present tense since the wants, needs and requirements STILL exist currently; they may have been identified before (past), but they still exist now (present) — so use present tense in regard to “what they are.”

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.

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

This section is comprised of the “Project Overview” section from your Problem Understanding Document, but ONLY the first paragraph and the stakeholders list/table.  To bring this content in, select the content in your Problem Understanding Document (all of it together as a single selection), copy, and select “SELECT THIS PARAGRAPH” (select the entire paragraph by triple-clicking anywhere in the paragraph).  Then paste.  The formatting, if you had it right in the Problem Understanding Document, will be correct.

Take some time to update this in case names have changed, and also to refine it based on your much better understanding of the problem at this point.  This will not take long, and will be time well spent to produce a document worthy of your hard work all year.  And at the very least, update the verb tense so it makes sense now versus before; that is, the project is complete, you are not “going to do” things (future tense), they have been done (past tense) and the solution is what it is (present tense).

Think of it this way, you are describing a scene — your situation as a team and project — as of the time you set out back then.  You do not talk about what was actually done since, that comes later.  Some examples follow:

• “Team ## was [not ‘has been’] engaged to …”; better yet, try “We were engaged to …”, using “We” instead of “Team ##” or “Our team was engaged to …”
• “Some of the primary challenges were [not ‘are’] …”
• “We set out to produce [not ‘will be producing’] a …”
• “Proving out with a more complex design was considered [not ‘would be’] ideal … but until this simple circuit was [not ‘is’] proven feasible, complexity would not [not ‘will not’] be pursued.”

Of course, do not include use italics in your formatting.

You can do this and can do it well, with just a small amount of time and a little thought.

You are now done with this section!

Write this from scratch.  It is okay to copy bits and pieces from previous documents and tech-memos, but be sure the final result flows well, so as not to seem like it is pieced together.  AND be sure to update the verb tense so it makes sense now versus before.  In all honesty, it will be easier to just write it fresh from scratch; but, do this after you have a complete draft of the rest of the document, which is what you are summarizing here.

The executive summary of this document, in the format provided in the template (Times New Roman 12-point, 1.3 line spacing, 1-inch margins, etc. — “Normal” paragraph style), should be a maximum of one (1) page.  As always, you must be complete but you must also be selective to make it fit and not spill over to a second page!  Remember the importance of executive summaries as described in the book. (Math to Mettle, Chapter 5, Section 2)

In the template, select “START HERE” and begin typing.