Category Archives: Guidance

PUD Section 3 — Background Research Findings

This section should be no more than three (3) pages in the format provided, including a small quantity of graphics that are the most useful to conveying your background knowledge.  It is a summary of the Individual Background Research B-Sheets compiled in Appendix A of your Technical Archive Document (TAD).  This section is extremely important and approval of the PUD will not be given until the team is judged to have a sufficient understanding of the problem domain in terms of content described here.

Note that the next section of the PUD will get into specifics of engineering requirements as defined by you by translating information of needs and wants from your customer into engineering requirements; engineering requirements should not be covered here.

The Background Research Findings section must demonstrate your cumulative understanding of the problem domain and beyond and outside the problem domain (near-field and far-field discovery), not the problem itself (that is captured in the Project Overview, Current Situation, and then, as defined in engineering terms, in the Engineering Requirements later).  The remainder of this section should be concise text including paragraphs and, as appropriate, bullet-point lists.  It should cover highlights from the cumulative individual background research work of all team members.  It is up to your team how you want to organize the content; doing a good job of organizing it will take some good thinking from multiple team members.  Given the anticipated length of this section (more than a page or so), you should use subsections to organize groupings of content here (as long as you have two or more; one subheading/heading makes no sense).  Use paragraph style “Heading 3” for subheadings; getting numbering to work in Google Docs is far from straightforward, so samples are included for you to use (make a copy of one of those provided if more are needed).  There should be at least one, more likely 2-3, really important graphics worthy of inclusion.  However, leave most of the graphics to the B-Sheets in TAD Appendix A to be included with this document.  Remember, the strict page limit with graphics is three (3) pages!  And no adjusting font or paragraph formatting to cheat that!  In regard to the bio/nature-inspired discovery work, unless you really found something plausibly relevant and/or useful, do not cover that here (but do keep it in the TAD Appendix A pages).  Reiterating from earlier-section guidance, for the last time here, 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 linked via the comment on the cover page along with the link to this guidance.

This section should begin with this sentence that directs the reader to additional details of background research.  The template does so by providing a sentence “The full details of the raw background research may be found in Appendix A of the attached Technical Archive Document (TAD).  Highlights are summarized in the subsections that follow.”  Keep the sentence as is then begin writing in the next paragraph where it says “START HERE-BACKGROUND”.

Conclude this section with a brief paragraph focused on what you learned, overall and/or most importantly, and how (with specifics, not generalities) this learning/information will influence your work moving forward.  The template provides a lead-in sentence to this paragraph, stating “The most important elements of what we learned, and how that will influence our work moving forward, is summarized as follows.”  Keep that sentence and then add to it where it says by selecting “CONTINUE FINAL PARAGRAPH HERE” and typing.  You should demarcate the start of this paragraph with a subheading “Moving Forward.”  Note that this is not a “summary” of the preceding, but a brief coverage of what these findings mean to you moving forward.

Again, the page limit with graphics is three (3) pages!  And no adjusting font or paragraph formatting to cheat that!  At the same time, using less than three pages is likely falling short.  The challenge here should be how to convey a complete coverage of your background research findings — the highlights — that is also concise enough to fit in 3 pages.  In doing so, the graphics need not be huge, but they should be large enough to make out what is important in them.  And you can work text around the graphics as well to avoid losing piles of white space to the sides of the graphic.

© 2017, William J. Endres Updated February 09, 2022

PUD Section 2 — Current Situation

This section is not about “the current situation for your team/project.”  Read below!

This section is about the current situation/state as related to the use of and/or need for the process/product upon which your project is focused.  Read on.

This section should be no more than ½ to ¾ page in the format provided, leaning to ¾ page if you include a brief note on a future vision.  If you have two narratives, as is applicable in projects with two different end-user classes and “situations,” then each may be of the noted length, doubling the length of this section.

1     Current Situation

The current situation is the focus.  In narrative form, verbally paint a mental picture of the current situation as it relates to this project.  Including one or more graphics to depict the current situation is a great addition if reasonably possible.  Repeating from the Project Overview section guidance, 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 linked via the comment on the cover page along with the link to this guidance.

If the project is addressing a pain point, then help your audience enter into the pain currently experienced by an end-user.  If the project is seeking a gain over the current situation, then simply describe in narrative form the current situation without attempting to make it out to be a bad or painful situation.  Just tell it like it is.  Including a photo or two is very helpful here to orient your audience to the problem domain and the current situation; not doing so would be seen as a serious shortcoming.  You can extend the page-length guidance above to accommodate a graphic or two (consider those page-length numbers to be guidance on textual length).  Examples (the textual part, no graphics) can be found in the book (A Game Against Reality, Chapter 8, Sec 2.3).

