Está en la página 1de 20

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
fundamentales

Inicio

Elaboracin

Construccin

Transicin

Requisitos

Anlisis

Diseo

Implementacin

Prueba
Iteracin Iteracin - - #1
# 2 ...

--- --- ---

- - - Iteracin Iteracin
#n
# n-1

Iteraciones

ASI FlujodeTrabajodeRequisitos

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

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

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

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

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

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

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

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

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.
11

ASI FlujodeTrabajodeRequisitos

Artefactos del F.T. Requisitos


Especificador
de Casos
de Uso

Analista de
Sistemas
responsable de

responsable de

Diseador
de Interfaz
de Usuario
responsable de

Arquitecto

responsable de

Tv Sat - Conexiones

Datos Planes Recep


tores
Cliente

Dni:

Nombre:
Domicilio

Calle:
C.P:

N:

Barrio:

Localidad:

Representante:
Cuit

Provincia:

Seleccionar

Aceptar

Razn Social

Cancelar

Modelo de
casos de uso

Actor

Actualizar Cliente

Glosario

Caso de uso

Actualizar Planes

Prototipo de
Interfaz de
Usuario

ASI FlujodeTrabajodeRequisitos

Descripcin
de la
Arquitectura

12

Flujo de Trabajo de Requisitos


Analista de
Sistemas

Arquitecto

Encontrar actores
y casos de uso

Estructurar el modelo
de casos de uso

Priorizar los
casos de uso

Especificador
de Casos
de Uso

Detallar un
caso de uso

Diseador
de Interfaz
de Usuario

Prototipar la
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

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.
Artefactos

ASI FlujodeTrabajodeRequisitos

Ej.

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

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.

Artefactos

ASI FlujodeTrabajodeRequisitos

Ej.

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

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.
Enc. Act. y C-U

ASI FlujodeTrabajodeRequisitos

Diag. C-U

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.

27

ASI FlujodeTrabajodeRequisitos

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


Registrar V enta

V endedor

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 CU.
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.
Encargado Cuentas
Aut omotor

Generar cuota Impuesto


Automotor
<<extend>>

Empleado de
At encin al Pblico

Emitir ceduln Impuesto


Automotor

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.

33

ASI FlujodeTrabajodeRequisitos

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

<<include>>

Registrar Justificacion cambio


cuota aut omotor

Eliminar Cuota A utomot or


<<include>>

Empleado Accin
Social

Registrar Estructura Familiar

Regist rar Integrante Grupo Familiar

ASI FlujodeTrabajodeRequisitos
34

17

Relaciones entre Casos de Uso


Otros ejemplos:
RegistrarConsultaInternado

RegistrarConsulta
Veterinario

RegistrarConsultaAmbulatoria
<<include>>

Registrar Nuevo Vehculo

Encargado Cuentas
Automotor

Actualizar Titular

<<extend>>
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
m os trador

V iajante

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.
Caso de Uso
Ejemplo:
Extensin
Generalizacin
Actor

<<ext>>
Registrar Industria
Registrar Contribuyente
Registrar nuevo
comercio
<<inc>>

Empleado Seccin
Comercio e Industria
Registrar Negocio

Inclusin

Describir Modelo

Consultar actividades

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