El Espíritu Empresarial

DECANATO DE
DECANATO DE INGENIERÍA E
INFORMÁTICA
ANALISIS Y DISEÑO DE SISTEMAS II (INF-

161)
GRUPO 43050
Práctica
Caso de Estudio – Sistema de Reembolso
Grupo #4
Omar Severino 2017-0266
Anderson del Rosario 2017-0794
Yileisy Luciano 2017-0281
Ralph Maldonado 2017-0607
Luis Montero 2017-0928
Periodo
2018-2
Prof. Leandro Fondeur
JULIO 4, 2018
Santo Domingo, D. N., República Dominicana
CASO DE ESTUDIO.
SISTEMA DE REMBOLSO DE LA EMPRESA VILLA GARCIA.
A la empresa Bright Solution, la cual está especializada en el desarrollo de software, se
le ha solicitado automatizar el proceso de reembolso de la empresa Villa García, ya que
no tienen un control de los gastos de sus empleados fuera del horario de trabajo (horas
extras); por otro lado, buscan agilizar el proceso de tramitar, aprobar y realizar el
reembolso, ya que todo se hace manualmente e invierten demasiado tiempo en ello.
DESCRIPCIÓN DEL OBJETO DE ESTUDIO.

La empresa Villa García SRL., es la mayor empresa de provisiones en República
Dominicana que se dedica a la venta de alimentos, en las provincias norte y este del
país. La Empresa recibe más de 1,5 millones en ingresos anuales, contando con una
flotilla de un aproximado de 10 camiones. La empresa hace un recorrido por provincias
como: San Pedro, La Romana, Hato Mayor, Consuelo, San Francisco, Bonao, Bani, San
Cristóbal, Haina y todo el Distrito Nacional. Teniendo la sede principal ubicada en Santo
Domingo Este. La empresa cuenta con una plantilla de 60 empleados entre Choferes,
Mantenimiento, Gerentes, Cajeros y personal administrativo.
DESCRIPCION DEL OBJETO DE AUTOMATIZACION.

El proceso de solicitud de reembolso se dividirá en tres fases: la primera será la fase de
solicitud de reembolso por parte del empleado, la segunda será la comprobación de la
solicitud por el supervisor del empleado y su posterior aprobación o rechazo, y la tercera
el procesamiento y entrega del reem bolso al empleado solicitante por parte del
departamento de contabilidad de la empresa. El sistema estará diseñado de manera
específica para cada una de sus fases, garantizando así su correcto uso durante todo el
proceso. Es decir, cada uno de los actores del sistema tendrá una plataforma diferente
diseñada específicamente para realizar la actividad que le corresponde. Cada uno de los
actores deberán loguearse a la plataforma utilizando el ID que les proporciona la
empresa y una contraseña de su elección.
Para la primera fase, el Sistema ofrecerá un formulario en donde se especifique el monto
a reembolsar y la justificación del reembolso (en que se invirtió el dinero que el solicitante
está pidiendo reembolsar). El sistema debe pedir, también, algún comprobante del gasto
hecho por el solicitante, esto para agilizar el proceso de comprobación de la solicitud. La
identificación del solicitante (nombres, apellidos, ID que le proporciona la empresa) serán
llenados automáticamente en el formulario. Posteriormente, el sistema se encargará de
enviar la solicitud al supervisor del empleado para su comprobación. A partir de este
paso, el solicitante podrá ver el estado de su solicitud mientras esta pasa por las
siguientes fases del proceso.
En la segunda fase, el supervisor recibe la solicitud de reembolso por el sistema. El
sistema debe notificar al supervisor de que existe una solicitud pendiente para revisión,
y debe mantenerse así hasta que el supervisor realice la misma. El sistema debe mostrar
al supervisor toda la información suministrada en la solicitud y dar la opción de aceptar
o rechazar la solicitud de la misma. En caso de que la solicitud sea rechazada, el sistema
debe pedir una justificación al supervisor y enviarla de manera inmediata al usuario
solicitante. En caso de ser aceptada, el sistema envía la solicitud al departamento de
contabilidad de la empresa y, al mismo tiempo, envía una notificación al solicitante,
avisándole que su solicitud fue aceptada por el supervisor y fue enviada al departamento
de contabilidad.
En la tercera fase, el departamento de contabilidad recibe la solicitud de reembolso ya
aprobada por el supervisor del solicitante. Junto con la solicitud de reembolso, el sistema
debe mostrar al departamento de contabilidad los fondos disponibles por la empresa, y
en cuanto quedarían los fondos de la misma luego de confirmado el reembolso. Debe
mostrar la opción de confirmación de reembolso o del aplazamiento del mismo. En caso
de que se decida aplazar, el sistema debe preguntar por una fecha en la cual el
reembolso se hará automáticamente, en esta fecha, el sistema depositará el reembolso
a la cuenta del solicitante automáticamente y le notificara al solicitante que su reembolso
está disponible para retirar. En caso de ser aprobado el reembolso directamente, el
mismo se depositará a la cuenta del solicitante y le notificará al mismo que su reembolso
está disponible para retirar. Luego de esto, el sistema automáticamente añade el
reembolso al reporte de contabilidad de la empresa como un gasto pagado por la misma.
En la Base de Datos del sistema se almacenará toda la información de los empleados
de la empresa (nombres, apellidos, IDs que les proporciona la empresa, no. de cuenta,
etc.) y un servidor web se encargará de tramitar todas las fases del proceso de
reembolso, desde la solicitud hasta el retiro del mismo por el solicitante.
El sistema debe permitir la incorporación y/o modificación de la información de
empleados en su base de datos. Debe ser diseñado de manera que su mantenimiento
se haga de manera sencilla. Debe ser estable, ágil y fácil de usar para los usuarios del
mismo. Debe tener guías y ventanas interactivas de ayuda de fácil acceso a los usuarios.
En caso de caídas del mismo, el sistema debe tener la capacidad de guardar el estado
del último proceso realizado antes de la caída, y poder volver a iniciarse en un tiempo
estimado de 15 segundos o menos.
1. Requisitos Funcionales
Identificador
(ID) de la Nivel de Nivel de
historia Historia de usuario importancia complejidad
1 Yo como Gerente de recursos humanos quiero MUST 2
que el sistema tenga un reporte mensual de los
rembolsos realizados para poder tomar el control
de los rembolsos.
2 Yo como Gerente general del departamento de MUST 3

contabilidad quiero que todos mis usuarios
puedan loguearse para entrar al sistema con
mayor seguridad.
3 Yo como empleado quiero que el sistema tenga MUST 1

un formulario para solicitar un reembolso.
4 Yo como Director Ejecutivo quiero que el MUST 1

sistema no proceda con el proceso de reembolso
sin antes contar con la aprobación del supervisor
del empleado solicitante del reembolso.
5 Yo como Director de sistemas de información SHOULD 2