If you include more than one end-user classes/situations, start each with a subheading.  Use paragraph style Heading 3 here, which should introduce automatically subheading numbers 2.1 and 2.2.

Note that our interest here is end-users (typically), not other stakeholders.  Other stakeholders are important, and use cases from their perspective are important; but for now, we will focus on end-user perspective(s) to tell the story.  This should be an explanatory story more so than just an explanation.

2     Future Vision

Only briefly make note of how the future will be different, if you can do so in general terms; that is, in an unforced way given that you do not have a specific solution yet defined.  If you include this, again in narrative form, verbally paint a mental picture of the future with a solution realized and in use by an end-user.  Whether a pain or gain is at hand, the future should be pain-free.  Help your audience enter into and experience what the future could be like.  It is less likely that including a graphic here will be helpful as noted for the current situation above, but if you have a graphic that makes sense to the purpose of this content, include it.  Examples can be found in the book (A Game Against Reality, Chapter 8, the end of Sec 2.3).

© 2017, William J. Endres Updated February 09, 2022

PUD Section 1 — Project Overview

This section should be no more than one (1) page in the format provided and including one graphic (NOT counting the stakeholder table if it is more than 5 rows; this is rare, but sometimes a well-thought-out table is longer than that).

1     Paragraph 1

This first paragraph will be written before the executive summary is written.  However, given the content expected for the first paragraph of the executive summary, there is a risk that this paragraph could be very similar to it.  This is often a potential pitfall in documents — similarity in the executive summary and an introduction section of the main document.  What is also common, and expected by the audience, is that the author has taken the time to not verbatim copy and paste from one to the other.  They will often be read in immediate sequence.  Reading the exact same thing again here after reading it in the executive summary would be, as you might imagine, pretty annoying.  Don’t do that to your audience.  Don’t do that to yourselves; that is, putting your audience in a less-than-favorable frame of mind at the outset.  You want to put your best foot forward here (along with the executive summary), not set the stage with annoyance through laziness.

As such, consider this first paragraph to include one sentence (per item) covering each of the following numbered items in the stated order:

  1. Identify the problem domain including reference to a relevant graphic, annotated to focus the reader’s attention to the few important elements in the graphic. 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 linked via the comment on the cover page along with the link to this guidance.
  2. Describe the “pain” or “gain.” You will expand upon this in the next subsections.
  3. Identify your customer and the general nature, or general idea, of the solution they are seeking.
  4. Identify the end-user(s) and how they will benefit from the solution.
  5. Identify your team by listing names of student members, your Primary Advisor, and your customer technical contact.

Select “START HERE-OVERVIEW1” and begin typing.

2     Stakeholder List

After the first paragraph, the template provides a sentence “The project stakeholders are summarized as follows” after which is a formatted two-column list.  Keep the sentence as is then fill in the list.  The first row is your customer.  Provide a concise reason for their inclusion, that is, their “interest or concern” in the project and its outcome.  For each stakeholder, the “reason” is not what they do, or their responsibilities; it is a description of why this matters to that individual or organization, how they will be affected by the outcome of the project.  The final row is for “your business”, that is, the ME-EM SCD Program.  That has been entered for you.  This must be the last row; other stakeholders are always higher priority, but still it is important to recognize “your business” does have an interest and concern in the outcome of the project.

The rows in between your customer and your business must include (second to your customer) end-user(s).  If your customer has helped you identify more than one end-user (class), include them all.  If not, don’t; that is, don’t make things up.  But there is always at least one end-user (class).

Beyond obvious end-users, this becomes an important thinking exercise to get you realizing this project is much more about others than yourselves, and who those others are and why it is important to them.  There is likely one or more other personas/parties significantly affected and, thus, having an interest or concern in the outcome of the project; note that they may not even be aware of the project.  Be thoughtful; this is neither a hoop to jump through nor a place to write fluff.  Recall from the book, there are various stakeholders, such as but not limited to those who manufacture, maintain, repair, and sell the product or process.

Space has been provided for one stakeholder between your customer and the SCD Program.  If you need more rows (and you generally will), select one of the middle rows (not the title row, first row, or last row!) by clicking just to the left of the left column at that row, right-click, and select ‘Insert   ►’, then ‘Insert Rows Above’ or ‘Insert Rows Below’.  By following these instructions you will preserve the provided formatting.  Finally, while you as individuals are indeed stakeholders, and/or is your team as a combination of you as individuals, this is not a place to state that.  The focus here is on others than the team and its members.

