Administración de Requerimientos

con Casos de Uso ¿Qué buscamos?

La META es entregar productos de calidad

a tiempo y dentro del presupuesto que
Como mejorar la cumplan con las necesidades reales del
administración de cliente.
requerimientos en un
ambiente de equipos
Un enfoque por Casos
de Uso

Construyendo el Sistema Correcto Correctamente

Administración de Requerimientos con Casos de Uso Unidad 1 - Overview
Guía del0 Curso
 Unidad 1: Construyendo el Sistema Correcto Correctamente Espacio
Problema
del
 Unidad 2: Analizando el Problema Necesi Problema
dades
 Unidad 3: Entendiendo las Necesidades del Negocio
Caract.
 Unidad 4: Definiendo el Sistema Producto
Espacio
 Unidad 5: Refinando la definición del sistema de la
Solución
Producto a
ser
Reqs. de
 Unidad 6: Desarrollando el Modelo de Casos de Uso Software
construido

Procedimiento
de Prueba Diseño Doc
Usuario

Pag 1
Construyendo el Sistema Correcto Correctamente
 Construyendo el Sistema
Correcto
 Llegar a un acuerdo con el cliente
de lo que el sistema debe hacer
(Modelo de casos de uso)
 Asegurar que el diseño está
acorde con los requerimientos
(Modelo de diseño)
 Produzca el código fuente acorde
con el diseño (Modelo de
Implementación)
 Verifique y valide el producto
entregado contra los
requerimientos (Modelo de
pruebas)
 Construyendo el sistema
correctamente
 Tener un proceso que
proporcione un enfoque
disciplinado para asignar tareas y
responsabilidades dentro de la
organización de desarrollo
Definiciones
Requerimiento: Condición o capacidad que el sistema
debe cumplir
Administración de Requerimientos es un enfoque
sistemático para:
 Recoger, organizar y documentar los requerimientos
de un sistema y
 Establecer y mantener un acuerdo entre el cliente y el
equipo del proyecto,sobre los requerimientos
cambiantes del sistema

Ligando Requerimientos a otros Elementos del Proyecto Standish Group Report

Factores de Exito de Proyectos
Principales
1) Participación del Usuario 15.9%
Factores de
Exito en
2) Soporte Administrativo 13.9%
Proyectos
y Ejecutivo
10 10 10 3) Requerimientos Claros 11.8%

Requerimientos SEGUIMIENTO
Sin Embargo...
• Solo el 16% a tiempo y dentro del presupuesto (todas las compañías)
•Solo el 9% a tiempo y dentro del presupuesto (compañías grandes)
•53% de proyectos sobrepasaron su estimado original por 189% (+$59 billones)
•31% de proyectos fueron cancelados antes de completarse ($81 billones)

Por qué son estos datos tan malos?

Standish Group, „97

Pag 2
 Standish Group Report Los Requerimientos
Factores de Falla de Proyectos Sistema a
Principales Cliente
Factores de 1) Falta de Participación 12.8% Desarrollar
Retrasos de del Usuario La Meta
Proyectos 2) Requerimientos y Especi- 12.3%
ficaciones Incompletas
3) Requerimientos y Especi- 11.8%
ficaciones Cambiantes

Principales 1) Requerimientos Incompletos 13.1%

Factores de
Cancelación 2) Usuarios no involucrados 12.4% Verificacion de La Meta
de Proyectos Requerimientos Específica
3) Requerimientos y Especi- 8.7%
ficaciones Cambiantes

Standish Group, „97 Especificación de

Requerimientos

Qué determina la calidad? Proceso de Desarrollo de Software

Enfocarse en las Necesidades del Cliente Desarrollo en Cascada
Funcionales Conjunto de Caract. Generales
Capacidades Seguridad
Análisis del Requerimientos
Uso Factores Humanos Consistencia Problema?
Estética Documentación

Reliability Frecuencia/Severidad Predicción Diseño

De Fallas Precisión
Confiabilidad Recobro Tiempo entre Fallas
Codigo
y Pruebas Unitarias
Performance Velocidad Tiempo de
Eficiencia Respuesta
Rendimiento Uso de Recursos Integración del
Sistema

Soporte Se puede Probar Es configurable

Se puede Extender Es servicial Cuando nos dicen “Si, pero ...”? Operación y
Se puede Adaptar Es fácil de instalar Mantenimiento
Se puede Mantener Localización - países
Es Compatible Es robusto

Pag 3
 Que proceso de Desarrollo usar?
El Modelo Espiral Proceso de Desarrollo de Software
Modelo Iterativo
Iterative Process Process
Phases

C om ponents Inception Elaboration Construction Transition

Determinar
objetivos Evaluar Requirem ents
alternativas Analysis
Alternativas y
limitantes Identificar y Architecture
Cuando Anal. Riesgos
resolver riesgos Level
nos dicen Design
C lass Level
“Si, pero Anal. Riesgos

