Fourth-year design project consultantships

The fourth-year design project is a capstone project that is meant to be the opportunity for you to apply the engineering principles, mathematics, judgement and design to an actual real-world problem, giving you a year to design a solution and implement a prototype of that solution.

In computer engineering, and even electrical engineer, there is always a temptation for a group to design an "app". Such "apps" are the easiest way to propose problems that are not actually engineering problems.

Your project should be an engineering problem, and and designing an engineering solution to a problem is one that requires application of the the practice of profession engineering. You may recall the definition of the practice of professional engineering from your undergraduate courses in first year, the relevant details being:

The practice of professional engineering is any act of...designing..that requires the application of engineering principles (engineering science, engineering mathematics, engineering judgement and engineering design)...that concerns the safeguarding of life, health, property, economic interests, the public welfare or the environment.

As yourself if the problem at hand requires a solution such that if poor decisions are made during the design process, there may be an identifiable and realistic and measurable harm to one of these six factors.

As an example, in creating a tool that helps a group of people create an itinerary for a holiday based on some inputs, what real harm may occur to the individuals if you deliver a sub-optimal itinerary? Might they pay $50 too much for a hotel?

Questions you should ask yourself:

• Does my description contain any poorly defined words that cannot be measured? For example, how do you measure "building memories"? How do you describe
• How can you measure each of the goals in your project proposal?
• What in this project requires a uWaterloo engineering student to create a solution where, for example, a graduate from a community college in a related engineering technical program would not have the required skills?
• If the solution is an "app", what in this project requires anything more than what an intelligent and skilled programmer could write?
• How is the solution going to be measured quantitatively? That is, what metrics can be used to evaluate whether or not your solution satisfies the engineering problem at hand? What are your intended target numbers? If the requirements are simply "Has this feature been implemented?" then that feature is not have an engineering purpose. Each requirement or specification should be related to a metric.
• How is each specification to be evaluated quantitatively? For example, if the specification is "Design and build Abstract Syntax Tree" then "Look at AST Library/Grammar and demo some examples" is unacceptable. "Looking" is not a metric.

Here are a few comments on specifications and procedures for testing specifications:

• Do not include trivial specifications: If the purpose is to have a running program, "Ability to run Bock Program and see output" is not a specification. It is an absolute, and therefore trivial, requirement for the project.
• Do not include specifications that are Boolean: "Machine is padded to avoid damage to circuits" with the procedure being "Machine will be fitted with a custom shell to protect internal circuitry." The way such a specification should be tested is "The device will be dropped from a height of 30 cm without sustaining damage." It would be reasonable for this to be the last test, just in case this test fails. If you do not want such a test, do not put such specification in your document.
• Do not include specifications that are simply the property of a purchased component. Instead, include a specification that describes how the component is being used and that can be measured. For example, "The camera is able to take photos at a rate of 1.4 photos per second." If the purpose is to achieve some goal (for example, tracking and isolating objects in view), then the procedure for evaluating this should be some testable means of tracking a number of objects moving a specified speeds. Another example: "Camera can take photos at 3280 x 2464 pixels." Instead, this should be described in terms of "The system is able to identify an object at ten meters (10 m)."
• Do not include specifications that cannot be tested during the demonstration. If your devise should move at 20 cm/s, then a reasonable test is to see the device move one meter in under five seconds: have a measuring tape ready.
• Do not have specifications that do not relate to outcomes: "The device can move autonomously in two modes: roaming mode and capturing mode." Instead, the specification should be "The device starts in roaming mode where it will examine one square meter per second." This can be tested by having nine square meters and having an object placed in any location and have it found in less than nine seconds. The next specification is "Once an object is detected, the device engages in obtaining the object within two seconds." This, again, can be tested.
• Do not have procedures for testing a specification that are simply conformation. For example, if the specification is "The device is capable of recognizing obstacles and avoiding them." then the procedure "The device is equipped with two ultrasonic sensors to detect incoming obstacles. When an obstacle is detected, the device will move in the opposite direction, and turn away from the obstacle," is not a valid procedure for measuring specification: it is a statement. A procedure would be "Observe how the device moves in a given environment, and then place an object in that environment and ensure that the obstacle is avoided while still achieving the same objectives."
• If the specification is "The device can operator at least four hours, and up to eight hours." then first, the upper bound is useless, unless it is indented that the device never operators beyond eight hours. As for the procedure for testing the lower bound, produce a video of the device working for four hours on, for example, YouTube, and we can observe the device operate for four hours. It is not a valid procedure to test this simply by having the statement "The specifications of the power bank were detailed prior to our selection."; this is not a procedure.
• None of your specifications should have qualitative measures: you should not be "reducing stress," for unless you have a way of measuring stress, you cannot determine if this has been satisfied. You also cannot measure "creating memories". You cannot make a task "easier" unless you can explicitly measure difficulty.

If you come up to me with a proposal that relates to any of the following topics or ideas, please be ready to see significantly push back:

• Refrigerators, expiry dates, recipes, etc.
• Any recommendations on exercise based on taking a video of yourself performing that exercise.
• Any collaboration tool with respect to itineraries.
• Anything that is fundamentally check-box related: for example, suggesting meals based on available food subject to various dietary restrictions.
• Anything I can do with a regular expression search on a sufficiently large file.
• Anything AI related that essentially has you doing nothing more than finding appropriate training sets.