3     Paragraph 2

Conclude this section with the two project constraints that are common to all projects, and the big-picture describing what defines success.  Those two constraints are time and money.  Thus, begin the paragraph with a single sentence stating (1) by when the project must be completed and (2) the monetary budget allocated.  Follow that with how you define success at (1) the end of the first term and (2) at the end of the project; one sentence for each of the noted items.  This should be one short focused paragraph of three sentences.  Select “START HERE-OVERVIEW2” and begin typing.

Give “success” some solid thought — great, well-thought-out success statements, versus so-so or even simply good success statements, goes a long way to establishing, from the start, (1) your credibility and (2) others’ level of confidence in you.

In regard to articulating it in written (or spoken) words, try to find a way to state it without explicitly using the word “defined.”  That is, avoid writing “Success at the end of term-I is defined as…”  Not only try to avoid the explicit use of the word “define,” but also try to frame it not in a status of your work, but in what you will have accomplished or will do/execute.  Use bold, definitive words/phrases, not weak ones like “we wish to” or “hope to.”   Rather, “we will…”  For example, “At the end of Term-I we will…” then state the action like “deliver” or the accomplishment like “have completed.”  Go ahead here and use first person.  First person should be used sparingly, and that actually makes it more powerful when used in a place like this.  “By the end of the project we will deliver a tested, functioning prototype and all supporting documentation” is way better than “By the end of the project a prototype should be complete along with a final report.”  There are differences both in person (first versus third) and voice (active versus passive) and definitiveness (will versus should).  Note that this all applies to paragraph 5 of the Executive Summary when you get to writing that.

© 2017, William J. Endres Updated January 08, 2022

PUD Executive Summary

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. — paragraph style “Normal text” in Google Docs), should be approximately ¾ to 1 page (1 page max; be complete but you must also be selective to make it fit and not spill over to a second page!) — NO changing font size or line spacing.

As with all executive summaries, this should be written after the body of the document that it is summarizing.  Here, as you are starting, very specific guidance is offered.  Still, you should write it after you have a complete-draft of the body of the document.  But, in doing so, it should consist of five (5) paragraphs as described below.

Here and throughout this document, and the rest of the course documents, you must realize that members of your audience outside the SCD Program do not know what the various acronyms mean, such as PUD, TAD, and PPD.  It is okay to use the acronyms, but only after introducing/defining each; for instance, “In the attached Technical Archive Document (TAD)…” and later “The TAD illustrates that…”  Though, introducing an acronym early on and then not using it until much later in the document is not very effective either.

1     Paragraph 1

Begin with the text included in the template, that is, “Our team has been engaged by CCCCC to XXXXX.”  Here, the XXXXX placeholder should be replaced with a phrase describing in a condensed way what you have been asked to do — meet your customer’s need for a solution to a problem as they see it.  The placeholder CCCCC is where you write out (identify) your customer and include any relevant specifier if (and only if) applicable.  This first paragraph should continue with a few sentences (perhaps 3-5) describing the pain or gain at hand.  We are engineers, so remember to be quantitative (include numbers) to the extent possible in describing the pain or gain at hand.  Some examples follow.  Select “CONTINUE HERE” and begin typing.

1.1    Example — Parts Cleaning

Senior Capstone Design Team 1 has been engaged by the Endruff Manufacturing Corporation (EMC) plant located in Rainyville, IL to solve a part cleaning problem.  The overall problem is that the parts are coming out of the tapping machine coated with oil and chips, which interfere with downstream processes.  EMC wishes to eradicate the need to transport parts to a batch cleaner after they come out of the tapping machines.  After meeting with the customer and visiting the plant, it has become apparent that a driving factor is the desire to eliminate the 3,000 square feet consumed by the batch cleaner, given that the plant is land locked with limited potential for expansion.  As such, each cleaning system of the developed solution must be contained in the floor space of the single tapping machine it is servicing, which is about 24 square feet.  It is imperative that the end-users — machine operators — be considered and consulted given that a previous solution was never fully implemented due to difficulties experienced by the operators.

1.2    Example — Surgical Drill Attachment

Senior Capstone Design Team 2 has been engaged by JCS Instruments (JCSI) of Snowville, MI to improve an attachment interface of a surgical product.  Surgical drill systems include the drill, which houses the high-speed motor, bearings, and controls, and an attachment that allows different reach distances and angles.  JCSI has received numerous complaints about the force required to remove the attachment from the drill.  For instance, surgical technicians have, at times, dropped the attachment on the floor due to the sudden release of the attachment from the drill when pulling them apart.  Also important is that the interface provides sufficient stiffness so the surgeon, when using the drill, does not experience unacceptable vibration or static deflection when targeting regions of boney mass to be removed.  En route to a solution, the extraction force and stiffness of the current interface must be determined.

