Temas UNIDAD 1

Requerimientos de Software
Actores e Involucrados relevantes
Qu es un caso de uso?
Cundo usar casos de uso?

Requerimientos de Software
Un requerimiento es considerado una condicin o capacidad a la que se debe
ajustar el sistema que se est desarrollando
Un requerimiento es una capacidad o cualidad que el sistema ofrece.
Los requerimientos pueden ser funcionales y no funcionales.
Los requerimientos funcionales definen los servicios que el sistema ofrece al
usuario.
Ej. Agregar registro de contrato, Eliminar registro.
Los requerimientos no funcionales definen aspectos de calidad del sistema.
Ej. Performance, usabilidad, etc.
Requerimientos
Los requerimientos funcionales de software describen las funcionalidades en
trminos del sistema que entregan valor al usuario.
Los requerimientos funcionales de software deben concentrarse en el qu y
no el cmo.
Proveen una definicin de caja negra del sistema.

Objetivos de los requerimientos

Llegar a un acuerdo formal con los clientes y
Usuarios finales sobre lo que el sistema debe de

Hacer.
Proporcionar a los miembros del proyecto una
Idea clara de los requerimientos del sistema.
Delimitar las fronteras del sistema.
Proporcionar las bases para la planificacin del
Contenido tcnico de las iteraciones, los costos y
el tiempo para el desarrollo del sistema.
Definir la interface grfica del sistema

Como capturar requerimientos

Entrevistas.
Cuestionarios.
Encuestas.
Descripcin de puestos.
Artefactos del Modelado de Negocio
TCNICAS DE RECOPILACIN DE INFORMACIN
Los analistas utilizan una variable de mtodos a fin de recopilar los datos sobre
una situacin existente, como entrevistas, cuestionario, inspeccin de registros
y observacin. Cada uno tiene ventajas y desventajas. Generalmente, se
utilizan dos o tres para complementar el trabajo de cada una y ayudar a
asegurar una investigacin completa. A continuacin se vern cada una de
ellas.
ENTREVISTA
Las entrevistas se utilizan para recabar informacin en forma verbal, a travs
de preguntas que propone el analista. Quienes responde pueden ser gerentes
o empleados, los cuales son usuarios actuales del sistema, existen usuarios
potenciales del sistema propuesto o aquellos que proporcionaran datos o sern
afectadas por la aplicacin propuesta. El analista puede entrevistar al personal
en forma individual o en grupos.
Recabar datos mediante la entrevista.
La entrevista es una forma de conversacin, no interrogacin! Al analizar las
caractersticas de los sistemas con personal seleccionado cuidadosamente por
sus conocimientos sobre ese sistema los analistas pueden conocerlos datos
que no estn disponibles en ninguna otra forma.
En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la
informacin son importantes. La informacin cualitativa est relacionada con
opiniones, polticas y descripciones cuantitativas tratan con nmeros,
frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de

informacin cualitativa; los otros mtodos tienden a ser mas tiles en la

recabacin de datos cuantitativos.
Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en
forma verbal. Como resultado de esto las entrevistas pueden descubrir
rpidamente malos entendidos, falsas expectativas o incluso resistencia
potencial para las aplicaciones en desarrollo; mas aun a menudo es ms fcil
calendarizar una entrevista con los gerentes del alto nivel, que pedirles que
llenen cuestionarios.
Generalidades de la entrevista.
La estructura de las entrevistas vara. Si el objetivo de la entrevista radica en
adquirir informacin general, es conveniente elaborar una serie de preguntas
sin estructura, con una seccin de preguntas y respuestas libres. La atmsfera
abierta y de fcil flujo de esta modalidad proporciona una mayor oportunidad
para conocer las actitudes, ideas y creencias de quien responde. Sin embargo,
cuando los analistas necesitan adquirir datos ms especficos sobre la
aplicacin o desean asegurar una alta confiabilidad en las respuestas a las
preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas
son mejores.
Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de
respuestas para las preguntas puede ser abierto o cerrado; las preguntas para
respuesta abierta permiten a los entrevistados dar cualquier respuesta que
parezca apropiada. Con las preguntas para respuestas cerradas se
proporciona al usuario un conjunto de respuestas que se pueda seleccionar.
Todas las personas que responden se basan en un mismo conjunto de posibles
respuestas.
La confiabilidad es solo una consideracin en la seleccin del mtodo de
entrevista. Los analistas tambin deben dividir su tiempo entre desarrollar
preguntas para entrevistas y analizar las respuestas. Las entrevistas no
estructuradas requieren menos tiempo de preparacin, porque no se necesita
tener por anticipado las palabras precisas de las preguntas. Sin embargo,
analizar las respuestas despus de las entrevistas lleva ms tiempo que con
las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la
preparacin, administracin y anlisis de las entrevistas estructuradas para
preguntas cerradas.

