7 Tema3

Anlisis y
Especificacin de Requisitos
Parte I. Introduccin a la
Ing. de Requisitos. Casos de
Uso
Introduccin a la Ingeniera de Requisitos
Qu entendemos por requisito?
Rational:
Una condicin o capacidad que el sistema en construccin
debe cumplir
IEEE:
Una funcionalidad del software necesaria para que el
usuario resuelva su problema o cumpla sus objetivos
Una caracterstica/funcionalidad del software que debe ser

cumplida por un sistema o componente de ste para
satisfacer un contrato, especificacin, estndar u otra
documentacin formalmente impuesta
Un punto importante
Un requisito slo estar correctamente definido si es
posible medir sus cumplimiento de alguna forma
Departamento de Lenguajes y Ciencias de la 3

Computacin.
Verificacin de requisitos
La verificacin de los requisitos se realiza en cuanto se

empieza a escribir
Su primera prueba es determinar si se puede cuantificar
un requisito especificando un criterio conveniente
Un criterio conveniente es una medida objetiva del
significado del requisito; es el criterio para evaluar cuando
una solucin satisface el requisito.
Si no se puede especificar un criterio conveniente para
un requisito, entonces se considera que ese requisito
es ambiguo y no hay forma de saber si una solucin
cumple con un requisito.

Computacin.
Curso 02/03

El cumplimiento de los requisitos define el xito
o fallo del proyecto, luego:
Hay que identificarlos
Escribirlos
Organizarlos
Seguir o trazar los posibles cambios
El Manejo de Requisitos tiene como objetivos
llevar a cabo las anteriores actividades
Ms formalmente el Manejo de Requisitos es:
Una forma sistemtica de descubrir, organizar y
documentar los requisitos del sistema
Un proceso que establece y mantiene un consenso
entre el cliente y el grupo del proyecto en el cambio de
los requisitos del sistema

Computacin.
Curso 02/03

El trmino Ingeniera de Requisitos es ms
general e incluye:
Tcnicas para Descubrimiento/Recogida de Requisitos
Hace referencia al trmino ingls ELICITATION, que cubre
las actividades destinadas a recoger las peticiones del
usuario y determinar las verdaderas necesidades de ste
Tcnicas de Anlisis
Especificacin y verificacin
Manejo de Requisitos

Computacin.
Curso 02/03
Problemas del Manejo de Requisitos

El problema bsico es cmo definir un proceso
que nos asegure que el sistema ser finalmente
lo que se espera que sea.
No es fcil:
El 85% de los fallos en los proyectos vienen derivados
de una incorrecta interpretacin de los requisitos.
Los fallos ms comunes en la interpretacin son:
No se pueden trazar los cambios (71%)
Son difciles de escribir (70%)
Deslizamiento de nuevas caractersticas (67%)
No estn bien organizados (54%)

Computacin.
Curso 02/03
Problemas del Manejo de Requisitos

Una lista ms completa:
Los requisitos no son siempre obvios y vienen dados por
distintas fuentes
No son fcilmente expresables textualmente
Hay muchos tipos de requisitos, con muy distintos niveles
de detalle
Su nmero puede ser inmanejable si no se controla
adecuadamente
Los requisitos se relacionan entre si y con otros elementos
de los proyectos
No todos los requisitos son igualmente importantes, ni
tienen la misma dificultad
Hay muchas partes interesadas y pueden ser manejados
por grupos multidisciplinares
Los requisitos cambian
Pueden ser dependientes del tiempo

Computacin.
Curso 02/03
Claves del Manejo de Requisitos

Existen unos puntos clave que ayudan a tratar
los problemas anteriores.
Los vamos a presentar en el orden en que se
deberan tener en cuenta en la primera iteracin
de un nuevo proyecto:
Anlisis del Problema
Comprensin de las necesidades de los distintos
participantes
Definicin del sistema
Control del alcance del sistema
Refinamiento de la definicin del sistema
Control del cambio en los requisitos

Computacin.
Curso 02/03

Sus objetivos son:
Entender los problemas del negocio/entorno
Centrarse en las necesidades iniciales de los participantes
Entendemos por participantes no slo los usuarios o clientes,
sino a cualquier persona, entidad,... que pueda verse afectada
por el proyecto
Proponer soluciones de alto nivel
Es necesario llegar a un acuerdo entre todos los
participantes sobre cuales son los problemas reales y
quienes son los participantes involucrados
Se deben definir fronteras y restricciones iniciales,
tanto tcnicas, como desde la perspectiva del negocio

Computacin.
Curso 02/03

participantes

Computacin.
Curso 02/03

Comprensin de las necesidades de los
participantes
Los requisitos provienen de muchas fuentes distintas
En realidad, de cualquiera con algn inters en los
resultados del proyecto
Clientes (finales y/o intermedios)
Socios
Usuarios finales
Expertos en el dominio
Miembros del equipo de desarrollo
Polticas de negocio
Agencias reguladoras,...
Es necesario determinar cuales son las fuentes realmente
importantes, cmo acceder a estas fuentes y cmo
obtener al informacin

Computacin.
Curso 02/03

Si se trata de un producto interno
Los participantes deben ser, al menos:
Usuarios finales
Expertos en el dominio
Las discusiones deben centrarse en un primer momento al
nivel del dominio del negocio y no al nivel del sistema
Si se trata de un producto externo
Los requisitos deben venir principalmente del
departamento de marketing, para entender mejor las
necesidades de los usuarios
Las tcnicas para el descubrimiento de los requisitos
iniciales son comunes:
Entrevistas
Prototipos conceptuales
Cuestionarios
Anlisis de productos similares de la competencia

Computacin.
Curso 02/03

El resultado del descubrimiento de los requisitos
iniciales es:
Una lista de peticiones o necesidades
Su descripcin textual o grfica
Una asignacin inicial de prioridades
Este ser el punto de partida en el manejo de los
requisitos
La lista se formalizar en un documento o documentos
de peticiones iniciales (formato estndar) y se
introducirn en la herramienta
A partir de estos requisitos se empieza a trazar todo el
desarrollo del sistema

Computacin.
Curso 02/03

participantes

Computacin.
Curso 02/03

Definicin del Sistema
Se trata de traducir y organizar las necesidades
anteriores en una primera descripcin del sistema a
desarrollar
Esta descripcin no tiene por qu ser slo textual y
puede incluir diagramas UML, que ayuden a valorar:
Esfuerzo estimado
Riesgos tcnicos y de direccin
Alcance
En cualquier caso debe ser lo suficientemente clara y
sencilla, para que pueda ser entendida por todos los
participantes

Computacin.
Curso 02/03

Un ejemplo:
Para realizar una llamada externa, el usuario debe

descolgar el auricular. El sistema responder con un
tono de marcado. El usuario marcar un 0. El sistema
responder con un cambio de tono....
El sistema tiene 4 estados: Inactivo, Tono de Marcado,

Tono de Marcad Externo y Conectado. Para pasar del
estado Inactivo al de Tono de Marcado, descolgar el
telfono. Para pasar de este estado al estado Tono de
Marcado Externo, marcar un 0.
Cal es mejor a este nivel?

Computacin.
Curso 02/03

participantes
Establecer el alcance del sistema

Computacin.
Curso 02/03

Se define en funcin de los requisitos asignados al

mismo
Se trata de establecer claramente que forma parte del
sistema a desarrollar y que no
Hay que definirlo en funcin de los recursos
disponibles (tiempo, personas y dinero)
Es una actividad continua que requiere un desarrollo
incremental o iterativo, que ayude a descomponer el
sistema en subsistemas ms manejables
En este punto es dnde se pueden incluir los modelos
del dominio y del negocio

Computacin.
Curso 02/03

Modelo del Dominio
Captura los requisitos ms importantes de objetos en el
contexto del sistema
Representan las cosas que existen o los eventos que suceden
en el entorno en el que trabaja el sistema
Modelo del Negocio
El modelado del negocio es una tcnica para comprender los
procesos de negocio de la organizacin
El trmino negocio no hace referencia al concepto genrico
Por ejemplo, en un sistema empotrado hace referencia al
modelo del sistema que rodea al sistema que vamos a
desarrollar:
En un sistema de control de ABS, la parte significativa del coche
que afecta a dicho sistema
En un marcapasos las partes del cuerpo humano afectadas

Computacin.
Curso 02/03

Se deben asignar atributos a los requisitos

Prioridad
Esfuerzo
Riesgo
En funcin de estos atributos se decide si un
determinado requisito es incluido o no en el sistema
Es mejor discutir sobre los atributos, en lugar de sobre
el propio requisito (ayuda a abstraernos del problema y
facilita la discusin).

Computacin.
Curso 02/03

participantes

Computacin.
Curso 02/03

Se realiza una vez que existe un acuerdo sobre la
definicin de alto nivel y el alcance inicial
Hay que llevar a cabo dos tareas paralelas
Desarrollar una descripcin ms detallada
Verificar que el sistema sigue cumpliendo con las
necesidades iniciales
Hay que tener en cuenta que la descripcin estar
destinada a audiencias muy distintas
Un error comn es describir lo que es complejo de
construir mediante una definicin compleja
Es particularmente grave si el cliente no entiende la
descripcin como para decidir si algo debe ser incluido en el
sistema o no
Hay que producir distintas descripciones del sistema para
distintas audiencias (Distintos diagramas de UML,
textual,...)

Computacin.
Curso 02/03

participantes

Computacin.
Curso 02/03

Control del cambio en los requisitos:
Independientemente de los bien especificados que
estn los requisitos iniciales, estos siempre cambian
La forma en que el equipo del proyecto se acomoda a
los cambios da una buena medida del buen desarrollo
del proyecto
El problema no es el cambio, es el cambio incontrolado
Un cambio en el requisito puede significar un cambio en
el tiempo de desarrollo y puede afectar a otros
requisitos
El control del cambio incluye actividades como:
Establecer una lnea base
Trazar la historia de cada requisito
Determinar las dependencias que hay que trazar.
Las herramientas como RequisitePro ayudan en estas
actividades

Computacin.
Curso 02/03