2     Paragraph 2

The second paragraph of the PUD executive summary should summarize in 2-3 sentences findings of the background/domain research.  Select “START HERE-EXEC2” and begin typing.

3     Paragraph 3

The third paragraph of the PUD executive summary should summarize the end-user use case(s).  This should be 2-5 sentences.  Some examples follow; note that some adjustment might be in order for improved flow from paragraph 2 to paragraph 3 from what is provided as examples.  Select “START HERE-EXEC3” and begin typing.

3.1    Example — Parts Cleaning

The parts cleaning system use case involves the machine operator releasing accumulated parts from each of the four tapping spindles into the parts cleaner.  The cleaner must not obscure the operator’s reach to the parts accumulators.  The operator is also responsible for periodic emptying of byproducts — collected oil and collected chips — into respective waste disposal containers.  The operator must also be able to periodically replenish the system with cleaning solution concentrate and water.

3.2    Example — Surgical Drill Attachment

End users include both surgical technicians, who are responsible for changing attachments on the drill as the surgery progresses, and the surgeon, who employs the drill system for drilling, cutting and sculpting bone.  Surgical technicians are under the pressure of speed and, of course, sterility.  Dropping an attachment on the floor as noted would add to the pressure and time; the longer the surgery takes the greater the cost and risks.  In regard to risk, any unexpected movement of the drill bit tip due to flexing of the attachment-drill interface is undesirable at least, debilitating or fatal to the patient at worst when working close to the central nervous system.

4     Paragraph 4

The fourth paragraph of the PUD executive summary should summarize in 2-4 sentences the engineering constraints and objectives.  In the interest of space, it is not necessary to cover objectives of priority less than 3.  This is a place to be quantitative; include targets and limits.  Some examples follow.  Select “START HERE-EXEC4” and begin typing.

4.1    Example — Parts Cleaning

The current engineering requirements are as follows:  the system must clean 120-200 parts per minute, it must not take up more than 1x1x6 feet of space, must not jam the vibratory feeder bowls into which parts are expelled from the cleaner, and it must meet with approval by all current machine operators.

4.2    Example — Surgical Drill Attachment

Engineering constraints include a minimum axial holding force of 5 lbf, setup time less than 3 minutes, a maximum attach/detach force of 13 lbf, required attach/detach hand-grip strength less than 14.5 lbf, an outer diameter no more than 11/16 inch, and a shaft through-hole of diameter at least 3/16 inch; furthermore, all materials used must be autoclavable.  Some of the noteworthy engineering objectives include improved ease of operation by way of end-user survey, attach and detach times of less than 1.5 seconds, be intuitive enough that 100 percent of competent end-users can learn to use it without instructions, and withstand operating forces of the current model with deflections less than those of the current model.

5     Paragraph 5

The fifth and final paragraph of the PUD executive summary should conclude the summary with the main milestones of the first and second terms that are of interest to your customer.  They are ones related to your definition of success at the end of each term.  Indicate the approximate dates of those milestones (i.e., the end of each term); refer to the guidance on Paragraph 2 of the Project Overview for important information on how to “define” what success looks like.  Clearly, this is a short one!  Select “START HERE-EXEC5” and begin typing.


Google Docs is a trademark of Google LLC.

© 2017, William J. Endres Updated September 07, 2022

PUD Cover Page

1     General

Make no changes to the cover page with the exception of adding a logo (optional) as described below.  Likewise, you should make NO changes to the headers on all other pages of the provided template document.

2     Corrections Needed?

Now, please give the entire cover page a thorough and careful proofreading and email the SCD program director with any corrections needed.  They will be recorded to avoid the same errors for the rest of the project.

3     Logo

Referring to the bottom-left corner of the cover page, you may include a logo as you wish.  With permission from your customer only, you can use their logo.  If your customer (company, organization, or individual) is of the sort that does not have a logo, you can create one for your team if you wish, but by no means is this required nor will it score you points.

