Ken did a great job of explaining the basics of the engineering process. I would have said the same things but didn't have time at that moment. But I think he missed a key point, budgets. He probably left it out in the interest of brevity.
When we are ready to move from the What stage to the How stage we set budgets for weight and sometimes cost before we get to the design. We also set aside "overhead weight" for those minor
items like the RC, battery, and light. The budget reflects somewhat the relative importance of the subsystem in our game strategy.
Last year's budget was something like this:
Overhead 30lbs
Frame 20 lbs (includes sidewalls)
Drive 20 lbs
Wedges (small arms to grip ramp) 30lbs (includes most pnuematics and compressor)
Arm and gripper 25 lbs
Notice: we have only budgeted 125 lbs in this example. Systems NEVER come in under budget so allow for "growth". Actually we usually budget to 115 lbs, but in this example I stayed closer to actual weights.
We also start our subsytem designs from the interface to the next system. (Remember "He who designs the interface first wins!") So if we have a lifting arm joined to the frame, the first thing is to define how the arm interfaces and "fix" that. The frame and arm are then designed around the interface. The frame doesn't care much what the gripper end of the arm looks like. This way the frame builders can get busy and build the robot while the arm guys flail around trying to get their gripper to work. This way, even if the arm guys fail entirely we can still drive.
Budgeting also provides something of a reality check. If you can't figure out a design that stays within budget then maybe you shouldn't be doing that function.
Finally we have a System Engineering function that ensures that ALL the interface requirements are defined and communicated to the relevant groups. (System Engineer: "No, we can't add that limit switch, it's not on the list and besides we have to ship tomorrow"). The Systems Engineers also track weight and cost to ensure that each system stays within budget, both cost and weight. They also monitor progress. If a subsystem isn't done a week before ship we will either funnel a massive effort towards finishing it or scrap it.
We usually have a mentor and a student who are dedicated to this vital function. They have other jobs in the team and participate in building the robot, but their PRIMARY responsibility is making sure we finish on time and within budget.
It's not necessarily fun, but it is important. Properly executed, a Systems Engineering approach enables many more people to participate in the design process while still staying co-ordinated. It lowers the individual work load, so that people have more time to think about what they are doing and do it right the first time. It is also how most major systems (ie aircraft, satellites, etc) are designed today. Such systems are far too complex for a single person to comprehend in detail, let alone design.