Вы находитесь на странице: 1из 10

ANLISIS DE REQUERIMIENTOS MEDIANTE CASOS DE USO

INTRODUCCIN
El desarrollo de sistemas es un proceso formado por etapas de anlisis y
diseo, el ciclo de vida de desarrollo de sistemas es el conjunto de actividades
que los analistas, diseadores y usuarios realizan para desarrollar e
implementar un sistema de informacin.
El aspecto fundamental es el anlisis de los sistemas, es comprender todas las
facetas importantes de la parte de la empresa que se encuentra bajo estudio.
Si no contramos con los requerimientos, simplemente no habra sistema, pues
a partir de estos, se realiza el anlisis y diseo del mismo, en conjunto con el
anlisis de los requerimientos conoceremos que son los casos de uso as como
su aplicacin y uso.
La forma en que representamos nuestros requerimientos es a travs de los
Diagramas de Casos de Uso.

NIVELES Y TIPOS DE REQUERIMIENTO


Existen diferentes niveles de requerimiento:

Cuando realizamos el anlisis de los requerimientos, estos pueden ser de dos


tipos:

Requerimientos funcionales Describen lo que el sistema debe hacer, es


decir especifican acciones que el sistema debe ser capaz de realizar
(funcionalidad).
Requerimientos no funcionales. Describen atributos del sistema o
atributos del ambiente del sistema, por ejemplo: facilidad de uso,
confiabilidad, desempeo, de diseo, de interfaz, legales, de seguridad.

El anlisis de un sistema es el conocimiento de las diferentes situaciones que


se dan en una empresa y que pueden afectar en la operacin de la misma, el
conocimiento no es la solucin a los problemas, para ello se debern realizar
una serie de investigaciones, que nos permitan observar como es el
funcionamiento de un sistema actual e identificar cuales son las necesidades
que debern cubrir con el nuevo sistema.
Nota: cabe mencionar que el punto de partida que son los requerimientos tienen
suma importancia, ya que si se omite algn proceso que debe llevar acabo el
sistema en el momento que se est realizando la entrevista, el producto final
puede que no cumpla los resultados esperados por el usuario final. Es por ello
que es recomendable no realizar slo una entrevista y no trabajar sobre los
requerimientos hasta que se est seguro de que se ha recopilado la informacin
que nos va a servir para desarrollar el sistema en ptimas condiciones.
CASOS DE USO
Una vez que se tiene recopilada toda la informacin para el anlisis de los
requerimientos de nuestro sistema, se comenzar a trabajar con los diagramas
de casos de uso.
Un diagrama de casos de uso modela las posibles formas en que un sistema
puede ser usado. El uso de este diagrama, hace posible el clculo de esfuerzo
y tiempo requeridos para el desarrollo del sistema, y permite observar el
tamao del proyecto y los recursos que sern necesarios.
Los casos de uso nos ayudarn a realizar descripciones de nuestro sistema
desde el punto de vista del usuario y permitirn el modelar y especificar los
requerimientos funcionales de nuestro sistema, de manera tcnica.
Un caso de uso captura el comportamiento de un sistema, as como representa
una secuencia de acciones que el software lleva a cabo para ofrecer algn
resultado de valor para un actor. Los casos de uso representan toda la
funcionalidad del sistema.
Los propsitos de los casos de uso son: que los clientes aprueben lo que el
sistema debe hacer; que los usuarios entiendan el funcionamiento del sistema;
proporcionar las bases para el anlisis y diseo del sistema; que los
desarrolladores comprendan cual ser el comportamiento del software; que se
puedan realizar pruebas con el diseo del sistema; y que la documentacin
sirva como una base o gua de uso para el usuario.

La notacin para los casos de uso se presenta a continuacin:

Un caso de uso es una interaccin tpica entre un usuario


(actor) y un sistema.
Un actor representa cualquier cosa que interacte con el
sistema.
Las asociaciones y dependencias permiten representar
interacciones entre un actor y un caso de uso o entre casos de
uso.

Analicemos cada uno de estos elementos:


Actores. Los actores no son parte del sistema; representan los roles que
pueden jugar los usuarios del sistema:

Un actor puede intercambiar informacin activamente con el sistema


(asociacin bidireccional).
Un actor puede ser un receptor pasivo de informacin, es decir, puede
ser una persona, una mquina u otro sistema
Cada actor participa en uno o ms casos de uso.
Un actor puede ser representado por distintas personas.
Una persona puede desempear varios roles.
Se tienen distintos tipos de actores: principales (personas que hacen uso
del sistema), secundarios (personas que darn mantenimiento o
administrarn al sistema) y otros sistemas (con los cuales el nuestro
puede interactuar).
El nombre que le demos a nuestro actor nos ayuda a describir las
funciones que desempea.

Casos de uso. Es una unidad coherente de funcionalidad. Los casos de uso


en conjunto representan toda la funcionalidad del sistema.

Especifica una secuencia de acciones, incluyendo variantes, que el


sistema puede llevar a cabo, y que producen un resultado observable de
valor para un actor.
Es una toma instantnea de algn aspecto del sistema.
Los casos de uso se determinan a travs de la observacin y precisin
de cada actor, secuencias de interaccin, escenarios (instancias de un
caso de uso) y puntos de vista del usuario.
Son de gran importancia pues el proceso de desarrollo de nuestro
sistema estar dirigido por los casos de uso.

UML define a cuatro tipos de relacin en los Diagramas de Casos de Uso:


Comunicacin.

La relacin include o uses ocurre cuando se tiene una porcin de


comportamiento que es similar en ms de un caso y no se quiere
duplicar la descripcin de tal conducta. Uses o include permite incluir la
misma funcionalidad en dos o ms casos de uso separados sin
necesidad de repetir los detalles. Por ejemplo:

