INGENIERÍA DE
SOFTWARE I
Requerimientos IV – Casos de Uso
- Historias de usuarios
2013
2013 Ingeniería de Software I 2
TÉCNICAS DE ESPECIFICACIÓN DE
REQUERIMIENTOS
Casos de Uso
2013 Ingeniería de Software I 3
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
Modelo de Casos de Uso
Proceso de modelado de las “funcionalidades” del
sistema en término de los eventos que interactúan
entre los usuarios y el sistema.
Tiene sus orígenes en el modelado orientado a
objetos (Jacobson 1992) pero su eficiencia en
modelado de requerimientos hizo que se
independice de la técnica de diseño utilizada,
siendo aplicable a cualquier metodología de
desarrollo.
El uso de CU facilita y alienta la participación de los
usuarios
Whitten y Bentley
2013 Ingeniería de Software I 4
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
Modelo de Casos de Uso
Beneficios
Herramienta para capturar requerimientos funcionales.
Descompone el alcance del sistema en piezas más manejables.
Medio de comunicación con los usuarios.
Utiliza lenguaje común y fácil de entender por las partes.
Permite estimar el alcance del proyecto y el esfuerzo a realizar.
Define una línea base para la definición de los planes de prueba.
Define una línea base para toda la documentación del sistema.
Proporciona una herramienta para el seguimiento de los
requisitos.
Whitten y Bentley
2013 Ingeniería de Software I 5
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Diagrama de Casos de Uso
• Ilustra las interacciones entre el sistema y los
actores.
• Escenarios (narración del CU)
• Descripción de la interacción entre el actor y el
sistema para realizar la funcionalidad.
Whitten y Bentley
2013 Ingeniería de Software I 6
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Diagrama de Casos de Uso
• Ejemplo
Whitten y Bentley
2013 Ingeniería de Software I 7
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Caso de Uso
• Representa un objetivo (funcionalidad) individual del sistema y
describe la secuencia de actividades y de interacciones para
alcanzarlo
• Para que el CU sea considerado un requerimiento debe estar
acompañando de su respectivo escenario
Whitten y Bentley
2013 Ingeniería de Software I 8
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Actores
• Un actor inicia una actividad (CU) en el sistema
• Representa un papel desempeñado por un usuario que interactúa
(rol)
• Puede ser una persona, sistema externo o dispositivo externo que
emita un evento (sensor, reloj)
Whitten y Bentley
2013 Ingeniería de Software I 9
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Relaciones
• Asociaciones
• Extensiones (Extends)
• Uso o Inclusión (Uses)
• Dependencia (Depends)
• Herencia
Whitten y Bentley
2013 Ingeniería de Software I 10
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Asociaciones
• Relación entre un actor y un CU en el que interactúan entre sí
(1) El Actor inicia el caso de uso
(2) El caso de uso interacciona con actor
Whitten y Bentley
2013 Ingeniería de Software I 11
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Extensiones
• Un CU extiende la funcionalidad de otro CU
• Un CU puede tener muchos CU extensiones
• Los CU extensiones sólo son iniciados por un CU
Whitten y Bentley
2013 Ingeniería de Software I 12
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Uso o inclusión
• Reduce la redundancia entres dos o más CU al combinar los
pasos comunes de los CU
Whitten y Bentley
2013 Ingeniería de Software I 13
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Dependencia
• Relación entre CU que indica que un CU no puede realizarse
hasta que se haya realizado otro CU
Whitten y Bentley
2013 Ingeniería de Software I 14
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de Uso
• Elementos del Diagrama de Casos de Uso
• Herencia
• Relación entre actores donde un actor hereda las
funcionalidades de uno o varios actores
Whitten y Bentley
2013 Ingeniería de Software I 15
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Elementos del Modelo de Casos de
Uso
• Escenarios (narración del CU)
• Conceptos Generales
• Descripción de la interacción del escenario
• Descripción de eventos alternativos
Whitten y Bentley
2013 Ingeniería de Software I 16
Técnicas de
Los Especificación
nombres del o los de Requerimientos
Fecha de la última
responsables del CU modificación y la versión
Dinámicas – Casos de Uso
Nombre del CU, debe actual de CU
comenzar con un verbo y
representar la meta del CU
Actor principal que se Identificación de CU
beneficia del CU Prioridad, importancia del CU en
términos de baja media alta
La fuente define la entidad que da
origen al CU Por Ejemplo un
requerimiento
Otros actores que
intervienen en el CU
Cualquier persona que
tenga un aporte en el
Una descripción corta y desarrollo y la operación
precisa del propósito del del sistema (diferente del
CU actor)
2013 Ingeniería de Software I 17
Evento que inicia la Una restricción del estado
Técnicas de Especificación de Requerimientos
ejecución de un CU (por del sistema antes de la
ejemplo el tiempo) ejecución del CU ( por
Dinámicas – Casos de Uso ejemplo otro CU que debe
ejecutarse previamente)
Secuencia normal (sin
errores ni condiciones)
realizada por los actores y
el sistema.
Debe representar la
interacción entre el actor y
el sistema.
2013 Ingeniería de Software I 18
Describen el
Técnicas de Especificación de Requerimientos
comportamiento si ocurre
Dinámicas – Casos de Uso una excepción o variación
del curso típico
Establece la finalización
con éxito del CU
Restricción del estado del
sistema después de la
finalización exitosa del CU
Políticas y procedimientos
relacionados con la ejecución
del CU
Restricciones y especificaciones
para la implantación del CU, por
ejemplo requisitos no
funcionales
Cualquier hipótesis relevante
sobre el CU
Aspectos a tener en cuenta
antes de finalizar el CU
2013 Ingeniería de Software I 19
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
• Proceso de modelado
1. Identificar a los actores
2. Identificar los CU para los
requerimientos
3. Construir el diagrama
4. Realizar los escenarios
Whitten y Bentley
2013 Ingeniería de Software I 20
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
Proceso de modelado
1. Identificar a los actores
Dónde buscar actores potenciales:
Diagrama de contexto que identifique el alcance del sistema
Documentación o manuales existentes
Minutas de reunión
Documentos de requerimientos
Responder a:
¿Quién o qué proporciona las entradas al sistema?
¿Quién o qué recibe las salidas del sistema?
¿Se requieren interfaces con otros sistemas?
¿Quien mantendrá la información en el sistema?
Deberán nombrarse con un sustantivo o frase sustantiva
Whitten y Bentley
2013 Ingeniería de Software I 21
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
Proceso de modelado
1. Identificar a los actores
2. Identificar los CU para los requerimientos
Responder a
¿Cuáles son las principales tareas del actor?
¿Qué información necesita el actor del sistema?
¿Qué información proporciona el actor al sistema?
¿Necesita el sistema informar al actor de eventos o cambios
ocurridos?
¿Necesita el actor informar al sistema de eventos o cambios
ocurridos?
3. Construir el diagrama
4. Realizar los escenarios
Whitten y Bentley
2013 Ingeniería de Software I 22
Técnicas de Especificación de Requerimientos
Dinámicas – Casos de Uso
Conceptos importantes
Un CU debe representar una funcionalidad concreta.
La descripción de los pasos en los escenarios debe contener
más de un paso, para representar la interacción entre los
componentes.
El uso de condicionales en el curso normal, es limitado a la
invocación de excepciones, ya que este flujo representa la
ejecución del caso sin alteraciones.
Las pre-condiciones no deben representarse en los cursos
alternativos, ya que al ser una pre-condición no va a ocurrir.
Los “uses” deben ser accedidos por lo menos desde dos CU.
Whitten y Bentley
2013 Ingeniería de Software I 23
TÉCNICAS DE ESPECIFICACIÓN
DE REQUERIMIENTOS
Historias de Usuario
2013 Ingeniería de Software I 24
Técnicas de Especificación de Requerimientos
Dinámicas – Historias de usuario
• Una historia de usuario es una
representación de un requisito de
software escrito en una o dos frases
utilizando el lenguaje común del
usuario.
• Son utilizadas en las metodologías de desarrollo ágiles
(Ejemplo: XP, SCRUM) para la especificación de
requisitos
• Acompañadas de las discusiones con los usuarios y las pruebas
de validación
2013 Ingeniería de Software I 25
Técnicas de Especificación de Requerimientos
Dinámicas – Historias de usuario
• Debe ser limitada, ésta debería poder escribirse sobre una
nota adhesiva pequeña.
• Son una forma rápida de administrar los requisitos de los
usuarios sin tener que elaborar gran cantidad de
documentos formales y sin requerir de mucho tiempo para
administrarlos.
• Permiten responder rápidamente a los requisitos
cambiantes.
• Al momento de implementar las historias, los
desarrolladores deben tener la posibilidad de discutirlas
con los clientes.
2013 Ingeniería de Software I 26
Técnicas de Especificación de Requerimientos
Dinámicas – Historias de usuario
• Generalmente se espera que la estimación de tiempo de
cada historia de usuario se sitúe entre unas 10 horas y
un par de semanas
• Estimaciones mayores a dos semanas son indicativo de que la
historia es muy compleja y debe ser dividida en varias historias.
2013 Ingeniería de Software I 27
Técnicas de Especificación de Requerimientos
Dinámicas – Historias de usuario
• Si bien el estilo puede ser libre, la historia de usuario debe responder a
tres preguntas:
• ¿Quién se beneficia?
• ¿Qué se quiere?
• ¿Cuál es el beneficio?
• Esquema: Como (rol) quiero (algo) para poder (beneficio).
• Ejemplos:
• Como usuario registrado deseo loguearme para poder empezar a utilizar la
aplicación.
• Como secretaria quiero poder imprimir el listado de turnos asignados en una
fecha determinada y guardar la información de los mismos.
• Como secretaria quiero poder consultar los horarios disponibles de un médico
determinado con el fin de determinar turnos libres para dicho médico.
2013 Ingeniería de Software I 28
Técnicas de Especificación de Requerimientos
Dinámicas – Historias de usuario
• Características
• Independientes unas de otras
• De ser necesario, combinar las historias dependientes o buscar otra
forma de dividir las historias de manera que resulten independientes.
• Negociables
• La historia en sí misma no es lo suficientemente explícita como para
considerarse un contrato, la discusión con los usuarios debe permitir
esclarecer su alcance y éste debe dejarse explícito bajo la forma de
pruebas de validación.
• Valoradas por los clientes o usuarios
• Los intereses de los clientes y de los usuarios no siempre coinciden,
pero en todo caso, cada historia debe ser importante para alguno de
ellos más que para el desarrollador.
2013 Ingeniería de Software I 29
Técnicas de Especificación de Requerimientos
Dinámicas –Historias de usuario
• Características
• Estimables
• Un resultado de la discusión de una historia de usuario es la
estimación del tiempo que tomará completarla. Esto permite estimar
el tiempo total del proyecto.
• Pequeñas
• Las historias muy largas son difíciles de estimar e imponen
restricciones sobre la planificación de un desarrollo iterativo.
Generalmente se recomienda la consolidación de historias muy cortas
en una sola historia.
• Verificables
• Las historias de usuario cubren requerimientos funcionales, por lo
que generalmente son verificables. Cuando sea posible, la verificación
debe automatizarse, de manera que pueda ser verificada en cada
entrega del proyecto.
2013 Ingeniería de Software I 30
Historias de usuario – Tarjeta de historia de usuario con
prueba de aceptación
Imagen extraída de : http://www.pmoinformatica.com/2013/04/que-son-las-historias-de-usuario-7.html
2013 Ingeniería de Software I 31
Técnicas de Especificación de Requerimientos
Dinámicas –Historias de usuario
• Beneficios
• Al ser muy corta, ésta representa requisitos del modelo de
negocio que pueden implementarse rápidamente (días o
semanas).
• Necesitan poco mantenimiento.
• Mantienen una relación cercana con el cliente.
• Permite dividir los proyectos en pequeñas entregas.
• Permite estimar fácilmente el esfuerzo de desarrollo.
• Es ideal para proyectos con requisitos volátiles o no muy claros.
2013 Ingeniería de Software I 32
Técnicas de Especificación de Requerimientos
Dinámicas –Historias de usuario
• Limitaciones
• Sin pruebas de validación pueden quedar abiertas a distintas
interpretaciones haciendo difícil utilizarlas como base para un
contrato.
• Se requiere un contacto permanente con el cliente durante el
proyecto lo cual puede ser difícil o costoso.
• Podría resultar difícil escalar a proyectos grandes.
• Requiere desarrolladores muy competentes.
2013 Ingeniería de Software I 33
Bibliografía
• Libros Utilizados
• Whitten y Bentley, Análisis de Sistemas Diseño y Métodos,
Capítulo 6, Mc Graw Hill 2008.
• Mike Cohn, User Stories Applied, Addison Wesley 2004.
