https://innovationportal.
org
This entry is most likely to receive a score of 5 based on the EDPPSR. Two of three
engineering educators who
scored this portfolio assigned a score of 5 for this entry. The third would have
liked to see evidence of validation by
others besides sales people and mechanics (e.g., drivers, employers, and/or factory
workers). Although the range
of stakeholders considered may not represent “many if not all primary stakeholder
groups,” in most other respects
the entry fits the description of a 5 more so than that of a 4.
The design requirements listed and prioritized are ones that can lead to multiple
viable solutions. It is worth
noting that one rater expressed concern about the “wordiness” of the entry and
noted that the entry would still
have received a score of 5 if information were presented in tabular form—a good
option for students to consider
when preparing their own portfolio entry for Element C.
The design requirements were regarded by all as consistently clear and detailed,
and as presented in a nearly
always objective and measurable way. The one instance of subjectivity explicitly
identified by one rater involved
design requirement 5 (“The solution concept will not overwhelmingly resemble
concepts of existing designs or
solutions for similar problems”), which the designers had explained by noting,
“Although this is not a disqualifying
specification, this spec is highly important because it is the opinion of the team
that in order to optimize the
engineering learning experience, the solution concepts should be original.” This
one exception to the otherwise
consistent objectivity with which design requirements are presented would not be
enough to drop the score from
a 5 to a 4. Instead, this entry provides a useful illustration of the scoring
guideline to select the descriptor (and
score) with “overall best fit.”
Engineering Design Process Portfolio Scoring Rubric
Component and Element Titles
Component I: Presenting and Justifying a Problem and Solution Requirements
Element A: Presentation and justification of the problem
Element B. Documentation and analysis of prior solution attempts
Element C. Presentation and justification of solution design requirements
Component II: Generating and Defending an Original Solution
Element D: Design concept generation, analysis, and selection
Element E: Application of STEM principles and practices
Element F: Consideration of design viability
Component III: Constructing and Testing a Prototype
Element G: Construction of a testable prototype
Element H: Prototype testing and data collection plan
Element I: Testing, data collection and analysis
Component IV: Evaluation, Reflection, and Recommendations
Element J: Documentation of external evaluation
Element K: Reflection on the design project
Element L: Presentation of designer’s recommendations
Component V: Documenting and Presenting the Project
Element M: Presentation of the project portfolio
Element N: Writing like an Engineer
Please Note: Elements M and N require no submission from the portfolio author(s)
and are intended to be scored based on the portfolio work as a
whole from what has been submitted from Elements A through L
https://innovationportal.org
Element C - Presentation and justification of solution design requirements
5 Design requirements are listed and prioritized, and they are consistently clear
and detailed;
these design requirements presented are consistently objective, measurable, and
they would be
highly likely to lead to a tangible and viable solution to the problem identified;
there is evidence
that requirements represent the needs of, and have been validated by, many if not
all primary
stakeholder groups.
4 Design requirements are listed and prioritized, and they are generally clear and
detailed; these
design requirements presented are nearly always objective and measurable, and they
would be
likely to lead to a tangible and viable solution to the problem identified; there
is evidence that
requirements represent the needs of, and have been validated by, several primary
stakeholder
groups.
3 Design requirements are listed and prioritized, and they are generally clear and
somewhat
detailed; these design requirements presented are generally objective and
measurable, and they
have the potential to lead to a tangible and viable solution to the problem
identified; there is
evidence that requirements represent the needs of, and have been validated by, at
least a few
primary stakeholder groups.
2 Design requirements are listed and prioritized, but some/all of these may be
incomplete
and/or lack specificity; these design requirements may be only sometimes objective
and/or
measurable, and it is not clear that they will lead to a tangible and viable
solution to the problem
identified; there is evidence that the requirements represent the needs, of/and or
have been
validated by, only one primary stakeholder group.
1 An attempt is made to list, format, and prioritize requirements, but these may be
partial
and/or overly general, making them insufficiently measurable to support a viable
solution to the
problem identified; there is no evidence that the requirements represent the needs
of, or have
been validated by, any primary stakeholder groups.
0 Design requirements are either not presented or are too vague to be used to
outline the
measurable attributes of a possible design solution to the problem identified.