...”? Im plementation
R Prot
A Opera
Concepto Prot 1 Prot 2
cional
Test
Concepto
Supporting
Plan de Requs.
Plan del ciclo de
de
Operacion
C om ponents
vida Reqs.de
SW
Project Managem ent
Diseño
detallado Process Configuration
Plan de desarrollo Valida
y de pruebas reqs.
Codigo
Prue.
Desarrollar, preliminary iter. iter. iter. iter. iter. iter. iter.
Unit
Planear la Prue. iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Integr. verificar el
siguiente fase Implementación Acept.
producto del Iterations
siguiente nivel

Cuando nos dicen “Si, pero ...”?

El Desarrollo Iterativo
El Enfoque Iterativo Reduce Riesgos Temprano
Características Importantes
Ataca riesgos a través de progresos demostrables Waterfall
 El progreso se mide en los productos, no en estimados de ingeniería Inception
o documentación

Integración Contínua Elaboration

Releases frecuentes ejecutables

Usuario involucrado de forma contínua
Construction
Requirements Risk
Capture Analysis & Design
Planning Transition
Implementation
Initial
Planning Management
Environment Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Post-
Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration deployment

Deployment
Time
Evaluation
Test

Pag 4
 El Enfoque de Casos de Uso Qué es un Modelo?

 Un modelo es una descripción completa del sistema desde

una perspectiva particular
Use-Case Model

 “Completa” significa que no se necesita información adicional para

entender el sistema desde esa perspectiva
 Cuatro modelos serán considerados para desarrollar
verifies
nuestro sistema
realization influenced by
 Modelo de Casos de Uso
• Describe los requerimientos desde el punto de vista del usuario
 Modelo de Diseño
• Describe las clases y objetos

Design Model
 Modelo de Implementación
Objetos y clases Implementation Model Test Model
• Código Fuente
Codigo Fuente Casos y Procedimientos  Modelo de Prueba
De Prueba
• Casos de Prueba y Procedimientos

Qué es un Modelo de Casos de Uso? Modelo de Casos de Uso

Conceptos
 Un modelo de casos de uso es un modelo de las
funciones de un sistema (casos de uso) y sus alrededores
(actores).  Un actor representa una
 Los actores representan a los usuarios o cualquier sistema
entidad externa que
que interactúa con el sistema que se va a construir. interactúa con el sistema
Actor
 Los casos de uso sirven como una secuencia unificada a  Un caso de uso define
través del desarrollo del sistema una secuencia de acciones
 El mismo modelo de casos de uso se usa en la captura desarrolladas por un
de requerimientos, análisis, diseño y pruebas. Caso de sistema que conducen a
Uso un resultado observable de
El rol más importante del modelo de casos de uso es comunicar la
Funcionalidad y el comportamiento del cliente o usuario final
valor a un actor

Pag 5
Beneficios del Modelo de Casos de Uso El modelo ayuda a manejar la basura en los requerimientos

 Facilita el acuerdo con el cliente de los Necesitaré un nuevo caso de uso y

requerimientos del sistema algunos cambios a casos de uso
que ya existen...

 Utiliza terminología que el usuario entiende

 Verifica el entendimiento del desarrollador del  El cliente esta consciente de
sistema que hay un cambio en el
modelo de casos de uso.
 Identifica el rol de los usuarios del sistema  Hace el impacto de costos
 Identifica las interfases del sistema visible para el cliente

 Ayuda a verificar que todos los requerimientos Cliente

sean capturados

Desarrollo de Requerimientos Administrador del Proyecto

A través del Ciclo de Vida del Producto Observa todos los componentes del Proceso
Phases
Process El Administrador del
C om ponents Inception Elaboration Construction Transition
proyecto es le líder y
Requirem ents coordinador del
Analysis desarrollo del proyecto
Architecture
Level
Design Administrador del
C lass Level Proyecto

Im plementation Responsable de

Test
Supporting
C om ponents
Project Managem ent
Process Configuration

preliminary iter. iter. iter. iter. iter. iter. iter.

iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
PRD
Iterations
Visión y
Casos del
Negocio

Pag 6
Trabajadores en la Captura de Requerimientos
El Arquitecto
El Arquitecto es líder y
coordinador de las actividades
técnicas y resultados a lo largo
del proyecto, incluyendo
priorizar los casos de uso en la
captura de requerimientos, este
Arquitecto es una entrada esencial en la
planeación de iteraciones y
administración del alcance
Responsablede
Documento de
Arquitectura de
Software
Trabajadores en la Captura de Requerimientos
El Inspector de Requerimientos
El Inspector de Requerimientos
planea y conduce las revisiones
formales del modelo de casos de
uso, asegura su calidad. Esto
usualmente lo realiza un equipo
Inspector de
Requerimientos
Costo Relativo de Reparar
Boehm „76, 88
Trabajadores en la Captura de Requerimientos
Especificador de Casos de Uso
El Especificador de Casos de
Uso detalla las especificaciones
de parte de la funcionalidad del
sistema, describiendo la captura
de requerimientos de los casos
de uso
Especificador de
Casos de Uso
Responsable de
Casos de Uso
Paquetes de
Casos de Uso
El Costo de errores de requerimientos
Etapa
.1-.2 Requerimientos
0.5 Diseño “Los resultados
muestran una promedio
1 Codificación
de costos de 200:1 entre
2 Pruebas Unitarias encontrar errores en la
5
Pruebas de Aceptación fase de requerimientos y
20 mantenimiento del ciclo
Mantenimiento
de vida del software”
Average cost ratio 14:1
Grady 1989
Pag 7
 Introducción a la Administración de Requerimientos