quiero que mis empleados puedan ver el estado
proceso de su solicitud de reembolso.
6 Yo como Gerente de recurso humanos deseo una MUST 13

vía para supervisar las acciones realizada en el
sistema, para poder notificar errores
7 MUST 3
Yo como director ejecutivo quiero que el sistema
le muestre a los supervisores las informaciones de
reembolso de manera organizada.
8 Yo como Director de tecnología quiero que el MUST 2

sistema debe mostrarle al usuario si fue
rechazado el reembolso y por qué para que los
usuarios tenga información detallada acerca de
todo el proceso.
9 Yo como Auxiliar contable quiero que el sistema SHOULD 2

muestre el monto a reembolsar para facilitar el
registro del reembolso.
10 Yo como Director técnico quiero que En caso de SHOULD 8

que se aplace el reembolso el sistema debe
preguntar una fecha para reembolsar el monto
automáticamente para que no quede rembolsos
pendientes.
11 Yo como Administrador de la compañía quiero WOULD 3

que el sistema tenga un historial de solicitudes
completadas para referenciar la aceptación del
sistema
12 Yo como director ejecutivo quiero que el sistema MUST 5

permita la incorporación y/o modificación de los
empleados en su base de datos.
13 Yo como Jefe de operaciones quiero que el WOULD 1

sistema debe tener un chat para los usuarios para
que puedan preguntar y estar pendiente por su
reembolso.
14 SHOULD 3
Yo como empleado del recursos humanos quiero
que el sistema cuente con un menú de ayuda para
ayudar a los empleados nuevos a adaptarse
rápidamente al sistema.
15 Yo como director de tecnología quiero que el SHOULD 3

sistema guarde la información de los campos
nombre, apellido y puesto de trabajo cuando el
usuario se loguee para que se rellene el
formulario automáticamente.
16 MUST 5
Yo como director general quiero que el sistema
permita que los empleados puedan cancelar sus
solicitudes de reembolso.
17 Yo como Secretario general quiero que el sistema MUST 8

debe permitir que el solicitante pueda modificar
la solicitud de reembolso y reenviarla para
cualquier error ocurrido pueda solucionar de
forma más fácil.
18 Yo como empleado quiero que el sistema me MUST 1

permita elegir el método de pago de reembolso.
19 Yo como director general quiero que el sistema SHOULD 3

tenga un periodo de tiempo cerrado para realizar
las solicitudes de reembolso.
20 Yo como director de tecnología me gustaría que SHOULD 13

el sistema permita cambiar a varios idiomas.
2. Requisitos No Funcionales
2.1 Requisitos de usabilidad.

2.1.1 El sistema debe estar diseñado de manera que todo tipo de usuarios puedan
usarlo con facilidad.
2.1.2 El sistema debe proporcionar mensajes de error que sean informativos y

orientados a resolver el mismo.
2.1.3 El sistema debe tener un diseño interactivo con el usuario.
2.2 Requisitos de Seguridad.

2.2.1 El sistema debe presentar información confidencial (como contraseñas y
números de tarjetas de crédito) con asteriscos.
2.2.2 El sistema debe asegurarse que la cantidad de dígitos de la clave de todos sus
usuarios sea mayor de 6 dígitos.
2.3 Requisitos de Hardware

2.3.1 El sistema debe correr en máquinas que tengan al menos 2GB de RAM y
procesador de 1.5GHz
2.3.2 El sistema debe correr en máquinas con conexiones de internet activa de al

menos 1MB.
2.4 Requisitos de Software

2.4.1 SQL Server
2.5 Requisitos de Fiabilidad

2.5.1 Después de completado, el formulario de solicitud de reembolso debe pasar de
una fase a otra en menos de 5 segundos.
2.5.2 Después de lograr la autenticación en el sistema, el mismo debe cargar toda la

información y funcionalidades en 10 segundos o menos.
2.5.3 El sistema debe realizar un backup de información automáticamente.

DECANATO DE
INFORMÁTICA
ANALISIS Y DISEÑO DE SISTEMAS II

(INF-161)
GRUPO 43050
Práctica
MODELOS DE CASO DE USO (Narrativa
de Casos de Uso)
Grupo #4
Periodo
2018-2
JULIO 4, 2018

CUS01 – Autenticación en el Sistema.
Caso de Uso Autenticarse en el sistema <<CUS01>>

Actor(es) Empleado
Tipo Básico
Propósito Permitir a los usuarios entrar al sistema con su cuenta
única
Referencias CUS02, CUS03, CUS04, CUS05
Precondición(es) 1. El empleado debe abrir el software.
2. El usuario debe ingresar sus credenciales.
Post-Condición El sistema permite al usuario entrar al sistema para hacer
uso del mismo.
Autor(a) Omar Severino Fecha 28/06/2018 Versión 1.1
Resumen
Este caso de uso inicia cuando el usuario abre el software. El software le pide
al usuario ingresar sus credenciales; el usuario procede a ingresar sus
credenciales. El software verifica que las credenciales sean correctas, en caso
afirmativo, el mismo permite al usuario ingresar al sistema y hacer uso de todas
sus funcionalidades.
Flujo Básico
Paso Actor(es) Sistema
FB1 El caso de uso comienza cuando
un empleado abre el software del
sistema.
FB2 El sistema le pide al usuario
ingresar sus credenciales.
FB3 El usuario ingresa sus
credenciales.
FB4 El sistema verifica en su base de
datos que la información
suministrada por el usuario es
correcta, y le permite ingresar al
sistema.
Flujos Alternos
FA1 en FB3: El usuario no recuerda su contraseña de ingreso.
FA1.1 El usuario selecciona la opción de
“Olvide mi contraseña”
FA1.2 El sistema muestra el formulario
de restablecimiento de
contraseña.
FA1.3 El usuario ingresa los datos que
pide el formulario de
restablecimiento de contraseña.
FA1.4 El sistema valida estos datos y
procede a pedir una nueva
contraseña.
FA1.5 El usuario ingresa la contraseña
nueva.
FA1.6 El sistema actualiza la base de
datos y vuelve a la pagina principal
para que el empleado ingrese al
sistema.
FA1.7 El usuario ingresa sus
credenciales.
FA1.8 El sistema verifica los datos en su
base de datos y actua acorde al
resultado de la comprobación de
los datos.
Flujos de Error
FE1 en FB4: Datos de autenticación incorrectos.
FE1.1 El usuario introduce las

credenciales erróneas.
FE1.2 El sistema despliega un mensaje
indicando que el usuario o
contraseña son incorrectos.
1.1.1. CUS02 – Creacion de Solicitud de Reembolso
Caso de Uso Crear Solicitud <<CUS02>>

