Anlisis de Sistemas Cursos: 2K7 2K10

Unidad: 8
Flujo de Trabajo de Requisitos
- Diapositivas de clases -

Docentes: Ing. Marcela F. Cattaneo

JTP : Ing. Claudia E. Snchez

Auxiliares Docentes:
2K7: Ing. Germn E. Vlez
2K10: Ing. Susana Turanzas

Los requerimientos en el PUD

Ubicacin en el ciclo de vida Fases

Flujos de trabajo Inicio Elaboracin Construccin Transicin

fundamentales

Requisitos

Anlisis

Diseo

Implementacin

Prueba

Iteracin Iteracin - - - --- --- --- - - - Iteracin Iteracin

#1 # 2 ... # n-1 #n

Iteraciones

ASI FlujodeTrabajodeRequisitos 2

1
 Propsito del F.T. Requisitos
El propsito fundamental del flujo de
trabajo de requisitos es guiar el desarrollo
hacia el sistema correcto.
Lograr una descripcin, suficientemente
buena, de los requisitos del sistema como
para que los desarrolladores lleguen a un
acuerdo con el cliente sobre qu debe hacer
y qu no debe hacer el sistema.

ASI FlujodeTrabajodeRequisitos 3

Propsito del F.T. Requisitos

Ms all de cul sea el punto de partida para el
descubrimiento de los requisitos (modelado del
negocio, del dominio, especificacin de
requisitos hecha por el cliente, etc.), hay una serie
de pasos que estn siempre presentes:
Enumerar los requisitos candidatos.
Comprender el contexto del sistema.
Encontrar requisitos funcionales
Encontrar requisitos no funcionales

ASI FlujodeTrabajodeRequisitos 4

2
 Pasos en el descubrimiento de
requisitos
Enumerar los requisitos candidatos:
Los involucrados presentan buenas ideas
Se elabora Lista de Caractersticas
Aumenta con la aparicin de nuevas ideas.
Disminuye cuando una caracterstica se convierte en
requisito verdadero y pasa a modelarse como Caso de
Uso.
Comprender el contexto del sistema, a partir de:
Modelo de Negocio
Modelo de Dominio

ASI FlujodeTrabajodeRequisitos 5

Comprensin del contexto:

Modelo de Dominio
El Modelo de Dominio (tambin llamado Modelo
de Objetos del Dominio de Problema y
frecuentemente encontrado por las siglas MODP)
captura los tipos de objetos ms importantes 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 se desenvuelve el sistema.
Muchos de las clases del dominio del problema,
pueden deducirse de la especificacin de requisitos o
mediante la entrevista con los expertos del dominio, o
del Modelo de Objetos del Negocio (entidades de
negocio) si se cuenta con dicho modelo.
ASI FlujodeTrabajodeRequisitos 6

3
 Comprensin del contexto:
Modelo de Dominio
Las clases del dominio aparecen como:
Entidades del negocio que representan cosas que se
manipulan en el negocio como pedidos, cuentas, contratos.
Entidades del mundo real y conceptos de los que el
sistema debe hacer un seguimiento, como artculos,
vehculos.
Sucesos que ocurrirn o han ocurrido, como la partida y/o
llegada de un avin, un siniestro en una compaa de
seguros.
El principal diagrama UML para describir el dominio es
el Diagrama de clases.
Para desarrollar este modelo debe conformarse un equipo
con los expertos del dominio (usuarios) como gente con
experiencia en modelado, coordinado por los analistas del
dominio.
ASI FlujodeTrabajodeRequisitos 7

Comprensin del contexto:

Modelo de Dominio
Utilidad del modelo de dominio:
Debe contribuir a la comprensin del problema
que se supone que el sistema resuelve.
Ayuda a los usuarios, clientes, desarrolladores y
otros participantes del proyecto a utilizar un
vocabulario comn.
Las clases del dominio que aqu se encuentren se
utilizarn
Al describir los casos de uso
Disear el prototipo de interfaz de usuario (dentro del
flujo de trabajo de Requisitos)
Para sugerir clases internas al sistema en desarrollo
durante el Anlisis.