Errores comunes relacionados a Requerimientos Unidad 2 - Analizando el Problema

Problema Espacio
del
Problema
Omisión Necesi
dades
Mal Ubicado
Ambiguo Caract.
Inconsistencia Producto
Espacio
Hechos Incorrectos de la Producto a
Solución ser
Reqs. de construido
Software

Procedimiento
de Prueba Diseño Doc
Usuario

Que es un problema? Pasos en el análisis del problema

“Un problema puede ser Paso 1 - Pónganse de acuerdo sobre el
problema que están resolviendo
definido como la Paso 2 - Identifique a los afectados (son
diferencia entre... los que se verán impactados por
la salida del sistema)
(Problema) Paso 3 - Defina los límites del sistema
Paso 4 - Identifique restricciones que
serán impuestas en el sistema
Las cosas como se Las cosas como se
y
perciben desean

Pag 8
 Encontrando el Problema detrás del Problema Paso 2 - Identifique los afectados
Manténgase preguntándose por que?
Diagrama de Espina de Pescado: Un método para análisis de
causa efecto en resolver nuestro problema ejemplo Identificar aquellas personas o entidades directamente
afectados por el sistema

Necesitamos
Maquinas de
Reciclar!

Enuncie las causas que contribuyen al problema identificado

Cuanto contribuye cada una?

Paso 3 - Definir los límites del sistema Paso 3 - Defina los Límites del Sistema
Otras Aplicaciones

Sepa que es lo que usted está

Usuarios construyendo y qué es lo que usted no
está construyendo
Sistemas
El Nuevo Sistema Antiguos Entienda que se necesita ahora y como la solución
evolucionará (estrategia del producto a corto y largo
plazo)
Entienda el mercado y cómo está cambiando
No “sobre-diseñe” la solución

Reportes
Comunicaciones

Pag 9
 Que es un Actor? Identifique Actores
Ejercicio
 Los actores no son parte del
sistema
 Los actores representan roles
que un usuario del sistema
puede jugar
 Un actor puede representar
un humano, una maquina u
otro sistema
 Una actor puede intercambiar
Actor información con el sistema
 Un actor puede dar
información
 Un actor puede ser un
recipiente pasivo de
información
Copyright © 1997 by Rational Software Corporation

Introducción a la Administración de Requerimientos

Paso 4 – Identifique los límites que serán impuestos a la solución
Unidad 3 - Entendiendo las Necesidades de los Afectados

Problema Espacio
del
Necesi Problema
dades
Politicas
Economicas
Ambientales Caract.
Producto
Espacio
de la Producto a
Solución ser
Reqs. de construido
Software

Tecnicas
Factibilidad
Procedimiento
de Prueba Diseño Doc
Sistema
Usuario

Pag 10
 Entendiendo las necesidades de los afectados Entendiendo las necesidades de los afectados
Cuales son las fuentes de requerimientos? Qué es importante para nuestro cliente?
Perfil de Adopción
Planes del Negocio de Tecnología
Metas personales from Crossing the Chasm
by Geoffrey Moore Late
Majority
Socios

% de Clientes Meta
Early
“Cruzando Majority
el ABISMO”
Early
Cliente Adopters
Late
Adopters

Innovators Laggers

Analista
Tiempo
Expertos INNOVADORES ADOPCION TEMPRANA MAYORIA TEMPRANA MAYORiA TARDIA REZAGADOS
•Influencia técnica •Con dinero •Pragmáticos •Conservadores •Escepticos
Reporte de Errores Analistas de la Industria
•Sin dinero •Fuertes influencias •Confiabilidad •Sensitivos a precio •Precio
Peticiones de Cambios Visitas en Sitio •Innovación discontínua •Características específicas •Soluciones completas •Simplificar
Usuarios Información Competitiva •Comodidad
Problema •Demandas

Como se ve internamente este proceso? Técnicas de Recolección

 Casos de uso (Escenarios)

Requerimientos alto nivel  Entrevistas
Especiicacion de Requerimientos  Cuestionarios
Rechazado  Talleres de Requerimientos
 Lluvia de Ideas & Reducción de Ideas
Especificacion reescrita
 Actuación de Roles o Intercambio de Roles
Rechazado  Bosquejos (Storyboards)
Cliente Reescrita de nuevo  Prototipos
Desarrollo
 Revisar Especificaciones de Requerimientos
Aprobada !

Pag 11
 Por que usar un Modelo de Casos de Uso para Palabras Claves para Casos de Uso
