In the first diagram I noted down the two states and just two events. Now I have to fill in some detail about the kinds of events which might befall our program. If you think about what a user of the system can do, you come up with four things:

1. space (i.e. don't press the button)

2. enter a dot (i.e. press the button and release it quickly)

3. enter a dash (i.e. press the button and release it slowly)

4. enter a "stuck" (i.e. hold the button down)

Each of these actions counts as an event which our system must respond to. Perhaps the most confusing one is "space". This is actually quite important however, as we need to know when the user has stopped entering any dots or dashes, since this marks the end of character. We can tell that a space has been entered by listening for a while. If we don't hear anything we assume that a space has been entered.

For now I don't want to consider how we can tell which event has been generated, we will instead consider how the system should react when the events occur. By react I mean what actions the system should perform, and whether or not it should change to a different state.

For example, if the system is in the quiet state and it receives a "dot" event it should move into the busy state, and record the fact that a dot has been received. If the system is in the quiet state and it received a "space" it should do nothing.

The next step of the design process is to take every event and every state and try to decide what should happen in each case. On the right you can seem my first attempt at this.