Es tambin importante establecer un proceso para
controlar los cambios. Un ejemplo
Entradas del cliente
y usuarios finales
Req
Nueva Marketing
Caracterstica
Control Diseo
De Nuevo
Requisito Ent. Codificadores
Cambios Ent. Pruebas
Cod.
Error
Diseo/Impl
Test Pruebas de
Peticin de usuarios finales
Cambio
Mant

Computacin.
Curso 02/03
Contenido
Introduccin a la ingeniera de requisitos

Problemas bsicos del manejo de requisitos
Conceptos bsicos: tipos de requisitos, trazabilidad y
atributos
Tcnicas y formatos para recogida de requisitos
Flujos de trabajo

Computacin.
Curso 02/03
Tipos de Requisitos
Un tipo de requisito es simplemente una clase que sirve
para agrupar un conjunto de requisitos con caractersticas
similares
Su utilidad principal es poder organizar grandes cantidades

de requisitos en grupos manejables
Tambin ayuda a revisar que el proceso de recogida ha

sido completo
La divisin de ms alto nivel es la que se realiza en:

Requisitos Funcionales
Requisitos No Funcionales

Computacin.
Curso 02/03
Tipos de Requisitos
Son el tema fundamental del sistema y son medidos por
unidades de medida concretas como valores de datos,
lgica de decisin y algoritmos
Vamos a distinguir dos tipos bsicos
Caractersticas bsicas
Su objetivo es enunciar y describir brevemente las
caractersticas funcionales del producto
Son capacidades de alto nivel necesarias para cubrir las
necesidades del clientes.
Cada caracterstica es un servicio externo solicitado del
producto, que normalmente requiere una serie de entradas
para proporcionar un determinado resultado
Casos de uso
El punto de partida inicial son las caractersticas
bsicas (FEATURES en terminologa Rational)
Computacin.
Curso 02/03
Tipos de Requisitos
Las caractersticas forman parte del Documento General de
Requisitos
Ya que este documento ser revisado por una gran cantidad
de personas, el nivel de detalle tiene que ser lo
suficientemente general para que todo el mundo lo entienda
Sin embargo, hay que proporcionar el suficiente nivel de
detalle para que el equipo de anlisis pueda crear el modelo
de casos de uso.
Como norma general, el nmero de caractersticas no debe
exceder el rango de 25-99.
Estas caractersticas van a ser fundamentales para la
definicin del producto, y de su alcance.
Cada caracterstica ser expandida, incluyendo un mayor
detalle, en el modelo de casos de uso.

Computacin.
Curso 02/03
Tipos de Requisitos
Su descripcin debe incluir su funcionalidad bsica y
cualquier aspecto relevante relacionado con ella.
Los dos siguientes puntos pueden servir de gua:

Evitar aspectos de diseo. Las descripciones deben
mantenerse a un nivel lo ms general posible.
Centrase en las capacidades que se necesitan y por qu, no
en cmo stas deben ser implementadas.
En la herramienta estos requisitos son del tipo CAR y

pueden ser manejados y seguidos de forma automtica

Computacin.
Curso 02/03
Tipos de Requisitos
Requisitos No Funcionales
Se refieren a otras propiedades que deben tener las funciones
especificadas:
Requisitos de Aspecto
Requisitos de Facilidad de Uso y Aprendizaje
Requisitos de Funcionamiento
Requisitos Operacionales
Requisitos de Mantenimiento y Portabilidad
Requisitos de Seguridad
Requisitos Culturales y Polticos
Requisitos Legales
No todos tienen que aplicarse en todos los proyectos
En nuestra plantilla de requisitos vamos a incluirlos bajo un
solo tipo de requisito como requisito adicional (ADC),
identificndolos en su descripcin
En caso de que el nmero de requisitos se vuelva no
manejable se pueden definir nuevos requisitos para algunos
de ellos

Computacin.
Curso 02/03
Tipos de Requisitos
Los tipos de requisitos en la herramienta se definen a nivel
de proyecto
Puede existir una plantilla de documento para cada tipo de
documento

Computacin.
Curso 02/03
Trazabilidad
La existencia de distintos tipos de requisitos y la
derivacin de unos a partir de otros, hace necesario que se
establezcan mecanismos de trazabilidad.
Por ejemplo:
Las peticiones de usuario (PET), estn relacionadas con las
caractersticas funcionales bsicas (CAR) y a caractersticas
adicionales (ADC)
Las caractersticas funcionales a su vez son el punto de
partida para los casos de uso
Los casos de prueba, a su vez, estn relacionados con los
requisitos a travs de la prueba de verificacin
Adems los requisitos no son independientes entre si
Para poder determinar el impacto de un cambio en un
requisito, las relaciones entre requisitos deben ser
entendidas, documentadas y mantenidas
Las herramientas como RequisitePro ayudan a mantener la
trazabilidad

Computacin.
Curso 02/03
Trazabilidad
Los mecanismos bsicos para mantener la

trazabilidad son las matrices de seguimiento
En ellas se muestra la relacin de un requisito de
un tipo con un requisito de otro tipo.
Ejemplos tpicos son:
Peticiones/Caractersticas
Caractersticas/Casos de uso
Las trazas son direccionales y se establecen
como un atributo ms de los requisitos

Computacin.
Curso 02/03
Trazabilidad

Computacin.
Curso 02/03
Trazabilidad

Computacin.
Curso 02/03
Atributos
Cada tipo de atributo puede tener un conjunto de atributos
propio
Los atributos pueden ser utilizados para crear vistas:
Caractersticas que tienen una determinada prioridad
Iteracin a la que pertenecen determinados casos de uso
Los atributos ms comunes son los siguientes:
Estado
Beneficio
Esfuerzo
Riesgo
Estabilidad
Versin objetivo
Asignada a

Computacin.
Curso 02/03
Atributos
Estado
Se asigna despus de la negociacin y debe ser
revisado por el equipo de seguimiento del proyecto.
El progreso para cada atributo se realizar despus de
la definicin de cada una de las lneas base
Propuesta Indica que una caracterstica est an bajo
discussion y que an no ha sido aceptada de
manera oficial..
Aprobada Capacidades que ya han sido aprobadas.
Incorpora Caractersticas ya incorporadas en alguna lnea

da base del producto en un punto especifico en el
tiempo.

Computacin.
Curso 02/03
Atributos
Beneficio
Atributo establecido por a nivel de direccin de
producto para determinar la prioridad de desarrollo
Crtico Caracterstica esencial. Un fallo en la
implementacin de esta funcionalidad indicar que
el proyecto no cumple las necesidades bsicas del
usuario. Un fallo en la implementacin de alguna
de estas caractersticas implicar un retraso en la
planificacin del proyecto.
Importa Caracterstica importante para la efectividad y
nte eficiencia del sistema y que no puede ser
sustituida de ninguna otra forma. Un fallo en la
inclusin de esta caracterstica puede afectar a la
satisfaccin del cliente, pero la planificacin no
til debe ser afectada..
Caractersticas tiles pero cuya funcionalidad, al
menos temporalmente, no afecta a la utilizacin
efectiva del producto. Si no est lista para la
versin planificada puede ser incluida en una
siguiente iteracin.

