Está en la página 1de 41

Captura de requerimientos

Captura de requisitos
Objetivo: descubrir y representar los requisitos e ideas que debe cumplir un nuevo sistema o la mejora de un sistema
Qu hay inicialmente? Inicialmente hay un gran volumen de informacin: requerimientos del usuario, del dueo del negocio, modelos del dominio, productos, etc.

Captura de requisitos
Se colectan requisitos brutos desde varias fuentes Se documentan explcitamente como una lista dividida en dos grandes grupos de requisitos:
Funcionales: dicen lo que el usuario puede hacer con el sistema No-funcionales: establecen restricciones y lmites tcnicos a la implementacin.

Colectando requisitos: ejemplo


Sistema de Mensajes Cortos (SMC) Se desea un sistema que permita al usuario de un telfono mvil enviar mensajes cortos a otros usuarios de telfonos mviles. Cmo comunicar la idea?
Se puede crear una transparencia como la siguiente:

Sistema de Mensajes Cortos


Fcil edicin de los mensajes
Manejo de listas de correos Puede almacenar los mensajes en forma persistente Pantalla PC Hola, cmo estas? Hola,

cmo estas?

Requisitos funcionales
1) El usuario puede enviar mensajes cortos desde un PC a travs de un telfono mvil adherido al PC 2) El usuario puede almacenar y cargar nmeros telefnicos basado en nombres de receptores (destinatarios) 3) El usuario puede construir listas de correo de mltiples destinatarios

Requisitos funcionales
4) El usuario puede almacenar y reutilizar dichos comunes como frases 5) El usuario puede grabar los mensajes enviados y ms tarde puede mirarlos y reutilizarlos

Requisitos no-funcionales
1) El sistema debe correr en plataformas Windows y Macintosh 2) El sistema debe permitir mltiples accesos simultneos a los nmeros de telfono almacenados as como a los grupos 3) El sistema debe almacenar los datos de las tonadas en archivos tipos ASCII delgado.

Casos de uso
El concepto del producto y la lista de requisitos es slo el comienzo del proyecto de desarrollo de un software En OMT++ se usan los casos de uso para que el usuario final y el desarrollador discutan los requisitos y se formen una comprensin comn sobre el tipo de sistema a desarrollar

Casos de uso
Los requisitos funcionales especifican qu debera hacer un sistema Un caso de uso describe cmo el sistema y el usuario final haran algo en forma conjunta El usuario final es un ser humano o cualquier otra entidad externa. Un caso de uso describe un flujo de eventos entre el usuario y el sistema

Casos de uso
El modelo de casos de uso usa actores para representar roles que los usuarios pueden jugar y usa casos para representar cmo los actores cooperan con el sistema. Un actor es tpicamente un usuario en un rol especfico. Tambin puede ser otro sistema que pide servicios.

Los casos de uso no describen cmo el sistema implementa lo que hace.

Casos de uso
Los casos de uso explican las acciones de los actores y las respuestas del sistema. Los casos de uso ilustran escenarios de uso tpico del sistema (secuencia normal, feliz). Guan el diseo y la implementacin final del sistema. El sistema debera ser probado contra los casos de uso para verificar la equivalencia entre los casos de uso y el sistema final.

Casos de uso
Los casos de uso son ejemplos concretos de cmo un actor usa el sistema para obtener beneficios concretos.

La tcnica de los casos de uso es una herramienta para colectar y analizar diferentes formas de usar el sistema, y entrega un medio de comunicacin en la fase de captura y anlisis de los requisitos.

Discusin de los casos de uso


Hable con los potenciales usuarios para saber cmo ellos podran usar el software Escriba las primeras versiones de los casos de uso basado en las discusiones con los potenciales usuarios. Escriba los casos de uso de manera que los clientes los puedan entender y hacer comentarios. Luego seleccione clientes claves para refinar los casos de uso. Despus que los casos de uso y otros requisitos han sido refinados, documentados y acordados, ellos forman la base de las siguientes fases del desarrollo.