Actor(es) Usuario
Tipo Básico
Propósito Permitir al usuario crear una solicitud de reembolso.
Precondición 1. El usuario ha iniciado sesión en el sistema.
2. El usuario selecciona la opción de crear una
solicitud.
Post-condición La solicitud de reembolso se envía al portal del supervisor
del empleado en cuestión para su aprobación.
Resumen
Este caso de uso inicia cuando el empleado selecciona la opción de crear una
solicitud de reembolso. El sistema le muestra el formulario al empleado y el
mismo rellena el formulario con la información correspondiente. Una vez
llenado el formulario en su totalidad, el usuario presiona el botón de “Solicitar
reembolso”, a partir de ahí, el sistema envía el formulario de reembolso al
supervisor del empleado en cuestión.
Flujo Básico
FB1 El usuario selecciona la opción de
“Crear solicitud”.
FB2 El sistema muestra el formulario
de solicitud.
FB3 El usuario llena la información de
la solicitud, y clickea “Enviar
solicitud”
FB4 El sistema envía la solicitud al
portal del supervisor del empleado
en cuestión.
Flujos Alternos
FA1 en FB3: El usuario decide cancelar la solicitud de reembolso.
FA1.1 El usuario selecciona la opción de
“Cancelar Solicitud”.
FA1.2 El sistema cierra la ventana del
formulario de solicitud.
Flujos de Error
FE1 en FB3: El usuario no llena la solicitud completamente.
FE1.1 El usuario deja un campo de la
solicitud en blanco.
indicando que todos los campos
de la solicitud deben estar
llenos.
1.1.2. CUS03 – Comprobacion de Solicitud por Supervisor
Caso de Uso Comprobar Solicitud <<CUS03>>

Actor(es) Usuario
Tipo Básico
Propósito Permitir al supervisor aprobar o denegar la solicitud de
reembolso de un empleado.
Referencias CUS02
Precondición 1. El usuario ha iniciado sesión en el sistema.
2. El supervisor tiene solicitudes de reembolso
pendientes por comprobar.
Post-condición La solicitud de reembolso pasa al departamento de
contabilidad con la información de la cantidad de dinero a
reembolsar, y dicho departamento procede a efectuar el
reembolso.
Resumen
Este caso de uso empieza cuando el supervisor inicia sesión en el sistema y
entra a la ventana de solicitudes pendientes. El supervisor selecciona una
solicitud y el sistema muestra la información de la misma. El supervisor decide
si aceptar o negar la solicitud. En caso de ser aceptada, la solicitud pasa al
departamento de contabilidad para procesar el reembolso; en caso de ser
negada, el sistema le notifica al empleado junto con un mensaje de
justificación por parte del supervisor.
Flujo Básico
FB1 El supervisor entra a la ventana
de “Solicitudes Pendientes”
FB2 El sistema muestra las solicitudes
pendientes.
FB3 El supervisor selecciona una
solicitud pendiente.
FB4 El sistema muestra la información
de la solicitud de reembolso y da
la opción de aceptar la misma o
denegarla.
FB5 El supervisor selecciona la opción
de aceptar la solicitud.
FB6 El sistema transfiere la solicitud al
departamento de contabilidad
donde será procesado el
reembolso.
Flujos Alternos
FA1 en FB5: El supervisor niega la solicitud.
FA1.1 El supervisor selecciona la opción
de negar la solicitud.
FA1.2 El sistema presenta la ventana con
un cuadro de texto donde el
supervisor debe explicar porque
niega la solicitud del empleado.
FA1.3 El supervisor escribe en el cuadro
de texto su justificación y
selecciona la opción de “Enviar
Justificacion”.
FA1.4 El sistema manda al empleado
solicitante la notificación junto
con el mensaje de justificación del
supervisor.
Flujos de Error
FE1 en FA1.3: El supervisor envía la solicitud sin escribir justificacion.
FE1.1 El supervisor selecciona la opción
de “Enviar Justificacion” sin
haber escrito nada en el cuadro
de texto
indicando que el cuadro de texto
no puede estar vacio.
1.1.3. CUS04 – Reporte mensual de reembolsos.
Caso de Uso Autenticarse en el sistema <<CUS04>>

Actor(es) Empleado, Supervisor
Tipo Básico
Propósito Permitir tanto a los usuarios como los supervisores tener
constancia de los reembolsos en que participan.
Referencias CUS02, CUS03
Precondición(es) 1. El usuario debe iniciar sesión en el sistema
2. Deben haberse hecho solicitudes de reembolsos
Post-Condición El sistema recopila todas las solicitudes de reembolsos en
una ventana donde los usuarios del sistema podrán tener
constancia de todas las solicitudes de reembolsos hechas
previamente.
Resumen
Este caso de uso inicia cuando ya se ha realizado un reembolso. El mismo queda
almacenado en una ventana, visible a los usuarios del sistema, denominada
“Historial de Reembolsos” con toda la información suministrada por el
solicitante del reembolso, asi como también información de la fecha en la que
fue solicitado, aceptado o denegado el reembolso. En caso de haber sido
negado el reembolso, también muestra el mensaje de justificación del
supervisor.
Flujo Básico
FB1 El usuario solicita un reembolso.
FB2 El sistema guarda constancia de la
solicitud en la ventana de
“Historial de Reembolsos”
FB3 El supervisor acepta la solicitud
del reembolso y la misma pasa al
departamento de contabilidad.
FB4 El sistema actualiza la constancia
de la solicitud en base a la
aceptación de la solicitud por el
supervisor.
FB5 El departamento de contabilidad
completa el reembolso
FB6 El sistema actualiza la constancia
de la solicitud en base a la
culminación del reembolso por
parte del departamento de
contabilidad.
1.1.5 CUS05 – Estado de la Solicitud

Caso de Uso Estado de la solicitud <<CUS05>>
Actor(es) Empleado
Tipo Básico
Propósito Permitir al empleado ver el estado de la solicitud del
reembolso.
Referencias
Precondición(es) 3. El empleado accede al sistema.
4. El empleado ha solicitado un reembolso.
Post-Condición Una vez enviada la solicitud, el sistema le muestra al
empleado el estado en que se encuentra dicha solicitud.
Autor(a) Yileisy Luciano Fecha 28/06/2012 Versión 1.1
Resumen
Este caso de uso se inicia cuando el empleado accede al sistema. Una vez el
empleado accede al apartado de “Estado de solicitud”, el sistema le muestra
todas las solicitudes enviadas. Por último, el empleado accede a la última
solicitud enviada y el sistema le muestra su estado.
Flujo Básico
FB1 El caso de uso comienza cuando FB2 El sistema le muestra la
un empleado ingresa al sistema. página principal.
FB3 El empleado accede al apartado FB4 El sistema busca en la base

