4.3. Salida del Proceso de Captura de Requerimientos

Casi todo el resultado del proceso de captura de requerimientos es documental. El unico diagrama es el diagrama de casos de uso, mostrando las relaciones entre casos de uso y actores.

4.3.1. Documento de Visi??n

Las secciones tipicas de este documento ser??an como sigue.

  • Resumen. Una declaraci??n del contexto, problema y objetivo de la soluti??n.

  • Objetivos. Que estamos intentando alcanzar (y como deseamos alcanzarlo).

  • Contexto de Mercado o Convenios Contractuales. Para un desarrollo guiado por el mercado, esto deber??a indicar mercados objetivo, diferencidores competitivos, eventos motivadores y cosas as??. Para un desarrollo contractual esto deber??a explicar los factores clave contractuales.

  • Partes Implicadas. Los usuarios (en el sentido m??s amplio) del sistema. Muchos de ellos se mapear??n en actores, o equipamiento de control que se mapea en actores.

  • Caracteristicas clave. Los aspectos funcionales clave de la soluci??n deseada al problema al nivel mas alto. Estos se mapear??n ampliamente en los casos de uso. Es de ayuda poner algo de priorizaci??n aqu??.

  • Limitaci??nes. Una visi??n general de los parametros no funcionales del sistema. Estos ser??n tratados detalle en la especificaci??n de requerimientos suplementarios.

  • Apendice. Un listado de los actores y casos de uso que ser??n necesarios para cumplir esta visi??n. Es util enlazar a estos desde las secciones tempranas para asegurar una cobertura exahustiva.

4.3.2. Diagrama de Casos de Uso

El documento de visi??n ha identificado los casos de uso y los actores. El diagrama de casos de uso captura como interaccionan. En nuestro ejemplo de Cajero Automatico hemos identificado “cliente usa cajero”, “mantener cajero” y “auditar” como los tres casos de uso principales. Hemos identificado “cliente”, ingeniero de mantenimiento“, ”“oficial de sucursal” y “sistema central” como los actores.

Figure 4.1, “Diagrama de casos de uso basico para un sistema de Cajero Automatico” muestra como esto puede ser visualizado en un diagrama de casos de uso. Los casos de uso son mostrados como ovalos, los actores como monigotes (incluso cuando son maquinas), con lineas (conocidas como asociaciones) conectando los casos de uso a los actores que est??n involucrados en ellos. Un cuadro alrededor de los casos de uso enfatiza la frontera entre el sistema (definido por los casos de uso) y los actores que son externos.

[Note]Note

No todos los analisis gustan de usar un cuadro alrededor de los casos de uso. Es un asunto de opci??n personal.

Figure 4.1. Diagrama de casos de uso basico para un sistema de Cajero Automatico

Diagrama de casos de uso basico para un sistema de Cajero Automatico


Las siguientes secciones muestran como el diagrama de casos de uso b??sico puede ser extendido para mostrar informaci??n adicional sobre el sistema que est?? siendo dise??ado.

4.3.2.1. Actores Activos y Pasivos

Los actores Activos inician la interacci??n con el sistema. Esto puede ser mostrado colocando una flecha en la asociaci??n desde el actor apuntando hacia el caso de uso. En le ejemplo del Cajero Automatico, el cliente es un actor activo.

La interacci??n con los actores pasivos es iniciada por el sistema. Esto puede ser mostrado colocando una flecha en la asociaci??n desde el caso de uso apuntando hacia el actor. En el ejemplo del Cajero Automatico el sistema central es un actor pasivo.

Este es un buen ejemplo donde la flecha ayuda, puesto que nos permite distinguir un sistema conducido por eventos (el Cajero Autom??tico inicia la interacci??n con el sistema central) de un sistema de consulta continua (el sistema central interroga al Cajero Autom??tico de tiempo en tiempo).

