Category Archives: PUD

Problem Understanding Document

PPD Section 3 — Task Descriptions

1     Organization and Formatting

1.1    General (same as for other B-Sheets; follow this link for easy reference)

1.2    Sheet-Specific — Making it All Fit

This one should be straightforward — two boxes to fit tasks for Term-I and Term-II.

2     Content Presentation

  • There is no specific Page Input textbox/content to be addressed for this page.
  • In the pre-titled Task Descriptions textboxes, present the main tasks for the respective term.
    • At the Problem Understanding Document (PUD) stage, no tasks should be included.
    • At the Concept Selection Review (CSR) stage, all Term-I tasks from the CSR week to the end of Term-I must be identified and documented here (in the Term-I textbox). These should be fleshed-out (i.e., full detail) focused on the remainder of Term-I, nothing prior to the CSR week.
    • At the Project Continuation Review (PCR) stage, all Term-II tasks must be identified and documented here (in the Term-II box). These should be fleshed-out (i.e., full detail) focused on the remainder of the project (Term-II).  Un-started Term-I tasks should be moved here and uncompleted Term-I tasks should be copied here (by name with referral to the Term-I listing for their descriptions) for their continuation to completion.
  • Present the main tasks by name (create a short descriptive name) and with a short description as follows:
    • The description should expand on the task name by adding more info than the name itself; do not just add fluff words if the name is fully self-descriptive.
    • However, in most cases, it is helpful in the description to state the actual work to be done, software to be used, tools to be used, and/or facilitates to be used (not consider that list exhaustive). You should be giving a description of what you will be doing, how you will be doing it, and with what.  A maximum of 3 – 4 short sentences for each task should suffice.
  • There is no specific Page Output textbox/content to be addressed for this page. However, this content is used elsewhere.  It represents, along with milestones, the input information to the Gantt charts for Term-I and Term-II.
© 2017, William J. Endres Updated September 09, 2022

PPD Section 2 — Design-Project Failure Modes and Effects Analysis

1     Organization and Formatting

1.1    General (same as for other B-Sheets; follow this link for easy reference)

1.2    Sheet-Specific — Making it All Fit

The DPFMEA table should be legible at the scaling required to make it fit across the width of the sheet.  That is generally not a problem.  You can split it vertically (an upper and lower portion, though each with headings) across two pages if needed.

Correct-Content Reminder:  The DPFMEA is not related to what you are designing; that will come later and is called your DFMEA (no “P” after the leading “D”).  Your DPFMEA is for your Design Project itself, identifying potential failure modes of the project.

2     Content Presentation

  • There is no specific Page Input textbox/content to be addressed for this page.
  • In the open space on the sheet, insert a graphical rendering of your DPFMEA table (or portion thereof if spread across two sheets) showing RPNs and all information that leads to their calculation. It should be sorted from highest RPN to lowest RPN.
  • In the pre-titled Recommended Actions box, present the ways in which the higher RPNs will be reduced (i.e., actions to be taken, meaning countermeasures to be put in place).
    • In the template is an example of putting a three side-by-side textboxes within the larger Recommended Actions
    • You need not adhere to that format, but it may be useful given the aspect ratio of a typical DPFMEA table being short-by-wide.
    • If you work your recommended actions into the DPFMEA table, that is fine as an alternative; delete the Recommended Actions group at the bottom, or use it to expand on what is in the table as that is often brief to the point that someone not immediately associated with the work would not be able to make sense of.
  • There is no specific Page Output textbox/content to be addressed for this page.

3     Examples of Great Work

Do a great job and be the first!


Project is a trademark of Microsoft Corporation.

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

PUD Cover Letter

Do NOT edit any of it, with the following exceptions:

  1. 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 “nickname” he has shared)
      – 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 “nickname” she has shared)
      – 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. Replace the placeholder “Dddd” with the weekday name (e.g., Monday, Tuesday, …) corresponding to the day of the week that you send it; i.e., if you send it on a Tuesday, then Dddd would be replaced with the word Tuesday.
  3. If the name at the upper left (as part of the contact information) is incorrect, please change it and let the SCD program director know your technical contact has changed (and to whom).

Again, do not edit the body other than the day, as noted.  It has specific messaging intended for your customer to help him/her understand the progression of your work.  It also is intended for your eyes for the same purpose; as such, you should each read this letter to reinforce in your mind where you are headed in the coming weeks.  Finally, it also serves as an example; as your project progresses you will need to write more and more of the release cover letters on your own.

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

PUD References

Your full references list is built up and maintained in the TAD.  If you cite any references in this document, copy the citation 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.

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

PUD Section 5 (or 4) — Engineering Requirements

As indicated in the template, this section should begin with the following sentence:  “The engineering constraints and objectives are shown in Tables 1 and 2, respectively.  Further details, such as reasoning for their inclusion and related information sources, can be found in Subsection 1.2 of the accompanying Technical Archive Document.”  It should be adjusted only in those rare (but occasional) projects where there may be more than one line of design or independent subsystem of design, each line having its own set of constraints and its own set of objectives.  One example would be a static version of a test fixture that must be designed, and a non-friction roller-type version of a similar test fixture that must be designed.  Another example, one for three lines of design, might be one line of design being an auxiliary power supply, which drives the second line of design, a lifting system, with a third line of design being a test system for the other two.  Again, these cases where there are multiple lines of design requiring separate sets of constraints and objectives are not the norm; don’t go this direction without advice of your primary advisor and/or consulting with the SCD program director.  But, if you think it might make sense, then ask!

In these cases, for instance for two lines of design, change the “and Table 2.” to “through Table 4, covering the constraints and objectives associated with the two lines of design that make up this project.”

The template provides some placeholder examples of tables with their table captions above them.  Replace the example graphics with your tables.  For second and third lines of design, put a page break between so the pair of tables for each line of design are alone on their own page.  Since the table captions indicate what they are (i.e., engineering constraints and engineering objectives), there is no need to have those titles in the table images you copy from DP Manager (i.e., use the “Copy Table Only” button in DP Manager).

Do not add explanatory text here.  More explanation is available in the various textboxes on the TAD sheet; your reader can refer to that for those details.

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

PUD Section 4 — Initial Ideas

Initial ideas of interest here are only those that have survived the problem understanding activity.  If, by the time you reach this point in understanding the problem, any ideas that surfaced along the way and were jotted down are no longer relevant… we don’t want to hear about them here.

This section is OPTIONAL.  So, if you don’t have any initial ideas for a solution, then delete this section by selecting the section heading down to but not including the page break before the next section (“Engineering Requirements”).  Google Docs will automatically change the “Engineering Requirements” section number from 5 to 4.

If you do have some initial ideas you would like to put forth for some initial feedback, as indicated in the template, this section should begin with the following sentences:

“While developing our understanding of the problem, some initial ideas for a solution began to surface.  They are offered here in brevity, seeking (a) early-stage validation that we are understanding the needs and wants, and/or (b) correction on how and where we are off track.”

You will have space for up to two (2) at a size large enough to be meaningful.  For each idea, provide a brief verbal description and a neat, annotated sketch.  Note the emphasis on the word “brief.”  The textual portion of this section must not exceed ¼ page; this section should be no more than one (1) page with graphics — graphics are GENERALLY helpful in engineering when annotated; neat hand-drawn sketches are fine here.


Google Docs is a trademark of Google LLC.

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

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