de “Estado de solicitud”. de datos las solicitudes
enviadas.
FB5 El empleado selecciona la FB6 El sistema accede a la
solicitud de la cual quiere saber solicitud y le muestra el
el estado. estado.
Flujos Alternos
FA1 en FB3: El en apartado “Estado de solicitud” el sistema permita crear
una solicitud.
FA1.1 El empleado accede al apartado FA1.2 El sistema accede al
de crear solicitud de reembolso. apartado y le muestra el
formulario de reembolso.
FA1.3 El empleado llena la solicitud de FA1.4 El sistema valida y registra
reembolso y lo envía. la solicitud.
Flujos de Error
FE1.1 El operador ingresa FE1.2 El sistema despliega un mensaje

información de indicando que el usuario o
autenticación errónea contraseña son incorrectos.
presiona el botón
“Entrar”.
FE2 en FB3: La solicitud de reembolso no existe.
FE2.1 El empleado accede al FE2.2 El sistema muestra un mensaje
apartado de “Estado de indicando que la solicitud del
solicitud”. reembolso no existe.
1.1.6 CUS06 – Supervisar acciones en el sistema.

Caso de Uso Supervisar acciones en el <<CUS06>>
sistema
Actor(es) Gerente de Recursos Humanos
Tipo Básico
Propósito Permitir al Gerente de recursos humanos supervisar las
acciones que se realizan en el sistema para controlar que
todo marche bien.
Referencias
Precondición(es) 1. El gerente de recursos humanos accede al
sistema.
2. Se dirige al apartado de “Registro de operaciones
realizadas”.
Post-Condición Una vez accedido al apartado de “Registro de operaciones
realizadas”, el sistema le muestra todos los movimientos
que se han hecho hasta el momento.
Resumen
Este caso de uso se inicia cuando el gerente de recursos humanos accede al
sistema y una vez el gerente de recursos humanos accede al apartado “Registro
de operaciones realizadas”, el sistema le muestra todos los movimientos que
se han realizado hasta el momento.
Flujo Básico
FB1 El caso de uso comienza cuando el FB2 El sistema le muestra la
gerente de recursos humanos página principal.
accede al sistema.
FB3 El gerente de recursos humanos FB4 El sistema busca en la base
accede al apartado “Registro de de datos y le muestra el
operaciones realizadas”. registro de todos los
movimientos que se han
realizado hasta el
momento.
Flujos Alternos
FA1 en FB3: El en apartado “Registro de operaciones realizada” el sistema
permite crear un documento de reporte.
FA1.1 El gerente de recursos humanos FA1.2 El sistema accede al
accede al apartado “Registro de apartado y le muestra la
operaciones realizadas”. opción crear documento de
reporte.
FA1.3 El gerente de recursos humanos FA1.4 El sistema envía una
crear un documento de reporte notificación con el
para notificar que todo está documento adjunto a los de
marchando bien o si hay algún soporte técnico.
error y lo envía.
Flujos de Error

presiona el botón
“Entrar”.
FE2 en FB3: Registro de los movimientos realizados no existen
FE2.1 El gerente de recursos FE2.2 El sistema no le muestra ningún
humanos accede al registro de lo que se ha estado
apartado “Registro de haciendo.
operaciones realizada”
1.1.7 CUS07 – Informacion organizada del reembolso.

Caso de Uso Información organizada del <<CUS07>>
reembolso.
Actor(es) Supervisores
Tipo Básico
Propósito Permitir a los supervisores ver la información de los
reembolsos de manera organizada.
Referencias CUS01
Precondición(es) 1. El supervisor accede al sistema.
2. El supervisor accede al registro de reembolsos
realizados.
Post-Condición Después de acceder al registro, el sistema le muestra al
supervisor todos los reembolsos realizados de forma
organizada desde la última que se hizo, hasta la primera.
Resumen
Este caso de uso comienza cuando el supervisor ingresa al sistema. Una vez el
supervisor accede al apartado de “Registro de reembolsos”, el sistema muestra
todos los reembolsos realizados de manera organizada, desde el más reciente
hasta el más antiguo.
Flujo Básico
FB1 El caso de uso comienza cuando FB2 El sistema le muestra la
el supervisor ingresa al sistema. página principal y el menú.
FB3 El supervisor accede al apartado FB4 El sistema busca en la base de

de “Registro de reembolsos”. datos y muestra todos los
reembolsos que se han hecho,
de manera organizada, desde
la más reciente hasta la más
antigua.
Flujos Alternos
FA1 en FB3: El en apartado “Registro de reembolsos” el sistema permite
elegir el modo de visualización de los reembolsos realizados.
FA1.1 El supervisor puede FA1.2 El sistema accede al
seleccionar ver reembolsos: apartado seleccionado y le
por empleado, por año, por muestra de manera
mes, por día o por monto organizada, desde el más
reembolsado. reciente al más antiguo, los
reembolsos realizados en
esa categoría.
Flujos de Error
FE1.1 El supervisor ingresa FE1.2 El sistema despliega un mensaje

autenticación errónea y contraseña son incorrectos.
presiona el botón
“Entrar”.
1.1.8 CUS08 – Motivo del Rechazo del Reembolso.

Caso de Uso Mostrar motivo del rechazo <<CUS08>>
del reembolso.
Actor(es) Empleado, supervisor
Tipo Básico
Propósito Permitir al empleado ver, en caso de que el reembolso haya
sido rechazado, el porqué del rechazo.
Referencias CUS01
Precondición(es) 1. El empleado accede al sistema.
2. El empleado ha solicitado un reembolso.
Post-Condición Una vez enviada la solicitud de reembolso, el supervisor ha
de haber rechazado la solitud, y al empleado acceder a los
apartados “Estado de solicitud y motivos de rechazo”, el
sistema le muestra al empleado que fue rechazada y el
porqué.
Resumen
El caso de uso comienza cuando el supervisor rechaza la solicitud del reembolso
y explica el porqué. Luego, el sistema le envía una notificación al empleado de
que la solicitud fue rechazada. Finalmente, el empleado accede al sistema a los
apartados de “Estado del reembolso y motivos de rechazo” y el sistema le
muestra toda la información.
Flujo Básico
FB1 El caso de uso comienza FB2 El sistema le exige la razón de
cuando el supervisor rechaza porque fue rechazada.
la solicitud del reembolso.
FB3 El supervisor rellena el FB4 El sistema le envía una notificación
apartado diciendo el motivo al empleado de que la solicitud fue
y lo envía. rechazada.
FB5 El empleado accede al FB6 El sistema le muestra que fue
apartado de “Estado del rechazada la solicitud.
reembolso”.
FB5 El empleado accede al FB6 El sistema muestra el motivo por el
apartado “Motivo del cuál fue rechazada.
rechazo”
Flujos Alternos
FA1 en FB3: El en apartado “Estado del reembolso” el sistema despliega una
notificación mostrando el motivo del rechazo.
FA1.1 El empleado accede al Estado del FA1.2 El sistema le despliega una
reembolso y le da “click” donde notificación mostrando el
dice “rechazado”. porqué.
Flujos de Error

