Caso 7 Los Rapidos SA - Gestion de una empresa de ambulancias.docx

Proyecto: Gestión
de una empresa de Ambulancias
Versión Producto: 1.5 Cliente: LOS RAPIDOS S.A.
Nombre del Documento: DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE SDD Versión: 1.5
Plantilla compilada por: Ph.D. Franklin Parrales Bravo Página: 1
GESTIÓN DE UNA EMPRESA DE AMBULANCIAS
Plantilla inspirada en el estándar IEEE 1016-2009 y adaptada a las necesidades del curso de
Diseño y Arquitectura de Software
(Plantilla compilada por Ph.D. Franklin Parrales B.)
Integrantes del proyecto:
⮚ Carlos Andrés Diaz Suarez
⮚ Mateo Israel Tobar Heredia
⮚ Intriago Santana Jean Franco
⮚ Erick Gabriel Campuzano Torres
⮚ Angel Daniel Mendoza Urgilés
⮚ José Manuel Carranza Ruiz
⮚ Farid Stephano Bardellini Vanoni
Tabla de contenido
1. INTRODUCCIÓN 3

Proyecto: Gestión
1.1. OBJETIVO 3
1.2. DEFINICIONES,ACRÓNIMOS Y ABREVIATURAS 3
1.3. AUDIENCIA 3
1.4. ALCANCE 4
2. PRESENTACIÓN DEL PRODUCTO 4
2.1. PROPÓSITO DEL SISTEMA 4
2.2.1. Planteamiento del problema 4
2.2.2. Objetivo 5
2.2.3. Alcance 5
2.2.4. El Sistema no contempla 5
2.2. RIESGOS 6
3. DESCRIPCIÓN GENERAL 6
3.1. CONTEXTO DEL PRODUCTO 6
3.2. PERSPECTIVAS FUTURAS DEL PRODUCTO 6
3.3. REGLAS Y FUNCIONES DE NEGOCIO 6
4. REQUISITOS 11
4.1. FUNCIONALES 11
4.2. NO FUNCIONALES 27
4.2.1. Tamaño y rendimiento 38
4.2.2. Calidad 38
5. ARQUITECTURA DEL PRODUCTO/SISTEMA 39
5.1. VISTADE CASOS DE USO 39
5.1.1. Actores 39
5.1.2. Modelo de casos de Uso 40
5.1.3. Lista de casos de Uso 46
5.1.4. Descripción de los Casos de Uso 47
5.2. VISTAFUNCIONAL 81
5.2.1. Modelo de Análisis 81
5.2.2. INTERFACES CON EL USUARIO 98
5.3 VISTA LÓGICA 110
5.3.1 DESCRIPCIÓN 110
5.3.2 PAQUETES DE DISEÑO ARQUITECTÓNICAMENTE SIGNIFICATIVOS. 110
5.3.3 VISTADE IMPLEMENTACIÓN –COMPONENTES 110
5.4 VISTADE DESPLIEGUE –AMBIENTE FÍSICO 110
5.5 VISTADE DATOS 110
5.5.1 DEFINICIONES 110
5.5.2 DISEÑO DE BASE DE DATOS 110
5.6 REQUISITOS DE SOFTWARE/HARDWARE 110
6. CALIDAD 111
7. OBSERVACIONES 111

Proyecto: Gestión
1. Introducción
1.1. Objetivo
El objetivo de este documento es dar un resumen de todo lo que se va a aplicar de acuerdo
con el producto solicitado (aplicativo para gestionar ambulancias), usando los métodos
necesarios para generar una buena arquitectura y describir los diferentes aspectos que
tendrá el sistema. Con el fin de gestionar de mejor manera los diversos servicios solicitados.
1.2. Definiciones, Acrónimos y Abreviaturas
Término Definición Alias Abrevia
tura
Flota de
ambulancias
Sitio donde se encuentran todas las
unidades de ambulancias disponibles para
ser utilizadas al momento de que sesolicite
un traslado de urgencia.
Flota de
Ambulancias
FA
Usuario Es la persona a la cual se le brindará el
servicio de traslado hacia un hospital.
Enfermo
Conductor Persona encargada de brindar el servicio
de movilización al usuario de forma
urgente, de acuerdo con la solicitud
recibida o asignada por el sistema.
Conductor
Asignar
ambulancias
Proceso automático del sistema para
asignar el servicio a cualquiera de las
unidades que se encuentren disponibles
dentro de la FA para brindar el servicio.
Asignar
ambulancias
Informe Proceso que se realizará mensualmente
para llevar un registro de los servicios
dados durante el mes y ver que
conductores realizaron estos serán
presentados al gerente.
Reporte Rep
1.3. Audiencia
Stakeholder Rol Responsa-
bilidad
Intereses
Criterios de
éxito Preocupación
Competenci
as técnicas/
Relación de

Proyecto: Gestión
ambiente de
trabajo
Gerente Usuario
directo
Gestiona el
sistema
Verificar
mensualmente
mediante
informes el
desempeño y la
asignación de
servicios a cada
uno de sus
conductores.
Mejor
rentabilidad,
Mejor manejo
de datos
Los tiempos de
respuestas sean
extensos y por
ende perdida de
fiabilidad,
Fallo en el
sistema,
baja de
solicitudes
de servicios,
mal manejo
de los datos
Cliente Usuario
indirecto
Se encarga
de solicitar
los servicios
Mayor facilidad
en pedir el
servicio y menor
tiempo de
respuesta
Optimización
en tiempo de
respuesta a la
solicitud
enviada.
Caídas del
sistema que
afecten el
servicio
solicitado de
urgencia
Errores de
tipeo, falta
de
información,
petición no
enviada
correctamen
te
Conductor Usuario
directo
Encargado
de proveer el
servicio
solicitado
Mejoramiento
en la gestión de
los servicios que
se le sean
asignados, sin
sobrecargarlo de
trabajo.
Mejor
asignación de
servicios y
respuesta
Largos tiempos
de espera entre
peticiones
Mal
funcionamie
nto del
sistema
1.4. Alcance
Eldocumento presente engloba la forma de la arquitectura del sistemade gestiónpor medio
del uso de diversas vistas a aplicar, como los casos de uso, el análisis de los requerimientos,
el diseño y modelado del sistema, su correcta implementación. De igual forma se detallarán
los procesos que deberá seguir el cliente para dar un correcto uso al aplicativo y manejar los
datos de forma correcta.
2. Presentacióndel Producto
2.1. Propósito del Sistema
2.2.1. Planteamiento del problema
El problema de la empresa de ambulancia LOS RAPIDOS S. contempla la correcta
asignación de choferes a las ambulancias disponibles, asignación de ambulancia a los
servicios contratados, revisión de los estados físicos de los vehículos, su disponibilidad
en el taller, registro de datos personales de los conductores, así como de su horario

Proyecto: Gestión
laboral, días de vacaciones y libres y envío de cobros de servicios enviados a los clientes
al finalizar el mes.
Afecta a: Clientes de la empresa LOS RAPIDOS S.A, clientes directos, conductores de la
empresa, directivos principales, administrativos, trabajadores asignados a el manejo de
los problemas, secretarios, mecánicos del taller de la empresa, etc.
Cuyo impacto es:
• El tiempo empleado en realizar asignaciones puede ser largo y puede ser
aprovechado en otros recursos.
• El personal puede perder los apuntes manuales de las gestiones realizadas.
• El error humano alrealizar alguna asignación,chequeo o ingreso de datos incorrecto.
• El personal encargado de realizar dichas tareas en vez de poder estar gestionando
otros problemas más.
• La productividad en general de la empresa al concentrarse en dichas acciones las
cuales pueden llegar a ser automatizadas con un sistema.
2.2.2. Objetivo
Para la empresa LOS RAPIDOS S.A quienes tienen como necesidad el manejo, asignación
y control de las unidades de ambulancia disponibles con el personal contratado, junto
con una práctica notificación de cuentas por pagar a sus clientes de prestadores del
servicio de manera automática, el sistema es una estrategia y solución que beneficiaría
alcontrol, brindara eficaciayrespuesta inmediata provocando una mayor productividad
y manejo de recursos como tiempo y talento humano para el staff administrativo,
quienes no tendrán que preocuparse más por la problemática principal.
2.2.3. Alcance
Una solución satisfactoria permitirá:
• Que el sistema pueda tener registrado los datos personales de los conductores de la
empresa, así mismo con datos de sus jornadas laborales: días trabajados, días libres y
de vacaciones
• Que el sistema pueda hacer llegar a los bancos los recibos de cobros realizados a los
clientes de la empresa LOS RAPIDOS S.A.
• Que una vez al mes se enliste los servicios a los que esta enlistado cada conductor.
• Que se pueda asignar cada conductor a una ambulancia correspondiente.
• Que se pueda registrar y ver si la ambulancia está disponible o no para sus funciones
y si se encuentra en el taller.
• Que se pueda asignar cada ambulancia a su servicio registrado para su respectivo
trabajo.
• Que se pueda dar de baja cuando corresponda al conductor seleccionado de la
empresa y a su vez todas sus asignaciones también se den de baja.
2.2.4. El Sistema no contempla
• Funciones tales como realizar el procedimiento de cobro directamente a los clientes,
solo receptar los recibos de cobro y enviarlos al banco.