Donde un actor puede ser, una de dos, activo o pasivo, dependiendo de las circunstancias, la flecha puede ser omitida. En el ejemplo del Cajero Autom??tico el ingeniero del banco se ajusta a esta categor??a. Normalmente el est?? activo, poniendose en funcionamiento en cicles regulares para dar servicio al Cajero. Sin embargo is el Cajero Autom??tico detecta un fallo, puede convocar al ingeniero para repararlo.

El uso de flechas en asociaciones es referido como la navegaci??n de la asociaci??n. Veremos esto usado en otro lugar en UML mas tarde.

Figure 4.2, “Diagrama de casos de uso para un Cajero Autom??tico mostrando navegaci??n.” muestra el diagrama de casos de uso del Cajero Autom??tico con navegaci??n representada.

Figure 4.2. Diagrama de casos de uso para un Cajero Autom??tico mostrando navegaci??n.

Diagrama de casos de uso para un Cajero Autom??tico mostrando navegaci??n.


4.3.2.2. Multiplicidad

Puede ser util mostrar la multiplicidad de asociaciones entre actores y casos de uso. Con esto queremos decir cuantas instancias de un actor interacciona con cuantas instancias del caso de uso.

Po defecto asumimos que una instancia de un actor interacciona con una instancia de un caso de uso. En otros casos podemos etiquetar la multiplicidad de un extremo de la asociaci??n, una de dos con un n??mero para indicar cuantas instancias est??n involucradas, o con un rango separado por dos puntos (..). Un asterisco (*) es usado para indicar un n??mero arbitrario.

En el ejemplo del Cajero Autom??tico, solo hay un sistema central, pero el puede estar gestionando cualquier n??mero de usos de Cajero Autom??tico. Por lo tanto colocamos la etiqueta 0..* en el extremos del caso de uso. No se necesita etiqueta en el otro extremo, ya que por defecto es uno.

Un banco local tendr?? hasta tres oficiales autorizados para cargar y descargar los Cajeros Autom??ticos. Asi en el extremo del actor de la relaci??n con el caso de uso Mantenimiento Cajero Autom??tico, colocamos la etiqueta 1..3. Ellos pueden estar tratando con cualquier n??mero de Cajeros Automaticos, as?? en el otro extremo colocamos la etiqueta 0..*.

Puede haber cualquier n??mero de clientes y puede haber cualquier n??mero de sistemas de Cajero Autom??tico que pueden usar. As?? a cada extremo de la asociaci??n colocamos la etiqueta 0..*.

Figure 4.3, “Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando multiplicidad.” muestra el diagrama de casos de uso del Cajero Autom??tico con multiplicidad representada.

Figure 4.3. Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando multiplicidad.

Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando multiplicidad.


La multiplicidad puede abarrotar un diagrama, y a menudo no se muestra, excepto donde es cr??tico comprenderlo. En el ejemplo de Cajero Automatico solo elegiriamos mostrar 1..3 contra el oficial del banco, ya que todos los demas son obvios por el contexto.

4.3.2.3. Jerarqu??as de Casos de Uso

En nuestro ejemplo de Cajero Automatico hasta ahora tememos solo tres casos de uso para describir el comportamiento del sistema. Mientras los casos de uso siempre deber??an describir un trozo significativo del comportamiento del sistema, si son demasiado generales pueden ser dificiles de describir.

Podr??amos por ejemplo definir el comportamiento del caso de uso “Uso Cajero” en terminos del comportamiento de los tres casos de uso mas simples, “Depositar Dinero”, “Retirar Dinero” y “Consultas de Cuenta”. El caso de uso principal podr??a ser especificado incluyendo el comportamiento de los casos de uso subsidiarios necesarios.

Similarmente el caso de uso “Mantener Cajero” podr??a ser definido en terminos de dos casos de uso “Mantener Equipamiento” y “Recargar Cajero”. En este caso los dos actores involucrados en el caso de uso principal est??n realmente solo involucrados en uno u otro de los dos casos de uso subsidiarios y esto puede ser mostrado en el diagrama.