entender las necesidades de los afectados?
 Para llegar a un acuerdo con el cliente de lo que el  Un caso de uso describe un conjunto
Un de ejecuciones posibles del sistema
sistema debe hacer
 Una ejecución específica (instancia) del
 Para identificar quien interactuará con el sistema caso de uso caso de uso es un escenario
define una
 Para identificar las interfases que el sistema debe tener secuencia de  Un conjunto atómico de actividades
 Para ayudar a verificar que no faltan requerimientos acciones
 Para verificar que los desarrolladores entienden los desempeñadas
por un sistema  Se desarrolla completamente o ninguno
requerimientos que conducen a de sus pasos
un resultado de
valor, observable  Un conjunto de actividades, decisiones
para un actor y peticiones
 Iniciado por un actor o un reloj

Palabras Claves para Casos de Uso Actores y Casos de Uso

Definen los Límites y las Funciones
Un caso de uso
define una secuencia
de acciones

desempeñadas Describe las funciones del sistema Persona que Llamada Local
por el sistema Llama
Receptor de la
que conducen a un Llamada Internacional llamada

resultado de
valor, Para evitar casos de uso muy detallados
Cliente
observable Facturar al cliente Administrador
De Facturación
para un Un sistema telefónico simple

actor Para evitar casos de uso muy complejos

Un modelo de lo que el sistema hace y para quien lo hace

Pag 12
 Como Encontrar Actores Como encontrar casos de uso

 Pregúntese lo siguiente:  Para cada actor pregúntese lo siguiente:

 Que grupos de usuarios ayudan al sistema a realizar
sus tareas?
P  Que grupos de usuarios se necesitan para ejecutar
A las opciones mas obvias del sistema?
 Que grupos de usuarios se requieren para
S S
desarrollar las funciones secundarias tales como
O mantenimiento y administración?
S  Interactuará el sistema con otro sistema o hardware
externo?
 Nombre y describa los actores que usted
encuentre
 Cuales son las tareas primarias que el actor quiere que el
sistema desarrolle?
P  Creará, almacenará, cambiará, removerá o leerá datos en el
sistema?
A  Tendrá el actor que informar al sistema de cambios subitos
externos?
 Tendrá el actor que estar informado de ciertas ocurrencias en el
O sistema?
 Tendrá el actor que desarrollar la inicialización o terminación
S del sistema?
 Ponga un nombre y descripción breve a los casos de
uso que ha encontrado
 Describa como los actores y los casos de uso
interactúan
 Evalúe sus resultados

Identificar Casos de Uso Modelo del Diagrama de Casos de Usoç

Ejercicio Una solución simple para la Máquina de Reciclaje
A Recycling Machine

Customer Recycle Items

Operator
Print Daily Report

Change Refund Values Manager

Add New Bottle Type

Un modelo de lo que el sistema se supone que que debe

hacer (casos de uso) y los alrededores (actores)

Pag 13
 Entrevistas - La Técnica de las Entrevistas
 Una técnica directa que puede ser usada al analizar
problemas o al obtener requerimientos
 Diseñado para obtener un entendimiento de los
problemas reales y soluciones potenciales desde la
perspectiva del usuario, cliente o afectados.
Entrevistas - Preguntas libres (usuarios)
¿Quién es el cliente?
¿Quién es el usuario?
¿Que los diferencia?
¿Cuales son sus antecedentes, capacidades y
ambientes?
Gause & Weinberg, 1989
Entrevistas - Preguntas libres
 Son preguntas alto nivel, abstractas que pueden
preguntarse al inicio de un proyecto para obtener
información sobre aspectos globales del problema del
usuario y soluciones potenciales
 Preguntas libres:
• Son siempre apropiadas
• Ayudan a entender la perspectiva de los afectados
• No están influenciadas por el conocimiento de la solución
Gause & Weinberg, 1989
Entrevistas - Preguntas libres (Procesos)
 ¿ Cual es el Problema?
 ¿Cual es la razón para resolver este problema?
 ¿Existen otras razones para resolver este
problema?
 ¿Cual es el valor de una solución Exitosa?
 ¿Como se resolveria el problema de inmediato?
 ¿Como se relacionan el tiempo y el costo?
 ¿Que otras alternativas pueden existir para este
problema?
Gause & Weinberg, 1989
Pag 14
Entrevistas - Preguntas libres (Productos) Entrevistas – Meta-Preguntas
 ¿Le estoy preguntando demasiado?
 ¿ Que problema resuelve el producto?
 ¿Tienen mis preguntas relevancia?
 ¿Que problemas de negocios podria este producto
crear?  ¿Es usted la persona indicada para contestar estas
preguntas?
 ¿Existen algunos riesgos/peligros para el usuario?
 ¿Son sus respuestas requerimientos?
 ¿Cual será el ambiente del producto?
 ¿Estaría dispuesto(a) a participar en una revisión de
 ¿Cuales son las expectativas de utilidad? los requerimientos?
 ¿Cuales son las expectativas de confiabilidad?  ¿Hay algo adicional que yo debería preguntarle?
 ¿Existen requerimientos de rendimiento/precision?
