Week 9 - Project Review and Engineering Requirements

Activities for Lecture 9

  • Discussion of final rules for the design competition
  • Discuss requirements for project plans and proposals
  • Presentation by Dr. Steingrimmson

Reading

Read Chapter 4 in the textbook by Mattson and Sorenson. Focus on these key aspects of Opportunity Development

  • Project Objective statement
  • Requirements matrix

The following sections from part 2 of the textbook describe tools for connecting market requirements to performance measures

  • Project Objective Statement, pp. 272-273, 4th ed.
  • Quality function deployment, pp. 276-277, 4th ed.
  • Requirements matrix, pp. 284-287, 4th ed.

Some notes on terminology

When talking about attributes of a product or service that make it desirable to the market, the following terms are (more or less) equivalent

  • Customer needs
  • Customer requirements
  • Market requirements

Mattson and Sorenson use "Market requirements"

When talking about the (mostly) measurable engineering metrics used in design decisions, the following terms are equivalent

  • Metrics, or performance metrics
  • Engineering requirements
  • Performance measures

Mattson and Sorenson use "Performance measures"

Rules for Design Competition

Version 1.00 of rules for the design competition are posted. The following issues were modified

  • Specification for location of the starting line
  • Judge's inspection of starting position
  • Point schemes for final position of minifigure
  • Point scheme for debris on the table at end of run
  • Disqualification for use of force or torque by humans

Feedback on Bid Proposals for ME 492-493

Some recurring misunderstandings appeared in the bid proposals for ME 492-493 projects. Please make sure you understand the following.

Project Objective Statement

The project objective statement is a single sentence that describes the scope, schedule and resources needed for your project. Refer to part 2 of the textbook. The resources needed are primarily the budget you are given, but also may include crucial in-kind resources like access to specialized manufacturing tools or sponsor labs or specialized artifacts given to the team.

The team should write your Project Objective Statement with care and precision, and revisit the Project Objective Statement throughout the evolution of your design project. By the third week of the Winter term (ME 492), the POS should be fixed. Throughout the project, team members should ask whether their efforts are consistent with achieving the goals specified in the POS.

Study the examples in Part 2 of the textbook (pp. 272-273 in the 4th edition).

Market requirements

Developing accurate market requirements is an essential step in doing design. The process will require you to consider the market from several perspectives: the end user, retailers, the buyer, the manufacturing partner, regulatory rules and agencies, and more. Different design projects have different constellations of individual and groups that constitute the market.

  • Should not be a copy of the client needs statement in the project description
  • Should be a list of many specific needs
  • Should be grouped into primary and secondary requirements.

Refer to the Requirements Hierarchy section in Part 2 of the textbook for a discussion of primary and secondary (or "original" requirements). (pp. 282-283 in the 4th edition.) Primary market requirements appear in the system-level requirements matrix.

Prototypes

Avoid thinking about the prototype. Prototypes are useful at many stages in the design process.

  • Create as many prototypes as necessary, within budget.
  • Low-fidelity prototypes (cardboard, tape, foam core) allow quick exploration of ideas
  • Subsystem prototypes (laser cut, 3D printed) allow performance testing for feasibility and subsystem optimization.
  • Final system-level prototype(s) demonstrate whether and how the system meets customer requirements. And, there may be more than one system-level prototype.

Design Challenges

The Design Challenge(s) are the hard parts of the design. Don't just list all (or even most) of the client/market requirements as challenges.

One purpose of explicitly listing the design challenges in the proposal is to show (to GWR and possibly the sponsor) that you clearly understand the design problem by being able to correctly identify the hard and easy parts. This will give your client confidence if they understand the problem well enough themselves. By pointing out the hard parts of the design problem to the client, you may help them understand the problem better and they may want to adjust their requirements.

Whether the sponsor has a clear idea of the hard and easy parts of the project, you should consult with the sponsor to share and calibrate your mutual understanding.

Another purpose of identifying the design challenges is that you should use your understanding of the hard and easy parts to guide your project planning. Oce you begin working on the project (as opposed to writing about it in a proposal), you should focus your efforts on solving the hard parts first.

Milestones and deliverables

In setting up a project plan, you need to identify the milestones and deliverables. Refer to the class notes on project planning for additional explanations.

  • Milestones are key events (deadlines, presentations, decisions) that have dates and will show up on Gantt chart
  • Deliverables are specific, tangible outcomes (reports, test data, prototypes) that are significant to the client

Not every date is a milestone. For example, weekly team meetings are not milestones. Likewise, not every artifact produced by the team is a deliverable. For example, a low fidelity prototype may be taken to an early meeting to show your client, but it (probably) shouldn't be considered a deliverable.

Requirements-matrix

In week 8 we discussed performance measures, a.k.a. engineering requirements.

The following terms are equivalent

  • performance measures (Mattson and Sorensen)
  • engineering specifications
  • engineering requirements

A more detailed discussion of the requirements matrix is on a separate web page in the notes section of this web site.


Document updated 2017-11-24.