Proyecto: Gestión
• Una vez asignado un conductor a una ambulancia, la reversión de dicha acción, así
mismo como la de las ambulancias a los diferentes servicios ofrecidos por la empresa.
• El registro de varios tipos de usuarios que puedan manipular las acciones de
asignaciones ya hechas en el sistema.
• El envío de notificaciones a los conductores ya asignados a una ambulancia.
• Notificaciones unas veces hechas alguna asignación.
2.2. Riesgos
Factor de riesgo Probabilidad Impacto
Estrategia de
mitigación Responsable
Falta de
disponibilidad
del gerente de
LOS RAPIDOS S.A
para definir
alcances
Media Alto Gerente del
proyecto
Falta de
disponibilidad
del gerente de
LOS RAPIDOS S.A
para definir la
ejecución del
documento
Media Alto Gerente del
proyecto
3. DescripciónGeneral
3.1. Contexto del Producto
A diferencia de nuestro proceso de gestión actual es el de brindar traslado de enfermos por
nuestra flota de ambulancias, sea de una unidad y su conductor asignado, nuestro
producto tiene mejor dirección al momento de dar de baja a los conductores por la gran
cantidad de conductores y vehículos se les aparte totalmente de sus deberes, para brindar
un mejor servicio.
3.2. Perspectivas futuras del producto
Una mejor asignación para los conductores y ambulancias en sus respectivas actividades y
poder brindar mejoras y eficiencia al momento de llegar a un destino en el tiempo menos
posible.
3.3. Reglas y Funciones de Negocio
Proceso de GESTION DE ASIGNACION DE AMBULANCIA: Situación propuesta (AS IS)

Proyecto: Gestión
Proceso de GESTION DE ASIGNACION DE AMBULANCIA: Situación propuesta (TO BE)
Proceso de ASIGNACIÓN DE RUTA: Situación propuesta (AS IS)

Proyecto: Gestión
Proceso de ASIGNACIÓN DE RUTA: Situación propuesta (TO BE)

Proyecto: Gestión
Proceso de COMPRA DE UN NUEVO VEHICULO: Situación propuesta (AS IS)
Proceso de COMPRA DE UN NUEVO VEHICULO: Situación propuesta (TO BE)
Proceso de REGISTRO DE CLIENTE: Situación propuesta (AS IS)

Proyecto: Gestión
Proceso de REGISTRO DE CLIENTE: Situación propuesta (TO BE)

Proyecto: Gestión
4. REQUISITOS
4.1. Funcionales
Número: RF1
Título: Autenticar usuario
Texto: El sistema permitirá la entrada de los usuarios a través de un proceso de
autentificación.
Tipo: Funcional - Acceso
Detalles de
requisitos y
restricciones:
El sistema debe permitir el acceso de los usuarios con rol y permiso de
gerente a través de una autentificación de datos.
Los datos son:
- Numero de identidad (tipo String – longitud 10)
- Contraseña (tipo String – longitud 20)
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Alta >
Número: RF2
Título: Registrar conductor
Texto: El sistema permitirá el registro del personal encargado para el rol de
conductor
Tipo: Funcional - Dato
Detalles de
requisitos y
restricciones:
El sistema deberá guardar el registro con los datos correspondientes para el
conductor. Estos datos son:
● Nombres y apellidos (tipo string-longitud 40)
● Numero de identidad (tipo string-longitud 10)
● Numero celular (tipo int-longitud 10)
● Dirección domiciliaria (tipo string-longitud 50)
● Unidad a cargo (tipo int-longitud 3)
● Horario laboral (tipo date – dd/mm/aaaa)
● Sueldo (tipo double-longitud 6)
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Alta >

Proyecto: Gestión
Número: RF3
Título: Editar conductor
Texto: El sistema permitirá la actualización de conductor respecto a los datos
personales y laborales del mismo.
Tipo: Funcional - Datos
Detalles de
requisitos y
restricciones:
El sistema actualizara los datos después de que hayan sido editados. La
edición podrá ser usada solo por el rol correspondiente con sus permisos para
poder actualizar los datos del conductor.
El conductor tendrá como campos de actualización los mismos con la que se
ingresaron al sistema:
Fecha de
revisión y
versión:
18/06/2022
versión 1.0
Prioridad: <Alta >
Número: RF4
Título: Listar conductor
Texto: El sistema permitirá verificar un listado de los conductores registrados.
Detalles de
requisitos y
restricciones:
El sistema permitirá mostrar un listado en el cual el usuario activo podrá
verificar el listado de los conductores registrados hasta la fecha.
Dicho listado tendrá filtros de activo y suspendido para la verificación de los
usuarios que estén en rotación activa.
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Baja >

Proyecto: Gestión
Número: RF5
Título: Eliminar conductor
Texto: El sistema permitirá la eliminación de los conductores registrados.
Detalles de
requisitos y
restricciones:
El sistema debe permitir la eliminación de los conductores que se les haya
dado de baja, se por motivo de fin de contrato u otro. Dicha eliminación solo
podrá realizarse si el usuario con rol de gerente aprueba dicha solicitud.
Cuando se elimine un conductor del registro, también se eliminarán todas sus
peticiones.
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Media>
Número: RF6
Título: Registrar ambulancia
Texto: El sistema permitirá el registro de las unidades que lleguen a la central.
Tipo: Funcional – Acceso.
Detalles de
requisitos y
restricciones:
El sistema deber permitir el registro de las unidades sin identificación que
lleguen a central. Dicho registro tendrá los campos de:
● Id de unidad (tipo String – longitud 4)
● Numero de placa (tipo String – longitud 6)
● Fecha de registro (tipo Date – formato dd/mm/aaaa)
● Conductor(es) a cargo (tipo int – longitud 2)
● Horario de disponibilidad (tipo Date – formato ss/mm/hh).
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Alta >
Número: RF7
Título: Editar ambulancia

Proyecto: Gestión
Texto: El sistema permitirá actualización del registro editado para las unidades.
Detalles de
requisitos y
restricciones:
El sistema actualizara los datos editados del registro de las unidades. Dichos
campos son:
● Horario de disponibilidad (tipo Date – formato ss/mm/hh)
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Alta >
Número: RF8
Título: Consultar ambulancia
Texto: El sistema consultar el registro de las ambulancias respecto las rutas y
horarios.
Detalles de
requisitos y
restricciones:
El sistema debe permitir consultar el registro de entrada y salida de las
unidades con su respectivo conductor activo en la unidad. Dicho registro
tendrá un filtro para verificar si se encuentra disponible en el momento de la
solicitud.
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Baja >
Número: RF9
Título: Eliminar ambulancia
Texto: El sistema permitirá la eliminación de las unidades del registro de unidades.

Proyecto: Gestión
Detalles de
requisitos y
restricciones:
El sistema debe permitir la eliminación y actualización de registro después de
borrar una unidad del sistema, ya sea por motivo de desuso de la unidad o por
otro motivo el cual será registrado en el informe una vez se haya aprobado a
la solicitud.
Dicha aprobación será dada únicamente por el usuario con rol de gerente y
tendrá un informe del mecánico en caso de ser la razón por “falla mecánica”.
Cuando se elimine una unidad del registro, también se eliminarán todas sus
peticiones.
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Media >
Número: RF10
Título: Crear cliente
Texto: El sistema permitirá el registro de los clientes que soliciten una petición por el
servicio.
Detalles de
requisitos y
restricciones:
El sistema debe permitir el registro de los clientes nuevos una vez soliciten
una petición de servicio. Dicho registro contendrá:
● Nombres y apellidos del solicitante (tipo String – longitud 50)
● Nombre de la entidad (tipo String – longitud 30)
● Numero de C.I. (tipo String – longitud 10)
● Fecha de registro (tipo date – formato dd/mm/aaaa)
● Numero de contacto (tipo String – longitud 10)
● Dirección de la entidad (tipo String – longitud 40)
En caso de no pertenecer a una entidad empresarial, se omitirán los campos.
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Alta >
Número: RF11
Título: Modificar cliente

Proyecto: Gestión
Texto: El sistema permitirá la actualización del registro de los clientes que soliciten
una petición por el servicio.
Detalles de
requisitos y
restricciones:
El sistema debe permitir actualizar el registro de los clientes una vez soliciten
una petición de servicio. Dicha actualización contemplara los siguientes
campos:
● Nombres y apellidos del cliente (formato String – longitud 30)
● Nombre de la entidad (formato String – longitud 20)
● Numero de C.I. (formato String – longitud 10)
● Fecha de registro (formato Date – dd/mm/aa)
● Numero de contacto (formato Integer – longitud 10)
● Dirección de la entidad. (formato String – longitud 30)
En caso de no pertenecer a una entidad empresarial, se omitirán los campos.
Fecha de
revisión y
versión:
18/06/2022
Versión 1.0
Prioridad: <Alta >
Número: RF12
Título: Listar cliente
Texto: El sistema permitirá listar los clientes con su información registrada previamente
Detalles de
requisitos y
restricciones:
El sistema debe listar los clientes permitiendo filtrar por medio de:
● Nombres (formato String – longitud 25)
● Fecha (formato Date – dd/mm/aa)
● Pagos (formato String – 25)
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media