Gause & Weinberg, 1989 Gause & Weinberg, 1989

Tipos de Preguntas Libres Entrevistas - Precauciones

Usuario
 Quién es el cliente?
 Quién es el usuario?
 Son sus necesidades diferentes?
 Cuáles son sus backgrounds,
capacidades, ambientes?
Proceso
 Cuál es la razón por la que se
quiere resolver este problema?
 Cuál es el valor de una solución
exitosa?
 Cómo usted resuelve el
problema ahora?
Gause & Weinberg, 1989
Producto  Trate de evitar que las personas traten de describir
 Qué problemas del negocio podría este
producto crear?
ideas o cosas que no describen con facilidad.
 En qué ambiente se usará el producto?  Evite preguntas ambiguas
 Cuáles son sus expectativas para fácil
de usar, confiable, rendimiento?  Evite preguntas que empiezan con “Por Qué..”
Meta-Preguntas  No espere respuestas simples
 Estoy preguntando demasiado?  No presione por respuestas
 Son mis preguntas relevantes?
 Es usted la persona correcta para  Escuche, escuche, escuche!!
resolver estas preguntas?
 Son sus respuestas requerimientos?
 Puedo preguntarle más preguntas
después?
 Hay algo más que yo debería Gause & Weinberg, 1989

preguntarle?

Pag 15
 Cuestionarios - Talleres de Requerimientos
 Uso común
 Reúna a todos los afectados juntos por un período
 Puede parecer científico por estadísticas intenso y enfocado
 Suele ser aplicado a temas amplios con preguntas  El facilitador conduce la reunión
claras y definidas  Todo el mundo opina
 Asume:  Los resultados son inmediatamente entregados
Preguntas relevantes pueden ser escogidas con  Proporciona un marco para aplicar otras técnicas de
anticipación. recolección de requerimientos
Redactadas para evitar ambigüedad.
 Puede ser util y poderoso , pero no substituye la
entrevista.
Gause & Weinberg, 1989

Talleres de Requerimientos Lluvia de Ideas

Pre-Taller Sesion Producción Follow-up Reglas para la Lluvia de Ideas

•Vender la idea del taller •Facilite el proceso •Crear conclusiones •Presentar  Diga el objetivo claramente
•Establecer Equipo(s) resultados
•Mantenga el Tema •Condensar la
•Administre la logística •Tome nota
Información •Determinar
siguientes pasos
 Genere tantas ideas como sea
•Suministre material con
anticipación
posible
•Prepare la agenda
 Deje volar la imaginación
 No critique ni discuta
 Mezcle y combine ideas

Pag 16
 Intercambio de Roles Bosquejos
 Permite al analista “actuar” el rol de usuario o cliente Representación grafica del sistema o
para obtener asi un punto de vista distinto del concepto a desarrollar
problema a resolver

 Técnicas
Ensayos
Análisis de Escenarios

Beneficios de los Bosquejos Bosquejos - Precauciones

• Ayuda a obtener y especificar requerimientos en una forma  Estas sesiones deben ser de ambientes donde los
fácil y amigable conceptos e ideas son faciles de crear y modificar.
•Motiva la creación de soluciones en forma creativa y  Evite ser perfeccionista. Esto no es un prototipo o
novedosa. demostración del producto real.
•Motiva a participantes a repasar conceptos y evitar
especificaciones que nadie desea.
•Asegura que las especificaciones son implementadas en
una forma accesible y efectiva
•Facilita el proceso de entrevista, evitando asi, la falta de
ideas.

Pag 17
Prototipos Los prototipos son excelentes pero...
Descartables
 Validan la factibilidad tecnológica; exponen los riesgos
potenciales
 Descartar todo exceptuando el conocimiento ganado
Evolucionario
 Demuestra la solución propuesta
 Descartar algo (guarda la tecnología central)
Prototipo Operacional
 Forma Final, funciones y tecnología
 Descartar lo menos que pueda
Davis „95 Excelente! El Faraón estará complacido de
saber que han completado la construcción bajo
el presupuesto y antes de tiempo

Definiendo el Sistema
Tip #8: Aplicación de Técnicas de Recolección Unidad 4 - Overview

ALTO “Alcanzarlos” “Maduros”

Entrevistas Análisis Orientado a Objetos
Investigación Especificación de Requerimientos Problema Espacio
Bosquejos Prototipos del
CLIENTE/ USUARIO
EXPERIENCIA DEL

Talleres de Requerimientos Casos de uso Necesi Problema

Reingeniería de Procesos del Negocio dades
Talleres de Requerimientos
Caract.
“Problema Enredado” “Vendiendo/Enseñando” Producto
Espacio
Lluvia de Ideas Prototipo Evolucionario de la Producto a
Actuación de Roles Especificación de Requerimientos Solución
Bosquejos Bosquejos
ser
Reqs. de construido
Entrevistas Casos de uso Software
Talleres de Requerimientos Reingeniería de Procesos del Negocio
Talleres de Requerimientos