Dado que un nmero de personas se seleccionara para la entrevista, los

analistas deben tener cuidado de incluir aquellas personas que tienen
informacin que no se podr conseguir de otra forma. Durante las primeras
etapas de un estudio de sistemas, cuando los analistas determinan la
factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la
gerencia o personal de supervisin. Sin embargo, durante la investigacin
detallada en donde el objetivo es descubrir hechos especficos, opiniones y

conocer como se manejan las operaciones desempeadas actualmente, las

entrevistas se aplican en todos los niveles gerenciales y de empleados y
dependen de quien pueda proporcionar la mayor parte de la informacin til
para el estudio. As, los analistas que estudian ala administracin de
inventarios pueden entrevistar a los trabajadores del embarque y de recepcin,
al personal del almacn y a los supervisores de los diferentes turnos, es decir,
aquellas personas que realmente trabajan en el almacn; tambin entrevistaran
a los agentes ms importantes.
Realizacin de la entrevista.
La habilidad del entrevistador es vital para el xito en la bsqueda de hechos
por medio de la entrevista. Las buenas entrevistas dependen del conocimiento
del analista tanto de la preparacin del objetivo de una entrevista especfica
como de las preguntas por realizar a una persona determinada.
El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar
una entrevista exitosa. La falta de estos factores puede reducir cualquier
oportunidad de xito. Por ejemplo, un analista que trabaja en la aplicacin
enfocada a la reduccin de errores probablemente no tendra xito si llegar a
una oficina de gerencia de nivel medio con la presentacin equivocada, por
ejemplo, si dijera, "hola, fui enviado para encontrar una forma de mojar el
rendimiento y de reducir los errores que presentan aqu. O la introduccin:
"Estamos aqu para resolver su problema", es igualmente mala. Es imaginable
la rapidez con la que va a responder ser irrita y se molesta con un enfoque de
este tipo.
A travs de la entrevista, los analistas deben preguntarse a s mismos las
siguientes interrogantes:
Qu es lo que me est diciendo la persona?
Por qu me lo est diciendo a m?
Qu se est olvidando?
Qu espera esta persona que haga yo?
Si se considera cada elemento de la informacin contra estas preguntas, los
analistas tendrn ms conocimientos no solamente de la informacin adquirida
sino tambin de su importancia.
C U E S T I O N A R I O.
Los cuestionarios proporcionan una alternativa muy til para las entrevistas; sin
embargo, existen ciertas caractersticas que pueden ser apropiadas en algunas
situaciones e inapropiadas en otras.

Recabacin de datos mediante cuestionarios