La descomposici??n de un caso de uso en subcasos de uso mas simples es mostrada en UML usando una relaci??n de inclusi??n, una flecha punteada desde el caso de uso principal hasta el subsidiario, con la etiqueta ??include??.

Figure 4.4. Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.

Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.


Las relaciones de inclusi??n son buenas para desmantelar los comportamientos de casos de uso en jerarquias. Sin embargo podemos tambien querer mostrar un caso de uso que es una extensi??n de un caso de uso existente para atender a una circunstancia particular.

En el ejemplo del Cajero tenemos un caso de uso cubriendo la rutina de mantenimiento del Cajero, “Mantener Equipamiento”. Tambien queremos cubrir el caso especial de una reparaci??n no programada causada por la detecci??n de un fallo interno por parte del Cajero.

Esto est?? mostrado en UML por la relaci??n de extensi??n. En el caso de uso principal, especificamos un nombre para un lugar en la descripci??n, donde una extensi??n del comportamiento podr??a ser adjuntada. El nombre y lugar son mostrados en un compartimento separado dentro del ovalo del caso de uso. La representaci??n de relaci??n de extensi??n es la misma que la de la relaci??n de inclusi??n, pero con la etiqueta ??extend??. Paralelamente a la relaci??n de extensi??on, especificamos la condicion bajo la cual ese comportamiento ser?? adjuntado.

Figure 4.5, “Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.” muestra el diagrama de casos de uso del Cajero con una relaci??n de extensi??n a un caso de uso para reparaciones no programadas. El diagrama se est?? volviendo bastante complejo, y as?? lo hemos dividido en dos, uno para el lado del mantenimiento, el otro para el uso del cliente y auditor??a.

El caso de uso “Mantener Equipamiento” define un nombre “Unsched”, al comienzo de su descripci??n. El caso de uso extendido “Unscheduled Repair” es adjuntado ah?? cuando el Cajero detecta un error interno.

Figure 4.5. Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.

Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.


Los casos de uso pueden ser enlazados juntos de una forma adicional. Un caso de uso puede ser una generalizaci??n de un caso de uso subsidiario (o alternativamente el subsidiario es una especializati??n del caso de uso principal).

Esto es muy parecido a la relaci??n de extension, pero sin la limitaci??n de puntos de extensi??n especificos en los cuales el caso de uso principal puede ser extendido, y sin condiciones sobre cuando puede ser usado el caso de uso subsidiario.

La generalizaci??n est?? representada en un diagrama de casos de uso por una flecha con una linea continua y una punta de flecha blanca desde el subsidiario al caso de uso principal.

Esto puede ser util cuando un caso de uso subsidiario especializa el comportamiento del caso de uso principal en un gran n??mero de posiciones y bajo un amplio rango de circunstancias.

Sin embargo la falta de alguna restricci??n hace la generalizaci??n muy dificil de especificar con precisi??n. En general usa una relaci??n de extensi??n en su lugar.

4.3.3. La Especificaci??n de Casos de Uso

Cada caso de uso debe ser documentado para explicar en detalle el comportamiento que est?? especificando. Este documento es conocido por diferentes nombres en diferentes procesos: especificaci??n de caso de uso, escenario de caso de uso o incluso (confusamente) solo caso de uso.