ASI FlujodeTrabajodeRequisitos 8

4
 Comprensin del contexto:
Modelo de Dominio
Diagrama de Clases del dominio de problema
Como ya vimos en la Unidad 4, un diagrama de clases
(en UML) es un diagrama que muestra un conjunto de
clases, interfaces, sus colaboraciones y relaciones.
Se utilizan para modelar la vista de diseo esttica de
un sistema. Con UML los diagramas de clases se
emplean para visualizar el aspecto esttico de los
bloques de construccin bsicos del sistema y sus
relaciones, y para especificar los detalles para
construirlos.

ASI FlujodeTrabajodeRequisitos 9

Comprensin del contexto:

Modelo de Dominio
Pautas para su construccin
Debe comunicar un aspecto de la vista de diseo esttica de
un sistema.
Debe contener slo los elementos esenciales para comprender
ese aspecto.
Debe proporcionar detalles en forma consistente con el nivel
de abstraccin, mostrando slo aquellos adornos que sean
esenciales en dicho nivel.
Se deben distribuir sus elementos de modo de minimizar los
cruces de lneas.
Organizar los elementos de modo que los que sean
semnticamente cercanos lo estn tambin fsicamente.
Usar notas y colores sobre aspectos importantes que se
quieran destacar.
Ayuda: Patrones Estructurales para Modelado de Dominio
ASI FlujodeTrabajodeRequisitos 10

5
 Pasos en el descubrimiento de
requisitos
Encontrar requisitos funcionales
La tcnica especfica para identificar los requisitos
funcionales del sistema se basa en los Casos de Uso
Encontrar requisitos no funcionales
Los requisitos no funcionales especifican propiedades
del sistema como restricciones del entorno o de la
implementacin, dependencias de la plataforma,
consideraciones de rendimiento, seguridad, flexibilidad,
facilidad de mantenimiento, etc.
Los casos de uso capturan tanto los requisitos
funcionales como los no funcionales, especficos de cada
caso de uso.

ASI FlujodeTrabajodeRequisitos 11

Artefactos del F.T. Requisitos

Especificador Diseador Arquitecto

Analista de
de Casos de Interfaz
Sistemas
de Uso de Usuario

responsable de responsable de responsable de responsable de

Tv Sat - Conexiones

Datos Planes Recep

Cliente tores

Dni: Nombre:
Domicilio

Calle: N: Barrio:

C.P: Localidad: Provincia:

Representante: Seleccionar
Aceptar
Cuit Razn Social

Cancelar

Modelo de Actor
Actualizar Cliente Actualizar Planes

Glosario Caso de uso Prototipo de Descripcin

casos de uso
Interfaz de de la
Usuario Arquitectura

ASI FlujodeTrabajodeRequisitos 12

6
 Flujo de Trabajo de Requisitos

Analista de Estructurar el modelo

Encontrar actores
Sistemas de casos de uso
y casos de uso

Arquitecto Priorizar los

casos de uso

Especificador Detallar un
de Casos caso de uso
de Uso

Diseador
de Interfaz Prototipar la
de Usuario interfaz del usuario
ASI FlujodeTrabajodeRequisitos 13

Artefactos del F.T. Requisitos

Modelo de Casos de Uso:
Es un modelo que contiene actores, casos de uso y las
relaciones entre stos.
Si el modelo de casos de uso es grande, es til introducir
paquetes en el modelo para tratar su tamao. Un paquete
reunir cierto nmero de casos de uso agrupados por
algn criterio de homogeneidad
Glosario:
Se puede utilizar un glosario para definir trminos
comunes importantes que los analistas y otros
desarrolladores utilizan al describir el sistema.

Artefactos ASI FlujodeTrabajodeRequisitos 14

7
 Artefactos del F.T. Requisitos
