Comments on Reports 
A1: An Analysis Report is much more than simply a User’s Guide! It should mainly address the designer (possibly customers as well). 
A2: An Analysis Report (like any type of a report) should be organized with respect to some criteria (e.g., software components). 
A3: Need to make sure section titles are clear enough to see how the overall organization is, what each section really includes, and how they complement each other. 
A4: The order in which activities during an analysis should be performed and written as part of the report should be as follows: optional domain analysis, UC analysis, object-interaction / activity / state diagrams, and final class diagrams. 


UC1: UC diagrams come pretty late and they seem to be done after the design of the menus. However UC analysis is the very first activity performed during analysis. On the contrary, menus should be designed around (in accordance with) UCs. Remember that in general the design should be organized the same way the analysis phase proceeds: first the UCs, then object interaction, activity and state diagrams, etc. Also remember that this documentation is not a post-analysis activity, it’s part of the analysis! 
UC2: UC analysis includes a textual description of the use-cases with one or two most common use cases given in detail. 
UC3: Make sure each UC actually makes a good use-case (passes one of the tests given the textbook such as the Boss Test). 


SD1: A Sequence Diagram represents the interactions of the objects in the software during a sequence of events. Thus you should introduce such a diagram by stating what that sequence is. E.g., the following Sequence Diagram shows how Ali successfully destroys the enemy spaceship by using blah blah, after doing blah blah… 
SD2: Incorrect flow of control in Sequence Diagrams. 
SD3: Make sure each object in a Sequence Diagram is actually responsible for each incoming message/method call. 
SD4: Poor naming of objects in Sequence Diagrams. 
SD5: Properly show the data passing (parameters) during messaging in between objects. 


ST1: Could make use of State Diagrams. 
ST2: States in a State Diagram belong to a particular object of a certain class, neither non-objects nor multiple objects. 
ST3: Activities in an Activity Diagram should be the activities of the system, not the user! 
ST4: Incorrect use of the synchronization in Activity Diagrams. 


G1: What you analyze, design, and implement is a software or software tool or simply tool, not simply a program. 
G2: In general it’s a lot more effective (in terms of conveying ideas) to have some pictures, screenshots as early as possible during a presentation or documentation in general. 
G3: Just like any other formal report, it should have a table-of-contents; all figures must be numbered and should have caption, etc. As “computer people” who write such documents regularly, we strongly recommend that you learn a word processor well; that is, use auto formatting, auto numbering, auto table of contents, etc. 
G4: Java API documentation is better be presented separately (than the internal document) as it is often long and clutters the report. So a nice organization of all about your software could be: 
Analysis Document 
Internal Document 
API Document 
Sources 
User’s Guide 
Download 


G5: The explanations of UML diagrams should be in plain English (e.g., use “main menu” instead of “MainMenu class”; use “collision manager” instead of “CollisionMgr object”; say “a new weapon of this type is created” instead of “create method of WeaponMgr is called with this type”).