Para los analistas los cuestionarios pueden ser la nica forma posible de
relacionarse con un gran nmero de personas para conocer varios aspectos del
sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se
puede distribuir los cuestionarios a todas las personas apropiadas para recabar
hechos con relacin al sistema. Por supuesto, no es posible observar las
expresiones o relaciones de quienes responden a los cuestionarios.
Tambin las preguntas estandarizadas pueden proporcionar datos ms
confiables. Por otra parte, las caractersticas anteriores tambin son
desventajas de los cuestionarios. Aunque su aplicacin puede realizarse con
un mayor nmero de individuos, es muy rara una respuesta total. Puede
necesitarse algn seguimiento de los cuestionarios para motivar al personal
que responda; todas las respuestas se encontraran en una proporcin entre el
25 o 35%, que es lo ms comn.
Seleccin de formas para cuestionarios.
El desarrollo y distribucin de los cuestionarios es caro; por lo tanto, el tiempo
invertido en esto debe utilizarse en una forma inteligente. Tambin es
importante el formato y contenido de las preguntas en la recopilacin de
hechos significativos.
Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y
cerrados, y se aplican dependiendo de si los analistas conocen de antemano
todas las posibles respuestas de las preguntas y pueden incluirlos. Con
frecuencia se utilizan ambas formas en los estudios de sistemas.
Cuestionarios abiertos.
Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican
cuando se quieren conocer los sentimientos, opiniones y experiencias
generales; tambin son tiles al explorar el problema bsico, por ejemplo, un
analista que utiliza cuestionarios para estudiar los mtodos de verificacin de
crdito, en un medio ambiente de ventas al a menudeo, podra recabar mas
informacin provechosa de una pregunta abierta de este tipo: Cmo podra
simplificarse y mejorarse el proceso de verificacin de crdito para los clientes?
Cuestionarios cerrados.
El cuestionario cerrado limita las respuestas posibles del interrogado. Por
medio de un cuidadoso estilo en la pregunta, el analista puede controlar el
marco de referencia. Este formato es el mejor mtodo para obtener informacin
sobre los hechos. Tambin fuerza a los individuos para que tomen una posicin
y forma de opinin sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario

Los cuestionarios bien hechos no se desarrollan rpidamente, llevan tiempo y
mucho trabajo. La primera consideracin se encuentra en determinar el objetivo
del cuestionario. Qu datos quiere conocer el analista a travs de su uso? El
analista define como utilizar los cuestionarios a fin de obtener los hechos al
considerar la estructura mas til para el estudio y la ms sencilla de entender
por parte de los interrogados.
Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse
y modificarse, si es necesario, antes de que imprima una forma final y se
distribuya.
Seleccin de quienes recibirn el cuestionario
Aquellas personas que reciban el cuestionario deben seleccionarse de a
cuerdo con la informacin que puedan proporcionar. Escribir o imprimir un
cuestionario no significa que se pueda distribuir ampliamente sin un anlisis
previo. Lo pueden contestar personas no calificadas y si el cuestionario no es
annimo, y no ser posible retirar sus respuestas de la muestra. La realizacin
de esto tambin es desgastante y cara.

OBSERVACION
Ver es creer! Observar las operaciones le proporciona la analista hechos que
no podra obtener de otra forma.
Recopilacin de datos mediante la observacin
Leer en relacin con una actividad del negocio le proporciona al analista una
dimensin de las actividades del sistema. Entrevistar personal, ya sea
directamente o a travs de cuestionarios, tambin le ayuda y le dice algo ms.
Ninguno de los dos mtodos da una informacin completa; por ejemplo, leer en
relacin con un viaje en jet no reproduce la experiencia de volar a unos 30 mil
pies de altura.
La observacin proporciona informacin de primera mano en relacin con la
forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de
documentos, la manera en la que se realizan las tareas y si ocurren los pasos
especficos como se pre-establecieron, pueden contestarse rpidamente si se
observan las operaciones.
Cuando observar

La observacin es muy til cuando el analista necesita ver de primera mano

cmo se manejan los documentos, como se llevan a cabo los procesos y si
ocurren los pasos especificados. Saber que buscar y como guiar su significado,
tambin requiere de experiencia. Los observadores con experiencia captan
quien utiliza los documentos y si encuentran dificultades; tambin estn alertas
para detectar documentos o registros que no se utilizan.

