A system doesn't live in isolation. It interacts with its environment. When we model a system as a state machine we are modeling the interface the system has with its environment. Later in the course when we discuss concurrency we will model the environment itself as a state machine and then discuss the interactions between a system and its environment as the behavior of the composition of two state machines. For now (and for the first part of this course) we will focus our attention on modeling the system and understanding a system's behavior through its state machine model. For now, you can pretend that you are the system's environment.
Intuitively the behavior of a state machine captures what the environment observes of the system modeled by the machine. Many state machine models differ on what ``observes'' mean. (That's one reason why I introduced an event-based view and a state-based view.) When you identify what a system's sets of states and actions are you are defining what its observable behavior is. So, when you design a system, especially if it is supposed to be put together with some other system, it is critical that you identify its interface. A rule of thumb to use when you're trying to nail down a system's interface and you're not sure whether something belongs in the interface or not, is to ask yourself, ``Can I observe it?'' If so, then ``it'' has to be modeled somehow; ``it'' is part of the system's interface.