If no logo, click on the logo placeholder image to select it, then hit the delete key.  To insert a logo, right-click on the logo placeholder image and select Replace image ► [select appropriate source] from the popup menu.  Select the new image from its source location.  Then…

  • If the image is clipped on the top and bottom, skip to the next sub-bullet. If the image is clipped on the left and right, right-click on the new image and select Reset image from the popup menu.  Then, to reposition it at the bottom margin, with the image selected, click on “Fix position on page” and select Position options, which will show them to the right.  Then scroll through the “Quick layouts” settings to the “Bottom left” icon and select it.
  • If the image is clipped on the top and bottom, right-click on the new image and select Reset image from the popup menu. Then, to reposition it at the bottom margin, with the image selected click on “Fix position on page” and select Position options, which will show them to the right.  Then scroll through the “Quick layouts” settings to the “Bottom left” icon and select it.  You will likely need to then expand “Size and rotation” section, make sure lock aspect ratio is checked, and change the “Height” to 2.5 inches.
© 2017, William J. Endres Updated September 07, 2022

Problem Understanding Review (PUR) — Pre-meeting Briefing

This one sheet serves three purposes:

  • brief/quick preparation for your audience prior to the meeting (“pre-meeting briefing”);
  • a guide for the PUR meeting, for you and your audience members; and
  • a take-away for your audience.

1     Organization and Formatting

  • There are four (4) sections that progress according to the numbers in their respective headings.
  • Each section on the sheet has, below its heading, a text field with a prompt for a short sentence to provide context (replace that prompt with yours) followed by a bullet-list starter “Xxxxx”.
  • The top headings (left- and right-columns) are on the master layout named “PMB-TBLR”(top-to-bottom then left-to-right) and should not be moved. The other two headings may be moved up or down (hold the shift key down to maintain vertical alignment) to redistribute space as it better serves you.  Do NOT change the wording of any of the headings.
  • Remember, this covers highlights for the purpose of prepping your audience before the meeting and that you will use to lead the discussion at the start of the meeting.
    • It need not be jam packed; you are allowed/encouraged to have your IRD content pages at hand to reference for details as needed.
    • The content should be graphics-rich with minimal text. Aim for (minimum) 75% of the space consumed by graphics (with the exception of sections 3 and 4 which will likely, though not necessarily, be mainly text).
    • But do not try to include all of your graphics relevant to the respective section. Be thoughtfully selective; you can have your IRDs to reference as noted, and the graphics on the PMB must be large enough to see any important feature on the graphic.
    • Think of each of the four sections as a “slide” dominated by graphics with some bullet points to complement the graphics.
  • Regarding graphics:
    • Graphics include annotated CAD, illustrations, plots, and photos as well as tables. Yes, annotate plots as needed (often but not all of the time) to point out what is of particular interest.
    • Graphics used here are copied and pasted from your other docs.
    • Choose graphical elements of substance, not just to be present as a token non-textual element that is otherwise useless.
    • Be sure to have figure and table numbers so your audience can follow you as you talk them through it.
    • Did you see “annotated” above?!
  • Regarding text:
    • The bullet points serve three purposes:
      • guidance for your audience, leading them through the storyline and graphics both during the meeting and for quick pre-meeting preparation,
      • cues for you during the meeting, reminding you not what specifically to say (use your spoken words for that), but what generally to talk about, and
      • refreshers for your audience, reminding them afterwards what you talked about and jogging their memory about some of the details of what they heard you say (your spoken words).
    • These bullet points are short, to-the-point, not copied from your IRD since they are to be very limited and short compared to your more extensive, archival bullet points in the IRD. Each should be no more than a single short sentence or phrase.
  • Again… more graphics, less text!

2     Content Presentation

  • Leading into each bullet-point list should be one short, complete sentence providing context for the list/section.
  • There are four general areas of your work-product you are covering (in this order):
    1. Project Overview
    2. Background Research
    3. Next Steps
    4. Use Cases and Engineering requirements
  • The three green-text sections are the focus for the content on this sheet, as indicated by them being the larger regions on the template. Some additional guidance follows:
    • Section 1 is a bullet-point rendition of your project overview section of the PUD complemented by a meaningful graphic — remember, your audience knows little to nothing about this problem at this point. Being bullet-based, this is not the sentence/paragraph-based version from the PUD.  Also, do not hit on budget and overall success items from the PUD.
    • Section 2 (the bottom-left and continuing in the top-right) hits on your team’s background research; this section is the primary focus of the PUR. It should contain the most important highlights of your IRD findings across the entire team, brought together in a logical way.  If not dominated by annotated graphics that are legible, you have failed in your main purpose for the meeting.
    • Section 3, next steps, is the secondary focus of the PUR. Be sure to make note of what you don’t yet know and need to find out.  Also note what your weekly work-focus will be for the rest of this week (week-3) through week-6.
    • The Use Cases and Engineering Requirements section (Section 4) likely will have some content, though keep it light as there usually is not time to even get into it. Again, what are the focal points?  Background Research and Next Steps.