BAJO Procedimiento
BAJO ALTO de Prueba Diseño Doc
EXPERIENCIA DEL DESARROLLADOR
Usuario
Adapted from Alan Davis

Pag 18
 Estructura de Requerimientos
Los métodos para administrar requerimientos Enfoque Documento de Requerimientos del producto (PRD)
/Use Case Model
Cómo detener un proyecto descarriado Documento
Método 1 De
Características
del Producto

Método 2

Modelo de Casos Especificaciones

De Uso Adicionales

Especificaciones Especificaciones Especificaciones

De Requerimientos De Diseño Documentación de
De Prueba Usuarios

El Documento de Requerimientos del Producto Documento de Requerimientos del Producto

Rol del PRD
•Documento a nivel del
sistema que describe los  Documento inicial de retroalimentación con el usuario
“que” y “por que” de un
producto o aplicación  Facilita el entendimiento del producto en sus términos más
•Se enfoca en generales
Administrador
del Proyecto •Las necesidades del  Establece el alcance general y las prioridades de las
usuario características de alto nivel
•Las Metas y Objetivos  Registra las caracterìsticas e ideas futuras
•Los ambientes de
usuario y plataformas
Un documento que permite que
•Las características del “todas las partes trabajen del mismo libro”
PRD producto
Visión y
Casos del
Negocio

Pag 19
 Documento de Requerimientos del Producto
Template
Product Requirements Document (PRD)
1. Introduction
1.1 Purpose
1.2 Product Overview
1.3 References
2. User Description
2.1 User Profiles
2.2 User Environment
3. Product Overview
3.1 Product Perspective
3.2 Summary of Capabilities
3.3 Assumptions and Dependencies
3.4 Licensing and Installation
PRD Sección 4
Atributos de las Características
 Las características tienen
atributos que proveerán
información adicional del
proyecto que puede usarse
para evaluar, dar seguimiento,
priorizar y administrar los
elementos del producto que se
implementarán
 Esta sección le proporcionará
atributos sugeridos para que
los utilice en su PRD
PRD Sección 5
Características del Producto
 Una característica es una capacidad del sistema
que va a llenar una necesidad directa del afectado
4. Product Features
5. Feature Attributes
6. Other Requirements
6.1 Applicable Standards  Ejemplos
6.2 System Requirements  El sistema de control de defectos proporcionará información para
6.3 Performance Requirements ayudar al administrador del proyecto a evaluar el estatus del
6.4 Environmental Requirements
6.5 Partner/Channel Requirements
mismo.
6.6 Supportability and Service  El ATM permitirá que el cliente transfiera fondos entre sus cuentas
Requirements
 La interfase gráfica GUI proveerá ayuda en línea
7. Documentation Requirements
7.1 User Manual
7.2 On-Line Help
7.3 Installation, Configuration, Read Me
7.4 Labeling and Packaging
El Incremento en el PRD
4. Atributos de las
Características
PRD 1.0 = General
•Estatus
+ Características de 1.0 Punto de Partida
+ Características Futuras
+
•Propuesto, aprobado,
incorporado
•Beneficio – Cuan
importante es esto para el Incremento PRD 2.0 = General
usuario o cliente
•Esfuerzo
Nuevas Características Información que Cambia
- Características Eliminadas
•Riesgo
+ Características Futuras
•Estabilidad
•Release meta a
====================
implementar
Toda la definición del
•Asignado a
producto
•Razón
Pag 20
Como describir el Modelo de Casos de Uso El Modelo del Diagrama de Casos de Uso
está basado en texto
A Recycling Machine
 Divida el modelo en paquetes con actores y
casos de uso Modelo de Casos de Uso
Customer Recycle Items
P
-Descripción resumen

 Cree diagramas del modelo de casos de uso

-Lista de actores
-Lista de todos los casos de
A uso Operator
Print Daily Report
 Desarrolle un resumen del modelo de casos de
S uso
O Añadir nuevo tipo de botella
 Involucre a las partes externas tales como al Reciclar Artículos -Descripción Breve Change Refund Values Manager
S -Descripción Breve -Flujo de Eventos
cliente y usuarios en revisiones informales del -Flujo de Eventos

modelo Add New Bottle Type

Cambiar valores de Retorno

-Descripción Breve
-Flujo de Eventos