Proyecto: Gestión
Número: RF13
Título: Eliminar cliente
Texto: El sistema permitirá eliminar el registro de los clientes enlistados en
el sistema.
Detalles de
requisitos y
restricciones:
El sistema deberá solicitar una confirmación de parte del gerente
para la eliminación del registro del usuario solicitado, una vez el
gerente apruebe la petición el sistema actualizará la lista con los
clientes restantes previo a la petición.
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF14
Título: Consultar servicio
Texto: El sistema permitirá consultar el servicio solicitado por los clientes
Detalles de
requisitos y
restricciones:
El sistema debe validar la disponibilidad de los servicios de
ambulancias en tiempo real, teniendo en cuenta la disponibilidad
de las ambulancias y los conductores.
Permitirá mantener una cola de espera en caso de no haber
unidades ni conductores disponibles.
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0

Proyecto: Gestión
Prioridad: media
Número: RF15
Título: Asignar Servicio
Texto: El sistema permitirá asignar el servicio a los conductores de las
ambulancias
Detalles de
requisitos y
restricciones:
El sistema debe asignar a los conductores un servicio acorde a su
disponibilidad, además se dará de baja a los conductores ya con
asignaciones para evitar retrasos e información duplicada.
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF16
Título: Asignar ambulancia
Texto: El sistema permitirá asignar una ambulancia a un conductor
Detalles de
requisitos y
restricciones:
El sistema debe actualizar el estado de las ambulancias asignadas,
aquellas ambulancias deberán tener un registro si se encuentran o
no en el taller previo a su asignación.
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0

Proyecto: Gestión
Prioridad: media
Número: RF17
Título: Asignar Conductor
Texto: El sistema permitirá asignar conductor a las ambulancias acorde a la
disponibilidad de los conductore
Detalles de
requisitos y
restricciones:
El sistema debe asignar a los conductores la siguiente información
sobre los clientes:
● Nombres (tipo String – longitud 40)
● Cedula (tipo String – longitud 10)
● Dirección (tipo String – longitud 50)
● Edad (tipo Integer – longitud 2)
● Días libres (tipo Date – formato dd/mm)
● Fecha de Vacaciones (tipo Date – formato dd/mm)
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF18
Título: Emitir aviso de pago
Texto: El sistema permitirá emitir un aviso de pago mensual a los clientes.
Detalles de
requisitos y
restricciones:
El sistema debe emitir mediante notificación un aviso de pago a
los clientes con servicios asignados y gestionados, permitiendo el
respectivo cobro de este.

Proyecto: Gestión
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF19
Título: Emitir aviso de cobro
Texto: El sistema permitirá emitir el aviso del cobro al banco
Detalles de
requisitos y
restricciones:
El sistema debe emitir el aviso de cobro a los clientes y al Banco
los recibos para poder efectuar los respectivos cobros, el banco
recibirá los recibos de los pagos.
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF20
Título: Control de pago
Texto: El sistema permitirá mantener un control de los recibos no cobrados
emitidos al banco
Detalles de
requisitos y
restricciones:
El sistema debe generar un listado de los clientes cuyos recibos de
pago no pudieron ser cobrados por el banco, emitiendo así un
nuevo aviso de pago.

Proyecto: Gestión
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF21
Título: Listar pagos realizados
Texto: El sistema permitirá listar los clientes que sus pagos fueron aprobados
y cobrados por medio del Banco.
Detalles de
requisitos y
restricciones:
El sistema debe listar los clientes con los pagos realizados y los
recibos cobrados por el banco, permitiendo volver a usar el servicio.
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: media
Número: RF22
Título: Generar informe
Texto: El sistema permitirá generar informes de cuyos clientes hayan
recibido un servicio de traslado.

Proyecto: Gestión
Detalles de
requisitos y
restricciones:
El sistema debe listar los clientes y servicios para generar los
informes con los siguientes datos:
● Numero de servicios (formato Integer – longitud 2)
● Nombre del cliente (formato String – longitud 25)
● Nombre del conductor (formato String – longitud 25)
● Fechas (formato Date – dd/mm/aa)
● Pagos (formato Double – longitud 5)
Fecha
de
revisión
y
versión:
13/6/2020
Versión1.0
Prioridad: alta
Número: RF23
Título: Listar servicios
Texto: El sistema emitirá el numero de servicios realizados por conductor
Detalles de
requisitos y
restricciones:
El sistema emitirá un informe con los servicios realizados por cada
conductor, para luego emitirse al gerente.
Los servicios se catalogarán por el ID correspondiente de la orden,
y se adjuntarán al conductor que finalizo dicho servicio.
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: media

Proyecto: Gestión
Número: RF24
Título: Asignar ID de servicio
Texto: El sistema asignará un identificador a cada servicio registrado.
Detalles de
requisitos y
restricciones:
El sistema asignará un identificador único a cada servicio
registrado en el sistema. Los identificadores de servicio se
catalogan según el sector. Ejemplo:
● Pascuales:
- Pascu00001
● Sauces:
- Sauc00001
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: media
Número: RF25
Título: Asignar ID de conductor
Texto: El sistema asignara un identificador al finalizar el registro del
conductor.
Detalles de
requisitos y
restricciones:
El sistema actualizara el listado de los conductores, para después
asignarles un identificador. El identificador se conformará por la
siguiente nomenclatura ascendente:
- AXX01
- AAx01
- AAB02
Se varía según la cantidad de conductores registrados.

Proyecto: Gestión
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: media
Número: RF26
Título: Asignar ID de ambulancia
Texto: El sistema asignara un identificador a las unidades registradas según
su lugar de matriculación y registro en el sistema.
Detalles de
requisitos y
restricciones:
El sistema asignara un identificador a las unidades registradas
según su lugar de matriculación y registro en el sistema. La
nomenclatura por seguir será:
Las dos primeras letras representan el orden de registro
- AAx-001
- ABx-001
- BAx-002
La tercera letra será la primera de la matrícula para representar la
ciudad de matriculación
- AAG-001
- ABG-001
- BAD-001
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: alta
Número: RF27
Título: Emitir informe de días libres.

Proyecto: Gestión
Texto: El sistema emitirá un informe con la información de los conductores
y de los días libres o vacaciones disfrutados.
Detalles de
requisitos y
restricciones:
El sistema podrá generar un reporte de la información personal
registrada del conductor, además de los días libres considerados
por la empresa no feriados.
Los días considerados como vacaciones también serán registrados,
siempre que el conductor las haya aceptado.
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: alta
Número: RF28
Título: Emitir listados a gerente
Texto: El sistema emitirá cada listado, de acuerdo con el módulo, como
modo de reporte al gerente.
Detalles de
requisitos y
restricciones:
El sistema recopilara cada listado, de acuerdo con el módulo, ya
sea de clientes, conductor, unidades o pagos, y estas se enviarán
periódicamente al gerente.
Para los conductores y ambulancias, se recopilará semanalmente.
Para los pagos o clientes, serán listados al finalizar cada mes.
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: alta

Proyecto: Gestión
Número: RF29
Título: Generar reporte de baja de servicios
Texto: El sistema genera un reporte donde estarán los servicios
suspendidos por la baja de conductor o ambulancia.
Detalles de
requisitos y
restricciones:
El sistema generara un reporte adicional donde están listados los
servicios suspendidos por la baja del conductor o la unidad. Dicho
reporte seguirá una sintaxis simple donde solo se detallará:
- El ID del servicio.
- El conductor o ID a cargo de la petición.
- La ambulancia o ID a cargo de la petición.
- Detalles del servicio.
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: baja
Número: RF30
Título: Delegar autoridad a secretario(a).
Texto: El sistema permitirá delegar los permisos de gerente temporalmente
al secretario.
Detalles de
requisitos y
restricciones:
El sistema permitirá delegar los permisos de gerente al secretario(a)
de manera temporal (periodo de 6 horas), en caso de que el
gerente no se encuentre disponible.
Solo el gerente podrá delegar los permisos, para este tendrá que
ingresar:
- Usuario (tipo String – longitud 10)
- Contraseña (tipo String – longitud 20)
Los permisos delegados al secretario(a) serán limitados de acuerdo
con el gerente.

Proyecto: Gestión
El gerente tendrá una pestaña donde podrá decidir que permisos
delegar a excepción del administrador principal.
Fecha
de
revisión
y
versión:
11/7/2020
Versión1.4
Prioridad: baja
4.2. No funcionales
Número: RNF-1
Título: Integridad de información
Texto: El sistema asegura la protección de los datos de los propietarios de los
clientes.
Tipo: Confiabilidad
Detalles de
requisitos y
restricciones:
El sistema encriptará los datos por medio de algoritmos de clave
simétrico, esto mantendrá la información inalterada ante accidentes o
intentos maliciosos por parte de terceros. Sólo se podrá modificar la
información de la base de datos con la respectiva autorización del
gerente.
Fecha de revisión y
versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-2
Título: Conexión a la red
Texto: Los usuarios deben estar conectado a red de datos de para acceder al
sistema
Tipo: Usabilidad
Detalles de
requisitos y
restricciones:
Las conexiones aceptadas por el sistema son:
● Wifi
● Red local
La velocidad de la web deberá ser mayor a 20mbps, para que así el sistema
pueda funcionar correctamente.

