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.