Un caso de uso tipico incluir?? las siguientes secciones.

  • Nombre. El nombre del caso de uso al que esto se refiere.

  • Objetivo. Un resumen de una o dos lineas de que realiza este caso de uso por sus actores.

  • Actores. Los actores involucrados en este caso de uso, y cualquier contexto con respecto a su participaci??n.

    [Note]Note

    Esto no deber??a ser una descripci??n del actor. Eso deber??a estar asociado con el actor en el diagrama de casos de uso.

  • Pre-condici??n. Ser??a mejor llamarlas “pre-asumciones”, pero el termino usado en todos sitios es pre-condiciones. Es una declaraci??n de cualesquiera asumciones de simplificaci??n que podemos hacer al comienzo del caso de uso.

    En el ejempli del Cajero Automatico, podemos hacer la asumci??n para el caso de uso de “Mantener Equipamiento” que un ingeniero est?? siempre disponible, y no necesitamos preocuparnos sobre el caso de que una visita de mantenimiento de rutina se halla dejado pasar.

    [Caution]Caution

    Evita pre-condiciones todo lo posible. Necesitas tener la absoluta certeza de que las pre-condiciones caben bajo todas las posibles circunstancias. Si no tu sistema estar?? debilmente especificado y por lo tanto fallara cuando la pre-condici??n no es cierta. Alternativamente, cuando no tienes la certeza de que la pre-condici??n es siempre cierta, necesitaras especificar un segundo caso de uso para manejar la pre-condici??n siendo falsa. En el primer caso, las pre-condiciones son una fuente de problemas, en el segundo una fuente de mas trabajo.

  • Flujo B??sico. La secuencia lineal de pasos que descruben el comportamiento de el caso de uso en el escenar??o “normal”. Donde un caso de uso tiene un n??mero de escenarios que podr??an ser normales, uno es seleccionado arbitrariamente. Especificar el flujo b??sico est?? descrito con m??s detalle mas Section 4.3.3.1, “Especificando el Flujo Basico” abajo.

  • Flujos Alternativos. Unas series de secuencias lineales describiendo cada uno de los comportamientos alternativos al flujo b??sico. Especificar flujos alternativos est?? descrito con mas detalle en Section 4.3.3.2, “Especificando los Flujos Alternativos”.

  • Post-condiciones. Ser??a mejor llamarlas “post-asumciones”. Esta es una especificaci??n de cualesquiera asumciones que podemos hacer al final del caso de uso. Son mas utiles donde el caso de uso es uno de una serie de casos de uso subsidiarios que estan incluidos en un caso de uso principal, donde pueden formar las pre-condiciones del siguiente caso de uso que va a ser incluido.

    [Caution]Caution

    Como las pre-condiciones, las post-condiciones son mejor evitarlas. Colocan una carga en la especificaci??n de los flujos de caso de uso, para asegurar que la post-condici??n siempre se mantiene. Por lo tanto son tambien una fuente de problemas y trabajo extra.

  • Requerimientos. En un mundo ideal el documento de visi??n, los diagramas de casos de uso, las especificaciones de casos de uso y la especificacion de requerimientos suplementarios formari??n los requerimientos para un proyecto.

    Para la mayor??a de los desarrollos lideres del mercado, donde la propiedad de los requerimientos esta dentro del mismo negocio que el equipo que har?? el desarrollo, este no es normalmente el caso. El departamento de marketing puede aprender captura de requerimientos basada en casos de uso y analisis para enlazar con las actividades primarias de sus consumidores.

    Sin embargo para desarrollos externos por contrato, los consumidores pueden insistir en una “lista de caracteristicas” tradicional como la base del contrato. Cuando este es el caso, esta secci??n de la especificaci??n de casos de uso deber??a enlazar con las caracteristicas del contrato que son cubiertas por el caso de uso.

    Esto es hecho a menudo a traves de una herramienta de terceros que puede enlazar documentos, proporcionando una prueba automatizada de cobertura de requisitos, en tal caso esta secci??n no es necesaria, o puede ser generada automaticamente.

El tama??o final de la especificac??on de caos de uso depender?? de la complejidad del caso de uso. Como peque??a regla, la mayor??a de los casos de uso toman alrededor de 10-15 paginas para especificar, la mayor??a de las cuales son flujos alternativos. Si el tuyo es mucho mas largo que esto, considera simplificar el caso de uso. Si el tuyo es mucho mas peque??o considera que el caso de uso esta describiendo una parte demasiado peque??a del comportamiento.

4.3.3.1. Especificando el Flujo Basico

Todos los flujos en una especificaci??n de casos de uso son lineales (esto es que no hay ramas condicionales). Cualesquiera elecciones en los flujos son manejadas especificando otro flujo alternativo que recoge el punto de elecci??n. Es importante recordar que estamos especificando comportamiento aqui, no programandolo.