Proyecto: Gestión
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-3
Título: Actualizaciones
Texto: El sistema va a tener actualizaciones cada 3 meses.
Tipo: Organizacional
Detalles de
requisitos y
restricciones:
Cada 3 meses el sistema tendrá una actualización, las actualizaciones
pueden contener nuevas funcionalidades, arreglos de errores,
modificaciones del sistema.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-4
Título: Privacidad de datos
Texto: El sistema clasificara que datos se va a poder compartir a terceros.
Tipo: Legistlativo
Detalles de
requisitos y
restricciones:
La privacidad de datos del sistema se va a regir según el Registro Oficial
Suplemento N°459 del 26 de mayo del 2021 que se refiere a la Ley
Orgánica de Protección de Datos, esto garantizará a nuestros clientes
garantizar el derecho a la protección de datos personales.
Fecha de revisión y
versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-5
Título: Tiempo de respuesta al usuario
Texto: El sistema debe tener un tiempo de respuesta al usuario menor a 7
segundos.
Tipo: Rapidez

Proyecto: Gestión
Detalles de
requisitos y
restricciones:
El funcionamiento y transacciones del sistema debe tener un tiempo de
respuesta menor a 7 segundos, si dentro de los 7 segundos no recibe una
respuesta del sistema se procederá a mostrar un mensaje de error. Para
lograr esto vamos a instalar una herramienta de cacheado en los
servidores y esto beneficiará en la velocidad de carga del sistema.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-6
Título: Probabilidad de fallos
Texto: La probabilidad media de una falla peligroso en el sistema es de 2%
Tipo: Fiabilidad
Detalles de
requisitos y
restricciones:
Mediante los requisitos de integridad de seguridad del hardware se
asegura que el sistema va a tener un 2% de una falla peligrosa que afecte
directamente a los clientes.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-7
Título: Lenguaje de programación
Texto: El sistema se va a desarrollar con
Tipo: Implementación
Detalles de
requisitos y
restricciones:
Los lenguajes de programación que se va a usar para el desarrollo del
sistema son los siguientes:
● Java
● C++
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-8
Título: Dependibilidad del sistema
Texto: Se debe tener una disponibilidad para poder acceder al sistema
Tipo: Disponibilidad

Proyecto: Gestión
Detalles de
requisitos y
restricciones:
El sistema deberá estar disponible el 99,99% de las veces en que un
usuario intente acceder al mismo. Para lograr esto vamos a implementar el
servidor NGINX, un servidor web que permitirá gestionar el alto tráfico
que va a tener el sistema.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: Alta
Número: RNF-9
Título: Control y asignación de conductores
Texto: El sistema permitirá gestionar a los conductores disponibles.
Tipo: No funcional - datos
Detalles de
requisitos y
restricciones:
Una vez que se reciba una petición de servicio el sistema consultará
inmediatamente ladisponibilidad de cada conductor para que pueda prestar
servicio a la petición.
El sistema debe permitir el uso de:
• 1 mouse
• 1 teclado.
• 1 pantalla
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>
Número: RNF-10
Título: Control y asignación de ambulancias
Texto: El sistema permitirá gestionar las ambulancias
Tipo: No funcional - datos
Detalles de
requisitos y
restricciones:
Se podrá visualizar la disponibilidad o estado de cada ambulancia para ser
enviada a la locación solicitada
• 1 mouse
• 1 teclado.
• 1 pantalla
Fecha de revisión
y versión:
14/6/2022
Versión1.0

Proyecto: Gestión
Prioridad: <Media>
Número: RNF-11
Título: Seguridad
Texto: El sistema tendrá diferentes permisos según el cargo.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Cuando el usuario inicie sesión, tendrá atributos que le correspondan al rol
que tenga. Los conductores solo tienen permiso para personalizar su perfil,
mientras que el gerente podrá administrar todos.
• 1 mouse
• 1 teclado.
• 1 pantalla
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>
Número: RNF-12
Título: Peticiones
Texto: El sistema debe dar respuesta a los usuarios.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Cuando se reciba una petición de ambulancia, se debe emitir una respuesta
lo más pronto posible. El protocolo que seguir será:
● Consultar los conductores disponibles
● Consultar las unidades disponibles
● Enviar la unidad al lugar solicitado
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Alta>
Número: RNF-13
Título: Reporte de unidades

Proyecto: Gestión
Texto: Se podrá visualizar las condiciones de cada unidad.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Esta función permitirá a la terminal conocer el estado de las unidades, es
decir cuando estas presenten fallas para que se manden a reparar de
inmediato. Por el contrario, también se sabrá si están en condiciones
óptimas para ser usadas.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>
Número: RNF-14
Título: Reporte de conductores
Texto: Se podrá visualizar información de los conductores.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Esta función servirá para que se tenga conocimiento de los días francos y
horas de serviciode los conductores. Dela misma manera sesabrá suestado
de salud y si están en condiciones óptimas para prestar servicio.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>
Número: RNF-15
Título: Ordenadores
Texto: Medio por el cual se podrá trabajar en la empresa.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Los ordenadores deben encontrarse en condiciones óptimas para que la
empresa pueda usar el sistema sin inconvenientes. De esta manera se
puede brindar un servicio de calidad sin que se vea comprometida la
eficacia de la empresa.

Proyecto: Gestión
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>
Número: RNF-16
Título: Aforo
Texto: El sistema está preparado para acoger un gran número de peticiones.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Al ser una empresa que brinda servicios constantemente, el sistema debe
tener la capacidad de soportar más de 1000 peticiones entrantes por
segundo, para evitar que el sistema se quede congelado o en el peor de los
casos que se termine colgando. Esto evitará la pérdida de tiempo al tratar
de reponer el sistema.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Alta>
Número: RNF-17
Título: GPS
Texto: El sistema brindará cobertura de la zona.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Las unidades deberán contar con GPS para que puedan encontrar las rutas
más factibles al momento de dirigirse a la locación solicitada. Esto también
servirá para tener conocimiento en la terminal sobre la geolocalización de
las unidades.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>

Proyecto: Gestión
Número: RNF-18
Título: Almacenamiento
Texto: El sistema debe almacenar gran cantidad de datos.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
El sistema deberá almacenar la información de conductores y unidades que
se encuentren en la institución, por ejemplo, su historial y estado. También
se almacenará las cuentas por los servicios prestados a cada cliente. Los
programadores anexarán todos los datos a la nube que haya contratado la
empresa.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Alta>
Número: RNF-19
Título: Compatibilidad
Texto: El sistema debe poder ser accedido desde cualquier S.O
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Elsistemadeberá permitir suaccesodesde cualquier ordenador sinimportar
el sistema operativo que tenga.
Será necesario el uso de:
• 1 mouse
• 1 teclado.
• 1 pantalla
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Media>
Número: RNF-20
Título: Soporte
Texto: El sistema contará con soporte preventivo.
Tipo: No funcional

Proyecto: Gestión
Detalles de
requisitos y
restricciones:
Es necesario que se tenga un soporte de contingencia por parte de los
desarrolladores en caso de que el sistema presente algún inconveniente. Es
importante que este pueda seguir prestando servicio el 99% del tiempo.
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Alta>
Número: RNF-21
Título: Comprobante de pago
Texto: El sistema emitirá la cuenta de la deuda a pagar al cliente.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
El sistema enviará un email de la factura por los servicios prestados al
cliente, hacia el banco para que se pueda efectuar el respectivo cobro.
Fecha de revisión
y versión:
14/6/2022
Versión1.0
Prioridad: <Baja>
Número: RNF-22
Título: Recepción GPS
Texto: El sistema contará con un dispositivo de geolocalización.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
El sistema permitirá recuperar información de la fecha, lugar y hora de la
petición para que la unidad pueda llegar hasta el lugar indicado de la
manera más pronta posible.
Fecha de
revisión y
versión:
14/6/2022
Versión1.0

Proyecto: Gestión
Prioridad: <Alta>
Número: RNF-23
Título: Baja de unidades
Texto: El sistema debe permitir dar de baja a cualquier unidad.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Si una unidad no se encuentra en condiciones óptimas para saliralas calles
y necesita reparaciones, el gerente debe darla de baja para tener
conocimiento de las ambulancias disponibles. Para ello es necesario que el
gerente haga uso de:
• 1 mouse
• 1 teclado.
• 1 pantalla
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Baja >
Número: RNF-24
Título: Baja de conductores
Texto: El sistema debe permitir dar de baja a cualquier unidad o conductor.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
Si un conductor no se encuentra en condiciones óptimas para prestar
servicio o no cumple con los requisitos de la empresa, se lo dará de baja
inmediatamente.
Para ello es necesario que el gerente haga uso de:
• 1 mouse
• 1 teclado.
• 1 pantalla
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Baja >

Proyecto: Gestión
Número: RNF-25
Título: Tiempo de respuesta de las bajas.
Texto: El sistema deberá responder de inmediato cuando se haga una baja en el
sistema y mantener dicha información actualizada.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
El tiempo de respuesta para dar de baja una ambulancia o conductor debe
ser mínimo 6 segundos y que se actualice en el sistema inmediatamente.
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Alta >
Número: RNF-26
Título: Implementaciones o actualizaciones
Texto: El sistema deberá acoplarse a las nuevas implementaciones.
Tipo: No funcional
Detalles de
requisitos y
restricciones:
El sistema permitirá la adición de nuevos features o características que
desee la empresa, de manera flexible sin que se vea comprometido el
código del sistema existente.
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Alta >
Número: RNF-27
Título: Confidencialidad
Texto: Información de usuarios.
Tipo: No funcional