Forma de los casos de uso


OMT++ no utiliza notacin grfica Se describen mediante una plantilla de caso de uso. Es importante que todo el mundo pueda leer los casos de uso El lenguaje natural contribuye a que todo el mundo entienda y ayude a su creacin La plantilla obliga a incluir los elementos ms importantes en el caso de uso

Casos de uso
10 mandamientos para obtener buenos casos de uso. (Segn los autores de OMT++)
Referencia: A. Jaaksi 'Our Cases with Use Cases', in Journal of Object-Oriented Programming, Vol 10, No 9, February 1998, pp 58 -65.

1. Los casos de uso especifican los requisitos funcionales ms importantes

Por ejemplo, si es importante para el cliente que el sistema imprima informes, entonces esa tarea debiera estar incluida en uno o ms casos de uso.

2. Un caso de uso describe algo que el diseador estara orgulloso de hacer y que el
cliente estara dispuesto a pagar con gusto

Cada caso de uso debiera describir algo que es beneficioso para el usuario. Por ejemplo, producir un informe de venta suena como un buen caso de uso, mientras seleccionar una impresora es un caso de uso demasiado pequeo y no slo es beneficioso para el usuario final.

3. Un caso de uso describe una manera tpica


de usar el sistema, pero no ms.

El caso de uso debiera describir la manera recomendada para ejecutar una tarea. No debera cubrir temas que quedan fuera de su incumbencia ni tratar de definir todas las posible formas de ejecutar la tarea. Otras maneras de usar el sistema se describe en otro caso de uso o en la seccin de Excepcin del caso de uso en cuestin.

4. Un caso de uso es una actuacin

Un caso de uso es como el manuscrito de un obra de teatro que describe lo que debe hacer un actor en un escenario dado. El que tome el lugar de un actor debe ser capaz de jugar su rol. El sistema juega el rol de otro actor. El caso de uso no debe dar demasiada libertad a los actores como para que el acto termine en un caos.

5. Un caso de uso tiene un comienzo, un cuerpo principal, y un final.

Cada caso de uso debiera ser una historia completa. El comienzo de la historia define las precondiciones y entrega una lista de los pasos iniciales del caso de uso. El cuerpo principal describe la funcionalidad que el cliente pagara con agrado. La parte final describe pasos con los cuales se termina la historia. Un caso de uso sin estas caractersticas es probablemente demasiado dbil.

6. Un caso de uso es como un ensayo escrito por un estudiante de escuela bsica.

A cierta edad los nios tienden a escribir historias que describen el flujo explcito de las acciones, una despus de la otra, eso es exactamente lo que un caso de uso debera hacer.

7. Un caso de uso cabe en una pgina

Los casos de uso grandes son difciles de comprender ya que, o son demasiado detallados, o intentan cubrir demasiada funcionalidad. En el ltimo caso el problema se puede resolver quebrando el caso de uso en dos o ms casos de uso.

8. Un caso de uso es fuerte y claro

Cada caso de uso debe hacer afirmaciones claras y explcitas para que cuando la gente lo lea, se pueda formar opiniones fuertes. Un caso de uso debe motivar a los clientes a mejorar el sistema argumentando, discutiendo, hasta lograr un acuerdo con el caso de uso. Si nadie est en desacuerdo con la primera versin de un caso probablemente es demasiado vago o debera ser ms explcito.

9. Los clientes y diseadores de software pueden firmar el caso de uso

Cada caso de uso debera ser concreto y claro para que los clientes y los diseadores lo puedan firmar. Los casos de uso actan como un contrato entre los clientes y los desarrolladores. Nadie debera hacer alguna modificacin a los casos de uso sin la aprobacin de todos.

10. Un caso de uso puede ser usado en el desarrollo y la prueba del sistema

Los casos de uso no se usan en forma aislada. Los casos de uso deberan especificarse para ser usados en las siguientes fases del proceso, por ejemplo, en la fase de anlisis de objetos y la fase de anlisis de comportamiento. Si los casos son suficientemente explcitos ellos se pueden usar como una base para la prueba del sistema.