presiona el botón
“Entrar”.
FE2 en FB1: Motivo del reembolso vacío.
FE2.1 El supervisor rechaza la FE2.2 El sistema despliega un mensaje
solicitud del reembolso y indicando que debe de escribir
lo envía. obligatoriamente el motivo del
rechazo antes de enviarlo..
1.1.9 CUS09 – Mostrar Monto a Reembolsar

Caso de Uso Mostrar el monto a <<CUS09>>
reembolsar
Actor(es) Auxiliar Contable
Tipo Básico
Propósito El sistema muestre el monto a reembolsar para facilitar
el registro del reembolso.
Referencias -
Precondición(es) 1. Un usuario ha solicitado un rembolso.
Post-Condición Si se ingresaron los datos para el reembolso de forma
correcta, se mostrara el registro con el monto a
reembolsar.
Autor(a) Luis Enrique Fecha 28/06/2018 Versión 1.1
Montero
Resumen
Este caso de uso se inicia cuando un auxiliar contable ingresa sus datos para
poder realizar el reembolso, el sistema valida si los datos de autenticación son
correctos y pasa a mostrar su perfil. En seguida, muestra un registro con los
datos de su reembolso.
Flujo Básico
FB1 comienza cuando un auxiliar de
contabilidad ingresa sus datos
para poder realizar el reembolso.
FB2 El sistema valida si los datos de
autenticación son correctos y pasa
a mostrar su perfil.
FB3 Se accede al perfil para que el
sistema pueda mostrar los
detalles al empleado.
FB4 El sistema muestra un registro con
los datos de su reembolso.
Flujos Alternos
FA1 en FB3: El auxiliar de contabilidad selecciona una opción diferente a
“nuevo”
FA1.1 El auxiliar contable selecciona
una opción diferente a “Nuevo”.
FA1.2 El sistema muestra los datos de la
pestaña seleccionada.
FA2 en FB2: El auxiliar de contabilidad valida si los datos de autenticación
son correctos.
FA2.2 El auxiliar contable presiona el
botón “revisar”, a fin de saber si
los datos de los empleados están
en la base de datos.
FA2.3 El sistema solicita los datos de la
persona.
FA2.4 El auxiliar contable ingresa los
datos de la persona y selecciona
“Guardar”.
FA2.5 El sistema despliega un mensaje
diciendo: “Datos almacenados
exitosamente”.
FA3 en FB1: Los datos del empleado no están actualizados.
FA3.1 El auxiliar contable selecciona el
empleado correspondiente y
presiona el botón “Modificar”.
FA3.2 El sistema muestra un formulario
con los datos del empleado y nos
permite modificarlos.
FA3.3 El auxiliar de contabilidad
actualiza los datos del ciudadano
y presiona el botón “Guardar”
exitosamente”.
FA4 en FB4: El auxiliar de contabilidad desea descartar la solicitud de
registro de felicitación.
FA4.1 El auxiliar de contabilidad
selecciona la opción “Descartar”.
FA4.2 El sistema redirige al operador
hacia la página de selección de
ciudadanos.
Flujos de Error
FE1.1 El auxiliar de contabilidad ingresa

información de autenticación
errónea presiona el botón
“Entrar”.
indicando que el usuario o
contraseña son incorrectos.
FE2 en FB7: No se ha seleccionado un empleado para registrar una
felicitación.
FE2.1 El auxiliar de contabilidad elige la
opción “Felicitación” sin haber
seleccionado un ciudadano.
FE2.2 El sistema muestra un mensaje
indicando que se debe seleccionar
un ciudadano antes de proceder a
registrar la felicitación.
1.1.10 CUS10 – Fecha de reembolso automático.

Caso de Uso Reembolso automatico. <<CUS10>>
Actor(es) Empleados, auxiliar de contabilidad
Tipo Básico
Propósito Establecer una fecha para realizar el reembolso
automáticamente de modo que no quede rembolsos
pendiente.
Precondición 1. Un empleado ha solicitado un reembolso.
2. Un auxiliar de contabilidad del área de recursos
humanos ha ingresado al sistema
Post-condición Si se ingresaron los datos de la consulta, ésta se registra y
se genera una carta de recibo que se puede imprimir o
enviar por correo.
Montero
Resumen
Este caso de uso se inicia cuando el departamento de contabilidad decide que
no es factible realizar el reembolso en la fecha de solicitud por lo que decide
aplazarlo; en ese caso, el sistema pregunta por una fecha en la que se deba
hacer el reembolso automáticamente.
Flujo Básico
FB1 El auxiliar de contabilidad aplaza
un reembolso
FB2 El sistema despliega un calendario
para que se indique una fecha
donde se deba realizar
automáticamente el reembolso.
FB3 El auxiliar de contabilidad indica
una fecha en el calendario.
FB4 En la fecha indicada, el sistema
realiza el reembolso de manera
automática al empleado
solicitante, al mismo tiempo que
le envía una notificación de que su
reembolso se ha efectuado.
Flujos de Error
FE1 en FB3: El auxiliar de contabilidad no ingresa una fecha de reembolso
automatico.
FE1.1 El usuario seleccióna la opción de
“Establecer fecha de reembolso
automatico” sin haber
especificado una fecha valida.
(Una fecha pasada se considera
fecha no valida).
indicando que se debe
especificar una fecha valida y
remite al auxiliar a la ventana de
especificación de fecha de
reembolso automatico.
1.1.11 Historial de Solicitudes Completadas.

Caso de Uso Historial de Solicitudes. <<CUS11>>
Actor(es) Auxiliar de contabilidad, empleados y gerentes de
departamentos.
Tipo Básico
Propósito un historial de solicitudes completadas para referenciar la
aceptación del sistema.
Precondición(es) 1. Un gerente ha solicitado ver todos los reembolsos
hechos en este mes.
2. Un auxiliar de contabilidad se ha buscado los
historiales en el sistema.
Post-Condición Si se ingresan la fecha del día de forma correcta el sistema
puede buscarte un registro de reembolsos por ese día.
Autor(a) Luis enrique Fecha 11/04/2012 Versión 1.1
Montero
Resumen
Este caso de uso se inicia cuando un gerente o un auxiliar de contabilidad
necesita un registro de la cantidad de reembolsos hechos por todo el mes , para
tener un control de cantidad de dinero reembolsada.
Flujo Básico
FB1 El caso de uso comienza cuando
el gerente pide un registro de los
reembolso del mes.
FB2 El sistema valida los datos del
gerente y lo envía hasta el menú
de registros.
FB3 El gerente selecciona la opción
“registros”.
FB4 El sistema re-direcciona al gerente
hacia la página de registros,
requiriendo los siguientes datos:
nombres, apellidos y fecha.
FB5 El operador ingresa los datos del
empleado y selecciona “Buscar”.
FB6 El sistema devuelve una lista de
resultados en base a la búsqueda
realizada por el operador.
FB7 El gerente busca el registro
correspondiente y elige la opción
de registro de reembolso por mes.
Flujos Alternos
FA2 en FB5: El gerente desea verificar los registros guardados en la base de
datos.
FA2.2 El gerente presiona el botón
“buscar”, a fin de buscar todos
los registro guardado en la base
de datos.
FA2.3 El sistema solicita los datos del
registro.
FA2.4 El gerente ingresa los datos del
registro y selecciona “Guardar”.
exitosamente”.
Flujos de Error
FE2 en FB7: No se ha seleccionado un registro.