Resumen del Modelo de Casos de Uso Ejemplo de Resumen del Modelo de Casos de Uso
El Modelo de Casos de Uso
es un modelo de las
Resumen del Modelo de Casos de funciones que el sistema
Uso debe hacer y su ambiente  Resumen descriptivo del Modelo de la Maquina de Reciclar
1. Introducción sirve como un contrato entre  Este modelo contiene tres actores y tres casos de uso. El caso de
Propósito del sistema el cliente y los uso principal es RECICLAR ARTICULOS, el cual representa el
2. Resumen desarrolladores; este modelo propósito principal de la Maquina de Reciclaje
Resumen de actores y casos de uso
es la fuente esencial de las
3. Paquetes de Casos de Uso actividades de analisis,  Los casos de uso de apoyo son:
Los paquetes en el modelo, representan la diseño y pruebas.
jerarquía.  Imprimir el Reporte Diario, el cual permite que un operador
4. Actores
El Resumen del Modelo de obtenga un reporte de cuantos artículos han sido reciclados y
Nombre y descripción breve de cada actor Casos de Uso le da un
y sus asociaciones overview funcional completo  Administrar los artículos reciclados, el cual permitirá que el
5. Casos de Uso del modelo Operador cambie el valor de retorno de un tipo de artículo a
Nombre y descripción breve de cada caso
de uso y sus asociaciones depositar o añada nuevos tipos de artículos a depositar
Anexos Una lista de todos los actores
Relaciones Una lista de todos los casos
Diagramas de uso
Vistas de los casos de uso

Pag 21
 Propiedades de un Actor en el Breves Descripciones de Actores
Resumen del Modelo de Casos de Uso Ejemplos
 Cliente
 Las propiedades del Actor incluyen:  El Cliente colecciona botellas y latas en su casa y las lleva
a la tienda para obtener un reembolso.
 Nombre
 Descripción Breve  Operador
• Que o quien representa el actor  El Operador es responsable de mantener la máquina de
• Por que se necesita el actor reciclaje.
• Que interés tiene el actor en el sistema
• Pocas líneas solamente
 Administrador
 Los actores también aparecen en diagramas que  El Administrador es responsable de atender las preguntas
muestran como el actor interactúa con casos de uso relacionadas al dinero y el servicio que la tienda
proporciona a sus clientes.
en el modelo

Propiedades de un Caso de Uso en el Como debo llamar a un Caso de Uso?

Resumen del Modelo de Casos de Uso
 Cada caso de uso debe tener un nombre que
indique lo que se logra con sus interacciones con los
 Las propiedades del Caso de Uso incluyen: actores
 Nombre  Ejemplos de Variaciones
• Reciclar artículos
 Descripción Breve • Recibir artículos a depositar
• Descripcion corta del rol y propósito del caso de uso • Recibiendo artículos a depositar
 Flujo de Eventos • Retornar artículos a depositar
• Depositar Artículos
• Un listado del flujo de eventos, en un formato de paso a paso

 Relaciones  Cuales variaciones muestran el valor al actor?

• Comunicaciones y asociaciones desde y hacia actores
Cuales no? Cual escogería usted como nombre del
caso de uso? Por que?
 Estas y otras propiedades se describirán
completamente en el Reporte de Casos de Uso

Pag 22
 Asociaciones
Descripción Breve de Casos de Uso Interacciones entre Actores y Casos de Uso
Ejemplos
Asociación – Comunicación
•Una línea o flecha entre el actor y el caso de uso indica
La descripción corta refleja el rol y el propósito del caso de uso que ellos interactúan enviando señales uno al otro.
Ejemplos:
 Reciclar artículos
 El usuario utiliza esta máquina para contar de forma Recycle Items
automatica, los artículos que va a devolver para reciclarlos
(botellas, latas y recipientes) y obtener un recibo. Este
recibo lo deberá llevar a la caja registradora para que sea
Operator
Print Daily Report
cambiado.
 Agregar un nuevo tipo de botella Maquina de reciclaje

 Nuevas clases de botellas pueden agregarse a la máquina

en su “modo de aprendizaje” e insertar 5 ejemplos del
artículo nuevo. De esta forma la máquina puede medir las
botellas y aprender a identificarlas. El administrador
identifica el nuevo valor del nuevo tipo de botella

Que Indica la Flecha? Cada caso de uso define una secuencia de interacciones
Presione el botón Start

Maquina lista

Primera Botella
La flecha de comunicación indica cual
fue el actor que inició el caso de uso
Maquina lista

Próxima botella

Alarma, botella atorada

Problema Arreglado

Un Sistema
Para cada flecha de comunicación, se asume
que un mensaje de retorno se brinda. Una secuencia de interacciones del sistema con los
Una línea sin flecha asume que hay actores que lograrán el resultado para el actor
comunicación en dos vías (algunas veces designado como el actor principal)

Pag 23
Un escenario – Una ruta a través del Caso de Uso
•Un caso de uso puede tener muchas instancias
•Un escenario es una instancia de un caso de uso:
una secuencia de acciones específicas que ilustra
los comportamientos del sistema
Reciclar
Cliente
Artículos
Operador
Ejercicio en Clase
 Al principio de cada semestre, el encargado de registro
proveerá una lista de cursos a todos los estudiantes a
través del nuevo sistema de registro en línea. La
información de cada curso y de profesores tal como
departamento y prerrequisitos será incluida para asistir a los
estudiantes a tomar una decisión.
 El nuevo sistema permitirá a los estudiantes revisar los