Proyecto: Gestión
Detalles de
requisitos y
restricciones:
No se podrá filtrar o revelar información privada del personal, ni de los
clientes. Ej: Tarjetas de crédtios, claves, cuentas de banco, etc.
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Alta >
Número: RNF-28
Título: Sistema responsive
Texto: Adaptable a todo tipo de resoluciones
Tipo: No funcional
Detalles de
requisitos y
restricciones:
El sistema podrá ser visualizado en cualquier pantalla sin importar el
tamaño en pulgadas que esta tenga.
Fecha de
revisión y
versión:
14/6/2022
Versión1.0
Prioridad: <Media>
4.2.1. Tamaño y rendimiento
● El sistema debe atender entre 10 a 100 usuarios diarios.
● El sistema debe almacenar más de 400.000 registros en la base de datos.
● El login del usuario no debe tomar más de 5 segundos en autenticar los datos
ingresados.
● El sistema soporta 5 peticiones de por segundo.
4.2.2. Calidad
● Solo puede acceder al sistema el usuario, el conductor y el gerente, por medio de
un usuario y una contraseña con diferentes privilegios entre ellos.
● La sesión del usuario se cierra después de 10 minutos de inactividad.
● El sistema deberá permitir un máximo de 3 intentos de validación.
● El sistema debe tener una disponibilidad del 99%

Proyecto: Gestión
● El sistema debe demorar como máximo de 5 a 11 segundos para imprimir los
informes mensuales para el gerente.
● Después de que el usuario inicie sesión, el sistema debe demorar como máximo
10 segundos para mostrar la página de inicio del sistema.
● Conectividad a la red.
● Se debe brindar la respectiva documentación asociadas al diseño del sistema,
modelo de base de datos usado, manual de instalación y operación del sistema.
5. Arquitecturadel Producto/Sistema
5.1. Vista de Casos de Uso
5.1.1. Actores
Número: ACT-1
Actor: Empleado
Descripción: Persona responsable de ofrecer los servicios
directos a los clientes.
Responsabilidades: El conductor puede realizar lo siguiente:
● Verificar datos del servicio asignado a su
unidad.
● Realizar la ruta de acuerdo con los
servicios asignados para él.
Fuentes: Administración de la empresa
Número: ACT-2
Actor: Cliente
Descripción: Persona que solicita el servicio de traslado. Actor
secundario.
Responsabilidades: El cliente puede realizar lo siguiente:
● Solicitar el servicio.
● Realizar pago.
● Recibir notificación por falta de pago.
Número: ACT-3
Actor: Gerente
Descripción: Persona que realiza la supervisión de las acciones
que se realizan en el sistema, así mismo, es quien
recibe los reportes de los servicios dados durante
el mes. Es un actor primario.
Responsabilidades: El empleado puede realizar lo siguiente:
● Verificar datos de los propietarios de
vehículos.

Proyecto: Gestión
● Emitir recibos de pago.
● Consultar deudas de los propietarios de
vehículos.
Fuentes: Gerente de la empresa
Número: ACT-4
Actor: Secretario
Descripción: Persona encargada de realizar el ingreso de nueva
información en el sistema.
Responsabilidades: El empleado puede realizar lo siguiente:
● Ingreso de datos de nuevos conductores.
● Emitir informes mensuales y enviarlos al
gerente.
5.1.2. Modelo de casos de Uso
Diagrama-1 Modelo inicio de sesión
Diagrama-2 Modelo gestión de empleados

Proyecto: Gestión
Diagrama-3 Modelo gestión de ambulancias

Proyecto: Gestión
Diagrama-4 Modelo gestión de pagos

Proyecto: Gestión
Diagrama-5 Modelo gestión de clientes

Proyecto: Gestión
Diagrama-6 Modelo gestión de servicios

Proyecto: Gestión
Diagrama-7 Modelo gestión de reportes a gerencia

Proyecto: Gestión
5.1.3. Lista de casos de Uso
CU-01 Autenticar usuario Media Alta Alta

Proyecto: Gestión
CU-02 Registrar conductor Alta Alta Alta
CU-03 Editar conductor Media Alta Alta
CU-04 Listar conductor Baja Media Media
CU-05 Eliminar conductor Baja Media Media
CU-06 Registrar ambulancia Media Alta Alta
CU-07 Editar ambulancia Alta Alta Alta
CU-08 Consultar ambulancia Media Alta Alta
CU-09 Eliminar ambulancia Baja Media Media
CU-10 Registrar cliente Baja Media Media
CU-11 Modificar cliente Media Alta Alta
CU-12 Listar cliente Alta Alta Alta
CU-13 Eliminar cliente Media Alta Alta
CU-14 Consultar servicio Baja Media Media
CU-15 Asignar Servicio Baja Media Media
CU-16 Asignar ambulancia Media Alta Alta
CU-17 Asignar Conductor Alta Alta Alta
CU-18 Emitir aviso de pago Media Alta Alta
CU-19 Emitir aviso de cobro Baja Media Media
CU-20 Control de pago Baja Media Media
CU-21 Listar pagos realizados Media Alta Alta
CU-22 Generar informe Alta Alta Alta
CU-23 Listar servicios Media Alta Alta
CU-24 Asignar ID de servicio Baja Media Media
CU-25 Asignar ID de conductor Baja Media Media
CU-26 Asignar ID de ambulancia Media Alta Alta
CU-27 Emitir informe de días libres
de conductores
Alta Alta Alta
CU-28 Emitir listados a gerente Media Alta Alta
CU-29 Generar reporte de baja de
servicios
Baja Media Media
CU-30 Delegar autoridad a
secretario(a).
Baja Media Media
5.1.4. Descripción de los Casos de Uso
IDENTIFICADOR CASO DE USO:
CU-01
NOMBRE: Autenticar Usuario
COMPLEJIDAD: Media PRIORIDAD: Alta
REQUERIMIENTO FUNCIONAL ASOCIADO: RF-01

Proyecto: Gestión
ACTORES: ACT-1, ACT-2, ACT-3, ACT -4
CASOS DE USO ASOCIADOS: N/A
DESCRIPCIÓN: El sistema realizara la autenticación del usuario al ingresar.
NOTAS:
El sistema procederá a realizar la validación de datos ingresados por el usuario al momento de
hacer login en el sistema llenando los siguientes datos permitirá el registro de los conductores
que se realizará llenando los siguientes campos:
● Usuario (tipo String-longitud 40)
● Contraseña (tipo String-longitud 20)
CRITERIOS DE ACEPTACIÓN: El empleado o Administrador se autentica mediante correo y
contraseña correctamente o no.
ESCENARIOS:
ES-1.01 DESCRIPCIÓN: Validación de ingreso de usuario y contraseña correctamente.
SUPOSICIONES/ASUNCIONES:
● El usuario (secretario, gerente o empleado) ingresa su nombre de usuario
en el sistema.
● El usuario (secretario, gerente o empleado) ingresa su contraseña en el
sistema.
● El secretario envía los datos al sistema.
● El sistema ingresa al perfil validado correspondiente.
RESULTADOS:
Validación exitosa e ingreso a la pantalla principal del usuario.
ES-1.02 DESCRIPCIÓN: Fallo de validación de usuario y contraseña por error de tipeo.
● El usuario ingresa su nombre de usuario en el sistema.
● El usuario ingresa su contraseña de usuario en el sistema.
● El usuario envía los datos al sistema.
● El sistema notifica que él usuario y contraseña ingresados son incorrectos y
no coinciden con ninguno registrado en el sistema.
● RESULTADOS:
● Las credenciales ingresadas en el sistema son incorrectas por lo tanto no se
puede acceder al sistema.
ES-1.03 DESCRIPCIÓN: Autenticación no realizada por problemas en la base de datos
● El usuario ingresa su nombre de usuario en el sistema.
● El usuario ingresa su contraseña de usuario en el sistema.
● El usuario envía los datos al sistema.
● El sistema notifica que no se pudo autenticar.
RESULTADOS:
● Sin autenticación el usuario no puede acceder al sistema

Proyecto: Gestión
RIESGOS:
● No poder validar las credenciales ingresadas por datos erróneos.
● Fallos internos en el servidor del sistema.
● Fallos internos en la base de datos.
PROTOTIPO EXPLORATORIO
N/A
CU-02
NOMBRE: Registrar conductor
COMPLEJIDAD: Alta PRIORIDAD: Alta
ACTORES: ACT-1, ACT-4
DESCRIPCIÓN: El sistema permitirá el registro de los conductores.
NOTAS:
El sistema permitirá el registro de los conductores que se realizará llenando los siguientes
campos:
CRITERIOS DE ACEPTACIÓN: Registró los conductores correctamente o no
ESCENARIOS:
ES-2.01 DESCRIPCIÓN: Registro de conductor exitosa.
● El secretario se autentica correctamente y accede al sistema.
● El secretario llena los campos de información del usuario en el sistema.
● El sistema notifica que el usuario ha sido registrado correctamente.
RESULTADOS:
● El conductor ha sido registrado correctamente.
ES-2.02 DESCRIPCIÓN: Fallo al registrar el conductor por error de ingreso de datos.
● El secretario llena los campos de información del usuario al sistema.
● El secretario envía los datos al sistema
● El sistema notifica que él usuario no ha sido registrado por error de datos.
● RESULTADOS:

