Assess the scope of analysis versus the scope of design.
The transition from analysis to design requires that you understand the difference between what was modeled in analysis and what you will model in design. Throughout project initiation and problem analysis you proceeded under the assumption that the
"system" you were modeling had nothing at all to do with software and hardware.
Problem domain definition
The functionality (use case model ), the resources (object model ), and the interaction of the resources to support the functionality (sequence and collaboration diagrams) would exist whether or not you ever provided automation.
For example, in the ticket sales system, you identified the need to set up the seating, set up shows, price the seating in the shows, and sell tickets. There is nothing technological about these functions. In fact, they have been performed manually for centuries.
Use case model :The UML model used to represent clients' expectations about how they will interact with the system.
Object model: For many people this phrase is synonymous with class diagram. However, the model in a larger sense also includes the object diagram and package diagram.
Sequence diagram: The UML diagram designed to model the interaction between objects overtime. The scope of the diagram is typically a single scenario.
Collaboration diagram: One of the two UML standard interaction diagrams designed to model the communication between objects.
Preserve the problem domain model
Everything you defined in analysis must remain intact as you move into design. In fact, the analysis level object model will be the basis for your database design.
Few, if any, of the new objects added during design will become part of the database. Those that do will be added during object design to improve performance, not functionality.
Design adds a layer of functionality on top of the analysis models. This layer is the software that facilitates the use of the problem domain resources using interfaces, databases, transaction control, and communication that conforms to the use case model.
This layer of technology will likely change often, but the underlying problem domain will remain relatively stable.