Computacin.
Curso 02/03
Atributos
Esfuerzo
Establecido por el equipo de desarrollo. Debe estar
medido en nmero de personas-semana, lneas de
cdigo o alguna otra mediada de complejidad. Se
utilizar para establecer la prioridad
Riesgo
Establecido por el equipo de desarrollo y basado en la
probabilidad de que el proyecto experimente problemas
no deseados durante su desarrollo (exceso de costes,
retrasos o incluso cancelacin
Se establecen normal mente tres niveles: alto, medio o
bajo, aunque se pueden utilizar graduaciones ms finas.
El riesgo puede ser inferido indirectamente midiendo la
certeza (rango) de las estimaciones de la planificacin
del proyecto por parte del equipo de desarrollo
Computacin.
Curso 02/03
Atributos
Estabilidad
Establecido por el analista y el equipo de desarrollo a partir de
la probabilidad de que la caracterstica cambia tras un anlisis
posterior de la misma
Se utiliza para establecer prioridades y para seleccionar que
requisitos deben ser analizados en prximas reuniones
Versin objetivo
Versin en la que est planificada la inclusin de esta
caracterstica
Asignada a
Persona o equipo de personas encargadas de escribir los
requisitos definitivos para esta caracterstica y probablemente
para su diseo e implementacin final
Se utiliza como base para el establecimiento de
responsabilidades

Computacin.
Curso 02/03
Atributos

Computacin.
Curso 02/03
Atributos

Computacin.
Curso 02/03
Contenido
Introduccin a la ingeniera de requisitos

Problemas bsicos del manejo de requisitos
Conceptos bsicos: tipos de requisitos, trazabilidad y
atributos
Tcnicas y formatos para recogida de requisitos

Computacin.
Curso 02/03
Documentos para Gestin de Requisitos

Aunque se utilice una herramienta de manejo de requisitos,
la descripcin textual es el punto de partida para la mayora
de los tipos de requisitos.
Existen plantillas estndar de documentos, pero estos

deben ser adaptados a las necesidades de cada empresa e
incluso de cada proyecto
Los documentos bsicos en nuestro caso van a ser los

siguientes:
Documento General de Requisitos
Documento de Solicitud de Participante
Documentos de Casos de Uso
Tres distintos, para tres tipos estndar de proyecto
Metodologa de Gestin de Requisitos

Computacin.
Curso 02/03

Denominado Vision en el Proceso Unificado
El objetivo de este documento es recoger, analizar y definir

las caractersticas y necesidades de alto nivel del sistema
Se centrar en describir las expectativas de cada una de

las partes del proyecto y de los usuarios finales y por qu
estas necesidades existen.
Los detalles de cmo el sistema cumple estas necesidades

se detallan en: los casos de uso y en las especificaciones
adicionales
Es el documento en el que se incluyen los requisitos del

tipo CAR

Computacin.
Curso 02/03

La estructura del documento es la siguiente:
1. Introduccin
2. Directivas del Proyecto
3. Descripcin de participantes y usuarios
4. Visin General del Producto
5.Requisitos Funcionales
6.Precendecia y prioridad
7.Requisitos No Funcionales
8.Requisitos de Documentacin
9. Anexo I. Atributos de las
Caractersticas Funcionales
10.Anexo II. Cuestiones Abiertas

Computacin.
Curso 02/03

Directivas del Proyecto
Oportunidad de Negocio
Describir brevemente cuales son las oportunidades de
negocio que este proyecto intenta aprovechar
Descripcin del Problema
Proporcionar una frase en la que se describa el problema
que el producto pretende solventar
Descripcin del producto
Para (clientes objetivo)

Quin (necesidad u oportunidad que
cubre)
El (nombre del Es un (categora del producto)
producto)
Que (beneficios clave)
Frente a (productos
competidores/alternativa)
Nuestro producto (caracterstica diferenciadora)

Computacin.
Curso 02/03

Descripcin de participantes y usuarios
Representante Nombre del representante del participante en el proyecto
Descripcin Breve descripcin del tipo de participante
Tipo Calificar el tipo de representante

Por ejemplo, Background tecnolgico, titulacin, etc.
Responsabilida Enumerar las responsabilidades claves del participante con respecto al

des sistema en desarrollo (es decir, sus intereses como participantes en
el proyecto)
Criterio de Qu considera el participante un xito en el proyecto desde su punto

xito de vista?. Cul es su recompensa?.
Entregables Documentos o salidas esperadas por el participante.
Comentarios Cualquier otra informacin adicional

Computacin.
Curso 02/03

Visin General del Producto
Entorno de despliegue
Entorno para la implementacin del sistema actual
Aplicaciones colaboradoras
Paquetes comerciales
Entorno fsico de trabajo
Resumen de Caractersticas Funcionales
Suposiciones y dependencias
Factores externos que tienen un efecto en el producto,
pero no son restricciones obligatorias
Suposiciones que asume el equipo sobre el proyecto
Precio y coste
Licencias e instalacin

Computacin.
Curso 02/03

Se introducen a travs de la herramienta o directamente
en el documento, pero siempre estableciendo las trazas
con la herramienta
Los atributos son los que ya se han descrito
anteriormente
Existe una seccin independiente para justificar
algunos atributos especialmente importantes, como la
prioridad y la precedencia
Requisitos Adicionales/No funcionales
Igual que en el caso anterior

Computacin.
Curso 02/03

Se trata de un documento de entrevista genrico
designado para entender los problemas del
usuario y el entorno de la aplicacin
Las cuestiones exploran aspectos como:

Funcionalidad
Usabilidad
Requisitos Adicionales
Como resultado el analista debe obtener una

visin de los objetivos que persigue el usuario
con la nueva aplicacin
Los requisitos del tipo CAR producidos por el anlisis
deben aparecer en la tabla resumen de este documento

Computacin.
Curso 02/03

Las secciones de este documento son las
siguientes:
Introduccin
Establecimiento del perfil del participante
Evaluacin del problema
Entorno de usuario
Recapitulacin
Validacin o invalidacin de suposiciones
Evaluacin de la solucin
Evaluacin de la oportunidad
Evaluacin de aspectos no funcionales
Conclusiones y Resumen del analista

Computacin.
Curso 02/03
Tcnicas para la Obtencin de Requisistos

Objetivos de aprendizaje:
Qu es?
Puntos de vista (cliente, desarrollador, ...)
Expresin de los requisitos del cliente
(notacin)
Expresin de los requisitos para
desarrolladores
Expresin de las soluciones
Validacin de los requisitos

Computacin.
Curso 02/03
Qu es el AR
Para construir algo primero hay que
entenderlo
AR: proceso de comprensin y descripcin
Regla: Comprender qu debe hacer la
aplicacin (retrasar el cmo debe hacerlo)
Es un Req: El sistema permitir al usuario
acceder a la informacin de su cuenta.
No es un Req.: Los balances se almacenarn en
una tabla llamada balanceUsu en una BD
AccessTM.

Computacin.
Curso 02/03
Qu es el AR
Excepcin a la regla: El cliente QUIERE que

se use una BD AccessTM para almacenar los
balances.
Consecuencia: hay que separar los qus de
los cmos.

Computacin.
Curso 02/03
Puntos de vista
Requisitos-C y requisitos-D
Dos visiones del mismo producto
Cliente:
Deseos y necesidades
Lenguaje
Desarrollador:
Tcnicos
Estructurados
Especficos
Nuestra labor: producir especificaciones con
los requisitos del cliente para este y para los
desarrolladores

Computacin.
Curso 02/03
Porqu escribir los requisitos?

Una especificacin escrita es til para:
Lograr el objetivo
Inspeccionar el trabajo
Probar el trabajo
Controlar la productividad
Predecir tamao y esfuerzo
Satisfacer al cliente
Sirve de contrato entre clientes y
desarrolladores

Computacin.
Curso 02/03
Proceso de anlisis de requisitos

Identificar al cliente
Entrevistarse con los Para
Paracada
cadapaso,
paso,
representantes del cliente registrar
registrarmtricas:
mtricas:
Identificar deseos y necesidades Tiempo
Tiempoempleado
empleado
Usar herramientas para la Cantidades
Cantidades
expresin Pginas
Pginasdede
Esquema del IU, identificacin requisitos-c
requisitos-c
del HW,... Tiempo
Tiempodede
interaccin
interaccin
Escribir requisitos-C en Autoevaluacin
formato estndar (IEEE, Autoevaluacinde de
la
lacalidad
calidad
RUP, ...) adaptado. Porcentajes
Porcentajesde de
Inspeccionar requisitos-C defectos
defectos
Una vez aprobados por el cliente... (inspeccin)
(inspeccin)
Desarrollar requisitos-D

Computacin.
Curso 02/03
El proceso de obtencin de requisitos

El cliente debe expresar sus deseos y necesidades
El analista debe entender el negocio del cliente
El analista debe conocer todos los actores (personas
o no) que interactuarn con el sistema
Si el cliente no conoce sus necesidades es necesario
un delicado proceso de observacin
La informacin debe estructurarse para que pueda
ser utilizada en el anlisis y diseo del sistema
Hay que descubrir las reglas de negocio (expertos)
Mantener la vista en el QU y no en el CMO
Escribir esta informacin para el cliente
Conviene realizar algn diagrama para comprender
mejor el sistema y confirmar los requisitos obtenidos
Computacin.
Curso 02/03
Casos de Uso
Se utilizan para especificar el comportamiento

deseado de un sistema o subsistema
Describe el conjunto de secuencias de acciones que
lleva a cabo el sistema para producir un resultado para
un actor.
Capturan el comportamiento deseado del sistema, sin
especificar como se lleva a cabo dicho comportamiento
Principalmente son un medio de comunicacin
para que los desarrolladores y los usuarios
lleguen a un consenso en la especificacin
Ayudan a validar el sistema durante el desarrollo

Computacin.
Curso 02/03
Casos de Uso
Los casos de uso son principalmente
descripciones textuales
La notacin grfica de UML (diagrama de
casos de uso) solo muestra los nombres y
sus relaciones
Al ser textuales, son informales y no son
buenas para razonar acerca del sistema
Para el diseo mejor utilizar los diagramas de
interaccin resultantes de su formalizacin.
Sin embargo stos dependen de los
requisitos.

Computacin.
Curso 02/03
Casos de Uso
Formas: Narrativa, Escenario, Conversacin.

Alternativas: diagramas de interaccin,
diagramas de actividades.
Fases:
1.El actor enva al sistema una peticin y los
datos necesarios para llevarla a cabo
2.El sistema valida la peticin y los datos
3.El sistema altera su estado interno
4.El sistema devuelve el resultado al actor

Computacin.
Curso 02/03
Casos de Uso
Un caso de uso es una descripcin de las

posibles secuencias de interaccin entre
el sistema y actores externos en relacin
a el objetivo de un actor particular

Computacin.
Curso 02/03
Casos de Uso
Los casos de uso se pueden detallar a muy

distintos niveles de granularidad
Se suelen distinguir los siguientes niveles:
Nivel de resumen: muestran ciclo de vida de la
secuencia de objetivos directamente relacionadas.
Se pueden considerar como una tabla de contenidos de
casos de uso de niveles ms detallados
Nivel de usuario: describen el objetivo del actor cuando
intenta llevar a cabo una accin sobre el sistema
Nivel de subfuncin: son casos de uso requeridos para
llevar a cabo los de usuario, con un mayor nivel de
detalle
Pueden ser considerados prcticamente como manuales
de operacin


Computacin.
Curso 02/03
Casos de Uso
Los casos de uso afectan a diferentes
porciones del sistema en cuestin. Este es
su mbito.
Se suelen distinguir los siguientes mbitos:

Organizacin (caja negra)
Organizacin (caja blanca)
Sistema (caja negra)
Sistema (caja blanca)
componente

Computacin.
Curso 02/03
Encontrando Casos de uso: Preguntas

tiles
Responda a las siguientes preguntas para hallar los casos
de uso:
Para cada actor identificado, Cules son las tareas en las
que el sistema estara involucrado?
El actor, crear, guardar, cambiar, eliminar o leer la
informacin en le sistema?
Cul caso de uso crear, guardar, cambiar, eliminar o
leer esta la informacin?
Necesitar el actor informar al sistema sobre cambios
externos e imprevistos?
Es necesario que el actor este informado sobre ciertas
ocurrencias en el sistema?
Qu casos de uso le darn soporte y mantenimiento al
sistema?

Computacin.
Curso 02/03
Casos de Uso
Un actor representa un conjunto coherente de

roles que los usuarios de los casos de uso
juegan al interactuar con el sistema
Normalmente representan a una persona, un dispositivo
hardware u otro sistema al interactuar con el nuestro
Se pueden definir categoras generales de
actores y especializarlos a travs de la relaciones
de generalizacin
Los actores se conectan a los casos de uso
mediante asociaciones.

Computacin.
Curso 02/03
Encontrando Actores: Preguntas tiles

Quin esta interesado en ciertos
requerimientos?
Dnde en la organizacin se usara el sistema?
Quien proveer, utilizar y eliminar esta
informacin del sistema?
Quin utilizara esta funcin?
Quien le dar soporte y mantenimiento al
sistema?
Usa el sistema un recurso externo?
Qu actores necesita el caso de uso?
Un actor desempea varios roles?
Varios usuarios desempean el mismo rol?
Computacin.
Curso 02/03
Casos de Uso

Computacin.
Curso 02/03
Diagramas de Casos de Uso
Se pueden organizar en paquetes

Se pueden especificar relaciones entre ellos:
generalizacin
extensin
inclusin
Estas relaciones se usan para:
Factorizar el comportamiento comn
extrayendo un comportamiento de los casos en que se
incluye
Factorizar variantes
poniendo ese comportamiento en otros casos de uso que
lo extienden

Computacin.
Curso 02/03

Generalizacin
El caso de uso hijo hereda el comportamiento y el
significado del caso de uso padre
El hijo puede aadir o redefinir el comportamiento del
padre
El hijo se puede colocar en cualquier lugar en que
aparezca el padre
Inclusin
El caso de uso base incorpora explcitamente el
comportamiento del caso de uso incluido
El caso de uso incluido forma parte de otro ms
complejo
Se utiliza para evitar describir flujos repetidos

Computacin.
Curso 02/03
logout
<<include>> modificar parmetros
<<include>>
acciones instructor
sesion instructor <<include>> cambiar estado
login controlCI
Instructor
control backtrack
sesin alumno

Computacin.
Curso 02/03
Extensin
Se utiliza para modelar la parte de un caso de uso que
puede ser vista como un comportamiento opcional
Tambin se pueden utilizar para modelar un subflujo
separado que solo se ejecuta bajo ciertas condiciones
Un ejemplo es el modelado de varios flujos que se puedan
dar en un punto dado por la interaccin explicita con un
actor

Computacin.
Curso 02/03
identificacin
<<include>>
Alumno sesion alumno <<include>>

<<extend>>
Accin errnea
Acciones de Alumno
Peticin de valores Activar vble dinmica
Todos los valores

Valores cambiados Seleccin

Computacin.
Curso 02/03
Nacional
<<includes>>
Marcar Nmero
<<extends>> Internacional
Realizar Llamada
Llamante
<<extends>>
<<extends>>
Numero no existe
<<extends>>
Numero Incorrecto
Comunicando
Recibir Llamada
Llamado
<<extends>> No hay linea
Llamada no atendida

Computacin.
Curso 02/03
Identificar Cliente Identificar Cliente y Cuenta en

Cajero Automtico
<<includes>>
<<includes>> <<includes>>
<<includes>>
Obtener un Balance
Ingresar Dinero Transferir Dinero Sacar Dinero
<<includes>>
<<includes>>
<<includes>>
Correo
Ciclo de Vida Cuenta
Cajero Cliente Cajero Automtico

Computacin.
Curso 02/03
Casos de Uso
Niveles:
Resumen
Ciclo de vida Cuenta
Usuario
Ingresar Dinero
Transferir Dinero
Obtener un Balance
Sacar Dinero
Subfuncin
Identificar Cliente
Identificar Ciente y Cuenta en Cajero Automtico

Computacin.
Curso 02/03
Cuestionario de Casos de Uso

Se utilizan para dar un formato uniforme a la explicacin
textual de los casos de uso
Caso
Casodedeuso:
uso:Nombre
Nombredel delcaso
casode deuso
uso
Este
Estees
esel
elobjetivo
objetivodeldelcaso
casodedeusousodescrito
descritocon
conuna
una
frase
frasecorta
corta
mbito:
mbito:LaLacaja
cajaconsiderada
considerada
Nivel:
Nivel:Uno
Unodedelos
lostres
tresniveles
nivelesdescritos
descritos
Contexto
Contextodedeuso:
uso:UnaUnafrase
frasems
mslargalargacon
conlala
descripcin
descripcindel
delobjetivo
objetivoyylas
lascondiciones
condicionesnormales
normalesde de
desarrollo,
desarrollo,precondiciones,
precondiciones,... ...
Actor
ActorPrincipal:
Principal:Un Unnombre
nombrede derolroldel
delactor
actorprincipal
principaloo
su
sudescripcin
descripcin
Escenario
Escenariodedexito
xitoPrincipal:
Principal:......
Extensiones:
Extensiones:......

Computacin.
Curso 02/03
Escenario
Escenariode
dexito
xitoPrincipal:
Principal:
Nmero_de_Paso
Nmero_de_Paso"." "."descripcin_de_accin
descripcin_de_accin
Se
Senumeran
numerantodos
todoslos
lospasos
pasosdel
delescenario
escenariodesde
desde
el
eldisparo
disparoalalobjetivo
objetivo
Se
Sepueden
puedenanidar,
anidar,utilizando
utilizandonumeracin
numeracinde de
Dewey
Dewey(3.1.2)
(3.1.2)
No
Nose
sedeben
debenincluir
incluirsentencias
sentenciascondicionales;
condicionales;las
las
condiciones
condicionesyyalternativas
alternativassesemuestran
muestranen
enlalaparte
parte
de
deextensin
extensin
Extensiones:
Extensiones:...
...

Computacin.
Curso 02/03
Extensiones:
Extensiones:
Condicin
Condicinespecial
especial":"
":" Descripcin
Descripcinde
deaccin
accin
||sub-caso
sub-casode
deuso
uso
Siempre

Siemprese
serefiere
refiereaaun
unpaso
pasodel
delescenario
escenarioprincipal
principal
Una

Unaextensin
extensinoosustituye
sustituyealalpaso
pasoprincipal
principalooes
esuna
una
alternativa.
alternativa.La
Lanotacin
notacinutilizada
utilizadaes:
es:
Sustitucin:
Sustitucin: 22||||
Alternativa:
Alternativa: 2a2a
Una

Unaalternativa
alternativapuede
puedecorresponder
corresponderaaun
un
comportamiento
comportamientoregular,
regular,excepcional
excepcionalrecuperable
recuperableoo
errneo
errneono
norecuperable
recuperable

Computacin.
Curso 02/03
Ejemplo
Caso
Casode
deuso:
uso:Ciclo
Ciclode
deVida
Vidade
deCuenta
Cuenta
mbito:
mbito:ElElsistema
sistemacompleto
completo
Nivel:
Nivel:Resumen
Resumen
Contexto
Contextode deuso:
uso:Para
Parainteractuar
interactuarcon
conelelsistema
sistemaelel
cliente
clientees
esrepresentado
representadoporporun
uncajero
cajerooopor
porcajero
cajero
automtico
automtico
Actor
ActorPrincipal:
Principal:Cliente
Cliente

Computacin.
Curso 02/03
Ejemplo
Escenario
Escenariode dexito
xitoPrincipal:
Principal:
1.1. Un
Uncliente
clienteinforma
informaal alcajero
cajerode deque
quequiere
quiereabrir
abriruna
una
cuenta
cuenta
2.2. En
Enrepresentacin
representacindel delcliente
clienteelelcajero
cajeroinicia
iniciala
la
apertura
aperturadedelalacuenta
cuentaen enelelsistema
sistema
3.3. El
Elsistema
sistemasolicita
solicitaal
alcajero
cajerola lasiguiente
siguiente
informacin:
informacin:
Nombre
Nombre
Direccin
Direccin
DNI
DNI
Tipo
Tipode
deCuenta
Cuenta
4.4. El
Elsistema
sistemavalida
validala
lainformacin
informacinyycrea creala
lacuenta
cuentadel
del
cliente
cliente

Computacin.
Curso 02/03
Ejemplo
Escenario
Escenariode
dexito
xitoPrincipal:
Principal:
Los
Lospasos
pasosdel
del55al
al88son
sonopcionales,
opcionales,individualmente
individualmenterepetibles
repetibles
yypueden
puedenocurrir
ocurriren
encualquier
cualquierorden
orden
5.5. El
Elcliente
clienteingresa
ingresadinero
dinerosub-caso
sub-casode deuso
uso
6.6. El
Elcliente
clienteobtiene
obtieneun unbalance
balancesub-caso
sub-casode deuso
uso
7.7. El
Elcliente
clientesaca
sacadinero
dinerosub-caso
sub-casode deuso
uso
8.8. El
Elcliente
clientetransfiere
transfieredinero
dinerosub-caso
sub-casode deuso
uso
9.9. Este
Estepaso
pasoseserepite
repiteindefinidamente
indefinidamenteuna unavezvezal
almes
mesdesde
desdela la
fecha
fechadedeapertura
aperturahasta
hastafecha
fechadedecierre
cierre
El
ElSistema
Sistemaenva
envapor
porcorreo
correoordinario
ordinariolalainformacin
informacinde desusu
cuenta
cuentaalalcliente
cliente
10.
10. El
Elcajero,
cajero,representando
representandoal alcliente,
cliente,inicia
iniciael
elcierre
cierrede
delalacuenta
cuenta
11.
11. El
Elsistema
sistemaelimina
eliminalalacuenta
cuenta
12.
12. El
Elsistema
sistemaenva
envaununbalance
balancecon
conlos
losltimos
ltimosmovimientos
movimientos
Computacin.
Curso 02/03
Ejemplo
Extensiones:
Extensiones:
4a.
4a.El Elsistema
sistemainforma
informaque queel
elcliente
clienteya
yatiene
tieneuna
unacuenta
cuenta
de
deeste
estetipo
tipoabierta
abierta
4a.1.
4a.1.El
Elsistema
sistemasolicita
solicitaal
alcajero
cajeroque
queconfirme
confirmela la
creacin
creacinde delalacuenta
cuenta
4a.2a.
4a.2a.ElElcajero
cajeroconfirma
confirmala lacreacin
creacinyyelelcaso
casodede
uso
usocontinua
continuapor porelelpaso
paso33
4a.2b.
4a.2b.ElElcliente
clientedecide
decidenonocrearla
crearlayyel
elcaso
casodede
uso
usofinaliza
finalizasin
sinningn
ningnefecto
efectosobre
sobreel el
estado
estado
........
........

Computacin.
Curso 02/03
Casos de Uso. Resumen
Los diagramas de casos de uso pueden ser vistos

como un mapa general de las funcionalidades ms
importantes des sistema
Deben ser lo suficientemente claros para que
alguien externo al sistema los entienda
Los casos de uso se deben utilizar para:
Modelar el contexto del sistema
Especificar las fronteras e identificar los actores
Modelar los requisitos del mismo
Especificar que debe hacer el sistema desde el punto de
vista externo

Computacin.
Curso 02/03
Casos de Uso. Resumen
Los casos de uso son la base para establecer las

pruebas del sistema
Para este cometido deben ir refinandose a lo largo del
desarrollo
Tambin pueden utilizarse en ingeniera inversa.
En este caso los pasos a seguir son:
Identificar cada actor que interacta con el sistema
Trazar el flujo de eventos del sistema ejecutable en
relacin con cada actor
Agrupar flujos relacionados en casos de uso
Organizarlos utilizando las relaciones vistas

Computacin.
Curso 02/03
Fallos Comunes
1. Lmites
2. Punto de vista
3. Actores
4. Demasiados CU
5. Telas de araa
6. Especificaciones laaargas
7. Especificaciones confusas
8. Descripcin funcional errnea
9. Ininteligibles
10. Inacabados

Computacin.
Curso 02/03
Glosario
Actor: Algo o alguien con un comportamiento.
Parte: Algo o alguien con un inters en el comportamiento del
sistema.
Actor principal: Parte que inicia una interaccin con el
sistema para lograr un objetivo.
Caso de uso: Contrato acerca del comportamiento del
sistema.
mbito: Identifica el sistema que se trata.
Precondiciones y garantas: Lo que debe ser cierto antes y
despus de la ejecucin del caso de uso.
Escenario principal de xito: El caso en que todo sale bien.
Extensiones: Variantes del EPE.
Referencias: Para referenciar un caso de uso en otro se
subraya.

Computacin.
Curso 02/03
El papel de los casos de uso en la

ingeniera de requisitos

Computacin.
Curso 02/03

Diferentes lenguajes
Diferentes necesidades
Diferentes intereses
Cmo garantizar que la traduccin es correcta?
Computacin.
Curso 02/03

Casos de Uso Colaboraciones

Computacin.
Curso 02/03

Los casos de uso:
Ayudan a razonar y a comprender el sistema
Proporcionan un lenguaje comn
Facilitan la traduccin de niveles
Constituyen un contrato
Representan requisitos
No representan todos los requisitos
(interfaces, formatos, ...)
Constituyen un elemento de enlace con otros
requisitos
Sirven para la prueba del sistema
Computacin.
Curso 02/03
Los cuatro pasos en la especificacin de un

caso de uso
1. Actores y objetivos: listar, revisar, priorizar
y asignar.
2. MSS/EPE: esquematizar y revisar.
3. Condiciones de fallo: completar EPE,
Brainstorm. Primero identificar, despus
manejar.
4. Manejo de fallos: respuestas. Trabajo sucio
y sorpresas.
Conviene calentar con una descripcin narrativa

Computacin.
Curso 02/03
Actores y partes
Los casos de uso constituyen un contrato de
funcionalidad
SUD (system under discussion) /SEC (sistema en cuestin)
Los actores tienen objetivos
Las partes tienen intereses
Cada lnea o frase de un caso de uso describe una
accin relevante para los intereses de una parte
Una lnea describe:
Una interaccin entre actores
Lo que el sistema debe hacer para proteger los intereses
de las partes

Computacin.
Curso 02/03
Actores y partes
Niveles: Las pulgas de las pulgas
Fallo: Los objetivos pueden no cumplirse
Escenario: Una interaccin compuesta (unas
circunstancias determinadas y un resultado)
Un caso de uso agrupa todos los escenarios (xito
y fallo)
La metfora de los pantalones
Un escenario puede contener subcasos de uso
(pasos).
Un paso de un escenario no depende de qu
evolucin del subcaso de uso se dio sino de su
resultado.
Computacin.
Curso 02/03
Actores y partes
El actor principal y los representantes
Importancia del actor principal Importancia
Actores Objetivos
Actores y Roles
Tabla actores/roles
Requisitos Entrega
Introduccin
Generalizacin (UML)
Descripcin de actores (nombre, alias, perfil)
Actores de Soporte
SEC
Actores Internos y Cajas Blancas

Computacin.
Curso 02/03
Ejercicio:
Qu son?
Cajero Aut.
Cliente
Tarjeta de crdito
Banco
Panel
Propietario del banco
Personal de servicio
Impresora
Sistema informtico del banco
Cajero (empleado)
Ladrn
Computacin.
Curso 02/03
Ejercicio:
Qu son?
Cajero Aut. SUD
Cliente Actor Ppal y Parte
Tarjeta de crdito No Actor
Banco No Actor
Panel Componente, No Actor
Propietario del banco Parte
Personal de servicio Actor Ppal
Impresora Componente
Sist. Inform. del banco Actor secundario
Cajero (empleado) ?
Ladrn !
Computacin.
Curso 02/03
Niveles en los objetivos del usuario

Usuario
Niveles en los CU de usuario
Resumen
Contexto, ciclos de vida, tablas de contenido
Los casos del nivel ms externo
1. Comenzar con un objetivo de usuario
2. Averiguar a qu actor A sirve este objetivo
3. Encontrar el mbito S ms externo al cual no
pertenece A (compaa, sistema informtico en
conjunto, sistema informtico en desarrollo)
4. Localizar todos los CU de A para S
5. Crear el CU de resumen (de A para S)
6. Escribir este CU

Computacin.
Curso 02/03
Niveles en los objetivos del usuario

Subfuncin
Slo deben incluirse por legibilidad
Por muy bajo que sea su nivel el actor
principal debe seguir siendo externo
Puntos importantes
Dedicar el mayor esfuerzo a los CU de usuario
Crear algunos CU de resumen para poner en
contexto los de usuario
No enfadarse porque un requisito no llegue
a CU

Computacin.
Curso 02/03
Usar el nivel adecuado

Iterar:
Qu desea realmente el actor principal?
Por qu hace esto?
Usar de 3 a 8(10) pasos (si tiene ms es seguro

que mejorar con la reduccin)
Eliminar detalles del IU
Subir el nivel
Unir pasos
Eliminar errores (continuar)
Subir el nivel: Por qu?

Bajar el nivel: Cmo?
Computacin.
Curso 02/03
Precondiciones, garantas y disparos

Precondicin: lo que debe ser cierto antes de que
un CU se ejecute
Debe ser necesaria SIEMPRE
Puede ser
Otro CU
Una condicin que se consigue en un paso de otro CU
Una condicin externa
Garanta: lo que es cierto una vez ejecutado el
caso de uso
Mnimas: se producen en cualquier caso (comprobar
con las partes)
De xito: se producen slo para los escenarios de xito
(Qu fastidiara a tal parte que sucediese (o no) en un
caso de xito?)

Computacin.
Curso 02/03
Precondiciones, garantas y disparos

Disparo: Evento que inicia el CU
Ejercicio:
Escribir las precondiciones, garantas y disparos del CU
de sacar dinero de un Caj. Aut.
Precondiciones:
Precondiciones:El Elcliente
clientetiene
tieneuna
unacuenta
cuentayy
una
unatarjeta
tarjetavlidas
vlidas
Garantas:
Garantas:
Mnimas:
Mnimas:
El
Elcajero
cajeroinforma
informadel
delsaldo
saldodisponible
disponible
El
Elcajero
cajeroproduce
produceun unrecibo
recibo(?)
(?)
De
Dexito:
xito:
El
Elcajero
cajeroentrega
entregaeleldinero
dinero
La
Lacuenta
cuentaseseactualiza
actualiza
Disparo:
Disparo:
El
Elcliente
clienteintroduce
introducesu
sutarjeta
tarjeta
Computacin.
Curso 02/03
Escenarios y pasos. Extensiones

MSS / EPE
Condiciones de ejecucin (precondiciones y
disparo)
Objetivo
Conjunto de pasos o acciones
Condicin de fin
Conjunto de alternativas (extensiones)
Cuerpo de un escenario
Cada paso describe:
Una interaccin entre dos actores (int. - ext. ?)
Validacin
Cambio de estado interno
Computacin.
Curso 02/03

Ejercicio: qu es cada paso?
1. El contable introduce los datos de la
reclamacin o el nombre y fecha del hecho
2. El sistema extrae la informacin de la pliza y de
la reclamacin
3. El contable introduce los costes
4. El sistema confirma que los costes son
conformes a la pliza y asigna un nmero d
reclamacin
5. El contable selecciona y asigna un tasador
6. El contable confirma los datos
7. El sistema salva la informacin y anota el
trabajo en la lista del tasador
Computacin.
Curso 02/03

Ejercicio: qu es cada paso?
1. El contable introduce los datos de la
reclamacin o el nombre y fecha del hecho
2. El sistema extrae la informacin de la pliza y de
la reclamacin
3. El contable introduce los costes
4. El sistema confirma que los costes son
conformes a la pliza y asigna un nmero d
reclamacin
5. El contable selecciona y asigna un tasador
6. El contable confirma los datos
7. El sistema salva la informacin y anota el
trabajo en la lista del tasador
Computacin.
Curso 02/03

Guas para escribir pasos:
Usar construcciones gramaticales simples
Sujeto...verbo...objetos
Mostrar claramente quien acta
Tomar un punto de vista elevado
Mostrar como se progresa hacia el objetivo
Mostrar la intencin del actor no sus movimientos
Incluir un conjunto razonable de acciones
Validar (no comprobar si...)
Puede mencionarse la temporizacin
Usar: El usuario hace que el sistema A (SEC)
active al sistema B
Usar: Repetir los pasos x-y hasta condicin
Computacin.
Curso 02/03
Ejercicio: criticar
Caso de uso: login
Este caso de uso describe el proceso de conexin al sistema de gestin de pedidos. Adems
establece los permisos para las diferentes categoras de actores.
EPE:
1. El caso de uso se inicia cuando el usuario inicia la aplicacin
2. El sistema presentar la pantalla de login
3. El usuario introduce su nombre y password
4. El sistema verificar la informacin
5. El sistema establecer los permisos de acceso
6. El sistema mostrar la pantalla principal
7. El usuario seleccionar una funcin
8. Mientras el usuario no seleccione SALIR hacer
9. Si el usuario selecciona Crear pedido, Usar Crear pedido
10. Si el usuario selecciona Devolucin, Usar Devolucin
11. Si el usuario selecciona Cancelar Pedido, Usar Cancelar Pedido
12. Si el usuario selecciona Obtener Estado, Usar Obtener Estado
13. Si el usuario selecciona Ver Catlogo, Usar Ver Catlogo
14. Si el usuario selecciona Queja, Usar Queja
15. Si el usuario selecciona Informe de Ventas, Usar Informe de Ventas
16. Fin Si
18. Fin Mientras
19. El caso de uso finaliza

Computacin.
Curso 02/03
Ejercicio: criticar
Caso de uso: login
Este caso de uso describe el proceso de conexin al sistema de gestin de pedidos. Adems
establece los permisos para las diferentes categoras de actores.
EPE:
1. El caso de uso se inicia cuando el usuario inicia la aplicacin
2. El sistema presentar la pantalla de login
3. El usuario introduce su nombre y password
4. El sistema verificar la informacin
5. El sistema establecer los permisos de acceso
6. El sistema mostrar la pantalla principal
8. Mientras el usuario no seleccione SALIR hacer
9. Si el usuario selecciona Crear pedido, Usar Crear pedido
10. Si el usuario selecciona Devolucin, Usar Devolucin
11. Si el usuario selecciona Cancelar Pedido, Usar Cancelar Pedido
12. Si el usuario selecciona Obtener Estado, Usar Obtener Estado
13. Si el usuario selecciona Ver Catlogo, Usar Ver Catlogo
14. Si el usuario selecciona Queja, Usar Queja
15. Si el usuario selecciona Informe de Ventas, Usar Informe de Ventas
16. Fin Si
18. Fin Mientras
19. El caso de uso finaliza

Computacin.
Curso 02/03

Extensiones: alternativas al EPE.
Condicin (deteccin) + Pasos
Los requisitos ms interesantes estn en las
extensiones
Primero listar, despus manejar
Considerar:
Escenarios de xito alternativos
El actor principal acta de forma incorrecta
El actor principal no acta
Cada paso que contenga el sistema valida
Respuesta incorrecta o nula de un actor de soporte
Fallos internos que deban detectarse y gestionarse
Fallos internos inesperados que deban tratarse
Fallos de eficiencia (velocidad) que deban detectarse
Computacin.
Curso 02/03
Cundo acabamos?
Tenemos todos los actores principales y todos los
objetivos de nivel de usuario
Tenemos todos los disparos (como disparos de CU o
como extensiones)
Hemos escrito todos los CU de usuario y los de
resumen y subfuncin que los soportan
Cada CU est descrito de forma que:
Los clientes reconocen que pueden saber si se cumplen
Los usuarios reconocen que son los que queran (o con los
que se conforman)
Los desarrolladores reconocen que pueden proporcionar
esa funcionalidad.
Los clientes reconocen que el conjunto de CU es el
que queran
Computacin.
Curso 02/03
Colaboraciones
Son el elemento bsico para describir la realizacin de un

caso de uso.
Una colaboracin permite nombrar a un bloque conceptual

que incluye tanto aspectos estticos como dinmicos
Denota una sociedad de clases, interfaces y otros

elementos que colaboran para proporcionar algn
comportamiento cooperativo mayor que la suma de los
comportamientos de sus elementos

Computacin.
Curso 02/03
Colaboraciones
Una colaboracin tiene dos aspectos:
Estructural: especifica las clases, interfaces o
componentes
Se organizan utilizando las relaciones normales de UML
(asociaciones, generalizaciones y dependencias)
Al contrario que los paquetes o subsistemas, no contienen
a sus elementos.
Puede hacer referencia o utilizar elementos declarados en
distintos sitios
Se trata de un bloque conceptual de la arquitectura del
sistema
Comportamiento: dinmica de cmo interactan estos
elementos
Se representa mediante diagramas de interaccin
Debe ser consistente con la visin estructural

Computacin.
Curso 02/03
Colaboraciones
Agente de Transporte
emisor
recibido
IDistribuido
enviarMensaje()
1
1
+Buzn 1..* 1..*
Cola Mensaje
ID
aadirMensaje() cabecera
quitarMensaje() cuerpo
contar()
colaDeEntrada colaDeSalida

Computacin.
Curso 02/03
Colaboraciones
: Mensaje : colaDeSalida : Agente de

: Actor
Transporte
1: crear
los agentes de transporte

peridicamente quitan
2: aadirMensaje
mensajes de las colas
asignadas, segn sus
3: quitarMensaje politicas de planificacin

Computacin.
Curso 02/03
Colaboraciones
Ambos diagramas deben ser consistentes

Los objetos deben ser instancias de clases
Los mensajes deben ser operaciones visibles
Puede haber ms de un diagrama de interaccin

por colaboracin, mostrando distintos aspectos
de una colaboracin
Representacin
Paso de Mensajes

Computacin.
Curso 02/03
Colaboraciones
Adems de para mostrar patrones de diseo, las

colaboraciones pueden utilizarse para mostrar la
realizacin de los casos de uso
La implementacin de un caso de uso vendr

dada por una o ms colaboraciones de los
objetos de implementacin del sistema
Se pueden representar en diagramas de casos de

uso, utilizando relaciones de realizacin y
refinamiento

Computacin.
Curso 02/03
Colaboraciones

Computacin.
Curso 02/03
Interacciones
Definicin
Una interaccin es un comportamiento que implica un
intercambio de de mensajes entre varios objetos en un
contexto determinado con un objetivo determinado
Se utilizan para expresar los aspectos dinmicos
de las colaboraciones
Las interacciones se llevan a cabo entre objetos
no entre clases
Un enlace es una conexin semntica entre
objetos
Para que se pueda enviar un mensaje entre dos objetos
debe existir un enlace
Un enlace es una instancia de una asociacin entre
clases
Computacin.
Curso 02/03
Interacciones
Persona Empresa
1..* *
Asignar(d:Departamento) empleado contratante
Asociacin
Asignar(desarrollo)
P:Persona :Empresa
Enlace

Computacin.
Curso 02/03
Interacciones
Normalmente basta con indicar que existe un enalce, pero se
puede indicar el tipo de enlace utilizando los estereotipos:
Association
Self
Global
Local
Parameter
Los mensajes tambin pueden ser ms o menos detallados
[Pre] 1:*(expr):mensaje(p,q):Valor
Precondicin Valor de
Retorno
N secuencia Parmetros
Expresin Identificador
Iteracin

Computacin.
Curso 02/03
Diagramas de Interaccin
Hay dos tipos:

Diagramas de secuencia
Diagramas de colaboracin
Son dos de los cinco que se utilizan para
modelar el comportamiento dinmico de
los sistemas
Un diagrama de interaccin consiste en:
Un conjunto de objetos (no clases) y sus
relaciones
Los mensajes que se pueden enviar entre ellos

Computacin.
Curso 02/03
Un diagrama de secuencia es un diagrama

en el que se destaca la ordenacin temporal
de los eventos
Un diagrama de colaboracin destaca la
organizacin estructural de los objetos que
envan y reciben los mensajes
Son semnticamente equivalentes
Se puede generar uno a partir del otro, sin
perdida de informacin
Visualmente, sin embargo, esta informacin
puede ser ms difcil de percibir
Computacin.
Curso 02/03
Diagramas de Secuencia
Los diagramas de secuencia se suelen asociar a los casos de uso,
mostrando como estos se realizan a travs de interacciones entre
sociedades de objetos
Consola BD
: Instructor Instructor instructores
Foco de
1: login(usuario)
2: leer(usuario) Control
Lnea de
3: usuario correcto
Vida
4: iniciar sesion
5: usuario aceptado

Computacin.
Curso 02/03
Los mensajes se Cliente Interfaz

corresponden : Alumno
Aplicacin Cliente
generalmente a 1: login
mtodos de los
objetos 2: crear sesion
Los objetos pueden 3: create

Sesion
ser creados durante
la ejecucin
En Rational Rose, la 4: logout
creacin de objetos 5: fin 6: destroy
no se puede reflejar
de la forma estndar

Computacin.
Curso 02/03

Computacin.
Curso 02/03
Diagramas de Colaboracin
Destacan la organizacin de los objetos que

participan en una interaccin
Es un grafo en el que los nodos son los objetos y

los arcos los enlaces
Los arcos se etiquetan con los mensajes que

envan y reciben los objetos
Dan una visin del flujo de control en el contexto

de la organizacin de los objetos que colaboran

Computacin.
Curso 02/03
Hay dos caractersticas que los distinguen

de los diagramas de secuencia:
El camino
Para indicar como se enlazan los objetos se utilizan
estereotipos en los extremos de los enlaces (local,
global y self)
El nmero de secuencia
Para indicar la ordenacin de los mensajes se utiliza
la numeracin decimal de Deway (1, 1.1,.....)

Computacin.
Curso 02/03

Computacin.
Curso 02/03
Equivalencia entre Diagramas
Utilizando el submenu Browse se puede generar un diagrama a partir

del otro
4: iniciar sesion
Consola BD
1: login(usuario)
Consola
Instructor 1: login(usuario)
2: leer(usuario)
5: usuario aceptado
: Instructor
3: usuario correcto
3: usuario correcto
4: iniciar sesion
2: leer(usuario)
5: usuario aceptado
BD
instructores

Computacin.
Curso 02/03
No tienen por que utilizarse slo para los

casos de uso
Son tiles para modelar aspectos dinmicos
de cualquier interaccin entre cualquier
instancia en cualquier vista del sistema
(clases, interfaces, componentes,...)
Las interacciones se pueden adornar con
restricciones temporales (marcas
temporales)

Computacin.
Curso 02/03
Consola BD
inicio 1: login(usuario)
2: leer(usuario)
3: usuario correcto
4: iniciar sesion
{Iniciar sesion.executionTime<5s}
5: usuario aceptado
fin
{inicio-fin<10s}

Computacin.
Curso 02/03
Recursos interesantes
http://www.usecases.org
http://www.object-ideas.com/oouc2/index.htm
http://www.foruse.com
http://www.pols.co.uk/usecasezone/
http://www.omg.org
http://www.software-engin.com/
http://polaris.lcc.uma.es/~amg/ISE/OOP-Java-UML.zip
Writing Effective Use Cases. Alistair Cockburn (pronunciar

cooburn). Addison-Wesley.
El Lenguaje Unificado de Modelado. Booch, Rumbaugh,
Jacobson. Addison-Wesley.
Aprenda UML en 24 Horas. Joseph Schmuller. Prentice Hall.

Computacin.
Parte II. Anlisis de
Requisitos
Departamento de Lenguajes y Ciencias de la Computacin

E.T.S. de Ingenieros en Informtica
Universidad de Mlaga
Curso 02/03
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen

Computacin.
Curso 02/03
Introduccin al Anlisis de Requisitos

Durante el anlisis se refinan y estructuran los
requisitos
El objetivo es:
Conseguir una comprensin ms precisa
Obtener una descripcin ms fcil de mantener
Estructurar el sistema, definiendo su arquitectura
El punto de partida son los elementos obtenidos
en la captura de requisitos
Documento general de requisitos
Casos de uso
Modelos del dominio y del negocio

Computacin.
Curso 02/03

El problema principal de estas descripciones es que se han realizado
con el objetivo de que sean entendibles por el cliente
A partir de estas definiciones hay que obtener una descripcin

adecuada a los desarrolladores
En el paso de una descripcin a otra es necesario resolver aspectos

relativos a los requisitos an no resueltos:
Al mantener los casos de uso lo ms independientes posible, en los

requisitos no se contemplan los aspectos derivados de las interferencias,
concurrencia y conflictos en los casos de uso
Se utiliza el lenguaje del cliente (lenguaje natural), con lo que se pierden

detalles que pueden ser clarificados con la utilizacin de lenguajes ms
formales
Los casos de uso se estructuran para que sean funciones completas e

intuitivas, sin evitar redundancias. Hay que llegar a un equilibrio entre
comprensibilidad y mantenibilidad

Computacin.
Curso 02/03

Los requisitos se estructuran de manera que nos
faciliten:
Su comprensin
Su preparacin
Su modificacin y mantenimiento
La estructura resultante es independiente de la
estructura que se dio a los requisitos, pero debe
mantenerse su trazabilidad

Computacin.
Curso 02/03

Por qu el anlisis no es diseo?
El diseo va mucho ms all del refinamiento y
estructuracin de los requisitos
En el diseo se moldea el sistema y se define la
arquitectura definitiva
Se toman decisiones acerca de cmo tener en cuenta
los requisitos de rendimiento y de distribucin
Los modelos son mucho ms abstractos (suele haber
una relacin 1 a 5 entre el nmero de elementos de los
modelos
De todas forma, el resultado final del anlisis

puede considerarse como una primera
aproximacin al diseo
Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03

El anlisis debe comenzar una vez que los
elementos bsicos de la recogida de requisitos
son ya estables:
El contexto del Sistema
Modelo del dominio
Modelo del negocio
Un modelo de casos de uso que capture los requisitos
funcionales y los no funcionales que son especficos de
casos de uso concretos
Descripcin general
Diagramas
Descripcin detallada de cada caso de uso
Una especificacin de requisitos adicionales genricos,
no dependientes de un caso de uso particular

Computacin.
Curso 02/03
Modelo del Dominio

Captura los tipos ms importantes de objetos en
el contexto del sistema
Los objetos del dominio representan las cosas que
existen o los eventos que suceden en el entorno en el
que trabaja el sistema
Aparecen en tres formas tpicas
Objetos de negocio que representan cosas que se
manipulan en el mismo, como pedidos, cuentas y
contratos (o seales de sensores externos)
Objetos del mundo real y conceptos de los que el
sistema debe hacer un seguimiento, como una
trayectoria
Sucesos que han ocurrido o ocurrirn, como la llegada
de una avin, su salida,...

Computacin.
Curso 02/03
Modelo del Dominio

Ejemplo:
El sistema utilizar Internet para enviar pedidos,
facturas y pagos entre compradores y vendedores.
El sistema ayuda:
al comprador
A confeccionar sus pedidos
A validar las facturas
A hacer efectivos los pagos de su cuenta a la del
vendedor
al vendedor a evaluarlos y a enviar las facturas
Un pedido es la solicitud de un comprador a un
vendedor de un nmero de artculos
Cada artculo ocupa una lnea en el pedido
Contiene la fecha de emisin y la direccin de entrega

Computacin.
Curso 02/03
Modelo del Dominio
Artculo
Pedido
Descricin
Fecha de emisin
Foto
Direccin de Entrega
1..n Precio
1..n +pagable
Factura
Cuenta
Cantidad +comprador
Saldo
Fecha de Emisin
Titular
Fecha Lmite de Pago 1

Computacin.
Curso 02/03
Modelo del Dominio

El objetivo del dominio es comprender y describir
las clases ms importantes dentro del sistema
Los dominios de tamao moderado normalmente
requieren entre 10 y 50 de esas clases
Las restantes cientos de clases que los analistas
pueden extraer del dominio ser guardan como
definiciones en el glosario (para mantener el
tamao del modelo manejable)
Si el dominio es simple y pequeo, el modelo del
dominio puede ser sustituido totalmente por el
glosario
Hay que evitar modelar el interior del sistema en
lugar del contexto

Computacin.
Curso 02/03
Modelo del Dominio

Las clases del dominio y el glosario se utilizan en
el desarrollo de los modelos de casos de uso y
de anlisis:
Al describir los casos de uso y al disear la interfaz de
usuario
Para sugerir clases internas al sistema durante el
anlisis

Computacin.
Curso 02/03
Modelado del Negocio

Es una tcnica para comprender los procesos de
negocio de una organizacin
El modelo de negocio comprende:
Un modelo de casos de uso con la descripcin del
negocio y sus actores
Un modelo de los objetos internos al negocio
Describe como cada caso de uso del negocio es llevado a
cabo por los trabajadores, utilizando un conjunto de
entidades de negocio
Cada caso de uso se puede describir mediante un
diagrama de interaccin o de actividad
Una entidad de negocio representa algo con lo que
interactan los trabajadores

Computacin.
Curso 02/03

Ejemplo:
Caso de uso del negocio realizar una venta
1. Un comprador solicita bienes o servicios contactando
con un vendedor
2. El vendedor enva una factura al comprador a travs del
gestor de pagos
3. El vendedor entrega los vienes o servicios al comprador
4. El comprador paga mediante el gestor de pagos. Esto
implica la transferencia de dinero de la cuenta del
comprador a la del vendedor

Computacin.
Curso 02/03
1: solicita bienes o servicios
: Comprador : Vendedor
3: Enva factura 2: Enva factura
: Gestor de Pagos
: Cuenta
: Factura

Computacin.
Curso 02/03

Un modelo de negocio se realiza en dos pasos:
Los modeladores del negocio realizan el modelo de casos de
uso del negocio
Se desarrolla un modelo de objetos del negocio a partir de los
trabajadores y entidades que participan en los casos de uso
El modelado del negocio y del dominio se parecen en
algunos aspectos
Podemos pensar en el modelo de dominio como una
simplificacin del modelo de negocio, en la que solo nos
centramos en las entidades
Sin embargo, existen algunas diferencias que aconsejan
diferenciarlos
Las fuentes de las entidades en ambos modelos son distintas
(clientes, en los casos de uso y expertos, en el caso del dominio)
Las clases del dominio tienen atributos, pero pocas operaciones,
mientras que en las clases de dominio ocurre al contrario, ya que
deben proporcionar las operaciones correspondientes a los casos
de uso

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03
El Modelo de Anlisis
Un modelo de anlisis tiene la siguiente
estructura descrita en UML
Modelo de Sistema de Paquete de

Anlisis Anlisis Anlisis
Clase de Anlisis realizacin de caso de uso

Computacin.
Curso 02/03
El paquete del sistema es el de ms alto nivel
La utilizacin de otros paquetes tiene como
objetivo organizar el modelo en partes ms
manejables que representan abstracciones de
subsistemas
Las clases de anlisis representan abstracciones
de clases y posiblemente de subsistemas del
diseo del sistema
Las realizaciones de los casos de uso se
describen mediante clases/objetos de anlisis

Computacin.
Curso 02/03
Clase de Anlisis
Se centran en el tratamiento de los requisitos
funcionales y pospone los no funcionales
Se trata de una clase evidente en el dominio del
problema (ms conceptual que las de diseo)
No contiene operaciones, ni signaturas
Su comportamiento se define mediante responsabilidades
Una responsabilidad es una descripcin textual de un
conjunto cohesivo del comportamiento de una clase
Define atributos de alto nivel (sus tipos son
conceptuales y reconocibles en el dominio del
problema)
Normalmente pasan a ser clases en el modelo de diseo
Las relaciones son conceptuales, no implican nada en
la fase de diseo e implementacin (ej. herencia)
Computacin.
Curso 02/03
Clase de Anlisis
Siempre encajan en uno de tres estereotipos bsicos:
Clase de Anlisis
Atributos de alto nivel
Responsabilidades()
Entidad Interfaz
Control

Computacin.
Curso 02/03
Clases de Interfaz
Se utilizan para modelar la interaccin entre el sistema y sus
actores (usuarios y sistemas externos)
La interaccin suele implicar recibir/presentar
informacin/peticiones de/hacia los usuarios y sistemas externos
Modelan las partes del sistema que dependen de sus actores
Clarifican y renen los requisitos en los lmites del sistema
Un cambio en un interfaz de usuario o en un interfaz de
comunicaciones queda aislado en una o ms clases de interfaz
Representan a menudo abstracciones de:
Ventanas
Formularios
Paneles
Interfaces de comunicacin
Sensores
APIS
Deben ser abstractas, describiendo solo la informacin y las
peticiones que se intercambian entre el sistema y sus actores

Computacin.
Curso 02/03
Clases de Entidad
Modelan informacin persistente
Tambin se usan para modelar la informacin y el
comportamiento asociado de algn fenmeno o
concepto del mundo real
Normalmente se derivan directamente de una clase del
modelo del negocio o del dominio correspondiente
Las diferencias son:
Que su definicin va orientada a los desarrolladores al
disear o implementar el sistema e incluye aspectos como su
soporte de persistencia
En las de dominio existe informacin del entorno del sistema
que puede no tener que manejarse en ste
Una entidad no tiene por qu ser pasiva
Pueden tener un comportamiento complejo
correspondiente a la informacin que respresentan

Computacin.
Curso 02/03
Clases de Control
Representan coordinacin, secuencia, transacciones y
control de otros objetos
Se utilizan para encapsular el control de un caso de uso
concreto
Modelan los aspectos dinmicos internos del sistema,
no los externos (interaccin con los usuarios), que son
modelados por las clases de interfaz

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03

Se trata de una colaboracin dentro del modelo
de anlisis que describe como se lleva a cabo y
se ejecuta un caso de uso en trmino de
interacciones entre los objetos de anlisis
Normalmente est compuesta por:
Una descripcin textual del flujo de sucesos
Diagramas de clases que muestran las clases
participantes
Diagramas de interaccin que muestran la realizacin
de un flujo particular del caso de uso
Se centra en los aspectos funcionales

Computacin.
Curso 02/03

Diagramas de clases
Una clase de anlisis y sus objetos pueden participar en varias
realizaciones de casos de uso
Algunas responsabilidades, atributos y asociaciones son solo
relevantes para una determinada realizacin
Diagramas de interaccin
Comenzaran siempre con un mensaje del actor a una clase
interfaz
Se suelen utilizar diagramas de colaboracin, ya que su objetivo
es identificar requisitos y responsabilidades y no identificar
secuencias detalladas de mensajes
La creacin y destruccin de las clases depender de su
estereotipo:
Algunos objetos de interfaz se crean y se destruyen en cada caso de
uso (ventanas para toma de datos)
Los objetos de entidad suelen ser comunes a varios casos de uso y
participan en varias realizaciones antes de su destruccin
Las clases de control van asociadas a los casos de uso y se crean y
destruyen al comienzo y final del mismo

Computacin.
Curso 02/03

Paquetes de anlisis
Proporcionan un medio para organizar los artefactos del
modelo de anlisis en piezas manejables
Contienen:
Clases de anlisis
Realizaciones de casos de uso
Otros paquetes de anlisis
Caractersticas
Deben ser cohesivos y dbilmente acoplados
Su creacin se basar en los requisitos funcionales y en el
dominio (nunca en los requisitos no funcionales)
Ej. Tareas crticas en tiempo y no crticas en tiempo

Computacin.
Curso 02/03

Paquetes de servicio
Aparte de proporcionar casos de uso un paquete puede
especificar un servicio
Un servicio representa un conjunto coherente de
acciones relacionadas funcionalmente, que se utiliza en
varios casos de uso
Normalmente un caso de uso se basa en la utilizacin
de varios servicios
En ocasiones se pueden identificar como conjuntos de
casos de uso del tipo sub-funcin

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03
Anlisis de la Arquitectura
Es la primera actividad para definir el modelo de
anlisis
Los pasos bsicos de esta actividad son los
siguientes:
Identificacin de paquetes de anlisis
Identificacin de clases del anlisis
Requisitos especiales comunes
El punto de partida es:
El modelo del negocio
El modelo de casos de uso
La descripcin de los requisitos adicionales obtenida en
el documento general de requisitos

Computacin.
Curso 02/03
Identificacin de paquetes del anlisis
Proporcionan un medio para organizar el modelo de
anlisis en piezas ms pequeas
Pueden identificarse:
Inicialmente como forma de dividir el trabajo de anlisis
Nos basamos en los requisitos funcionales y el dominio del
problema
Asignamos los casos del uso al paquete atendiendo a:
Su relacin en un proceso de negocio
Los necesarios para dar soporte a un actor
Los casos de uso relacionados mediante relaciones de
generalizacin y extensin
Encontrarse a medida que el modelo crece
Qu hacemos en caso de entidades/casos de uso
compartidos?
Paquete independiente
Entidad aislada, con relaciones de traza

Computacin.
Curso 02/03
Identificacin de clases de entidad
Se puede empezar con un conjunto de clases basado en
las del dominio
Se confirma su adecuacin al realizar los casos de uso
El nmero debe ser pequeo para no perdernos en los
detalles al especificar las realizaciones
Para identificar las relaciones, partimos del modelo de
dominio e incluimos nuevas si es necesario para la
realizacin de los casos de uso

Computacin.
Curso 02/03
Identificacin de requisitos adicionales comunes
Se trata de requisitos que aparecen durante el anlisis,
pero no deben ser tratados hasta las fases de diseo o
implementacin
Persistencia
Distribucin y concurrencia
Tolerancia a fallos
Igual que en el caso anterior estos requisitos suelen
aparecer durante la realizacin de los casos de uso

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03
Anlisis de un Caso de Uso

Los objetivos de esta actividad son:
Identificar las clases de anlisis cuyos objetos son
necesarios para llevar a cabo el flujo de sucesos del
caso de uso
Asignamos estereotipos
Esbozamos:
Nombres
Responsabilidades
Atributos
Relaciones
Distribuir el comportamiento entre los objetos de
anlisis
Captura de requisitos especiales

Computacin.
Curso 02/03
Anlisis de un Caso de Uso

Descripcin de interacciones
Se utilizan diagramas de interaccin
Un diagrama por cada flujo o subflujo diferenciado
Se parte de la descripcin textual que se traduce a
intercambio de mensajes entre clases de anlisis
Se aaden las relaciones necesarias a los diagramas de
clases
Nos interesa ms encontrar estas relaciones que su
ordenacin

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03
Anlisis de una Clase

Objetivos:
Identificar y mantener las responsabilidades
Se obtienen combinando todos los roles de la clase en los
distintos casos de uso
Se pueden obtener a partir de los distintos diagramas de
interaccin
Identificar y mantener los atributos y relaciones
Especifican las propiedades de las clases de anlisis
El nombre de un atributo debe ser un nombre
Los tipos deben ser conceptuales: cantidad vs integer
Debemos intentar reutilizar tipos existentes
Las instancias de los atributos no pueden compartirse. Si es
necesario hay que definirlo como atributo y no como clase
Si un atributo es complejo se puede convertir en otra clase
Los atributos en las clases de control son poco habituales
(valores acumulados o calculados)
Capturar requisitos adicionales que deben cumplir las clases

Computacin.
Curso 02/03
Anlisis de una Clase

Objetivos:
Identificar y mantener las responsabilidades
Se obtienen combinando todos los roles de la clase en los
distintos casos de uso
Se pueden obtener a partir de los distintos diagramas de
interaccin
Identificar y mantener los atributos y relaciones
Especifican las propiedades de las clases de anlisis
El nombre de un atributo debe ser un nombre
Los tipos deben ser conceptuales: cantidad vs integer
Debemos intentar reutilizar tipos existentes
Las instancias de los atributos no pueden compartirse. Si es
necesario hay que definirlo como atributo y no como clase
Si un atributo es complejo se puede convertir en otra clase
Los atributos en las clases de control son poco habituales
(valores acumulados o calculados)
Capturar requisitos adicionales que deben cumplir las clases

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.
Curso 02/03
Anlisis de un Paquete
Objetivos:
Garantizar que un paquete sea tan independiente como
sea posible
Garantizar que cumple su objetivo de realizar clases de
dominio o casos de uso
Describir las dependencias de forma que pueda
estimarse el efecto de los cambios futuros

Computacin.
Curso 02/03
Contenido
Introduccin
Modelo de Anlisis
Resumen

Computacin.

7 Tema3

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

7 Tema3

Încărcat de

Drepturi de autor:

Formate disponibile

Anlisis y

Una caracterstica/funcionalidad del software que debe ser

Departamento de Lenguajes y Ciencias de la 3

La verificacin de los requisitos se realiza en cuanto se

Departamento de Lenguajes y Ciencias de la 4

Introduccin a la Ingeniera de Requisitos

Departamento de Lenguajes y Ciencias de la 5

Introduccin a la Ingeniera de Requisitos

Departamento de Lenguajes y Ciencias de la 6

Problemas del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 7

Problemas del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 8

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 9

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 10

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 11

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 12

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 13

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 14

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 15

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 16

Claves del Manejo de Requisitos

Para realizar una llamada externa, el usuario debe

El sistema tiene 4 estados: Inactivo, Tono de Marcado,

Cal es mejor a este nivel?

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 18

Claves del Manejo de Requisitos

Se define en funcin de los requisitos asignados al

Departamento de Lenguajes y Ciencias de la 19

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 20

Claves del Manejo de Requisitos

Se deben asignar atributos a los requisitos

Departamento de Lenguajes y Ciencias de la 21

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 22

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 23

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 24

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 25

Claves del Manejo de Requisitos

Departamento de Lenguajes y Ciencias de la 26

Introduccin a la ingeniera de requisitos

Departamento de Lenguajes y Ciencias de la 27

Su utilidad principal es poder organizar grandes cantidades

Tambin ayuda a revisar que el proceso de recogida ha

La divisin de ms alto nivel es la que se realiza en:

Departamento de Lenguajes y Ciencias de la 28

Departamento de Lenguajes y Ciencias de la 30

Los dos siguientes puntos pueden servir de gua:

En la herramienta estos requisitos son del tipo CAR y

Departamento de Lenguajes y Ciencias de la 31