Hi, Jason.
I don't have much time, so I'll just outline how I'm doing it:
1. Do a process diagram, using the artifacts in the Analysis tool box. Users understand these processes much better that use cases. This is also the "panoramic" view of your subject area.
2. Create a use case model, so that the all functional requirements are covered (and documented in the use cases).
3. Create (at least) one sequence diagram for every use case. I drag the sequence diagram into its use case element in the project tree, which makes documentation very clear. Be aware, however, that Sparx recommends to maintain the original view structure in your tree. (Follow whatever you find makes more sense for you.)
4. If your use case is complete, you should have discovered practically all your classes in your sequences. You can now change the appropriate "sequence" objects to "class" (right click on them in the diagram, chage object type...). In your tree, move the classes to the appropriate structural package (that is, where you will create your database diagram).
Import all class info you can get from existing models in other packages (ERWin, for instance). Or, oftentimes, you can reverse-engineer classes / tables from existing code. Saves a lot of time, because you do not have to type attributes and so forth...
5. Draw your structural diagram by placing your classes / tables into it, and joining them with appropriate associations.
Also, your structural package can contain a package for the database, and another for user interface classes. This is optional, since there is nothing wrong with having a single class diagram for both.
6. Make diagrams of your technical architecture: see if you can get away with a single diagram that has components and nodes. You will specify here your server and PC types, the components and packages they contain...
7. Complete and check your model by specifying the states of class instances that have non-trivial life-cycles. (See my posting on states in sequence diagrams.)
As you go along, generate interim (RTF or HTML) documents to see if everything is comming out clearly. (Don't worry about document details: all your changes should go into your EA model, not into the interim docs.)
As nice details for your system documentation: "move external" your use case (and other) requirements into requirements in a "Project Definition" package. Make a requirements diagram, and join requirements with appropriate depedencies. I place this at the very beggining of my tree, so it comes out first in my documentation. It is also nice to move all actors to a "Project Organization" package, and make an org chart.
Hope it helps!
Jaime Gonzalez