3     Examples of Great Work

Do a great job and be the first!

© 2017, William J. Endres Updated October 09, 2022

Individual Research Document (IRD)

1     Organization and Formatting

1.1    General

  • This is your sandbox, or canvas, for laying out information in a concise, logical manner.
  • Organize/group information into boxes, providing each box with an appropriate title.
  • Size and arrange boxes as you wish.
  • Use the styles provided, in particular, stick to Times New Roman 12-pt font for the majority of the written content.

1.2    Specifics

  • Include the following on a single B-Sheet; you (each team member) are allowed one sheet of content
    • Identification: Enter your initials in the “by” box at the upper right of the header (replacing the placeholder “FML”).
    • Date: Enter the date of latest update in the “on” box at the upper right of the header (replacing the placeholder “mm/dd/yy”).
  • References should be listed on the second B-Sheet. It is two-column for future use/expansion; it is not anticipated you will need the whole sheet or even a whole column.  IEEE format is to be used with numbering as [FML##] according to the following:
    • FML is your First, Middle and Last initials (e.g., William J. Endres is WJE)
    • ## is a two-digit sequential number (e.g., 01, 02, 03, …, 10, 11, …).
    • For example, my reference numbering would be [WJE01], [WJE02], [WJE03], …, [WJE10], [WJE11], …. You can continue with this reference numbering as each team member identifies new references throughout the course of the project.
    • Further information on references can be found in the Doc-Prep Guidance — Getting Started section, subsection 4, References.
  • All figures should have a caption and be numbered as FML.# (e.g., WJE.1, WJE.2, …, WJE.10, WJE.11).

2     Content Presentation

2.1    General

  • Depending on your team’s strategy and what areas of background research have been allocated to you, logically organize your findings into boxes having text and graphics.
  • Use graphics (photographs, illustrations, sketches, etc.) liberally (i.e., plentifully) for clarity. Clarity implies that graphics should be annotated to highlight specific visual information of interest.
  • Keep descriptions/notes concise, but also thorough, making liberal use of bullet point lists and short paragraphs (2-3 sentences) rather than long paragraphs.
  • Make use of at least ten unique references.

2.2    Specifics

  • When presenting your perspective (in the one pre-titled box) on the history and nature of the problem, be concise and focus on what led your customer to initiate this project, which should dig down into the root of the problem at hand, the pain or gain that is of interest to your customer.
  • When covering products/processes that accomplish similar but possibly different results, from the same or other industries, patents can be a huge source of information and should not be overlooked. Patents can provide design ideas to pursue, or design ideas not to pursue (as it would be infringing), and often both.
  • When covering the key scientific/engineering concepts and methods that may be relevant to the design work. Go beyond an understanding at a less technical level to consider how equations (mathematical models) and experimental testing/trials that you have learned (in classes or more likely through additional research) may apply.

3     Examples of Great Work

Do a great job and be Example #2!

Example

© 2017, William J. Endres Updated August 31, 2017

 

Doc-Prep Guidance — Getting Started

Heavily used in this course for documentation are Google Slides and Google Docs.  G-Slides is used not only for conventional presentation slides, but also here for documents comprised of larger format 11 × 17 inch (ANSI B) sized pages we call a “B-sheet.”

You will be provided with a team-specific template in one or the other (G-Slides or G-Docs) for each document, pre-meeting briefing, tech-memo, and cover letter you will have to produce.  While one could download any of those templates as a Microsoft (MS) PowerPoint or Word file to work with in that way, please do not do that.  First, that actually introduces far more failure modes in regard to producing the final deliverable PDFs needed; it may not make sense now, but having seen literally over 1,000 docs generated that way, it is a fact here.  Second, and more important to you and your benefit, working in G-Slides and G-Docs comes with outstanding collaborative capability, something students have craved for a number of years and you now can benefit from since we have transitioned in 2022 from MS Office to Google Apps.  That having been said, MS Excel is used extensively as a tool called DP Manager; perhaps someday time will permit converting it to G-Sheets.

1     Formatting

For MEEM 4901 and 4911, prior to receiving the editable version of your team’s team-specific templates your project title, customer name, team number, team members, etc. will be pre-filled for you in the appropriate and required places of the template.  There is no need to alter any information on the cover page or in the headers with the exception of optionally adding a logo on the cover page as indicated in those templates that have a cover page.

For G-Docs templates, any areas where you will be adding content make use of the standard paragraph styles in G-Docs — Title, Subtitle, Heading 2 (Heading 1 not used), Heading 3, Heading 4, and Normal text — already defined as desired including line spacing, indenting, and font types (Arial for headings, Times New Roman for non-heading text) and sizes.  Do not change anything about these styles!  And while not a matter of formatting, do not change the wording of the section headings; most section headings are tied to a grading rubric.

A bit more on font types… Times New Roman is a “serif” font.  That means it has little “thingies” called serifs at the ends of the letters.  In contrast, san serif fonts like Arial do not have those “thingies.”  Serif fonts are easier for the eye to follow in multi-line, textual format whereas san serif fonts are good for situations where resolution may be limited and/or for short text elements like headings and bullet points of a line or two.

Furthermore,

That was repeated (word for word) so you can see the difference between the two fonts; it adds up by line height, not just line length.  In any case, as noted, serif fonts like Times New Roman are easier for the eye to track across more than short phrases like section headings, titles, etc.

To summarize, just stick to the noted styles in G-Docs without changing them, and your formatting will be appropriate and as expected.

2     Graphics Annotations

A graphic (photo, illustration, CAD model, etc.) is generally much more effective if it is annotated to point the reader’s attention to certain aspects of the graphic to which you are referring in the referencing/accompanying text.  Annotations are not optional here, they are expected/required by us and will have a strong impact on your audiences well beyond your capstone design year.  By the way, Arial (sans serif fonts) is good for figure annotations, which take the form of one to a few words.

3     Executive Summaries

Every document of length greater than about four to five pages should be summarized in an executive summary.  In industry, the purpose of an executive summary is to brief the executive, manager, supervisor, etc., who may or may not read the entire document.  Those on your Project Continuation Review panel at the end of Term-I may or may not read the full document in detail and often rely on your executive summary for a thorough yet concise summary of the document.  Those on the SCD Advising Team will read your documents in their entirety!

As you may be deducing, the executive summary is one of the most important parts of a technical document.  It must stand alone and be concise while delivering enough detail to provide an accurate understanding of the status of your project.  Stand-alone means it must be understood without having to leaf through the document.  Do not refer to the body of the document (e.g., “This report contains objectives and constraints …”).  An executive summary is also not a diary.  It is not a discussion of “what you did.”  It is a summary of the content of the document.  Yes, the content mirrors what you did, but it is not to be described as what you did, rather what the content of the document is.  For instance, do not write “The team determined the design requirements and divided them into constraints (having limits to which the solution must adhere) and objectives (having desired targets).  They include…”  Rather, write “Engineering requirements include and constraints (having limits to which the solution must adhere) and objectives (having desired targets).  They include…”

This is offered as a basic example and is not actual content we seek to be in your executive summary.  You should assume in your executive summary and throughout your documentation that your audience knows generally what the design process is, what the design tools are, and why they are used.  You need not explain the “what”, “why” and “how” of the design process steps and tools.

Online doc-prep guidance will provide specifics for each document indicating an expected length and guidance on what content is expected.  Guidance will begin with high specificity at the Problem Understanding Document (PUD) stage and taper off in specificity over the course of the project; you are expected to be learning with time and experience to gauge what content to cover in the later stages (and beyond capstone design into your career).

Throughout all your documentation and other communication, you must realize that members of your audience outside the Capstone Design Program do not know what the various acronyms mean, such as PUD, TAD, and PPD.  It is okay to use the acronyms, but only after introducing/defining each; for instance, “In the attached Technical Archive Document (TAD)…” and then later you can write it as “The TAD illustrates that…”  Though, introducing an acronym early on and then not using it until much later in the document is not very effective either.

4     References

Rather than numbering references sequentially relative to their order of appearance in the document, number them sequentially relative to when they are added into document; this is to avoid the non-value-added busy work of renumbering existing references when new references are added at a later date.  Use the FML prefix as described in the doc-prep guidance for the Individual Research Document (IRD) assignment.  References that are brought in by more than one member of the team should use the prefix TEAM, i.e., [TEAM##].  This is not a contest!  The entirety of this approach, while being contradictory to the norm/standard-practice of (non-prefixed) sequential numbering by order of appearance, is used here to minimize the risk of errors in reference numbering by significantly reducing the burden of reference number management.  We break with convention for good reason — to reduce the nonvalue-added burden on you so you can be more efficient in your work with less bookkeeping and error proofing.

Formatting of the reference list is governed by the IEEE Citation style document; this is a great, simple, efficient PDF document that gives many good examples (i.e., it teaches largely by example).

Your reference list will be presented on one or more two-column page(s) in your Technical Archive Document (TAD), which is in the aforementioned B-sized (11 × 17 inch) format.  Your team’s initial references list will be compiled by merging references from all team members’ Individual Research Document (IRD) assignment, which is also in the B-sized format and includes a references page for each individual to accumulate their references.  Your references list in the TAD will be created at the Problem Understanding Document/Review stage, and expanded from there throughout the course of the project.  The references section of the TAD is after the final section of the body and before the Appendices; it is all set up for you in the TAD template you will receive soon.

Doc-prep guidance will be provided throughout, as needed, to help you manage your reference list over the course of the project, correctly and efficiently.

5     Appendices

The number of appendices in your Technical Archive Document (TAD) depends on the needs of the audience.  A number of appendices are mandatory and already set up in the TAD template.  You may add appendices beyond those if you feel it is warranted; this is rare, but an option if it makes sense.  Specifically, Appendices A through E are reserved so you can start with F if needed.

Regarding content, remember that an appendix is for information not required to understand the content of the main body of the document.  Appendices are for supplemental information that may be useful for the reader desiring more detail.  So, if it is a piece of information or graphic you think is important but not necessary to read or view in the main body of the document (in a textual portion or a B-sized “summary” page), then put it in the appendix and simply reference it in the main body of the document (e.g., “Additional background information on material properties of options considered is presented in Appendix XX”).

Do not just do a data-dump in the appendices.  No one needs to see every piece of MATLAB code, for example.  Additionally, each appendix must be clearly labeled at the top of the pages; this is already done for you in Appendices A through E in the TAD template to be provided.

 

6     The Storyline — Saving the Most Important for Last!

It is important to see the entirety of your reporting as telling a story.  Not that your writing is story-like (with the exception of the narratives related to current situation and future vision, which are told in a story-like fashion).  The “storyline” is a flow of information throughout the documentation; it represents your line of thought as you work through the work you are presenting — your work-product.  Remember, the reader is generally someone who is not as close to the project as you are.  You will be living and breathing this work on a daily basis.  Your reader is living and breathing other things.  He/she is busy too.  Making the reader’s life easier is always good for your cause.  And remember also, most of your readers will be viewing this in a future where you are not available to answer their questions or to provide clarifications.  This is important in any forms of your documentation and reporting, in particular the TAD as described below.

One key element of maintaining the storyline is the presence of “inputs” and “outputs” text boxes on many of the TAD pages.  The Page Input helps the reader center their mind on the new topic at hand (for that page) and reminds him/her of the information that flowed into the work that generated the information on that page.  This is important even if it flows from the immediately previous page; often this is not the case, though, as the design process is not purely serial.  It is easy for someone to lose the storyline without some help from the author — you.

The Page Output provides information to “wrap-up” the work presented on that page.  It can be conclusions, decisions (which are different than conclusions), or simply “where next.”  Where next is generally always an element of a page output textbox.  It indicates where this information is next used and for what and/or how it will be used.  In a sense, it is the start of a virtual bridge that leads to the input textbox somewhere else in the document.

Hopefully you can see the logic in the following requirement: the Page Input textbox should be at the top left of the page and the Page Output textbox should be at the bottom right of the page (if at all possible; move elsewhere, if necessary, still preferably at the bottom somewhere).  How you lay out the other information on a B-sized page is up to you.  The examples provided in the templates are simply examples.  Depending on the relative sizes of tables, illustrations, etc., rearranging your content relative to the examples may be needed.  One exception is the requirement noted in regard to the Page Input and Page Output textboxes.


Google Docs, Google Slides, and Google Sheets are trademarks of Google LLC.
Microsoft and Excel are trademarks or registered trademarks of Microsoft Corporation.
MATLAB
is a registered trademark of The MathWorks, Inc.

© 2017, William J. Endres Updated August 28, 2022

 

B-Sheet Organization and Formatting — General

1     Organization and Formatting

1.1    General

  • This is your sandbox, or canvas, for laying out information in a concise, logical manner.
  • Organize/group information into boxes, providing each box with an appropriate title; the pre-titled boxes are required at a minimum.
  • Size and arrange boxes as needed/desired to best organize and fit all needed information in each box and on the sheet as a whole.
  • Use the styles provided, in particular, stick to Times New Roman 12-pt font for the majority of the written content.
  • Enter the initials in the “by” box at the upper right of the header (replacing the placeholder “FML”) of the one, or sometimes two (enter as, for example, NBB/WJE) team members who are responsible for the sheet. The text will resize to fit.
  • Enter the date of latest update in the “on” box at the upper right of the header (replacing the placeholder “mm/dd/yy”).
© 2017, William J. Endres Updated January 15, 2017