Actor:
Un actor es el rol que juega un usuario en un caso de uso.
Normalmente, un actor representa un rol que es jugado
por una persona, un dispositivo de hardware o incluso
otro sistema al interactuar con nuestro sistema.
Rol: Cada usuario puede desempear uno o ms roles al
interactuar con el sistema. Cada rol se identifica como un
actor.
Tipos de actores:
Actor Primario: Tiene un objetivo claro que debe ser tenido en
cuenta y concretado con la ayuda del sistema de informacin.
Actor Secundario: Es de quin el sistema necesita ayuda para
cumplir con el objetivo del actor primario.
Ej.
Artefactos ASI FlujodeTrabajodeRequisitos 15

Artefactos del F.T. Requisitos

Caso de Uso:
Un caso uso representa cada forma en que los
actores usan el sistema.
Son fragmentos de funcionalidad que el sistema
ofrece para aportar un resultado de valor para sus
actores.
Especifica una secuencia de acciones que el
sistema puede llevar a cabo interactuando con sus
actores, incluyendo secuencias dentro de la
secuencia.
Artefactos ASI FlujodeTrabajodeRequisitos 16

8
 Artefactos del F.T. Requisitos
Categoras de casos de uso:
Esenciales: Describen la funcionalidad principal que
tiene que cumplir el sistema. Comprenden los
principales procesos que debe ejecutar el sistema de
informacin.
De soporte: Comprenden la funcionalidad que surge
a partir de analizar aquello que se necesita para que
puedan funcionar los casos de uso esenciales. Por ej.:
casos de uso para administrar clases de soporte, casos
de uso para administrar los datos de los usuarios del
sistema, permisos asignados a los mismos, inicio y
cierre de sesin, etc.
Ej.
Artefactos ASI FlujodeTrabajodeRequisitos 17

Artefactos del F.T. Requisitos

Tipo de Caso de Uso:
Concreto: caso de uso que es iniciado por un
actor.
Abstracto: no es iniciado nunca por un actor,
en cambio es nicamente instanciado por otro
caso de uso. Surgen a partir de relaciones de
extensin, inclusin o generalizacin.

Artefactos ASI FlujodeTrabajodeRequisitos 18

9
 Artefactos del F.T. Requisitos
Prototipo de Interfaz:
Nos ayudan a comprender y especificar las interacciones
entre actores humanos y el sistema durante la captura de
requisitos.
No slo nos ayuda a desarrollar una interfaz grfica
mejor, sino a comprender mejor los casos de uso.
Descripcin de la Arquitectura:
contiene una vista del modelo de casos de uso, que
representa los casos de uso significativos.
Debera incluir los C-U que describan alguna
funcionalidad importante y crtica, o que impliquen
algn requisito importante que deba desarrollarse pronto,
dentro del ciclo de vida del software.

Artefactos ASI FlujodeTrabajodeRequisitos 19

Actividades del F.T. Requisitos

Encontrar actores y casos de uso:
Encontrar los actores
Encontrar los casos de uso
Describir brevemente los casos de uso
Describir el modelo de casos de uso
completo

Actividades ASI FlujodeTrabajodeRequisitos 20

10
 Actividades del F.T. Requisitos:
Encontrar Actores y Casos de Uso
Para encontrar actores, hacerse las siguientes
preguntas ser til:
Quin proveer, usar o quitar informacin?
Quin usar esta funcionalidad?
Quin est interesado en este requerimiento?
En qu parte de la organizacin ser usado el sistema?
Quin dar soporte y mantendr el sistema?
Cules son los recursos externos del sistema?
Qu otros sistemas necesitarn interactuar con este
sistema?

Enc. Act. y C-U ASI FlujodeTrabajodeRequisitos 21

Actividades del F.T. Requisitos:

Encontrar Actores y Casos de Uso
Encontrar Casos de Uso
El analista de sistemas identificar los C-U a travs de los
talleres con los clientes y los usuarios.
Repasar los actores de a uno y pensar en qu forma pueden
utilizar el sistema o qu necesitan del sistema, proponiendo
as C-U, considerados en primera instancia candidatos.
Los C-U esenciales suelen ser los primeros en ser
descubiertos, y luego se identifican otros casos de uso a los
que llamamos secundarios o de soporte
Se elige un nombre por cada C-U, que represente la
secuencia de acciones concreta que produce algo de valor
para el actor. El nombre del caso de uso comienza con un
verbo en infinitivo.

