Tips for Writing the Design Proposal
1. If you are continuing a project that was started in a previous semester,
Use any and all documentation(written or visual) prepared by the previous teams (e.g.,
proposal, code, block diagrams, final report, info on their website) to help you write your
Proposal.
There’s no need to “reinvent the wheel.” If the documentation at your disposal is clear,
accurate, and useful, by all means use it. This isn’t considered plagiarism—this is how the
real world operates. Don’t do more work than necessary.
In the Introduction (the paragraph before the Objectives section) of your Proposal, you will
state that you are continuing project X (what is project X?);
summarize what the previous group accomplished (a, b, and c were built; d and e
were integrated, and so forth);
summarize what was not completed by the previous group;
explain your goals for continuing the project.
The focus of your Proposal is what you are designing, adding, modifying, to the existing device or
system.
2. The first sentence of the Executive Summary, the Introduction, and the
Objectives sections should NOT be “This project is a device that…” Instead, try
The KittyKibbler is an automated, web-based system that allows cat owners to remotely
control and track the amount of dry food dispensed during a 24 hour period. The system is
comprised of a microprocessor, sensors, etc. The food dispenser is a plastic cylinder
attached to a base that reads information from the PC…
The goal is to name the device then describe what it is, how it works, and what components
it contains.
3. Follow the “Formula” for writing Executive Summaries.
Explain/define the project (what are you doing?)—don’t reinvent the wheel; use the
verbiage from the Introduction and Objective sections.
Identify the need (why is this device/system needed? who is the customer?).
State the cost of the device/system.
State the expected outcome of the project: prototype, ready-to-market product, subset of a larger
product/project
4. In the Demonstration section, describe what the audience will see you do on
the day you demo.
The description of the demo should include
o where and when it will take place (e.g., Van Leer, Women’s Shelter; the last
week of April),
o who will do what (e.g., one member of the team will activate the food dispenser
so that several cups of dry kibble are in the food bowl; another member will
show the web-based interface),
o how we will know if the technical specifications have been met (e.g., food will
dispense into a bowl)
5. Whenever you can SHOW rather than TELL, do so.
Block diagrams
Wiring diagrams
GUI screens
Flow charts
Photos
Tables
6. Use bullets and enumerated lists to “show” information. If you don’t have to
write a paragraph, don’t.
7. Proofread carefully. Print, read, and use the “Errors to Avoid Every Time
You Write” as a checklist. (This was sent as an email a few weeks ago as you worked on the Technical
Review paper.)
Comma misuse and abuse, misusing “that” and “which,” typos, misspellings, and all
other egregious errors are unprofessional and unacceptable. Learn and apply the rules.
8. Follow IEEE citation formatting guidelines. A handout with all of the
possible source types and examples of proper formatting is on the UPCP 4007
page and on the 4007 course website (under Proposal deliverables).
9. Avoid personal pronouns. No “I,” “we,” “our,” or “you.” Use 3rd person
instead--“The user” or “The designers”