View Single Post
  #36   Spotlight this post!  
Unread 01-03-2010, 17:13
Dmentor's Avatar
Dmentor Dmentor is offline
Registered User
AKA: Daniel Bray
FRC #1895 (Lambda Corps)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2007
Location: Manassas, VA
Posts: 85
Dmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant futureDmentor has a brilliant future
Re: legality of bolt and screw heads breaking plane of chassis meeting bumpers

Quote:
Originally Posted by Chris is me View Post
Yeah, in the real engineering world, complaining that your boss or client gave you a requirement isn't a good idea, but I'd rather not jade my teammates into the philosophy that there's no use expressing an opinion on anything. Just yet.
Segue to the real world for a moment… I agree that simply complaining is not a constructive approach for resolving issues (requirements or otherwise) but communications is absolutely essential in engineering. My experience has been that in complex projects there is almost always a two-way communications channel between the engineer and the customer. Requirements are an abstraction of what a customer wants (by the way this leads to the distinction between system verification and validation). Said another way, requirements are a powerful communication device but they don’t always perfectly reflect the customer’s desires. Many times the customer’s need can’t even be fully articulated. That is where direct dialog with a customer is crucial to ensure that we aren’t spending disproportionate time and material resources on meeting requirements that don’t really represent the customer’s need in the first place. As an engineer, when I don’t understand the rationale behind a particular requirement that really means that I don’t fully appreciate the customer’s problem and means I better spend more time communicating. So please don’t think that in engineering requirements always come down from high engraved in stone.

I think the frustration that we see in many of these requirements "debates” is that we have a limited communication channel for understanding the rationale behind non-obvious requirements. As practicing engineers, we are trained to think critically about requirements, figure out how to make improvements, and then communicate this back to the customer. Friction results when we can’t “close the loop” between our thought processes and our customer’s. In FIRST, the GDC obviously has the authority to define the requirements any way they like. I would like to think that they aren’t intentionally trying to irritate their engineering mentor base with arbitrary rules, but the question remains how can we bridge the gap in our understanding without an appropriate communication channel? Since we haven’t been able to carry on an effective dialog with the GDC, we instead turn to our peers on Chief Delphi in hopes that maybe they can set us straight.
__________________
Dan was here.


2014 VA Semi-Finalist (2363, 1533), Johnson & Johnson Gracious Professionalism Award
2013 Johnson & Johnson Gracious Professionalism Award, Woodie Flowers Finalist - James Gillespie
2012 Chesapeake Finalist (358, 714), Johnson & Johnson Gracious Professionalism Award
2011 VA Semi-Finalist (122, 1111), Johnson & Johnson Gracious Professionalism Award
2010 DC Semi-Finalist (2912, 449), Dean's List Finalist - Chris Dorick, Xerox Creativity Award
2009 VA Semi-Finalist (612, 1908)
2009 DC Semi-Finalist (1712, 176), Imagery Award
2007 CMP Newton Semi-Finalist (68, 111)
2007 VA Rookie All-Star Award, Regional Semi-Finalist (343, 612), Highest Rookie Seed Award (#2), Website Award