Enc. Act. y C-U ASI FlujodeTrabajodeRequisitos 22

11
 Actividades del F.T. Requisitos:
Encontrar Actores y Casos de Uso
Describir brevemente los casos de uso
Describir el modelo de casos de uso completo:
Esta tarea consiste en elaborar diagramas y
descripciones para explicar el modelo de casos de uso
en totalidad.
Podemos tener varios diagramas: por proceso de
negocio, o diagrama que reune todos los casos de uso
en los que interviene un mismo actor, etc.
El modelo de casos de uso puede organizarse en
conjuntos de casos de uso conformando paquetes de
casos de uso.

Diag. C-U
Enc. Act. y C-U ASI FlujodeTrabajodeRequisitos 23

Actividades del F.T. Requisitos

Priorizar los casos de uso:
El propsito de esta actividad es determinar cules
casos de uso son necesarios para el desarrollo en las
primeras iteraciones y cules pueden dejarse para ms
adelante.
Detallar casos de uso:
El objetivo de esta actividad es detallar el flujo de
sucesos en detalle, incluyendo cmo comienza,
termina e interactan con los actores (uso de
plantillas).
Piezas C-U
Actividades ASI FlujodeTrabajodeRequisitos 24

12
 Actividades del F.T. Requisitos
Protipar la interfaz del usuario:
Hay que disear la interfaz de usuario que le
permita llevar a cabo los C-U de manera
eficiente.
Se comienza intentando determinar qu se
necesita de las interfaces de usuario para
habilitar los casos de uso. Esto es hacer un
diseo lgico de la interfaz. Luego se realiza
un diseo fsico y se desarrollan prototipos.

Actividades ASI FlujodeTrabajodeRequisitos 25

Actividades del F.T. Requisitos

Estructurar el Modelo de Casos de Uso:
Extraer descripciones de funcionalidad generales y
compartidas que pueden ser utilizadas por descripciones
ms especficas.
Extraer descripciones de funcionalidad adicionales u
opcionales que pueden extender descripciones ms
especficas.
El analista debe buscar comportamientos compartidos y
extensiones. Esto se refleja en la determinacin de
relaciones de generalizacin, inclusin y extensin
entre casos de uso.

Actividades ASI FlujodeTrabajodeRequisitos 26

13
 Relaciones entre Casos de Uso
Generalizacin entre Casos de Uso:
Un caso de uso hijo hereda el comportamiento
del caso de uso padre. El hijo puede modificar
y/o agregar comportamiento al heredado.
La generalizacin se emplea para simplificar
la forma de trabajo y la comprensin del
modelo de casos de uso y para reutilizar casos
de uso semifabricados.

ASI FlujodeTrabajodeRequisitos 27

Relaciones entre Casos de Uso

Generalizacin entre Casos de Uso:
Grficamente se indica con una lnea contnua con
punta de flecha cerrada vaca dirigida del caso de uso
hijo hacia el padre.
Caso de uso padre
Registrar venta
de c ontado

Caso de uso hijo

V endedor Registrar V enta

Regis trar venta

c on tarjeta

ASI FlujodeTrabajodeRequisitos 28

14
 Relaciones entre Casos de Uso
Extensin:
Una relacin de extensin entre C-U
significa que un caso de uso base incorpora
implcitamente el comportamiento de otro C-
U.
El C-U base puede ejecutarse aisladamente,
pero bajo ciertas condiciones su
funcionalidad ser extendida por la del C-U
de extensin.

ASI FlujodeTrabajodeRequisitos 29

Relaciones entre Casos de Uso

Extensin
Una relacin de extensin se utiliza para
modelar una parte opcional de un C-U,
modelar un subflujo separado que slo se
ejecuta bajo ciertas circunstancias.
El caso de uso de extensin puede en algunos
casos ser instanciado directamente por un
actor, adems de instanciarse para extender el
comportamiento de un caso de uso base.

