OK, after turning the problem statement into a set of requirements at class Monday night, we are ready now to create a set of use cases to represent the requirements. I've gone ahead and taken an initial stab at a set of use cases on the web site (
http://www.ajug-scea.org/app.htm#design). The original problem statement and distilled requirements are also there. You'll notice that in the requirements list, I have linked each requirement to the use cases that represent it. Conversely, in the use case list, I've linked each use case to the requirements that drive it. By cross-checking them back and forth, we can make sure that the requirements are solid (use cases don't bring up any implied or missing requirements) and that the use cases when properly implemented will in fact satisfy the requirements (requirements don't state anything that isn't covered by at least one use case, with the exception of non-functional requirements like availability, stability, etc.)