MUESTREO
Con frecuencia, en muchas empresas la informacin ya se encuentra
disponible para que el analista conozca las actividades u operaciones con las
cuales no est familiarizado. Muchos tipos de registros e informes son
accesibles si el analista sabe dnde buscar. En la revisin de registros, los
analistas examinan datos y descripciones que ya estn escritos o registrados y
en relacin con el sistema y los departamentos de usuarios. Esta forma de
encontrar datos puede servir como presentacin del analista, si se realiza al
iniciar el estudio, o como un trmino de comparacin de lo que sucede en el
departamento con lo que los registros presentan como lo que debera suceder.
Recopilacin de datos por medio de la inspeccin de registros.
El trmino "registro" se refiere a los manuales escritos sobre polticas,
regulaciones y procedimientos de operaciones estndar que la mayora de las
empresas mantienen como gua para gerentes y empleados. Los manuales que
documentan o describen las operaciones para los procesos de datos
existentes, o sistemas de informacin que entran dentro del rea de
investigacin, tambin proporcionan una visin sobre la forma en la que el
negocio debera conducirse. Normalmente muestran los requerimientos y
restricciones del sistema (como cantidad de transacciones o capacidad de
almacenamiento de datos) y caractersticas de diseo (controles y verificacin
del procesamiento).
Los registro permiten que los analistas se familiaricen con algunas
operaciones, oficinas de la compaa y relaciones formales a las que debe
darse apoyo. No obstante, no muestran como producen de hecho las
actividades, donde se ubica el poder verdadero para las decisiones, o como se
realizan las tareas en la actualidad. Los otros mtodos con objeto de encontrar
datos estudiados en esta seccin son ms eficaces para proporcionar al
analista este tipo de informacin.
Seleccin de los registros para revisin
En la mayor parte de las empresas los manuales de estndares sobre
procedimientos de operacin usualmente son obsoletos; a menudo no se
mantienen al corriente lo suficiente para sealar los procedimientos existentes.

Los diagramas de organizacin muestran como las diferentes unidades

deberan relacionarse con otras; pero muchas no reflejan las operaciones
actuales.

Actores e Involucrados relevantes

Definicin Actores
Un actor es algo con comportamiento, como una persona (identificada por un
rol), un sistema informatizado u organizacin, y que realiza algn tipo de
interaccin con el sistema. Se representa mediante una figura humana dibujada
con palotes. Esta representacin sirve tanto para actores que son personas
como para otro tipo de actores.
Un actor es aquel involucrado relevante que tiene interaccin con el sistema.
Puede ser una persona, una empresa u organizacin, un programa o un
sistema computacional.
Se emplea el trmino de actor para llamar as al usuario, cuando desempea
ese papel dentro del sistema. Cuando se trata con actores, conviene pensar en
los papeles, no en las personas ni en los ttulos de sus puestos. Los actores
llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de
uso; a la inversa, un caso de uso puede ser realizado por varios actores.
Se debe tener en cuenta que no es necesario que los actores sean seres
humanos, a pesar de que los actores estn representados por figuras humanas
en el diagrama de casos de uso. El actor puede ser tambin un sistema
externo, que necesite cierta informacin del sistema actual o interacte con l
como una base de datos por ejemplo.
Una forma fcil de representar casos de uso es haciendo que solo se muestren
los actores del sistema cuando ellos sean los que necesiten el caso de uso. Por
tanto, si el sistema genera cada noche un archivo que despus es recogido por
el sistema de contabilidad, entonces este es el actor que corresponde, debido a
que es quien necesita el archivo generado.
Un involucrado relevante es aquel que tiene un inters de por medio en las
funcionalidades del sistema.
El actor primario es aquel que generalmente inicia un caso de uso.
Los involucrados relevantes pueden participar o no en un caso de uso.
Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:

actores, casos de uso y relaciones entre casos de uso.

