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 información:
requerimientos del usuario, del dueño del negocio,
modelos del dominio, productos, etc.
 Captura de requisitos
• Se colectan requisitos brutos desde varias fuentes
• Se documentan explícitamente 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 límites técnicos a
la implementación.
 Colectando requisitos: ejemplo
Sistema de Mensajes Cortos (SMC)

• Se desea un sistema que permita al usuario de un

teléfono móvil enviar mensajes cortos a otros usuarios
de teléfonos móviles.

• ¿Cómo comunicar la idea?

Se puede crear una transparencia como la siguiente:
 Sistema de Mensajes Cortos
•Fácil edición de los mensajes
•Manejo de listas de correos
•Puede almacenar los mensajes en forma persistente

Pantalla PC
Hola,
Hola,
¿cómo estas?
¿cómo estas?
 Requisitos funcionales
1) El usuario puede enviar mensajes cortos
desde un PC a través de un teléfono móvil
adherido al PC
2) El usuario puede almacenar y cargar
números telefónicos basado en nombres de
receptores (destinatarios)
3) El usuario puede construir “listas de
correo” de múltiples destinatarios
 Requisitos funcionales
4) El usuario puede almacenar y reutilizar
dichos comunes como frases
5) El usuario puede grabar los mensajes
enviados y más tarde puede mirarlos y
reutilizarlos
 Requisitos no-funcionales
1) El sistema debe correr en plataformas
Windows y Macintosh
2) El sistema debe permitir múltiples accesos
simultáneos a los números de teléfono
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 sólo 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
comprensión común sobre el tipo de sistema
a desarrollar
 Casos de uso
• Los requisitos funcionales especifican qué debería
hacer un sistema
• Un caso de uso describe cómo el sistema y el
usuario final harían 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 cómo los actores
cooperan con el sistema.
• Un actor es típicamente un usuario en un rol
específico. También puede ser otro sistema que
pide servicios.

Los casos de uso no describen cómo 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 típico
del sistema (secuencia normal, feliz).
• Guían el diseño y la implementación final del
sistema.
• El sistema debería 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 cómo
un actor usa el sistema para obtener beneficios
concretos.

• La técnica de los casos de uso es una herramienta

para colectar y analizar diferentes formas de usar
el sistema, y entrega un medio de comunicación en
la fase de captura y análisis de los requisitos.
 Discusión de los casos de uso
• Hable con los potenciales usuarios para saber cómo
ellos podrían 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.
• Después 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 notación gráfica
• 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 creación
• La plantilla obliga a incluir los elementos más
importantes en el caso de uso
 Casos de uso