Proyecto: Gestión
● El conductor no ha sido registrado en el sistema por mal ingreso de la
información.
ES-2.03 DESCRIPCIÓN: Registro de usuario no generado, por error en el servidor del
sistema.
● El secretario llena los campos de información del usuario al sistema.
● El secretario no puede enviar los datos del usuario por, un error presentado
en el sistema.
RESULTADOS:
El conductor no puede ser registrado por error en el servidor del sistema.
RIESGOS:
● No poder registrar usuarios por datos erróneos.
N/A
CU-03
NOMBRE: Editar conductor
ACTORES: ACT-1 Conductor, ACT-4 Secretario.
DESCRIPCIÓN: El sistema permitirá modificar la información de los conductores.
NOTAS:
El sistema permitirá modificar la información de los conductores que se encuentren registrados
correctamente, los campos que se pueden modificar son los siguiente:
●
CRITERIOS DE ACEPTACIÓN: Modificación de la información de los conductores correctamente o
no.

Proyecto: Gestión
ESCENARIOS:
ES-3.01 DESCRIPCIÓN: Modificación de la información del conductor exitosamente.
● El secretario modifica los campos de información del conductor en el
sistema.
● El secretario envía los datos modificados al sistema.
● El secretario notifica que los datos del conductor han sido registrados
correctamente.
● RESULTADOS:
● El secretario ha modificado correctamente los datos del conductor.
ES-3.02 DESCRIPCIÓN: Fallo en la modificación de la información del conductor, por falla en
la base de datos.
● El secretario modifica los campos de información del conductor en el
sistema.
● El secretario no puede enviar los datos al sistema por, fallo en la base de
datos.
RESULTADOS:
El secretario no puede modificar los datos del conductor por fallo en la base
de datos.
ES-3.03 DESCRIPCIÓN: Fallo en la Modificación de datos del conductor por mala
autenticación del secretario.
● El secretario se autentica incorrectamente
● El secretario no puede acceder al sistema.
RESULTADOS:
● El secretario no puede Modificar los datos del conductor por mala
autenticación.
RIESGOS:
● Fallo en la base de datos y no permite modificar los datos del empleado en el
sistema.
● Fallo en la modificación de los datos del conductor por mala autenticación del
secretario.
N/A
CU-04
NOMBRE: Listar conductor
COMPLEJIDAD: Baja PRIORIDAD: media

Proyecto: Gestión
DESCRIPCIÓN: El sistema permitirá verificar un listado de los conductores registrados.
NOTAS:
El sistema mostrar un listado en el cual se podrá verificar el estado de los conductores
registrados en la institución hasta la actualidad. Dichos estados se podrán verificar mediante los
filtros:
● Activo
● Suspendido
CRITERIOS DE ACEPTACIÓN: Verificación de conductores
ESCENARIOS:
ES-4.01 DESCRIPCIÓN: Verificación exitosa de conductores registrados.
● El usuario se autentica correctamente y accede al sistema.
● El usuario realiza la consulta del personal registrado
● RESULTADOS:
● El usuario obtiene la lista de los conductores y su estado.
ES-4.02 DESCRIPCIÓN: Fallo en la verificación de conductores registrados por falla de la
base de datos.
● El usuario realiza la consulta del personal registrado.
● El usuario no puede consultar los datos al sistema por, fallo en la base de
datos.
RESULTADOS:
El usuario no puede obtener la lista de conductores y su estado por fallo en
la base de datos.
ES-4.03 DESCRIPCIÓN: Fallo en la verificación de usuarios registrados por mala
autenticación del usuario.
● El usuario se autentica incorrectamente
● El usuario no puede acceder al sistema.
RESULTADOS:
● El usuario no puede obtener la lista de conductores y su estado por mala
autenticación.
RIESGOS:
● Fallo en la base de datos y no permite obtener el listado de los conductores
registrados hasta la fecha.
N/A
CU-05
NOMBRE: Eliminar conductor

Proyecto: Gestión
DESCRIPCIÓN: El sistema permitirá la eliminación de conductores.
NOTAS:
● El sistema permitirá la eliminación de conductores cuyo contrato haya finalizado, o se
haya dado de baja previamente.
● Solo un usuario con rol de gerente puede eliminar a los conductores que hayan cumplido
con las condiciones mencionadas anteriormente, mediante la aprobación de dicha
petición.
ESCENARIOS:
ES-5.01 DESCRIPCIÓN: Eliminación de conductor exitosa.
● El secretario aprueba la petición para eliminar conductor.
● El secretario envía los datos actualizados al sistema.
● El secretario notifica que se ha realizado la eliminación del conductor.
● RESULTADOS:
● El secretario ha eliminado correctamente al usuario.
ES-5.02 DESCRIPCIÓN: Fallo en la eliminación de conductor, por ingreso de datos erróneos.
● El secretario se autentica incorrectamente y el sistema no le permite el
acceso.
● El secretario no puede realizar la eliminación del conductor.
● RESULTADOS:
● No se pudo eliminar al usuario por mala autenticación del secretario.
ES-5.03 DESCRIPCIÓN: Eliminación no realizada por problemas en la base de datos
● El secretario aprueba la petición para eliminar conductor.
● El secretario no puede enviar los datos actualizados al sistema por
problema en la base de datos.
● El secretario notifica que no se ha realizado la eliminación del conductor.
RESULTADOS:
● El conductor no puede ser puede ser autenticado por problema en la base
de datos.
RIESGOS:
● Fallo en la eliminación por datos incorrectos.

Proyecto: Gestión
N/A
CU-06
NOMBRE: Registrar ambulancia
ACTORES: ACT 1
DESCRIPCIÓN: El sistema permitirá el registro de unidades que lleguen a la central.
NOTAS:
El sistema deber permitir el registro de las unidades sin identificación que lleguen a central.
Dicho registro tendrá los campos de:
● Horario de disponibilidad (tipo Date – formato ss/mm/hh).
CRITERIOS DE ACEPTACIÓN: El sistema permite que solo se registren las unidades sin ID.
ESCENARIOS:
ES-6.01 DESCRIPCIÓN: Registro de unidad mediante ID exitosa.
● El secretario se autentica y accede al sistema.
● El secretario llena los campos de registro de unidad.
● El secretario notifica que se registró la unidad correctamente.
RESULTADOS:
● La unidad se registró exitosamente.
ES-6.02 DESCRIPCIÓN: Fallo en el registro, por datos erróneos.
● El secretario ingresa una ID y no puede realizar el registro porque ya existe
en el sistema.
RESULTADOS:
● La unidad no puede ser registrada por datos repetidos.
ES-6.03 DESCRIPCIÓN: Error al momento de registrar ambulancia por problemas en la base
de datos
● El secretario no puede enviar los datos al sistema.
● El secretario notifica que no se registró la unidad.
RESULTADOS:

Proyecto: Gestión
● La unidad no puede ser puede ser registrada por problema en la base de
datos.
● La unidad no se puede registrar porque ya existe dicha ID.
RIESGOS:
● Fallo en el registro de la unidad.
N/A
CU-07
NOMBRE: Editar ambulancia
DESCRIPCIÓN: El sistema permitirá la actualización del registro de las unidades.
NOTAS:
El sistema actualizara los datos editados del registro de las unidades. Dichos campos son:
● Horario de disponibilidad (tipo Date – formato ss/mm/hh)
CRITERIOS DE ACEPTACIÓN: Solo se puede editar unidades registradas.
ESCENARIOS:
ES-7.01 DESCRIPCIÓN: Edición de registro de ambulancia exitoso.
● El secretario modifica el registro de unidad.
● El secretario notifica que se modificó el registro de la unidad.
RESULTADOS:
● El registro de la unidad se modificó correctamente.
ES-7.02 DESCRIPCIÓN: Fallo la edición del registro de unidad, por ingreso de datos erróneos
del secretario.
● El secretario se autentica incorrectamente y no accede al sistema.
● El secretario no puede modificar el registro de la unidad
RESULTADOS:
● El registro no pudo ser modificado por datos erróneos.

Proyecto: Gestión
ES-7.03 DESCRIPCIÓN: Edición no realizada por problemas en la base de datos
● El secretario no puede enviar los datos al sistema.
● El secretario notifica que no se modificó el registro de la unidad.
RESULTADOS:
El registro de la unidad no pudo ser modificado por problema en la base de datos.
RIESGOS:
● Fallo en la edición de registro por datos incorrectos.
N/A
CU-08
NOMBRE: Consultar ambulancia
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá la consulta de una ambulancia con respecto a rutas y
horarios.
NOTAS:
El sistema debe permitir consultar el registro de entrada y salida de las unidades con su
respectivo conductor activo en la unidad. Dicho registro tendrá un filtro para verificar si se
encuentra disponible en el momento de la solicitud.
CRITERIOS DE ACEPTACIÓN: Únicamente se puede consultar unidades registradas en el sistema.
ESCENARIOS:
ES-8.01 DESCRIPCIÓN: Consulta de ambulancias exitosa.
● El secretario consulta el ID de la unidad
● El sistema informa el estado de dicha unidad|
● Se consultó el estado de la unidad correctamente.
RESULTADOS:
● Se consultó la ambulancia sin fallos.