Qu es un caso de uso?
Tpicamente los casos de uso son tiles para documentar requerimientos
funcionales de un sistema o para documentar los procesos de negocio de una
organizacin (casos de uso de negocio).
Un caso de uso describe el comportamiento de cmo un sistema responde a
las solicitudes de uno de los involucrados relevantes llamado actor primario. El
sistema responde protegiendo los intereses de todos los involucrados
relevantes.
Los casos de uso son generalmente un documento de texto. Sin embargo,
pueden ser representados como diagramas de flujo, diagramas de secuencia,
redes de Petri o en un lenguaje de programacin.
Un caso de uso debe ser fcil de leer. Contiene oraciones de una sola forma
gramtica -pasos que representan una accin- en las que el actor alcanza una
meta.
Sirven como un medio de comunicacin entre personas que no tienen
habilidades especializadas en el rea de desarrollo de software, por lo cual los
casos de uso en forma de documentos de texto son la mejor opcin.
Para escribir un caso de uso efectivo se deben tener en cuenta los siguientes
tres aspectos:
Alcance: Qu es el sistema en discusin.
Actor primario: Quin tiene la meta.
Nivel: Que tan alto o bajo es el nivel de esa meta.
Un caso de uso puede ser representado como una secuencia de interacciones
que se producen entre un actor y el sistema, cuando el actor usa el sistema
para llevar a cabo una tarea especfica. Expresa una unidad coherente de
funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una
elipse con el nombre del caso de uso en su interior. El nombre del caso de uso
debe reflejar la tarea especfica que el actor desea llevar a cabo usando el
sistema.
Relaciones de Casos de Uso
Las tres relaciones principales entre los casos de uso son soportadas por el
estndar UML, el cual describe notacin grfica para esas relaciones.

Inclusin (include o use)

Es una forma de interaccin o creacin, un caso de uso dado puede "incluir"
otro. El primer caso de uso a menudo depende del resultado del caso de uso
incluido. Esto es til para extraer comportamientos verdaderamente comunes
desde mltiples casos de uso a una descripcin individual, desde el caso El
estndar de Lenguaje de Modelado Unificado de OMG define una notacin
grfica para realizar diagramas de casos de uso, pero no el formato para
describir casos de uso. Mucha gente sufre la equivocacin pensando que un
caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin
grfica y las descripciones son importantes, ellos forman parte de la
documentacin de un caso de uso --un propsito para el que el actor puede
usar el sistema. de uso que lo incluye hasta el caso de uso incluido, con la
etiqueta "include". Este uso se asemeja a una expansin de una macro,
donde el comportamiento del caso incluido es colocado dentro del
comportamiento del caso de uso base. No hay parmetros o valores de retorno.
Aqu tambin podemos decir q este va de padre a hijo.

Extensin (Extend)
Es otra forma de interaccin, un caso de uso dado, (la extensin) puede
extender a otro. Esta relacin indica que el comportamiento del caso de La
extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe
tener extensin o inclusin. Uso extensin puede ser insertado en el caso de
uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta
abierta con lnea discontinua, desde el caso de uso extensin al caso de uso
extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos
especiales, o para acomodar nuevos requisitos durante el mantenimiento del
sistema y su extensin.
"La extensin, es el conjunto de objetos a los que se aplica un concepto. Los
objetos de la extensin son los ejemplos o instancias de los conceptos."
Generalizacin
"Entonces la Generalizacin es la actividad de identificar elementos en comn
entre conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
taxonmicas entre conceptos que entonces se representan en jerarquas de
clases. Las subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intencin y extensin."
En la tercera forma de relaciones entre casos de uso, existe una relacin
generalizacin/especializacin. Un caso de uso dado puede estar en una forma

especializada de un caso de uso existente. La notacin es una lnea slida

terminada en un tringulo dibujado desde el caso de uso especializado al caso
de uso general. Esto se asemeja al concepto orientado a objetos de subclases, en la prctica puede ser til factorizar comportamientos comunes,
restricciones al caso de uso general, describirlos una vez, y enfrentarse a los
detalles excepcionales en los casos de uso especializados.
Ejemplos de casos de uso
Para comprender un poco mejor la funcionalidad de los casos de uso, se da un
pequeo ejemplo de cmo funcionan todos los elementos integrados en un
diagrama, tanto actores como relaciones y casos de uso como tal.
Un Diagrama de Casos de Uso muestra la relacin entre los actores y los
casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en
lo que se refiere a su interaccin externa. En el diagrama de casos de uso se
representa tambin el sistema como una caja rectangular con el nombre en su
interior. Los casos de uso estn en el interior de la caja del sistema, y los
actores fuera, y cada actor est unido a los casos de uso en los que participa
mediante una lnea. En la Figura se muestra un ejemplo de Diagrama de Casos
de Uso para un cajero automtico.