FE2.1 El operador elige la opción
“entrar” sin haber seleccionado
buscar registros.
FE2.2 El sistema muestra un mensaje
indicando que se debe seleccionar
buscar registros antes de poder
entrar.
1.1.12 CUS 012 – Actualización de empleados en base de datos.

Caso de Uso Actualización información <<CUS12>>
de empleados.
Actor(es) Empleados, administradores de base de datos
Tipo Básico
Propósito Permita la incorporación y/o modificación de los
empleados en su base de datos.
Precondición(es) 1. Un empleado este registrado en el sistema.
Post-Condición La actualización de los datos de los empleados en la base
de datos del sistema.
Montero
Resumen
En este caso de uso, los administradores de bases de datos entran al sistema
con sus credenciales que los identifiquen como DBA, y agregan, modifican
información, o eliminan empleados de la base de datos del sistema.
Flujo Básico
FB1 El DBA ingresa al sistema con sus
credenciales que lo identifican
como DBA y se dirige a la base de
datos del sistema.
FB2 El sistema muestra toda la
información de la base de datos.
FB3 El DBA selecciona la opción de
“Agregar empleado”
FB4 El sistema le muestra el formulario
para agregar un empleado a la
base de datos.
FB5 El DBA llena los datos del
formulario y selecciona “Agregar
empleado”
FB6 El sistema agrega los datos nuevos
a la base de datos y despliega el
mensaje “Empleado añadido
correctamente”
Flujos Alternos
FA1 en FB3: El DBA selecciona la opción de “Modificar información”
FA1.1 El DBA selecciona la opción de
“Modificar información” y
selecciona al empleado de quien
quiere actualizar la información.
FA1.2 El sistema muestra todos los datos
del sistema.
FA1.3 El DBA selecciona al empleado de
quien quiere actualizar la
información.
FA1.4 El sistema muestra los datos del
empleado a modficar.
FA1.5 El DBA actualiza los datos del
sistema y presiona el botón de
“Guardar”
FA1.6 El sistema guarda la información y
despliega el mensaje de
“Informacion actualizada
correctamente”
FA2 en FB5: El DBA desea eliminar un empleado de la base de datos.
FA2.2 El DBA presiona el botón
“Eliminar datos”,
FA2.3 El Sistema muestra todos los los
empleados de la base de datos.
FA2.4 El DBA selecciona al empleado a
eliminar y selecciona la opción de
“Eliminar empleado”
FA2.5 El sistema elimina al empleado y
despliega el mensaje de
“Empleado eliminado
correctamente”
Flujos de Error
FE1 en FB6: El ID de empleado ya existe en la base de datos.
FE1.1 El DBA llena el formulario con un

usuario cuyo ID sea igual a otro
existente en la base de datos.
indicando ya existe un empleado
con ese ID.
1.1.13 CUS013 Ventana de Chat en todo el Sistema.

Caso de Uso Chat <<CUS13>>
Actor(es) Empleado, supervisores, Gerente de recursos Humanos
Tipo Básico
Propósito Permitir a todo el que este en el sistema conversar vía
chat
Referencias CUS2
Precondición(es) 1. El usuario debe haber hecho el login
satisfactoriamente
Post-Condición Se abre un chat para comunicaciones internas
Autor(a) Anderson del Fecha 28/06/2018 Versión 1.1
Rosario
Resumen
Este caso de uso se inicia cuando un Usuario accede al sistema y este presiona
la ventana chat, donde puede comunicarse internamente por la empresa
Flujo Básico
FB1 Este caso de uso se inicia cuando
un empleado accede al sistema y
este presiona la ventana chat
FB2 El sistema valida los datos del
operador y le abre las opciónes de
chat
FB3 El empleado decide con qué
departamento o persona desea
comunicarse
FB4 El sistema abre una ventada al
empleado con la persona o
departamento que selecciono.
FB5 El operador se comunica con la
opción selecionada
FB6 El sistema almacena el chat
realizado por el empleado.
Flujos de Error
FE1 en FB4: No tiene conexión a internet
FE1.1 El empleado envía un mensaje a

cualquier departamento o
persona, sin tener conexión a
intenet
indicando que el usuario no tiene
acceso a internet
1.1.14 CUS014 Menu de Ayuda.

Caso de Uso Menu de ayuda <<CUS014>>
Tipo Básico
Propósito Permitir a un empleado entrar en el menú de ayuda.
Precondición(es) 1. Un Empleado logea satisfactoriamente al sistema
2. Accede al formulario de reembolso.
Post-Condición Si se Presionó el menú de ayuda, el sistema despliega las
informaciones para orientar al empleado
Autor(a) Anderson Del Fecha 28/06/2018 Versión 1.1
Rosario
Resumen
Este caso comienza cuando el usuario presiona el botón de menú de ayuda,
donde podrá referenciarse a cualquier actividad que tenga que realizar este en
el sistema, con una documentación puntual de cómo hacerlo.
Flujo Básico
FB1 Este caso comienza cuando el
usuario presiona el botón de
menú de ayuda
FB2 El sistema accede a la base de
datos y abre el manual de del
sistema, dándole opciones al
usuario de que apartado del
sistema desea ayuda.
FB3 El empelado selecciona el
apartado de donde desea la
ayuda o assistencia
FB4 El sistema re-direcciona al
empleado hacia la página del
manual de ayuda selección del
empleado.
Flujos Alternos
FA1 en FB3: El empleado no encuentra su problema
FA1.1 El empleado selecciona la opción
de “Deseo asistencia técnica”
FA1.2 El sistema manda un mensaje al
supervisor del área, dándole la
ubicación del usuario que pide
ayuda.
FA1.3 El supervisor orienta al empleado
Flujos de Error
FE1 en FB1: El menú de ayuda no carga.
FE1.1 El empelado presiona el menú de

ayuda y este no responde.
indicando que el tiempo de espera
ha pasado y que hubo un error al
cargar el manual
1.1.15 CUS015 Autorellenado de campos de formulario.