Sistema de Mensajes Cortos (SMC) (Un ejemplo)


Requerimiento funcional:
El usuario puede enviar mensajes cortos desde un PC mediante un telfono mvil adherido

Ejercicio: escribir un caso de uso que describa el cmo toma lugar este envo Titular el caso de uso: Enviando un mensaje corto

Ejemplo 1

Casos de uso del SMC


Caso de uso n 1: Enviando un mensaje corto Actor: Un usuario corriente del telfono mvil Precondiciones: El usuario tiene derecho a usar el sistema. Hay nombres de destinatarios de mensajes, de grupos y frases guardadas en el sistema.

Casos de uso importantes de SMC (continuacin del c.u. n 1)


Descripcin: El usuario escribe un mensaje corto (Excepcin: carga un mensaje) y le agrega su firma al final del mensaje. El usuario selecciona dos diferentes nombres de destinatarios y dos grupos (Excepcin: no hay destinatarios ni grupos disponibles). Despus guarda el mensaje para s mismo. Luego l enva el mensaje corto a los destinatarios y grupos seleccionados. Finalmente, la aplicacin anuncia que la red ha recibido el mensaje corto.

Caso de uso importantes del SMC (continuacin c.u. n 1)


Excepciones: Carga un mensaje: el usuario carga un mensaje que estaba guardado para trabajar con l No hay destinatarios ni grupos disponibles: el usuario primero entra al sistema de informacin de nombres de destinatarios y lo usa. Poscondiciones: Mensaje corto del usuario enviado y hay una copia almacenada.

Ejemplo 2

Caso de uso clave de SMC


Caso de uso N 2: Creando y manteniendo grupos Actor: Un usuario corriente del telfono mvil
Precondiciones: El usuario tiene derecho a usar el sistema. Hay nombres de destinatarios y grupos de destinatarios guardados en el sistema

Caso de uso clave de SMC (continuacin c.u. n 2)


Descripcin: El usuario crea un nuevo grupo de destinatarios de mensajes. El/ella agrega al grupo seis nombres de destinatarios (Excepcin: los nombres necesarios no estn en el sistema). Luego el usuario elimina algn otro grupo. Despus el usuario elimina un nombre del primer grupo y le agrega dos nuevos. Finalmente, el usuario parte escribiendo un mensaje.

Caso de uso clave de SMC (continuacin 2do. Ejemplo)


Excepciones: Los destinatarios necesarios no estn en el sistema: el usuario entra la informacin de los destinatarios. Poscondiciones: Informacin de los grupos modificada y guardada.

Pre y pos condiciones


Proveen contexto a los casos de uso
Permiten conectar un caso de uso con otros casos de uso. Por ejemplo, una precondicin puede determinar que algn otro caso de uso debe ser ejecutado antes del caso de uso en cuestin.

Estudio de factibilidad
Se denomina estudio de factibilidad a la etapa en que se colectan y se analizan por primera vez los requisitos de un sistema Es una fase de clarificacin de los conceptos sobre el producto Ocurre antes de comenzar a monitorear el proceso de desarrollo.

Estudio de factibilidad
Sirve para dos propsitos:
Se colectan requisitos y se sugieren soluciones Se estima el esfuerzo de desarrollo basado en las soluciones sugeridas. Estas estimaciones son la fuente para la decisin de planificar y hacer el proyecto.

Estudio de factibilidad
Cules son los requisitos del sistema o sus mejoras? Cmo ha de funcionar el sistema para satisfacer los requisitos? Es tcnicamente posible implementar el sistema para satisfacer los requisitos? Qu tipo de soluciones diferentes de implementacin se pueden crear?

Estudio de factibilidad
Cul es la solucin ms factible, si la hay? Cunto trabajo se requiere? Dados los datos del anlisis anterior, se debera iniciar el proyecto?

Preguntas ?

También podría gustarte