La relacin extend describe una variacin de la conducta normal del


proceso. En el siguiente ejemplo, la variacin es que no haya dinero
suficiente en el cajero:

Otro ejemplo sera:

El caso de uso origen extiende el comportamiento del caso de uso destino.

Herencia. Este caso se da cuando el caso de uso origen hereda las


especificaciones del caso de uso destino y tal vez la modifique o la
ample.

El ejemplo muestra el caso de la biblioteca donde hay un miembro


Adulto que tiene todo los privilegios, mientras que el miembro Nio
depende del miembro Adulto para prstamos y devoluciones, llegada la
edad para tener su credencial heredar todos los atributos y
comportamientos del miembro Adulto.
CARACTERSTICAS DE LOS CASOS DE USO
Nuestros casos de uso deben ser simples, muy claros y concisos.
Comnmente existen pocos actores asociados a cada caso de uso. Para poder
generar nuestro caso de uso es importante que realicemos las siguientes
preguntas:

Cules sern las tareas de los actores?


Qu informacin es la que se va a crear, guardar, modificar por el
actor?
El actor deber notificar al sistema sobre los posibles cambios?
Deber el actor notificar sobre los posibles cambios internos?

ESPECIFICACIN DE LOS CASOS DE USO


Cuando realizamos la descripcin de los casos de uso, sta debe comprender:

INICIO: Cundo y qu actor lo produce?


FIN: Cundo se produce que valor es que nos devolver?
INTERACCIN ACTOR-CASO DE USO: Cules sern los mensajes
que se intercambiarn?
OBJETIVO DEL CASO DE USO: Qu es lo que se llevar acabo o qu
es lo que se intenta?
Cronologa y origen de las interacciones.
REPETICIONES DE COMPORTAMIENTO.
SITUACIONES OPCIONALES, Qu ejecuciones alternativas se
presentan en el caso de uso?

Este conjunto de preguntas nos ayudarn a la documentacin, es decir, a


definir cada uno de los pasos que sern necesarios para el desarrollo de
nuestro sistema. Asimismo, es una forma de comunicacin entre los integrantes
encargados del sistema.
Ejemplo de formato para la especificacin de un caso de uso:

La documentacin de los casos de uso, nos permite describir slo los eventos
que pertenecen al caso de uso y no los que pertenecen a otros casos de uso,
adems de que se emplea un lenguaje comprensible para el cliente.
Los Casos de Uso pueden especificarse utilizando narrativa simple o
secuencias.
Narrativa simple
El usuario indica que desea recuperar contrasea. El sistema despliega la
pregunta secreta elegida por el usuario al momento de registrarse y el usuario
ingresa la respuesta. El sistema verifica que la respuesta sea coincidente y
enva la nueva contrasea al correo electrnico del usuario.
La contrasea es generada automticamente por el sistema de forma aleatoria,
la cual est formada como sigue: 2 nmeros + 2 letras maysculas + 2
nmeros + 1 carcter especial. Ejemplo: 87JU65+
Secuencia
1. El usuario indica que desea Recuperar contrasea.
2. El sistema despliega la pregunta secreta elegida por el usuario al
momento de registrarse.
3. El usuario ingresa la respuesta.
4. El sistema verifica que la respuesta sea coincidente.

5. Si es coincidente, el sistema enva la nueva contrasea al correo


electrnico del usuario, la cual est formada por: 2 nmeros + 2 letras
maysculas + 2 nmeros + 1 carcter especial. Ejemplo: 87JU65+
Se deben de tomar en cuenta los siguientes para el anlisis y diseo del
sistema:

Los casos de uso deben escribirse utilizando el lenguaje del cliente.


El nombre debe denotar una accin (verbo), como infinitivo o como
sustantivo, por ejemplo: Generar informes Generacin de informes.
Redactar en presente y en voz activa (no pasiva).
Cada caso de uso debe estructurarse para que forme una especificacin
de funcionalidad completa e intuitiva. No deberan estructurarse slo
casos de uso pequeos y no intuitivos para reducir redundancias; debe
llegarse a un equilibrio entre el nivel de comprensin y el de
manutencin.
Describir claramente la informacin que se intercambia entre un actor y
el caso de uso.
Las especificaciones de requerimientos no deben considerar aspectos
propios de la implementacin ni tecnicismos. No describe los detalles de
la interfaz de usuario, describe las acciones. Sin embargo los
diseadores y probadores necesitan un mayor detalle por lo que es
altamente recomendable enfatizar cosas como entradas y salidas de
informacin, restricciones y validaciones, detalle de los algoritmos y
caractersticas de los datos (obligatoriedad, longitud, tipo).
Tambin pueden incluirse notas tcnicas dentro del caso de uso,
identificadas de tal manera que no se confundan con la especificacin
base ya que son irrelevantes para el usuario.

ESCENARIOS
Un escenario es una instancia de un caso de uso. En ese sentido, puede ser
uno de los siguientes casos:

Un flujo a travs de un caso de uso


Una ruta que muestra una combinacin particular de condiciones en un
caso de uso
Un caso de prueba, es decir, un conjunto de entradas, condiciones de
ejecucin y resultados esperados desarrollados para probar un camino
concreto a travs de un caso de uso
Flujos secundarios o excepciones del escenario primario

Se considera que un caso de uso est terminado cuando se han capturado


todos los requerimientos funcionales a manera de que pueda ser entendido por
todos los involucrados con el sistema (clientes, usuarios y desarrolladores).
Los casos de uso se pueden complementar con otros diagramas UML, tales
como de estado, de actividad o de secuencia.

Вам также может понравиться