Proyecto: Gestión
ES-8.02 DESCRIPCIÓN: Fallo en la consulta de ambulancia, por ingreso de datos erróneos.
● El Sistema presenta aviso de que la ID ingresada no está registrada en el
sistema.
RESULTADOS:
● No se puede consultar la unidad por datos erróneos.
ES-8.03 DESCRIPCIÓN: Fallo en la consulta de ambulancia, por error en la base de datos
● El Sistema presenta aviso que no se pudo acceder a la base de datos
RESULTADOS:
● No se puede consultar la unidad por falla en la base de datos
RIESGOS:
● Fallo en la consulta por datos incorrectos.
● Fallo en la consulta, por error en la base de datos
N/A
CU-09
NOMBRE: Eliminar ambulancia
REQUERIMIENTO FUNCIONAL ASOCIADO: RF9
DESCRIPCIÓN: El sistema permitirá la eliminación de unidades registradas.
NOTAS:
● El sistema debe permitir la eliminación y actualización de registro después de borrar una
unidad del sistema, ya sea por motivo de desuso de la unidad o por otro motivo el cual
será registrado en el informe una vez se haya aprobado a la solicitud. Dicha aprobación
será dada únicamente por el usuario con rol de gerente y tendrá un informe del mecánico
en caso de ser la razón por “falla mecánica”
CRITERIOS DE ACEPTACIÓN: Las unidades deben constar en el registro para ser eliminadas.
ESCENARIOS:

Proyecto: Gestión
ES-9.01 DESCRIPCIÓN: Eliminación de ambulancia exitosa.
● El secretario aprueba la petición para eliminar la unidad
● El secretario notifica la eliminación de la ambulancia
● RESULTADOS:
● El secretario ha eliminado correctamente la unidad
ES-9.02 DESCRIPCIÓN: Eliminación de ambulancia no realizada, por problemas en la base
de datos.
● El secretario aprueba la petición para eliminar la unidad
● La unidad sigue apareciendo en el registro.
● El secretario no puede notificar que ha sido eliminada la unidad.
RESULTADOS:
● La unidad no puede ser eliminada por problema en la base de datos.
ES-9.03
DESCRIPCIÓN: Fallo en eliminación de unidad, por mala autenticación del
secretario.
● El secretario no puede notificar la eliminación de la unidad
RESULTADOS:
El secretario no ha eliminado correctamente la unidad
RIESGOS:
N/A
CU-10
NOMBRE: Registrar cliente
COMPLEJIDAD: Baja PRIORIDAD: Media
DESCRIPCIÓN: El sistema permitirá el registro de los clientes.

Proyecto: Gestión
NOTAS:
El sistema permitirá el registro de los usuarios que se realizará llenando los siguientes campos:
CRITERIOS DE ACEPTACIÓN: Registró los clientes correctamente o no
ESCENARIOS:
ES-10.01 DESCRIPCIÓN: Registro del cliente exitosamente.
● El secretario llena los campos de información del cliente en el sistema.
● El sistema notifica que el cliente ha sido registrado correctamente.
RESULTADOS:
● El cliente ha sido registrado correctamente.
ES-10.02 DESCRIPCIÓN: Fallo Registro de cliente por error de ingreso de información.
● El secretario llena los campos de información del cliente al sistema.
● El secretario envía los datos al sistema
● El sistema notifica que él cliente no ha sido registrado por error de datos.
● RESULTADOS:
● El cliente no ha sido registrado en el sistema por error de datos.
ES-10.03 DESCRIPCIÓN: Registro de cliente no generado, por error en el servidor del sistema.
● El secretario llena los campos de información del cliente al sistema.
● El secretario no puede enviar los datos del cliente por, un error presentado
en el sistema.
RESULTADOS:
El cliente no puede ser registrado por error en el servidor del sistema.
RIESGOS:
● No poder registrar cliente por datos erróneos.
N/A
CU-11
NOMBRE: Modificar cliente
COMPLEJIDAD: Media PRIORIDAD: alta

Proyecto: Gestión
DESCRIPCIÓN: El sistema permitirá actualización del registro de los clientes.
NOTAS:
El sistema debe permitir actualizar el registro de los clientes una vez soliciten una petición de
servicio. Dicha actualización contemplara los siguientes campos:
● Nombres y apellidos del cliente (formato String – longitud 30)
● Nombre de la entidad (formato String – longitud 20)
● Numero de C.I. (formato String – longitud 10)
● Fecha de registro (formato Date – dd/mm/aa)
● Numero de contacto (formato Integer – longitud 10)
● Dirección de la entidad. (formato String – longitud 30)
● En caso de no pertenecer a una entidad empresarial, se omitirán los campos.
CRITERIOS DE ACEPTACIÓN: El cliente debe estar previamente registrado para poder editar el
registro.
ESCENARIOS:
ES-11.01 DESCRIPCIÓN: Modificación exitosa del registro de clientes.
● EL secretario modifica los datos del cliente.
● El secretario notifica que se ha modificado el registro del cliente.
RESULTADOS:
● Se modificó correctamente el registro del cliente
ES-11.02 DESCRIPCIÓN: Fallo en la modificación del cliente por mal ingreso de información.
● EL secretario modifica los datos del cliente.
● El sistema notifica que los datos del cliente no coinciden con los registros
previos.
RESULTADOS:
● El registro no se puede realizar por datos erróneos.
RIESGOS:
● Fallo en la modificación por datos incorrectos.
N/A
IDENTIFICADOR CASO DE USO: NOMBRE: Listar cliente

Proyecto: Gestión
CU-12
DESCRIPCIÓN: El sistema permitirá verificar un listado de los clientes registrados.
NOTAS:
El sistema mostrar un listado en el cual se podrá verificar a todos los clientes que han sido
registrado anteriormente.
CRITERIOS DE ACEPTACIÓN: Verificación de clientes
ESCENARIOS:
ES-12.01 DESCRIPCIÓN: Obtención exitosa de lista de clientes registrados.
● El secretario realiza la consulta de los clientes registrados
● RESULTADOS:
● El secretario obtiene la lista de los clientes.
ES-12.02 DESCRIPCIÓN: Fallo en la obtención del listado de clientes registrados por error en
la base de datos.
● El usuario realiza la consulta del personal registrado.
● El usuario no puede consultar los datos al sistema por, fallo en la base de
datos.
RESULTADOS:
El secretario no puede obtener la lista de clientes por fallo en la base de
datos.
ES-12.03 DESCRIPCIÓN: Fallo en la verificación de clientes registrados por mala
autenticación del secretario.
● El secretario se autentica incorrectamente.
● El secretario no puede acceder al sistema.
RESULTADOS:
● El secretario no puede obtener la lista de clientes por mala autenticación.
RIESGOS:
● Fallo en la base de datos y no permite obtener el listado de los conductores
registrados hasta la fecha.
N/A

Proyecto: Gestión
CU-13
NOMBRE: Eliminar cliente
COMPLEJIDAD: Media PRIORIDAD: alta
DESCRIPCIÓN: El sistema permitirá la eliminación de clientes.
NOTAS:
● El sistema permitirá la eliminación de clientes registrados previamente.
● Solo un usuario con rol de gerente puede eliminar a clientes mediante la aprobación de
dicha petición.
ESCENARIOS:
ES-13.01 DESCRIPCIÓN: Eliminación de cliente exitosa.
● El secretario aprueba la petición para eliminar clientes.
● El secretario notifica que se ha realizado la eliminación del cliente.
● RESULTADOS:
● El secretario ha eliminado correctamente al usuario.
ES-13.02 DESCRIPCIÓN: Fallo en la eliminación de cliente, por ingreso de datos erróneos del
secretario.
● El secretario no puede realizar la eliminación del cliente.
● RESULTADOS:
● No se pudo eliminar al cliente por mala autenticación del secretario.
ES-13.03 DESCRIPCIÓN: Eliminación no realizada por problemas en la base de datos
● El secretario aprueba la petición para eliminar cliente
● El secretario no puede enviar los datos actualizados al sistema por
problema en la base de datos.
● El secretario notifica que no se ha realizado la eliminación del cliente.
RESULTADOS:
● El cliente no puede ser puede ser autenticado por problema en la base de
datos.
RIESGOS:
● Fallo en la eliminación por datos incorrectos.

Proyecto: Gestión
N/A
CU-14
NOMBRE: Consultar servicio
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá consultar el servicio solicitado por los clientes
NOTAS:
● El sistema debe validar la disponibilidad de los servicios de ambulancias en tiempo
real, teniendo en cuenta la disponibilidad de las ambulancias y los conductores.
● Permitirá mantener una cola de espera en caso de no haber unidades ni conductores
disponibles.
CRITERIOS DE ACEPTACIÓN: Preguntar para autenticar la verificación del servicio
ESCENARIOS:
ES-14.01 DESCRIPCIÓN: Verificación de disponibilidad exitosa.
● El secretario entra al sistema.
● El secretario verifica la disponibilidad.
● El secretario comprueba en el sistema exitosa.
RESULTADOS:
● Con la verificación el servicio está disponible.
ES-14.02 DESCRIPCIÓN: Verificación de la disponibilidad envía a cola de espera.
● El sistema envía a cola de espera por no haber unidades disponibles.
RESULTADOS:
● El cliente entra en espera debido a no haber unidades ni conductores.
ES-14.03 DESCRIPCIÓN: Verificación de la disponibilidad errónea por fallo en la base de
datos.
● El sistema no muestra la disponibilidad de ambulancias y personal.
RESULTADOS:
● El cliente entra en espera debido a no haber respuesta del sistema.

