Start to implement "Black-box" framework code. It's mainly done by composing parts of existing application (extracting abstract classes/interfaces for commonality) , or component framework. Basic functionality should map to basic concepts of domain.

Verify that the implementation is fit for its purpose. Examine the code for its suitability to perform its intended function. This is a quality assurance step that you perform in addition to testing which is described in other tasks. Consider these strategies:

• Pair programming. By pairing to implement the code in the first place, you effectively evaluate the code as its being written.
• Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a reminder reference.
• Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or set the compiler to the most detailed warning level.
• Use tools that can visualize the code. Code visualization, such as the UML visualizations in the Eclipse IDE, help developers identify issues such as excessive coupling or circular dependencies.
• Perform informal, targeted code inspections. Ask colleagues to review small critical sections of code and code with significant churn. Avoid reviewing large sections of code.
• Use a tester to ensure the implementation is testable and understandable to testing resources.

Improve the implementation based on the results of these evaluations.

Communicate the impact of unexpected changes to the design and requirements.

The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact of issues discovered during implementation must be incorporated into future decisions. If appropriate, use  the change management process to reflect ambiguities that you identified and resolved in the implementation so they can be tested and you can manage stakeholder expectations appropriately. Similarly, leverage the design process to update the design to reflect new constraints and issues uncovered during implementation to be sure that the new information is communicated to other developers.

Usually, there is no need for a change request if the required change is small and the same person is designing and implementing the code element. That individual can make the design change directly. If the required change has a broad impact, it may be necessary to communicate that change to the other team members through a change request.