cursos disponibles y seleccionar 4 para el nuevo semestre.
Adicionalmente cada estudiante indicará dos opciones
alternas en caso de que sus otras opciones se llenen o
cancelen. Ningún curso tendrá menos de tres estudiantes,
Si un curso tiene menos de tres estudiantes será cancelado.
Si hay suficiente interés en el curso, una segunda oferta se
abrirá.
Casos de uso especiales que no se deben olvidar
 Encendido y apagado del sistema
 Mantenimiento del sistema
 Mantenimiento de la información
 Trabajos automáticos de chequear la base de datos – esto es
usualmente una caja blanca en la descripción del sistema –
muchos detalles internos de la base de datos están en este caso
de uso (No se trabaja en este caso de uso en las primeras
iteraciones).
 Añadir nueva funcionalidad al sistema
 Importante para sistemas en tiempo real donde no hay tiempo de
caídas posibles
 Portar el sistema a un nuevo ambiente
 Casos de uso en el cual la organización de desarrollo de sistemas
es el actor.
Ejercicio (continuación)
 Los profesores deben poder accesar el sistema en línea para indicar
cuales cursos van a dictar. Ellos también necesitarán ver cuales
estudiantes se han registrado para sus cursos.
 El proceso de registro durará 3 días. El primer día se dará
orientación y registro a los novatos. Todos los demás estudiantes
llegarán el segundo día de registro. El tercer día se utilizará para
resolver conflictos en las asignaciones de cursos.
 Una vez se complete el proceso de registro para un estudiante, el
sistema de registro le envía la información al sistema de Facturación,
para que se le cobre al estudiante por el semestre.
 Mientras el semestre progresa, los estudiantes tendrán acceso al
sistema en línea para agregarse o salirse de cursos.
Pag 24
Solución simple – Sistema de Registro de Cursos Evite descomposición funcional
Asignar y modificar
Información de Profesores  Síntomas  Acciones
 Casos de uso pequeños  Busque un contexto amplio
Revisar y Registrar y alterar
Información de Cursos  Muchos casos de uso  Pregúntese por que estoy
Seleccionar
cursos
Encargado
del Registro  Dificultad para entender el construyendo este sistema?
modelo  Pregúntese Qué quiere
 Nombres como: operación, lograr el usuario cuando
Resolver conflictos
De registro Transferir
objeto, función o datos este usando este sistema?
Estudiante Alterar su selección Información de Cobro
De cursos • Por ejemplo “Inserte Tarjeta”  Póngase en el rol del
usuario: Que valor dará el
caso de uso?
Generar la Sistema de
Lista de la clase Facturación

Ingresar sus Profesor

Cursos para el
Nuevo semestre

Describiendo un Caso de Uso – Flujo Basico Identificar Flujos Alternos

 Reciclar Artículos Usualmente está escrita  Propósito
a mano en este punto
 Descripción Corta  Encontrar todos los escenarios posibles del caso de uso
 El cliente utiliza esta máquina para contar automáticamente los  Listar todas las preguntas para hacer al usuario
artículos (latas, botellas y recipientes) y obtener un recibo. El  Procedimiento
recibo se cambia en la caja.
 Trabaje en papel con los usuarios
 Flujo de Eventos Borrador  Pregúntese: que puede salir mal?
1. El cliente presiona el botón START  Pregúntese: que puede “no” pasar?
2. El cliente deposita los artículos a reciclar
 Pregúntese: que clase de recursos pueden estar bloqueados?
3. El sistema revisa el tipo de artículo insertado
 Enumérelos A1, A2, A3 en adelante
4. Incrementa el total del día para cada tipo de artículo recibido
 Usted puede escribirlos en detalle pero usualmente es suficiente
5. El cliente presiona el botón recibo solo identificarlos
6. El sistema imprime el recibo

Pag 25
Caso de Uso – Diferentes Flujos de Eventos Ejercicio Escribiendo su Paso a Paso
•Para cada caso de uso de su modelo, escriba el
paso a paso de su flujo de eventos

Nombre del Caso de Uso

 Tenga uno normal, flujo básico
(escenario del día feliz!)
Descripción corta del caso de uso
 Varios flujos alternos
Flujo Básico
 Variantes regulares A1 Flujo Alterno 1
 Casos extraños 1 Primer paso
A2 Flujo Alterno 2
 Flujos excepcionales para 2 Segundo paso
manejar situaciones de error A3 Flujo Alterno 3
3 Tercer Paso

Ejemplo
Escribir un mensaje en foro
Flujo normal:
1. El usuario pulsa sobre el botón para crear nuevo mensaje
2. El sistema mustra la caja de texto para introducir
El título del mensaje y una zona de mayor tamaño para
introducir el cuerpo del mensaje
3. El usuario introduce el título del mensaje y el curpo
del mismo
4. El sistema comprueba la validez de los datos y los
Almacene
Flujo Alterno
4. El sistema comprueba la validez de los datos, si no son
correctos, lo notifica al usuario para que los corrija

Pag 26