Proyecto: Gestión
RIESGOS:
● Escases de unidades o conductores.
● Falla en los servidores internos.
N/A
CU-15
NOMBRE: Asignar servicio
COMPLEJIDAD: Baja PRIORIDAD: medio
ACTORES: ACT-1.
DESCRIPCIÓN: El sistema permitirá asignar el servicio a los conductores de las ambulancias
NOTAS:
● El sistema debe asignar a los conductores un servicio acorde a su disponibilidad, además
se dará de baja a los conductores ya con asignaciones para evitar retrasos e información
duplicada.
CRITERIOS DE ACEPTACIÓN: Asignación dependiente de la disponibilidad.
ESCENARIOS:
ES-15.01 DESCRIPCIÓN: Asignación exitosa de servicio.
● El sistema verifica el estado de los conductores.
● El sistema asigna a los conductores disponibles un servicio.
RESULTADOS:
● El servicio se asignó correctamente.
ES-15.02 DESCRIPCIÓN: Fallo en la asignación de servicio y envío a cola de espera, por falta
de disponibilidad de ambulancias.
● El sistema verifica el estado de los conductores y unidades.
● No hay conductores disponibles.
RESULTADOS:
● El servicio no puede ser asignado y se envía al cliente a cola de espera.
ES-15.03 DESCRIPCIÓN: Asignación no realizada por problemas en la base de datos.
● El sistema no puede cargar el estado de los conductores.
● El sistema no puede asignar servicio.
RESULTADOS:
● El servicio no puede ser asignado por error en la base de datos.
RIESGOS:
● Fallo en la asignación de servicio.

Proyecto: Gestión
N/A
CU-16
NOMBRE: Asignar ambulancia
REQUERIMIENTO FUNCIONAL ASOCIADO: R-22
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá asignar una ambulancia a un conductor
NOTAS:
El sistema debe actualizar el estado de las ambulancias asignadas, aquellas ambulancias
deberán tener un registro si se encuentran o no en el taller previo a su
asignación.
CRITERIOS DE ACEPTACIÓN: Se le asignara una ambulancia el sistema a cada conductor.
ESCENARIOS:
ES-16.01 DESCRIPCIÓN: Asignación de ambulancia exitosa.
● El sistema se actualiza
● Se asigna por parte del sistema una ambulancia al conductor.
RESULTADOS:
● Cada conductor se le asigna una ambulancia.
ES-16.02 DESCRIPCIÓN: Fallo al momento de asignación porque no hay unidades
disponibles.
● Se solicita la asignación de ambulancia.
● Se actualiza el sistema para ver el estado.
● No cuentan ambulancias registradas libres.
RESULTADOS:
● No se logró la asignación.
ES-16.03 DESCRIPCIÓN: Error al momento de asignación por error de actualización de
salidas de ambulancias.
● Se solicita una asignación de ambulancia a un conductor.
● En el sistema no se encuentra ambulancias.
● No se registraron correctamente las que salieron del taller.
● Se vuelve actualizar el sistema.

Proyecto: Gestión
RESULTADOS:
● No se puedo asignar ambulancias por un error de registro previo a la salida
del taller.
RIESGOS:
● Poco inventario de ambulancias.
● Mala comunicación entre procesos
N/A
CU-17
NOMBRE: Asignar Conductor
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá asignar conductor a las ambulancias acordes a la
disponibilidad de los conductores.
NOTAS: El sistema debe asignar a los conductores la siguiente información sobre los clientes:
Nombres, Cedula, Dirección, Edad, Días libres, Fecha de Vacaciones.
CRITERIOS DE ACEPTACIÓN: La asignación de conductores es acorde a la disponibilidad de
ambulancias.
ESCENARIOS:
ES-17.01 DESCRIPCIÓN: Error en la asignación por inconsistencia de ambulancias
disponibles.
● Inicio del sistema para la asignación
● Se verifica la disponibilidad de ambulancias.
● La cantidad disponible no concuerda.
● Se debe actualizar el sistema.
RESULTADOS:
● Fallo en la base de datos con las cantidades reales.
ES-17.02 DESCRIPCIÓN: Asignación de conductor exitosa.
● Inicio del sistema para la asignación.
● Se le asigna una ambulancia al conductor.
● Asignación correctamente.
RESULTADOS:
● Asignación de correcta al conductor.

Proyecto: Gestión
ES-17.03 DESCRIPCIÓN: Error al momento de asignación de conductor.
● Inicio del sistema para la asignación.
● No se logra validar la disponibilidad.
● Los datos no están correctamente.
RESULTADOS:
● Se crea un error al momento de verificación por error de datos.
RIESGOS:
● Error de verificación con la disponibilidad.
N/A
CU-18
NOMBRE: Emitir aviso de pago
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá emitir un aviso de pago mensual a los clientes.
NOTAS: El sistema debe emitir mediante notificación un aviso de pago a los clientes con
servicios asignados y gestionados, permitiendo el respectivo cobro de este.
CRITERIOS DE ACEPTACIÓN: Emisión de aviso de pago exitoso
ESCENARIOS:
ES-18.01 DESCRIPCIÓN: Exitosa emisión de aviso de pago por parte del sistema.
● El sistema registra a los clientes que hayan adquirido el servicio de
ambulancias.
● El sistema verifica aquellos pagos pendientes.
● El sistema emite una notificación al cliente y al banco de la deuda.
RESULTADOS:
● El aviso de pago se emite satisfactoriamente.
ES-18.02 DESCRIPCIÓN: Fallo en generación del aviso de pago por datos de email
incorrectos.
● El sistema registra a los clientes que hayan adquirido el servicio de
ambulancias.
● El sistema verifica aquellos pagos pendientes.
● El sistema emite una notificación al cliente y al banco de la deuda.
● El cliente no recibe la notificación porque ingresó una dirección errónea

Proyecto: Gestión
RESULTADOS:
● El aviso de pago no llegó al cliente por mal ingreso de dirección email, por
lo tanto, el banco tendrá que contactar al cliente para corregir su correo.
ES-18.03 DESCRIPCIÓN: Fallo en emisión de aviso de pago por fallas en la base de datos.
● Fallo al registrar los datos del cliente
● El sistema no tiene suficiente información para enviar la notificación.
RESULTADOS:
● El aviso no puede ser emitido por falta de datos en el registro de clientes.
RIESGOS:
● Fallo en la base de datos
● Falla en la entrega de la notificación de pago.
N/A
CU-19
NOMBRE: Emitir aviso de cobro
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá emitir el aviso del cobro al banco
NOTAS: El sistema debe emitir el aviso de cobro a los clientes y al Banco los recibos para poder
efectuar los respectivos cobros, el banco recibirá los recibos de los pagos.
CRITERIOS DE ACEPTACIÓN: Una vez cancelada la deuda se emite un aviso de cobro
ESCENARIOS:
ES-19.01 DESCRIPCIÓN: Emisión exitosa de aviso de cobro por parte del sistema.
● El cliente cancela la deuda en el banco
● El sistema registra el pago
● El sistema emite el aviso de cobro al banco y al cliente
RESULTADOS:
● El aviso de cobro se emite satisfactoriamente.
ES-19.02 DESCRIPCIÓN: Fallo en emisión del aviso de cobro porque el sistema no lo registra.
● El cliente cancela la deuda en el banco
● El sistema no registra el pago realizado
● El sistema no puede validar el cobro de la deuda
● El sistema no puede emitir el aviso de cobro
RESULTADOS:

Proyecto: Gestión
● No se pudo emitir el aviso de cobro por fallas en la base de datos.
ES-19.03 DESCRIPCIÓN: Fallo de emisión del aviso de cobro por falla en la BD.
● El sistema muestra valores no correspondientes a la deuda del cliente.
● El cliente no puede realizar el pago.
● El sistema no puede registrar el cobro.
● El sistema no puede emitir el aviso de cobro.
RESULTADOS:
● No se puede emitir el aviso de cobro por datos erróneos en la BD.
RIESGOS:
N/A
CU-20
NOMBRE: Control de pago
ACTORES: ACT-1
DESCRIPCIÓN: El sistema permitirá mantener un control de los recibos no cobrados emitidos al
banco
NOTAS: El sistema debe generar un listado de los clientes cuyos recibos de pago no pudieron
ser cobrados por el banco, emitiendo así un nuevo aviso de pago
CRITERIOS DE ACEPTACIÓN: Solo se podrá emitir un nuevo aviso de pago si la deuda no ha sido
cobrada.
ESCENARIOS:
ES-20.01 DESCRIPCIÓN: Reemisión del aviso de pago exitoso.
● El sistema verifica los recibos de pago no cobrados
● El sistema genera listado de las deudas no cobradas.
● El sistema emite de nuevo el aviso de pago
RESULTADOS:
● Nuevo aviso de pago emitido satisfactoriamente.

Caso 7 Los Rapidos SA - Gestion de una empresa de ambulancias.docx

Caso 7 Los Rapidos SA - Gestion de una empresa de ambulancias.docx

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Caso 7 Los Rapidos SA - Gestion de una empresa de ambulancias.docx

Similar a Caso 7 Los Rapidos SA - Gestion de una empresa de ambulancias.docx (20)

Último

Último (10)

Caso 7 Los Rapidos SA - Gestion de una empresa de ambulancias.docx