Con este ejemplo podemos comprender las diferentes relaciones entre

Casos de Uso

Un caso de uso, en principio, debera describir una tarea que tiene un sentido
completo para el usuario. Sin embargo, hay ocasiones en las que es til
describir una interaccin con un alcance menor como caso de uso. La razn
para utilizar estos casos de uso no completos en algunos casos, es mejorar la
comunicacin en el equipo de desarrollo, el manejo de la documentacin de
casos de uso. Para el caso de que queramos utilizar estos casos de uso ms
pequeos, las relaciones entre estos y los casos de uso ordinarios pueden ser
de los siguientes tres tipos:
Incluye (<>): Un caso de uso base incorpora explcitamente a otro caso de
uso en un lugar especificado en dicho caso base. Se suele utilizar para
encapsular un comportamiento parcial comn a varios casos de uso. En la
Figura se muestra cmo el caso de uso Realizar Reintegro puede incluir el
comportamiento del caso de uso Autorizacin.

Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de
extensin) en los cuales, dependiendo de ciertos criterios, se va a realizar una
interaccin adicional. El caso de uso que extiende describe un comportamiento
opcional del sistema (a diferencia de la relacin incluye que se da siempre que
se realiza la interaccin descrita) En la Figura se muestra como el caso de uso
Comprar Producto permite explcitamente extensiones en el siguiente punto de
extensin: info regalo. La interaccin correspondiente a establecer los detalles
sobre un producto que se enva como regalo estn descritos en el caso de uso
Detalles Regalo.

Ambos tipos de relacin se representan como una dependencia etiquetada con

el estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el
sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede
detallar el/los puntos de extensin del caso de uso base en los que se aplica la
extensin.
Generalizacin ( ): Cuando un caso de uso definido de forma abstracta se
particulariza por medio de otro caso de uso ms especfico. Se representa por
una lnea continua entre los dos casos de uso, con el tringulo que simboliza
generalizacin en UML (usado tambin para denotar la herencia entre clases)
pegado al extremo del caso de uso ms general. Al igual que en la herencia
entre clases, el caso de uso hijo hereda las asociaciones y caractersticas del
caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto,
que no est definido completamente. Este tipo de relacin se utiliza mucho
menos que las dos anteriores.

Cundo usar casos de uso?

Son una herramienta esencial para la captura de requerimientos, la
planificacin o el control de proyectos iterativos. La captura de los casos de uso
es una de las tereas principales durante la fase de elaboracin; de hecho es lo
primero que se debe hacer.
La mayora de los casos de uso se generaran durante la fase del proyecto,
pero se irn descubriendo otros a medida que se avance. Todo caso de uso es
un requerimiento potencial y hasta que o se hayan capturado todos los
requerimientos, no se podr planear como se manejaran estos en el proyecto.
Algunas personas prefieren listar y analizar los casos de uso primero y luego
llevar a cabo un poco de modelado. Esta fase ayuda en gran medida a
comprender mejor los procesos de interaccin, el modelado conceptual ayuda
a descubrir los casos de uso.

Los diseadores emplean casos de uso en distintos grados de granularidad.

Pero es recomendable o manejar demasiados, que hagan tedioso y extenso el
trabajo dependiendo de su interpretacin.
Para concluir podemos comentar que los casos de uso se usan cuando se
desea definir el comportamiento de un sistema de una manera clara, coherente
y fcil de entender. Cuando se tienen la necesidad de comunicar el
comportamiento de un sistema con miembros de un equipo multidisciplinario.
Cuando es necesario documentar los requerimientos funcionales de un
sistema. Cuando se desea estimar el esfuerzo que representar el diseo y
construccin de un sistema.