As the name suggests, here we get technical. The contractor refines the ERD and creates a schema that fully defines the database. He'll define any required stored procedures (in the case of databases that support them), and defines the modules to be created and their functions.
Work from the top down, and recurse! Start with the overall system design, then design the functional modules that make up the system. Start with high-level functional modules and work down to the submodules that comprise them. Do the same thing at each level of detail until you run out of detail. Then work out the technical design of each functional module, including the class or classes that implement it, from the bottom up. If you're working with a development team, obviously you should not do all of this yourself: make sure the analysts who will be doing the work have input into the design of the modules they'll be writing.
I'm aware that in recent years, object-oriented techniques have stressed bottom-up design. Note that I'm not suggesting that you throw this away. To the contrary, I say that you should define from the top down, and refine and implement from the bottom up. Prior to implementing your design, normalize it. Normalization is a term borrowed from database management meaning roughly "to maximize efficiency while assuring minimum duplication." I use it here to describe the process of analyzing your design to find duplication (or near duplication) of classes. You should determine which of these can be re-engineered to maximize code re-use.
ITERATE! The design may actually change during development, but these changes should attempt to follow the spirit of the Technical System Design, as inherited from the Functional System Design. USE AN RCS TO MAINTAIN CHANGES!
The design phase may last as long or longer than actually writing the program. This doesn't necessarily mean that you have to wait to code until the design is finished... remember that you should always look for opportunities to work concurrently! Since you're designing recursively you can start coding in most cases as soon as you've designed to the end of a branch (as soon as you've designed to a "leaf node"). You can often save normalization for iteration; but in real life (unless you're one of a team of designers), when you get to a similar class you simply remember what you've designed at a previous leaf and revise the design of the class at that time.
Originator: the contractor.
Deliverables: Technical design documents...
Phase 4. Functional System Design Phase 6. Programming