En esta actividad se especifica el diseño detallado de una parte del sistema, no del sisstema como un todo. Debe
tomar como entrada un pequeño subconjunto de los requerimientos del sistema. Los requerimientos que impulsan el diseño pueden ser requerimientos funcionalesl (basados en escenarios de uso u otro tipo), requerimientos no funcionales, o una combinación de ambos.
Esta actividad se puede realizar en algún contexto específico, como ser especificar los elementos de acceso a la base
de datos necesarios para algún escenario de uso del sistema. En este caso, la actividad podría aplicarse nuevamente más
tarde para tratar un contexto diferente con los mismos requerimientos (por ejemplo, el diseño de la interfaz de
usuario). Tener en cuenta que para construir un requerimiento que sea de valor para los usuarios, en general todos los
contextos deberán diseñarse e implementarse. Por ejemplo, para completar una parte de la funcionalidad del sistema,
debe diseñarse e implementarse en todos sus contextos (perspectivas o aspectos), incluida la interfaz de usuario, las
reglas de negocio, el acceso a la base de datos, etc.
Para mayor cohesión e integridad, esta actividad se describe como un paso end-to-end (de punta a punta) para diseñar un
requerimiento de uso del sistema. En la práctica, esta tarea se realizará de forma repetida, a medida
que implementen porciones de código, se realice más diseño en función de lo aprendido, etc. Es recomendable
que esta actividad se realice de forma muy cercana a la implementación del software.
Si se está diseñando un elemento o componente relevante a la arquitectura, se debe referenciar a este diseño en la
descripcion de la arquitectura.
|
