4.2. El Prodeso de Captura de Requerimientos

Empezamos con una visión general del problema que estamos resolviendo y las areas clave de funcionalidad que debemos tratar en cualquier solución. Este es nuestro documento de visión, y debería ser de solo algunas páginas de longitud.

Por ejemplo la visión general de un cajero automatico (automated teller machine; ATM) puede ser que debería soportar lo siguiente.

  1. Depositos monetarios, reembolsos monetarios y consultas de cuenta por los clientes.

  2. Mantenimiento del equipamiento por los ingenieros del banco, y descarga de depositos y carga de dinero por la sucursal local del banco.

  3. Auditorias de todas las actividades enviadas al sistema central del banco.

Desde esta visión general podemos extraer las actividades principales del sistema, y los agentes externos (personas, equipamiento) que están involucradas en estas actividades. Estas actividades son conocidad como casos de uso y los agentes externos son conocidos como actores.

Los actores pueden ser personas o maquinas. Desde un punto de vista practico es beneficioso conocer la parte implicada detras de cada maquina, puesto que solo ellos serán capaces de tratar con el proceso de captura de requerimientos.

Los casos de uso deberías ser actividades significativas para el sistema. Por ejemplo el uso por el cliente del Cajero Automatico es un caso de uso. Introducir un numero PIN no lo es.

Hay una zona intermedia entre estos dos extremos. Como veremos a menudo es util dividir casos de uso muy grandes en pequeños subcasos de uso. Por ejemplo podemos tener subcasos de uso cubriendo depositos de dinero, retiradas de dinero y consultas de cuenta.

No hay una regla clara y rápida. Algunos arquitectos preferirán un pequeño numero de casos de uso relativamente grandes, otros en en cambio preferirán un grán número de pequeños casos de uso. Una regla util a primera vista es que cualquier proyecto practico debería requerir no mas de alrededor de 30 casos de uso (si necesita mas, debería ser dividido en proyectos separados).

Luego mostramos la relación entre casos de uso y actores en uno o mas diagramas de casos de uso. Para un proyecto grande puede ser necesario mas de un diagrama. Normalmente los grupos de casos de uso relacionados son mostrados en un mismo diagrama.

Debemos luego dar una especificación mas detallada de cada caso de uso. Esto cubre su comportamiento normal, comportamientos alternativos y cualquier precondición y postcondición. Esto se refleja en un documento conocido como especificación de caso de uso o escenario de caso de uso.

Finalmente, puesto que los casos de uso son funcionales en su naturaleza, necesitamos un documento para capturar los requerimientos no funcionales (capacidad, rendimiento, necesidades de entorno, etc). Estos requerimientos son capturados en un documento conocido como una especificación suplementaria de requerimientos.

4.2.1. Pasos del Proceso

Los pasos en el proceso de captura de requerimientos pueden ser resumidos como sigue.

  1. Captura una vista general del problema, y las caracteristicas deseadas de su solución en el documento de visión.

  2. Identificar los casos de uso y actores desde el documento de visión y mostrar sus relaciones en uno o mas diagramas de casos de uso.

  3. Da especificaciones de casos de uso detalladas para cada caso de uso, cubriendo el comportamiento normal y alternativo, precondiciones y postcondiciones.

  4. Captura todos los requerimientos no funcionales en una especificación de requerimientos suplementarios.

En cualquier proceso de desarrollo iterativo, priorizaremos, y las iteraciones tempranas se enfocaran en capturar el comportamiento clave del los casos de uso mas importantes.

La mayoría de los procesos de captura de requerimientos modernos están deacuerdo con que es esencial que un representante autorizado del cliente esté completamente involucrado a traves del proceso.