2. Traza un Modelo de Casos de Uso al Modelo del Proceso de Negocio para definir exactamente que funcionalidad intenta proveer desde la perspectiva del usuario de negocios. Mientras cada Caso de Uso se agrega, crea un vínculo trazable desde los procesos de negocios apropiados al Caso de Uso (es decir, una conexión de realización). Este trazado claramente establece que funcionalidad proveerá el nuevo sistema para cumplir con los requisitos del negocio establecido en el modelo del proceso. Este también asegura que no existe ningún Caso de Uso sin un propósito.

3. Refine los Casos de Uso – incluye requisitos, restricciones, clasificación de complejidad, notas y escenarios. Esta información ambiguamente describe lo que hace el Caso de Uso, como se ejecuta y las restricciones en esta ejecución. Se asegura de que el Caso de Uso todavía reúne los requisitos del proceso de negocio. Incluye la definición de las pruebas del sistema para cada Caso de Uso y así definir el criterio de aceptación para cada Caso de Uso. También incluye algunos scripts de pruebas de aceptación del usuario para definir como el usuario probará esta funcionalidad y cuales son los criterios de aceptación.

4. Desde las entradas y las salidas del Modelo del Proceso de Negocio y los detalles de los casos de uso, comienza a estructurar un modelo de dominio (objetos de negocio de alto nivel), diagrama de secuencia, diagrama de colaboración y los modelos de la interfaz de usuario. Estos describen las “cosas” en el nuevo sistema, la manera en que esas partes interactúan y la interfaz que un usuario usará para ejecutar los escenarios de los casos de uso.

5. Desde el modelo de dominio, el modelo de la interfaz de usuario y los diagramas del escenario crean el Modelo de Clase. Esta es una especificación precisa de los objetos en el sistema, sus datos o atributos y su comportamiento u operaciones. Los objetos del dominio se pueden abstraer en las jerarquías de la clase usando herencias. Los mensajes del diagrama del escenario normalmente trazarán las operaciones de la clase. Si se usa un marco existente o patrón del diseño, es posible importar elementos del modelo existentes para usarlos en el nuevo sistema. Para cada clase define pruebas de unidad y pruebas de integración para probar completamente i) que la clase funciona como se especifican internamente y que ii) la clase interactúe con otras clases relacionadas y los componentes como se espera.

6. Mientras la clase del modelo se desarrolla, se puede fraccionar en paquetes y componentes discretos. Un componente representa una porción despegable del software que recolecta el comportamiento y datos de una o más clases, y expone una interfaz estricta a otros consumidores de sus servicios. Así un Modelo del Componente se compila para definir el empaquetamiento lógico de las clases. Para cada componente define pruebas de integración para confirmar que la interfaz del componente reúne la especificación dada en relación con otros elementos del software.