Caso de Uso Atomatizacion de campos <<CUS015>>
Tipo Básico
Propósito El sistema llena autamticamente algunos campos del
formulario
Precondición(es) 1. Un Empleado logea satisfactoriamente al sistema
Post-Condición Se rellenan autmaticamente los campos nombre apellido
y puesto de trabajo
Rosario
Resumen
Este caso comienza cuando el usuario accede al formulario de reembolso, este
se rellena autamaticamente los campos nombre, apellido y puesto.
Flujo Básico
usuario accede al formulario de
reembolso
FB2 El sistema accede a la base de
datos y toma los campos nombre,
apellido y que estén asociados a la
cuenta logeada
FB3 El sistema rellena los campos
nombre, apellido y puesto
autamticamente del formulario de
reembolso
Flujos de Error
FE1 en FB2: El sistema no encuentra ningún nombre asociado a la cuenta
FE1.1 El empelado accede al formulario

de reembolso.
indicando que el no hay ningún
nombre asociado a la cuenta y
deniega el acceso de este al
formulario.
1.1.16 CUS016 Cancelar Solicitud de Reembolso.

Caso de Uso Cancelar solicitud de <<CUS016>>
reembolso
Tipo Básico
Propósito El usuario tiene la opción de cancelar su solicitud de
reembolso
Precondición(es) 1. Un Empleado haya solicitado un reembolso
Post-Condición Queda cancelada su solicitud
Rosario
Resumen
Este caso comienza cuando el usuario accede al formulario de reembolso, y
este selecciona cancelar solicitud, al aceptar y asegurar todas las credenciales
su solicitud queda cancelada.
Flujo Básico
usuario accede al formulario de
reembolso y presiona cancelar
solicitud de reembolso
FB2 El sistema le pregunta si esta
seguro de cancelar su solicitud de
reembolso
FB3 El usuario presiona en si esta
seguro de cancelar su solicitud de
reembolso
FB4 El sistema cancela su solicitud y la
quita de solicitudes pendientes, y
despliga un mensaje indicando
que “su solicitud fue cancelada
satisfactoriamente”.
Flujos Alternos
FA1 en FB3: El reembolso ya a sido aprovado
FA1.1 El sistema comprueba que la
solicitud fue aprobada y despliga
un mensaje diciendo que no es
posible cancelar la solicitud por
que ya fue aprovada
Flujos de Error
FE1 en FB2: No existe ninguna solicitud
FE1.1 El empelado accede al formulario

de reembolso.
indicando que el no hay ningún
ninguna solicitud para cancelar
1.1.17 CUS017 Modificar Solicitud.

Caso de Uso Modificar solicitud <<CUS17>>
Actor(es) Empleados, supervisores
Tipo Básico
Propósito Permitir al empleado la modificación de su solicitud
ante cualquier error detectado
Referencias
Precondición(es Haber enviado la petición de reembolso
)
Post-Condición Haber cambiado sin ningún problema los campos que
el empleado deseo.
Autor(a) Ralph Fecha Versión 1.1
Resumen
El caso de uso inicia cuando el empleado envía su solicitud de reembolso.
Una vez verificada su solicitud, se percata que tiene algún dato o archivo
adjunto erróneo. El sistema le permitirá la modificación y actualización
correcta de su solicitud, cuantas veces lo desee.
Flujo Básico
FB1 El caso de uso comienza
cuando un empleado envía su
solicitud
FB2 El sistema le muestra una opción
dentro de su solicitud, donde
puede realizar cualquier
modificación
FB3 El empleado realiza un cambio
FB4 El sistema valida que los datos
estén correctos y cumplan con
los requisitos.
FB5 El sistema envía un mensaje al
supervisor del área, sobre una
nueva solicitud
FB6 El supervisor aprueba la
solicitud
FB7 El sistema procede con el
reembolso
Flujos Alternos
FA1 en FB3: El empleado tiene un error, pero no se da cuenta
FA1.1 El empleado no hace ningún
cambio (piensa que esta todo
correcto)
FA1.2 El sistema valida que los datos
los requisitos.
FA1.3 El sistema envía un mensaje al
nueva solicitud
FA1.4 El supervisor rechaza la
solicitud
empleado diciendo: “Su
solicitud fue rechazada. Por
favor, verifique que los datos
de su solicitud estén correctos,
y de no ser así; modifique su
solicitud y reenvíela”
FA1.6 El empleado nota el error y
hace los ajustes de lugar
FA1.7 El sistema valida que los datos
los requisitos.
nueva solicitud
FA1.9 El supervisor aprueba la
solicitud
FA1.10 El sistema procede con el
reembolso
Flujos de Error
FE1 en FB3: El empleado no posee ningún error en su solicitud
FE1.1 El empleado envía todos sus

datos correctos
FE1.2 El sistema valida que los datos
estén correctos y cumplan con los
requisitos.
FE1.3 El sistema envía un mensaje al
nueva solicitud
FE 1.4 El supervisor rechaza la
solicitud
FE 1.5 El sistema envía un mensaje al
empleado diciendo: “Su solicitud
fue rechazada. Por favor, verifique
que los datos de su solicitud estén
correctos, y de no ser así;
modifique su solicitud y reenvíela”
FE 1.6 El empleado pierde su
reembolso (Lleno todos los
datos correctamente)
1.1.18 CUS018 Diferentes Formas de Pago.

Caso de Uso Formas de pago <<CUS18>>
Actor(es) Empleados, supervisor
Tipo Básico
Propósito Permitir a los empleados seleccionar la vía por donde
se le hará el pago del reembolso
Referencias
Precondición(es 1. Haber realizado algún gasto extra por motivos
) laborales
2. Haber iniciado sesión en el sistema
Post-Condición Si no se ha pasado de la fecha límite de solicitud,
proceder con el pago del reembolso
Resumen
Este caso de uso inicia al momento que el empleado se encuentre en la
plantilla de solicitud de reembolso. Una vez completados todos los
campos, se valida que el empleado haya seleccionado su método de pago;
por último, se realiza el pago del reembolso.
Flujos de Error
FE1 en FB2: No se ha seleccionado la forma de pago
FE1.1 El empleado llena todos los

datos necesarios, menos el
método de pago del reembolso.
FE1.2 El sistema valida que los datos
los requisitos.
FE1.3 El sistema envía un mensaje
indicando que no se puede
realizar el reembolso porque no
ha seleccionado el método de
pago del mismo
Flujo Básico
cuando un empleado ingresa a
la plantilla de solicitud de
reembolso.
FB2 El empleado llena todos los
datos necesarios, incluyendo
el método de pago del
reembolso
B3 El sistema valida que los datos estén
correctos y cumplan con los
requisitos.
supervisor del área, sobre una nueva
solicitud
solicitud
FB6 El sistema procede con el pago del
reembolso
1.1.19 CUS019 Limitar tiempo de Solicitud.