ASI FlujodeTrabajodeRequisitos 30

15
 Relaciones entre Casos de Uso
Extensin entre Casos de Uso:
Se representa como una dependencia estereotipada
con la palabra extend o ext, dirigida desde el C-U de
extensin hacia el C-U base.

Generar cuota Impuesto

Encargado Cuentas
Automotor
Aut omotor

<<extend>>

Emitir ceduln Impuesto

Empleado de
Automotor
At encin al Pblico
ASI FlujodeTrabajodeRequisitos
31

Relaciones entre Casos de Uso

Inclusin:
Una relacin de inclusin entre C-U significa
que un caso de uso base incorpora
explcitamente el comportamiento de otro
caso de uso en el lugar especificado en el caso
base.
El C-U incluido o caso de uso de inclusin
puede ser instanciado por un actor (es decir,
puede ser un CU concreto) si constituye un
curso de accin completo en s mismo. Esto
es as a partir de UML 2.0.
ASI FlujodeTrabajodeRequisitos 32

16
 Relaciones entre Casos de Uso
Inclusin
La relacin de inclusin se usa para:
Abstraer el comportamiento comn entre
varios casos de uso
Abstraer un comportamiento complejo que
complica el caso de uso base.

ASI FlujodeTrabajodeRequisitos 33

Relaciones entre Casos de Uso

Inclusin entre Casos de Uso:
Se representa una dependencia estereotipada con la
palabra include o inc, dirigida desde el C-U base hacia
el C-U includo.
<<inc lude>>
Modificar Cuota Automotor

Encargado Cuent as
Automotor Registrar Justificacion cambio
<<include>>
cuota aut omotor
Eliminar Cuota A utomot or

<<include>>

Registrar Estructura Familiar Regist rar Integrante Grupo Familiar

Empleado Accin
Social ASI FlujodeTrabajodeRequisitos
34

17
 Relaciones entre Casos de Uso
Otros ejemplos:
RegistrarConsultaInternado

RegistrarConsulta

RegistrarConsultaAmbulatoria
Veterinario

<<include>>

Registrar Nuevo Vehculo Actualizar Titular

Encargado Cuentas <<extend>>

Automotor

Modificar Vehculo

ASI FlujodeTrabajodeRequisitos
35

Generalizacin entre Actores

Pueden definirse categoras generales de actores
y especializarlos a travs de relaciones de
generalizacin.
Los actores especializados (hijos) heredan el
comportamiento del actor padre.
Si un caso de uso es instanciado por el actor
padre puede ser instanciado por cualquiera de
sus hijos. Ahora bien podra haber casos de uso
que son instanciados por uno de los actores
hijo en particular.

ASI FlujodeTrabajodeRequisitos 36

18
 Generalizacin entre Actores
Ejemplo

Regis trar V enta

V endedor

V endedor de V iajante
m os trador

Generalizacin

ASI FlujodeTrabajodeRequisitos
37

Diagrama de Casos de Uso

Modelan el comportamiento de un sistema o un
subsistema.
Contienen: casos de uso, actores, relaciones de
dependencia, generalizacin y asociacin.
Ejemplo: Caso de Uso

Generalizacin
Extensin
Actor

<<ext>>
Registrar Industria

Registrar Contribuyente
Registrar nuevo
Empleado Seccin
comercio
Comercio e Industria <<inc>>
Registrar Negocio

Inclusin Consultar actividades

Describir Modelo ASI FlujodeTrabajodeRequisitos

38

19
 Bibliografa
Booch Grady, Rumbaugh James, Jacobson
Ivar, (1999), El lenguaje de Modelado
Unificado, Espaa, Editorial Addison Wesley
Iberoamericana.
Jacobson Ivar, Booch Grady, Rumbaugh
James, (2000), El Proceso Unificado de
Desarrollo de Software, Espaa, Editorial
Addison Wesley.

ASI FlujodeTrabajodeRequisitos 39

20