The STAIR process can be applied to situations that have nothing to do with computing. As an example, imagine the following situation: Tom came home one day to be confronted by his wife about the small sailboat that was filling space in the garage. She suggested he find a more efficient way to store the boat than leaving it where she normally parked her car. (Her suggestion was couched in somewhat stronger terms than this.!..) Being quite a good problem solver, he decided to apply the STAIR methodology to this problem.
Notice that Tom started with as simple a statement of the problem as possible. He also listed some of the relevant constraints. He didn't worry about what the exact solution might be yet. This may not be the finished statement of the problem. Tom may find he needs to come back and refine his problem statement a little more before he can finish the solution.
Notice how flexible he was with the term `tool.' This approach allows Tom to think of the IDEAS he will choose from, as well as the physical entities. In fact, the actual mechanical tools that will be used will be decided much later in the problem solving process. It's way too early to worry about whether he will use a hammer or a screwdriver.
In this instance, the algorithm step involved choosing the best alternative from the tools step. At this point, he had made a decision about how he was going to tackle the problem. Notice that he also started thinking about which physical tools (in this case a rope) he would use to help solve the problem.
The implementation step so far has been unsuccessful in the obvious sense; the boat is still sitting on the garage floor. Rather than being discouraged by this, Tom will use the experience as an information gathering stage for the next step:
The refinement step made some visits back to many of the other parts of the problem-solving process. Our handyman had to adjust his perception of the problem. Attaching the boat to the ceiling was a good idea, but Tom's first statement of the problem did not specify how he was going to do this. Finding a way to solve this part of the problem involved combining algorithm development and tool selection. The implementation happened in segments as he found more of the right ideas and tools to solve the problem. The process does not always flow in a set order, but because he used a systematic approach, he always knew how to think about solving the problem. Tom knew, for example, that his algorithm was good, but he would need to rethink his tool selection. Obviously, plenty of people solve this kind of problem without ever taking a computer science class. Tom may not even know that he was using an organized problem solving technique. The reason we begin with this problem is to illustrate that our problem solving-process is really just a somewhat formalized summary of the techniques we already recognize as problem solving techniques in many settings.