For example, a good method would be setVolume(). What will this method do?? Part of the state of the Radio object is its current volume level, so this should be a data member: int volume. Now it is clear what the method setVolume() should do: alter the value of the volume data member.
Similarly, we could have turnOn() and turnOff() methods. The Radio must consider whether it is currently on or not as part of its "state", so this should be a data member: boolean power. Therefore the method turnOn() would set power to true while turnOff() would set power to false.
Question 2: I think the biggest problem was not stating which methods were associated with which objects. Many people listed 10 or more objects, and then listed 5 to 20 methods, but gave no indication which objects the methods were for. This is a very important part of the design! Basically you were supposed to do what you did for the Radio for every object you defined!
Also, I think some people thought only the animate objects could have methods (e.g. Instructor and Student objects had methods, but not Classroom or Blackboard). Although this is basically true in real life, in programming we make a practice of personifying all our classes --- we pretend they can be active, and manipulate data and send messages etc. It takes a bit of a leap of the imagination to get used to this, but once you get going it gets easier!
A note on grading: I tried to give everyone 3 points who I thought had the basic idea. Sometimes it was really hard to tell due to insufficient detail. If I had any doubt I generally gave a 2, even if it seemed like the student might understand it all. Remember that the lessons don't count towards your final grade, so if you didn't get 3 consider it as a warning bell: if you think you might be missing something, get it clarified right away; otherwise ignore the inaccurate grade and realize that maybe you just didn't convey the fact that you understood very well!