I would proceed in this order:
Negative Test Cases
Happy Path: These are based on the functional requirements as described by the requirements doc or the person requesting the feature. This is the most basic ruleset that must govern the system. If this set of rules doesn't work, either the developer or tester did not fully understand the design constraints.
Negative Test Cases: These are also based on the functional requirements. They may not be explicitly expressed. They can be found by asking the PM, "What happens if...". Such scenarios in this instance can include what happens when the window is up and the Up button is pushed. The general rule here is that the system should respond gracefully. Popping a fuse or breaking a window would be a fail.
Edge Cases: This is where Exploratory Testing shines. Exploratory testing is the simultaneous discovery of the behaviour of the system, creation of the test suite, and understanding the system under test. What sort of things can go wrong that aren't listed in the requirements? What happens if one of the switch connectors works loose, or becomes corroded? What if a ground wire breaks? What if the car voltage drops? What if the motor fuse blows but the controller fuse is OK? What if the motor is wired backwards?
Implicit Requirements: This goes one step further than functional requirements. These are requirements that must be in place to create a pleasing experience for the customer, but they typically aren't thought of until they breach customer expectations. Things like performance, usability, reliability, repeatability, cost, reliability show up here. If it takes an hour to roll up the window the functional requirement is met, but the implicit performance requirement is not. If holding the Down button for an extra second causes the window to roll down all the way 9 times out of 10, the functional requirement is met but the repeatability requirement might not be. If the switches give out within the manufacturer's warranty period, the functional requirement is met but the reliability requirement may not be.