10 mandamientos para obtener buenos
casos de uso.
(Según 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 más importantes

Por ejemplo, si es importante para el

cliente que el sistema imprima informes,
entonces esa tarea debiera estar incluida en
uno o más casos de uso.
2. Un caso de uso describe algo que el
diseñador estaría orgulloso de hacer y que el
cliente estaría 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 pequeño y no sólo es
beneficioso para el usuario final.
3. Un caso de uso describe una manera típica
de usar el sistema, pero no más.

El caso de uso debiera describir la manera

recomendada para ejecutar una tarea. No
debería 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 sección de “Excepción”
del caso de uso en cuestión.
4. Un caso de uso es una actuación

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
pagaría con agrado. La parte final describe
pasos con los cuales se termina la historia. Un
caso de uso sin estas características es
probablemente demasiado débil.
 6. Un caso de uso es como un ensayo escrito por
un estudiante de escuela básica.

A cierta edad los niños tienden a escribir historias

que describen el flujo explícito de las acciones,
una después de la otra, eso es exactamente lo que
un caso de uso debería hacer.
7. Un caso de uso cabe en una página

Los casos de uso grandes son difíciles 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 más casos de
uso.
8. Un caso de uso es fuerte y claro

Cada caso de uso debe hacer afirmaciones

claras y explícitas 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 versión de
un caso probablemente es demasiado vago o
debería ser más explícito.
9. Los clientes y diseñadores de software pueden
firmar el caso de uso

Cada caso de uso debería ser concreto y

claro para que los clientes y los diseñadores
lo puedan firmar. Los casos de uso actúan
como un contrato entre los clientes y los
desarrolladores. Nadie debería hacer alguna
modificación a los casos de uso sin la
aprobación 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 deberían especificarse para ser
usados en las siguientes fases del proceso, por
ejemplo, en la fase de análisis de objetos y la fase
de análisis de comportamiento.
Si los casos son suficientemente explícitos 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 teléfono móvil adherido”

• Ejercicio: escribir un caso de uso que describa

el cómo toma lugar este envío

• Titular el caso de uso: “Enviando un mensaje

corto”
 Casos de uso del SMC

• Caso de uso nº 1: Enviando un mensaje corto

• Actor: Un usuario corriente del teléfono móvil
• Requisito de usabilidad: El usuario puede
detectar si el mensaje ha sido enviado
exitosamente.
• Precondiciones: El usuario ha sido aceptado
por el sistema. Hay nombres de destinatarios
de mensajes, de grupos y frases guardadas en
el sistema.
Casos de uso importantes de SMC
(continuación del c.u. nº 1)
Descripción: El usuario escribe un mensaje corto
(Excepción: carga un mensaje) y le agrega su firma al
final del mensaje. El usuario selecciona diferentes
nombres de destinatarios y grupos (Excepción: no
hay destinatarios ni grupos disponibles). Después
guarda el mensaje para sí mismo. Luego él envía el
mensaje corto a los destinatarios y grupos
seleccionados. Finalmente, la aplicación anuncia que
la red ha recibido el mensaje corto.
 Caso de uso importantes del SMC
(continuación c.u. nº 2)
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 información de nombres
de destinatarios y lo usa.

Poscondiciones:
Mensaje corto del usuario enviado y hay una copia
almacenada.
 Caso de uso clave de SMC
Caso de uso Nº 2: Creando y manteniendo grupos
Actor: Un usuario corriente del teléfono móvil

Precondiciones: El usuario ha sido aceptado por el

sistema. Hay nombres de destinatarios y grupos de
destinatarios guardados en el sistema
 Caso de uso clave de SMC
(continuación c.u. nº 2)
Descripción: El usuario crea un nuevo grupo
de destinatarios de mensajes. El/ella agrega al
grupo varios nombres de destinatarios
(Excepción: los nombres necesarios no están en
el sistema). Luego el usuario elimina algún otro
grupo. Después el usuario selecciona otro
grupo, elimina un nombre y le agrega dos
nuevos. Finalmente, el usuario comienza
escribir un mensaje.
 Caso de uso clave de SMC
(continuación 2do. Ejemplo)
Excepciones:
• Los destinatarios necesarios no están en el
sistema: el usuario entra la información de los
destinatarios.
Poscondiciones:
Un grupo ha sido eliminado. Hay un nuevo
grupo con varios nombres. Información de un
grupo ha sido 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 precondición
puede determinar que algún otro caso de
uso debe ser ejecutado antes del caso de uso
en cuestión.
 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 clarificación de los
conceptos sobre el producto
• Ocurre antes de comenzar a monitorear el
proceso de desarrollo.
 Estudio de factibilidad
• Sirve para dos propósitos:

– 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 decisión de planificar y hacer
el proyecto.
 Estudio de factibilidad
• ¿Cuáles son los requisitos del sistema o sus
mejoras?
• ¿Cómo ha de funcionar el sistema para
satisfacer los requisitos?
• ¿Es técnicamente posible implementar el
sistema para satisfacer los requisitos?
• ¿Qué tipo de soluciones diferentes de
implementación se pueden crear?
 Estudio de factibilidad
• ¿Cuál es la solución más factible, si la hay?
• ¿Cuánto trabajo se requiere?
• ¿Dados los datos del análisis anterior, se
debería iniciar el proyecto?