Caso de Uso Limitar tiempo de <<CUS19>>
solicitud
Actor(es) Empleados , supervisor
Tipo Básico
Propósito Limitar el tiempo de solicitud de reembolso, si el
empleado realizo su compra en un lapso de más de 45
días antes de su solicitud; no se realizará el
reembolso
Referencias
Precondición(es Haber realizado un gasto en tiempo de trabajo extra,
) asignaciones extras, etc.
Post-Condición Si se el empleado no paso el tiempo límite para
solicitar el reembolso, se procede con el pago del
mismo.
Resumen
Este caso de uso se inicia cuando el empleado envía su solicitud de
reembolso. Luego se verifica que todos los datos estén correctos,
incluyendo el tiempo de realizada su compra. Por último, indicar si ha
cumplido correctamente con los requisitos y proceder con el reembolso.
Flujo Básico
cuando el empleado envía su
solicitud de reembolso
FB2 El sistema valida los datos de la
solicitud , incluyendo la fecha y
la hora de la compra
nueva solicitud
solicitud
FB5 El sistema procede con el
reembolso al empleado
Flujos de Error
FE1 en FB2: Solicitud fuera de rango
FE1.1 El sistema valida los datos de la

solicitud, incluyendo la fecha y
la hora de la compra
FE1.2 El sistema despliega un
mensaje indicando que su
solicitud de reembolso esta
fuera del rango permitido
1.1.20 CUS020 Cambio de Idiomas.
Caso de Uso Alternar idiomas <<CUS20>>
Actor(es) Empleados
Tipo Básico
Propósito Permitir a los clientes el cambio de idioma en el
momento que gusten
Referencias
Precondición(es Acceder al sistema
)
Post-Condición Cambia al idioma que el usuario desea
Resumen
Este caso de uso se inicia antes del empleado iniciar sesión en el sistema.
Una vez en la pantalla del sistema se muestra una ventana de los diferentes
idiomas disponibles a cambiar. Por último, se cambia al idioma que el
empleado desea.
Flujo Básico
cuando un empleado se
encuentra en la pantalla de
inicio del sistema
FB2 El sistema le muestra un menú
con los diferentes idiomas
disponibles a cambiar
FB3 El empleado selecciona el
idioma al que desea cambiar
FB4 El sistema cambia por completo
el idioma del sistema al que el
empleado selecciono
Flujos de Error
FE1 en FB3: Cambio de idioma incorrecto
FE1.1 El empleado selecciona el

idioma al que desea cambiar
FE1.2 El sistema despliega un
mensaje que ha ocurrido un
error al cargar el idioma
DECANATO DE
INFORMÁTICA
ANALISIS Y DISEÑO DE SISTEMAS II

(INF-161)
GRUPO 43050
Práctica
Diagrama de Caso de Uso y Modelo de Negocio
Grupo #4
Periodo
2018-2
JULIO 5, 2018

Caso de uso Gestionar pago de reembolso
Caso de uso: Gestion de Solicitudes
Modelo del Dominio

El Espíritu Empresarial

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

El Espíritu Empresarial

Загружено:

Авторское право:

Доступные форматы

DECANATO DE

ANALISIS Y DISEÑO DE SISTEMAS II (INF-

Prof. Leandro Fondeur

DESCRIPCIÓN DEL OBJETO DE ESTUDIO.

DESCRIPCION DEL OBJETO DE AUTOMATIZACION.

2 Yo como Gerente general del departamento de MUST 3

3 Yo como empleado quiero que el sistema tenga MUST 1

4 Yo como Director Ejecutivo quiero que el MUST 1

5 Yo como Director de sistemas de información SHOULD 2

6 Yo como Gerente de recurso humanos deseo una MUST 13

8 Yo como Director de tecnología quiero que el MUST 2

9 Yo como Auxiliar contable quiero que el sistema SHOULD 2

10 Yo como Director técnico quiero que En caso de SHOULD 8

11 Yo como Administrador de la compañía quiero WOULD 3

12 Yo como director ejecutivo quiero que el sistema MUST 5

13 Yo como Jefe de operaciones quiero que el WOULD 1

15 Yo como director de tecnología quiero que el SHOULD 3

17 Yo como Secretario general quiero que el sistema MUST 8

18 Yo como empleado quiero que el sistema me MUST 1

19 Yo como director general quiero que el sistema SHOULD 3

20 Yo como director de tecnología me gustaría que SHOULD 13

2.1 Requisitos de usabilidad.

2.1.2 El sistema debe proporcionar mensajes de error que sean informativos y

2.1.3 El sistema debe tener un diseño interactivo con el usuario.

2.2 Requisitos de Seguridad.

2.3 Requisitos de Hardware

2.3.2 El sistema debe correr en máquinas con conexiones de internet activa de al

2.4 Requisitos de Software

2.5 Requisitos de Fiabilidad

2.5.2 Después de lograr la autenticación en el sistema, el mismo debe cargar toda la

2.5.3 El sistema debe realizar un backup de información automáticamente.

ANALISIS Y DISEÑO DE SISTEMAS II

Santo Domingo, D. N., República Dominicana

Caso de Uso Autenticarse en el sistema <<CUS01>>

FE1.1 El usuario introduce las

1.1.1. CUS02 – Creacion de Solicitud de Reembolso

Caso de Uso Crear Solicitud <<CUS02>>

1.1.2. CUS03 – Comprobacion de Solicitud por Supervisor

Caso de Uso Comprobar Solicitud <<CUS03>>

1.1.3. CUS04 – Reporte mensual de reembolsos.

Caso de Uso Autenticarse en el sistema <<CUS04>>

1.1.5 CUS05 – Estado de la Solicitud

FB3 El empleado accede al apartado FB4 El sistema busca en la base

FE1.1 El operador ingresa FE1.2 El sistema despliega un mensaje

1.1.6 CUS06 – Supervisar acciones en el sistema.

FE1.1 El operador ingresa FE1.2 El sistema despliega un mensaje

1.1.7 CUS07 – Informacion organizada del reembolso.

FB3 El supervisor accede al apartado FB4 El sistema busca en la base de

FE1.1 El supervisor ingresa FE1.2 El sistema despliega un mensaje

1.1.8 CUS08 – Motivo del Rechazo del Reembolso.

FE1.1 El operador ingresa FE1.2 El sistema despliega un mensaje

1.1.9 CUS09 – Mostrar Monto a Reembolsar

FE1.1 El auxiliar de contabilidad ingresa

1.1.10 CUS10 – Fecha de reembolso automático.

1.1.11 Historial de Solicitudes Completadas.

FE2 en FB7: No se ha seleccionado un registro.

1.1.12 CUS 012 – Actualización de empleados en base de datos.

FE1.1 El DBA llena el formulario con un

1.1.13 CUS013 Ventana de Chat en todo el Sistema.

FE1.1 El empleado envía un mensaje a

1.1.14 CUS014 Menu de Ayuda.

FE1.1 El empelado presiona el menú de

1.1.15 CUS015 Autorellenado de campos de formulario.

FE1.1 El empelado accede al formulario