Un flujo es especificado como una serie de pasos numerados. Cada paso debe implicar alguna interacci??n con un actor, o al menos generar un cambio que sea observable externamente por un actor. La captura de requerimientos no deber??a estar especificando comportamiento interno y oculto del sistema.

Por ejemplo nosotros podemos dar la siquiente secuencia de pasos para el flujo basico del casos de uso "Retirar Dinero" en nuestro ejemplo de Cajero Automatico.

  1. Consumidor indica que se requiere recibo.

  2. Consumidor introduce cantidad de dinero requerido.

  3. Cajero Automatico verifica con el ordenador central que el consumidor puede realizar esta operaci??n.

  4. Cajero Automatico entrega el dinero a el consumidor.

  5. Cajero Automatico emite recibo al consumidor.

Recuerda que esta es un sub-caso de uso incluido en el caso de uso principal “Usar Cajero Automatico”, el cual presumiblemente manejar?? la verificaci??n de tarjetas y PINs antes de invocar este caso de uso incluido.

[Note]Note

El primer paso no es una condici??n. Tomamos como nuestro flujo b??sico el caso donde el consumidor quiere un recibo. El caso donde de consumidor no quiere un recibo ser?? un flujo alternativo.

4.3.3.2. Especificando los Flujos Alternativos

Esto captura los escenarios alternativos, como flujos lineales, mediante referencia la flujo b??sico. Inicialmente unicamente construimos una lista de los flujos alternativos.

  1. A.1.

    Consumidor no requiere recibo.

    A.2.

    La cuenta del consumidor no soportar?? el retiro de dinero.

    A.3.

    Comunicaci??n con el ordenador central est?? interrumpida.

    A.4.

    El consumidor cancela la transacci??n.

    A.5.

    El consumidor falla a coger el dinero entregado.

Subsequently we flesh out each alternate flow, by reference to the basic flow. For example the first alternate flow might look like.

  1. A.1.

    Customer does not require a receipt.

    A.1.1.

    At step 1 of the basic flow the customer indicates they do not want a receipt.

    A.1.2.

    The basic flow proceeds from step 2 to step 4, and step 5 is not used.

The convention is to number the various alternate flows as A.1, A.2, A.3, etc. The steps within an alternate flow are then numbered from this. So the steps of the first alternate flow would be A.1.1, A.1.2, A.1.3, etc.

4.3.3.3. Iterative Development of Use Case Specifications

Iterative development will prioritize the use cases, and the first iterations will address the most important.

Early iterations will capture the basic flows of the most important use cases with only essential detail and list the headings of the main alternate flows.

Later iterations will address the remaining use cases, flesh out the steps on individual alternate flows and possibly provide more detail on individual steps.

4.3.4. Supplementary Requirement Specification

This captures the non-functional requirements or constraints placed on the system. Since use cases are inherently functional in nature, they cannot capture this sort of information.

[Note]Note

Some analysts like to place non-functional requirements in a section at the end of each use case specification, containing the non-functional requirements relevant to the use case.

I don't like this for two reasons. First key non-functional requirements (for example about performance) may need to appear in many use cases and it is bad practice to replicate information. Secondly there are invariably some non-functional requirements that are system wide and need a system wide document. Hence my preference for a single supplementary requirements specification.

There should be a section for each of the main areas of non-functional requirements. The checklist provided by Ian Sommerville in his book Software Engineering (Third Edn, Addison-Wesley, 1989) is a useful guide.

  • Speed. Processor performance, user/event response times, screen refresh time.

  • Size. Main memory (and possibly caches), disc capacity.

  • Ease of use. Training time, style and detail of help system.

  • Reliability. Mean time to failure, probability of unavailability, rate of failure, availability.

  • Robustness. Time to restart after failure, percentage of events causing failure, probability of data corruption on failure.

  • Portability. Percentage of target-dependent code/classes, number of target systems.

To this we should add sections on environment (temperature, humidity, lightening protection status) and standards compliance.