FRPB Das Plantilla Especificacion Diseno2022 (Final)

Proyecto: Gestión de
Ambulancias
Versión Producto:1.0 Cliente: Empresa Rápidos S.A.
DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE

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.)
Nombre del Documento: DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE SDD Versión: 1.1
Creación: Sábado 15 de diciembre,2021 Página: 1
Ambulancias
Tabla de contenido
1. INTRODUCCIÓN............................................................................................................................................... 3
1.1. OBJETIVO.......................................................................................................................................................... 3
1.2. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS...........................................................................................................3
1.3. AUDIENCIA.........................................................................................................................................................4
1.4. ALCANCE........................................................................................................................................................... 5
2. PRESENTACIÓN DEL PRODUCTO...................................................................................................................... 5
2.1. PROPÓSITO DEL SISTEMA......................................................................................................................................5
2.2.1. Planteamiento del problema........................................................................................................................5
2.2.2. Objetivo........................................................................................................................................................6
2.2.3. Alcance.........................................................................................................................................................6
2.2.4. El Sistema no contempla..............................................................................................................................7
2.2. RIESGOS............................................................................................................................................................ 7
3. DESCRIPCIÓN GENERAL................................................................................................................................... 8
3.1. CONTEXTO DEL PRODUCTO...................................................................................................................................8
3.2. PERSPECTIVAS FUTURAS DEL PRODUCTO...................................................................................................................9
3.3. REGLAS Y FUNCIONES DE NEGOCIO.........................................................................................................................9
4. REQUISITOS.................................................................................................................................................... 9
4.1. FUNCIONALES.....................................................................................................................................................9
4.2. NO FUNCIONALES..............................................................................................................................................10
4.2.1. Tamaño y rendimiento...............................................................................................................................11
4.2.2. Calidad........................................................................................................................................................11
4.2.3. Otros...........................................................................................................................................................11
5. ARQUITECTURA DEL PRODUCTO/SISTEMA..................................................................................................... 11
5.1. VISTA DE CASOS DE USO....................................................................................................................................11
5.1.1. Actores........................................................................................................................................................11
5.1.2. Modelo de casos de Uso.............................................................................................................................12
5.1.3. Lista de casos de Uso..................................................................................................................................13
5.1.4. Descripción de los Casos de Uso.................................................................................................................14
5.2. VISTA FUNCIONAL.............................................................................................................................................16
5.2.1. Modelo de Análisis......................................................................................................................................16
5.2.2. Interfaces con el usuario.............................................................................................................................18
5.3. VISTA LÓGICA...................................................................................................................................................19
5.3.1. Descripción.................................................................................................................................................19
5.3.2. Paquetes de Diseño Arquitectónicamente Significativos...........................................................................21
5.3.3. Vista de Implementación - Componentes...................................................................................................24
5.4. VISTA DE DESPLIEGUE - AMBIENTE FÍSICO..............................................................................................................25
5.5. VISTA DE DATOS...............................................................................................................................................26
5.5.1. Definiciones................................................................................................................................................26
5.5.2. Diseño de Base de Datos............................................................................................................................27
5.6. REQUISITOS DE SOFTWARE/HARDWARE................................................................................................................27
6. CALIDAD....................................................................................................................................................... 28
7. Observaciones...........................................................................................................................................................28
Ambulancias
1. Introducción
1.1. Objetivo
La presente Documentación de Diseño de Software tiene como objetivo definir con claridad
los requerimientos correspondientes al proyecto.
Este documento debe ser fiel reflejo de toda la funcionalidad del sistema, contiene toda
aquella información necesaria para que el lector de este documento pueda entender
claramente los objetivos y el funcionamiento del producto mencionado.
1.2. Definiciones, Acrónimos y Abreviaturas

<
Término Definición Alias Abre
viatu
ra
Cliente • Es la persona que solicita el servicio Cliente
Ambulancia• Es el medio de transporte indispensable para la Ambulancia
prestación del servicio.
Conductor • Es el encargado de manejar la ambulancia. Conductor
Servicio • Es la prestación que realiza la empresa al cliente. Servicio
Paramédico• Es el encargado de asistir a los pacientes. Paramédico
Lista de
• Es una lista de clientes a los que el sistema Lista de clientes
clientes en bancario del Banco Guayaquil no autorizó el en mora
mora cobro.
Pagado • Estado que indica que el cliente ha pagado el Pagado
servicio, es decir, el banco pudo realizar el cobro P
del servicio de manera exitosa.
Deuda • Estado que indica que el cliente tiene no ha Deuda
pagado el servicio, es decir, el banco no pudo D
realizar el cobro del servicio.
Mantenimie • Estado que indica una ambulancia que está en Mantenimiento
nto en el proceso de mantenimiento. en el taller M
taller
Ocupado/a• Estado que indica que el conductor, paramédico, Ocupado/a
o la ambulancia ya han sido asignados a un O
servicio actualmente.
Disponible • Estado que indica que el conductor, paramédico, Disponible
o la ambulancia se encuentran actualmente D
disponibles para ser asignados a un servicio.
Fuera de
• Estado que indica que el conductor ya no se Fuera de servicio
servicio encuentra en horas laborables, por lo tanto, no F
está disponible para ser asignado a un servicio.
Ambulancias
Finalizado • Estado que indica que el servicio ya ha sido Finalizado

atendido, es decir, los conductores, paramédicos
F
y ambulancias asignadas a dicho servicio se
encuentran disponibles.
Muy urgente • Nivel de prioridad alto al momento de la Muy urgente
I
asignación de ambulancias disponibles
Urgente • Nivel de prioridad intermedio al momento de Urgente
II
asignación de ambulancias disponibles
Poco • Nivel de prioridad bajo al momento de asignación Poco Urgente
III
Urgente de ambulancias disponibles.
Asistido • Estado que indica que el servicio está siendo Asistido
atendido. Es el lapso de tiempo en el que los
A
conductores, ambulancias y paramédicos
asignados al servicio están en estado a “O”.
Espera • Estado que indica que el servicio está en espera Espera
E
de ser atendido.
Plantilla de• Plantilla que contiene los campos necesarios para Plantilla de
registro registrar un nuevo cliente en el sistema. registro
• Se genera de manera automática cuando la
secretaria registra un servicio y el cliente que ha
solicitado dicho servicio no se encuentra
registrado en el sistema.
• Por lo tanto, esta plantilla contiene datos
autocompletados como el Nombre y Cédula del
cliente ya que éstos ya han sido registrados en el
servicio.
Días libres • Son los días que los conductores no laboraron: Días libres
Días libres pagados (días libres al mes, días libres
por feriados, días libres por vacaciones, días que
pidieron permiso por calamidad doméstica,
enfermedad, etc.) y días libres no pagados (días
que pidieron permiso personal).
Remuneraci• En la Tabla "Días libres del conductor", el campo Remuneración
ón Remuneración se refiere a si el día libre es
pagado o no.
Próxima • Es un campo del registro de la ambulancia que Próxima fecha
fecha de hace referencia a la próxima fecha de de revisión
revisión mantenimiento preventivo de la ambulancia.
Sistema • Entidad que provee servicios de cobros, Banco Banco
bancario Guayaquil.
Dirección • En el registro del servicio, el campo dirección se Dirección
refiere al lugar donde debe trasladarse la
ambulancia.
Ambulancias
1.3. Audiencia
<

Competencias
Criterios de técnicas/
Stakeholders Rol Responsa- Intereses éxito Preocupación
Relación de
vialidad ambiente de
trabajo
Gerente Usuario Generar Validar •el -Gestionar -Calidad de N/A
directo informes complimi las los servicios
Enviar ento de actividades que brinda la
recibos al procesos de los otros empresa y
banco dentro de actores. asuntos
la internos de la
empresa. misma.
-
Involucramien
to de los
actores que
intervienen en
el proceso.
Secretarias Usuario Registrar Perfeccio -Satisfacción -No se Liberación del

directo datos nar y de los registre de servicio.
requeridos validar los clientes forma Gestión de
por el procesos apropiada la procesos.
sistema. información
Gestionar requerida.
solicitudes
de los
clientes.
Conductores Usuario Proveer Ejecutar• -Satisfacer Tipo de -Brindar un
indirecto servicio las las servicio que buen servicio.
solicitude necesidades va a brindar
s de de los (dependiendo
servicio clientes. del tipo de
ingresada emergencia a
s al afrontar).
sistema.
Cliente Usuario Hacer uso Crear • N/A Calidad del N/A
Indirecto de los solicitude servicio a
servicios s de recibir.
de la servicio.
empresa.
Servicios Sistemas Proveer Gestionar -Soporte en - Facturación N/A
Ambulancias
Bancarios de sistema de sistema la a clientes que

servicio cobros al de generación no han podido
sistema. cobranzas de informes cubrir el pago
. sobre la del servicio.
Informar facturación.
de recibos
• -Cobro de
no servicios.
cobrados
1.4. Alcance
El alcance de la DDS comprende la definición de los requerimientos funcionales y no
funcionales, como también otros aspectos que definen el producto, incluyendo objetivo del
producto, restricciones, lo que el sistema no contempla, reglas de negocio, requerimientos
de interfaz, restricciones de diseño, requerimientos de licencia o componentes comprados
necesarios para el producto a desarrollarse, entre otras cosas
2. Presentación del Producto

2.1. Propósito del Sistema
2.2.1. Planteamiento del problema

Para los trabajadores de la empresa Los Rápidos S.A., quienes realizan el proceso manual
de asignación de ambulancias, conductores y paramédicos a los servicios que solicitan los
clientes, se construye el software Rapisoft, aplicación de escritorio que asigna de manera
automática las ambulancias, paramédicos y conductores disponibles a cada servicio
solicitado, registra a los clientes, conductores, ambulancias, paramédicos y servicios
prestados, gestiona el cobro a los clientes, y emite dos informes mensuales, uno sobre el
rendimiento de los conductores y otro sobre los clientes en mora.
2.2.2. Objetivo
El problema de la asignación manual de las ambulancias, paramédicos y conductores a
cada servicio solicitado genera demora y desorganización debido a que no existe un proceso
automatizado de cada actividad que se genera cada vez que se realiza una asignación.
Afecta a: Clientes, secretarias, paramédicos, conductores y gerente de la empresa
:
2.2.3. Alcance
El alcance de la DDS comprende la definición de los requerimientos funcionales y no

funcionales, como también otros aspectos que definen el producto, incluyendo objetivo del
producto, restricciones, lo que el sistema no contempla, reglas de negocio, requerimientos
Ambulancias
de interfaz, restricciones de diseño, requerimientos de licencia o componentes comprados

necesarios para el producto a desarrollarse, entre otras cosas
Afecta a: Clientes, secretarias, paramédicos, conductores y gerente de la empresa.
Cuyo impacto es:

 El tiempo para realizar las asignaciones es alto.
 Se desperdicia tiempo mientras se piden los datos completos del cliente y
se imprime el comprobante pago.
 Se desperdicia tiempo en volver a pedir datos de clientes que ya están
registrados.
 Se desperdicia tiempo en tareas relacionadas con buscar la bitácora del
conductor y llenar los datos con el nuevo servicio.
 La tediosa labor de buscar y contar los servicios mensuales de cada
conductor para hacer el informe (manual) dirigido al gerente.
 El proceso manual de buscar en los comprobantes, generados en el mes, a
los clientes que pagaron con cheques sin fondo, para posteriormente
listarlos y gestionar ese proceso de cobro.
Una solución satisfactoria permitirá:

 Que la gestión y priorización de las asignaciones las realice el sistema.
 Que se implemente un nuevo método de pago (tarjeta), el cual aportará
con la disminución de datos (iniciales) requeridos del cliente, acortando
el tiempo de asignación.
 Que se genere automáticamente una plantilla de registro del cliente cada
vez que se registra un servicio, en caso de que ya esté registrado, solo se
agregará el nuevo servicio que ha solicitado.
 Que se registre automáticamente los nuevos servicios asignados a cada
conductor y paramédico.
 Que se genere el informe mensual para el gerente, sobre los conductores,
con los datos registrados en el sistema.
 Que se conozca el estado de cada cliente, conductor, paramédico,
ambulancia, y servicio.
 Que exista un seguimiento de los clientes en mora, mediante un informe
detallado con todos los datos registrados en el sistema.
2.2.4. El Sistema no contempla

NO CONTEMPLA
 Registro de las personas que manejan el sistema (secretarias).
 Registro de las personas que manejan el sistema externo de cobros (banco).
 Asignación de ambulancias, paramédicos y conductores manualmente.
 Modificación de los datos del servicio una vez registrado.
 Validación de cédula de ciudadanos que no sean de Ecuador, por lo tanto, no permitirá el
registro de personas de personas extranjeras.
Ambulancias
2.2. Riesgos
Estrategia de
Factor de riesgo Probabilidad Impacto mitigación Responsable
Poco interés de Media Alto Llevar a cabo talleres o Gerente de
las secretarias. capacitaciones para el proyecto
correcto uso del
software.
Cambio del Bajo Alto Personal del soporte Personal

sistema técnico nos enviará un técnico de la
bancario. mail sobre las empresa.
novedades en caso de
cambio en el sistema
bancario.
Sobrepasar el Bajo Alto El sistema muestre Equipo de

almacenamiento mensajes de alerta desarrollo.
permitido en la cuando la capacidad de
base de datos. la base de datos esté
llegando a su límite.
Probabilidad de Baja Alto Cobrar anticipadamente Gerente de
abandono del el 30% del costo del proyecto
proyecto proyecto en el caso de
que la empresa a la cual
se le está desarrollando
el sistema desea
abandonar.
Perder archivos Media Alto Realizar copias de Equipo de
de vital seguridad físicas y en la desarrollo.
importancia del nube cada vez que un
proyecto archivo o el proyecto en
su totalidad se llegue a
modificar.
Ambulancias
3. Descripción General
3.1. Contexto del Producto
A diferencia del sistema actual en el que todo se maneja de manera física y manual, la
gestión de servicios ambulatorios será semiautomatizada ya que a pesar de que el objetivo
de este sea una automatización completa del servicio contará con la intervención de las
secretarias de la empresa Rápidos S.A. que lo gestionarán.
El producto no es independiente ya que trabaja en conjunto con el sistema del Banco
Guayaquil. Además, este producto no es parte de un sistema más grande, pero sí tendrá
conexiones con sistemas pertenecientes a otras entidades.
3.2. Perspectivas futuras del producto

Este producto tendrá versiones a futuro en las que se incluirá la gestión de usuarios
(empleados y gerente) de la empresa, el registro de clientes/trabajadores extranjeros.
Ambulancias
3.3. Reglas y Funciones de Negocio

<Gestión de Ambulancias: Situación Actual (AS IS)
Gestión de Ambulancias: Situación Propuesta (TO BE)
Ambulancias
Ambulancias
Gestión de Cobros: Situación Propuesta (TO BE)
Ambulancias
Registrar Clientes: Situación Propuesta (TO BE)
Ambulancias
4. REQUISITOS
4.1. Funcionales
<
Número: RF-1
Título: Ingresar cliente
Texto: Describe los datos requeridos del cliente mantenidos por el sistema.
Tipo: Funcional - Datos
Detalles de El sistema debe almacenar la siguiente información acerca de los clientes:
requisitos y • Nombres y apellidos: Caja de texto editable con longitud de 50

restricciones: caracteres. Tipo de dato “cadena de caracteres”.
• Cédula de identidad: Caja de texto editable con longitud 10. Tipo
de dato “cadena de caracteres”, solo caracteres numéricos.
• Fecha de nacimiento: Formato DD/MM/AA. 3 Combo box (día,
mes y año).
• Teléfono: Caja de texto editable con longitud máxima 10. Tipo de
dato “cadena de caracteres”, solo caracteres numéricos.
• Dirección domiciliaria: Caja de texto editable con longitud de 100
caracteres. Tipo de dato “cadena de caracteres”.
• E-mail: Caja de texto editable con longitud de 40 caracteres. Tipo
de dato “cadena de caracteres”.
• Número de cuenta bancaria: Caja de texto editable, con longitud
16. Tipo de dato “cadena de caracteres”, solo caracteres
numéricos.
• Código del cliente: Caja de texto NO editable con longitud 6. Tipo
• Estado del cliente: 2 “Radio button”.
• Servicios: Combo box, las opciones serán los códigos de los
servicios que ha solicitado.
Fecha de 10/12/2021
Versión3.0
revisión y
versión:
Prioridad: <Alta >
Ambulancias
Número: RF-2
Título: Ingresar ambulancia
Texto: Describe los datos requeridos de la ambulancia mantenidos por el sistema.
Detalles de El sistema debe almacenar la siguiente información acerca de las ambulancias:
requisitos y • Código de la ambulancia: Caja de texto NO editable con longitud

restricciones: 4. Tipo de dato “cadena de caracteres”, solo caracteres
numéricos.
• Placa vehicular: Caja de texto editable con longitud máxima de 7
caracteres. Tipo de dato “cadena de caracteres”, los 3 primeros
caracteres alfabéticos y los 4 siguientes numéricos.
• Próxima fecha de revisión: Formato DD/MM/AA. 3 Combo box
(día, mes y año).
• Estado de la ambulancia: 3 “Radio button”.
servicios en los que ha sido asignada.
Fecha de 10/12/2021
Versión3.0
revisión y
versión:
Prioridad: <Alta>
Ambulancias
Número: RF-3
Título: Ingresar conductor
Texto: Describe los datos requeridos del conductor mantenidos por el sistema.
Detalles de El sistema debe almacenar la siguiente información acerca de los conductores:

mes y año).
• Código del conductor: Caja de texto NO editable con longitud 4.
Tipo de dato “cadena de caracteres”, solo caracteres numéricos.
• Estado del conductor: 3 “Radio button”.
• Días libres: Tabla de 3 columnas (Día, Remuneración, Motivo) y el
número de filas dependerá de la cantidad de días libres.
servicios en los que ha sido asignado.
Fecha de 10/12/2021
Versión3.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-4
Ambulancias
Título: Ingresar paramédico
Texto: Describe los datos requeridos del paramédico mantenidos por el sistema.
Detalles de El sistema debe almacenar la siguiente información acerca de los paramédicos:

mes y año).
• Código del paramédico: Caja de texto NO editable con longitud 4.
Tipo de dato “cadena de caracteres”, solo caracteres numéricos.
• Estado del paramédicos: 3 “Radio button”.
servicios en los que ha sido asignado.
Fecha de 10/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-5
Ambulancias
Título: Ingresar servicio
Texto: Describe los datos requeridos del servicio mantenidos por el sistema
Detalles de El sistema debe almacenar la siguiente información acerca de los servicios:
requisitos y • Código del servicio: Caja de texto NO editable con longitud 6. Tipo
restricciones: de dato “cadena de caracteres”.
• Motivo de la emergencia: Área de texto editable con longitud 500.
Tipo de dato “cadena de caracteres”.
• Nivel de emergencia: 3 “Radio button”.
• Cantidad de ambulancias: Caja de texto editable con longitud 2.
Tipo de dato “entero”.
• Cantidad de paramédicos: Caja de texto editable con longitud 2.
Tipo de dato “entero”.
• Código de la ambulancia(s): Detalles de este campo en RF-2.
• Código del conductor(es): Detalles de este campo en RF-3.
• Código de los paramédicos: Detalles de este campo en RF-4.
• Estado del servicio: 3 “Radio button”.
• Dirección: Caja de texto editable con longitud de 100 caracteres.
Tipo de dato “cadena de caracteres”.
• Código del cliente: Detalles de este campo en RF-1.
• Fecha: Label, Formato DD/MM/AA.
• Hora: Label, Formato HH:MM:SS Sistema horario de 24 horas.
• Monto a pagar: Label, Formato de moneda EEUU ($).
Fecha de 10/12/2021
Versión4.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-6
Ambulancias
Título: Validar Número de cédula
Texto: El sistema validará los Números de cédula.
Tipo: Funcional - Funcionalidad
Detalles de El sistema deberá validar los números de cédula de los clientes, conductores y paramédicos registrados en el
sistema verificando que dicho número conste de 10 números.
requisitos y
restricciones: Nota: El sistema solo validará Números de cédula ecuatorianas. Si se ingresa un número de cédula no válido,
no se podrá seguir con el registro.
Fecha de 10/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-7
Título: Validar Número de cuenta bancaria
Texto: El sistema validará los Números de cuenta bancaria.
Detalles de El sistema deberá validar los Números de cuenta bancaria de los clientes registrados en el sistema. Se hará la
validación de dicho número constando que tenga un 20 carácter.
requisitos y
restricciones: Nota: El sistema solo validará Números de cuenta del Banco Guayaquil. Si se ingresa un número de cuenta
bancaria no válido, no se podrá generar el registro
Fecha de 10/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-8
Título: Validar Número de placas vehiculares
Texto: El sistema validará los Números de placa vehicular.
Ambulancias
Detalles de El sistema deberá validar los Números de placa vehicular de las ambulancias registradas en el sistema.
Se debe constar para hacerse valido de tres letras del abecedario español y seguido de tres números.
requisitos y
restricciones:
Fecha de 10/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-9
Título: Generar código del servicio
Texto: El sistema generará los códigos que dispondrán los servicios.
Tipo: Funcional – Funcionalidad
Detalles de El sistema deberá generar un código único para cada servicio:
requisitos y • Código del servicio: Constará de 6 dígitos aleatorios (4 numéricos

restricciones: y 2 alfabéticos).
Nota: El sistema no debe generar el mismo código de un servicio

eliminado.
Fecha de 10/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-10
Título: Generar código de la ambulancia
Texto: El sistema generará los códigos que dispondrán las ambulancias.
Ambulancias
Detalles de El sistema deberá generar un código único para cada ambulancia:
requisitos y • Código de la ambulancia: Constará de 4 dígitos aleatorios

restricciones: (numéricos).
Nota: El sistema no debe generar el mismo código de una ambulancia

eliminada.
Fecha de 10/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-11
Título: Generar código del conductor
Texto: El sistema generará los códigos que dispondrán los conductores.
Detalles de El sistema deberá generar un código único para cada conductor:
requisitos y • Código del conductor: Constará de 4 dígitos aleatorios

Nota: El sistema no debe generar el mismo código de un conductor

eliminado.
Fecha de 10/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-12
Título: Generar código del paramédico
Texto: El sistema generará los códigos que dispondrán los paramédico.
Detalles de El sistema deberá generar un código único para cada paramédico:
requisitos y • Código del paramédico: Constará de 4 dígitos aleatorios
Ambulancias
Nota: El sistema no debe generar el mismo código de un paramédico

eliminado.
Fecha de 10/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-13
Título: Generar código del cliente
Texto: El sistema generará los códigos que dispondrán los clientes.
Detalles de El sistema deberá generar un código único para cada cliente:
requisitos y • Código del cliente: Constará de 6 dígitos aleatorios (4 numéricos y

restricciones: 2 alfabéticos).
Nota: El sistema no debe generar el mismo código de un cliente

eliminado.
Fecha de 10/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-14
Título: Priorizar emergencias
Texto: El sistema deberá priorizar las emergencias al asignar ambulancias.
Detalles de Cuando solo queden 15 ambulancias en estado “D”, el sistema deberá

requisitos y priorizar las emergencias:
restricciones:
• Si se registra un servicio con emergencia Nivel III, el sistema
cambiará el estado de dicho servicio a “E”, y cada 2 minutos
Ambulancias
revisará la cantidad de ambulancias hasta que hayan más de 15

en estado “D”.
• Si se registra un servicio con emergencia Nivel I o II, el sistema

seguirá su procedimiento habitual, dándoles prioridad.
Fecha de 13/12/2020
Versión2.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-15
Título: Registrar servicio
Texto: El sistema permitirá registrar un nuevo servicio.
Detalles de El sistema mostrará los campos necesarios para ingresar los datos del
requisitos y servicio (Ver RF-5).
restricciones: Acerca de los siguientes campos:
• Cantidad de ambulancias: El sistema establecerá por defecto la
cantidad de 1 ambulancia, pero debe permitir editar dicha
cantidad.
Ambulancias
• Código de la ambulancia(s): El sistema debe asignar de manera

aleatoria la cantidad de ambulancias especificadas en el campo
“Cantidad de ambulancias”, y debe llenar este campo con el
código de dicha(s) ambulancia(s). Si no hay ambulancias
disponibles para asignar al servicio, este campo queda vacío.
• Código del conductor(es): El sistema debe asignar de manera
aleatoria la cantidad de conductores especificadas en el campo
“Cantidad de ambulancias”, y debe llenar este campo con este
campo el código de dicho(s) conductor(es). Si no hay conductores
disponibles para asignar al servicio, este campo queda vacío.
• Cantidad de paramédicos: El sistema establecerá por defecto la
cantidad de 2 paramédicos, pero debe permitir editar dicha
cantidad.
• Código de los paramédicos: El sistema debe asignar de manera
aleatoria la cantidad de paramédicos especificadas en el campo
“Cantidad de paramédicos”, y escribirá en este campo los códigos
de dichos paramédicos. Si no hay paramédicos disponibles para
asignar al servicio, este campo queda vacío.
• Código del cliente: El sistema debe comparar el número de cédula
ingresado con los números de cédula de los clientes registrados en
el sistema. Si no encuentra coincidencias, el sistema debe generar
el código del nuevo cliente, y lo escribirá en este campo. Si
encuentra una coincidencia, el sistema escribirá en este campo el
código del cliente del que se ha obtenido la coincidencia.
• Estado del servicio: El sistema seleccionará por defecto el estado
“A”. Si no hay ambulancia(s), conductor(es) o paramédico(s)
disponible(s) para asignar al servicio, el sistema deberá
seleccionar el estado “E”.
• Fecha: El sistema llenará este campo con la fecha actual.
• Hora: El sistema llenará este campo con la hora actual.
• Monto a pagar: El sistema llenará este campo con el monto a
pagar según la cantidad de ambulancias y paramédicos
solicitados. La tarifa base (1 ambulancia y 2 paramédicos) es de
$20. Si la emergencia requiere ambulancias adicionales, el costo
es $10 más por cada ambulancia, y $15 por cada paramédico
adicional.
Nota:
 El sistema solo debe asignar ambulancias, conductores y paramédicos
en estado “D”.
 Cada vez que asigne ambulancias, conductores y paramédicos a un

servicio, el sistema debe realizar lo descrito en los RF-39 y RF-44.
 Si la secretaria cancela el registro del servicio, el sistema deberá

cambiar el estado a “D” de la(s) ambulancia(s), conductor(es) o
Ambulancias
paramédico(s), en caso de haber sido asignados(as), y eliminar el

servicio a los mismos.
 El sistema debe priorizar las asignaciones cuando solo queden 15

ambulancias en estado “D”. (Ver RF-14)
(Ver definición de abreviaturas en el glosario)

Fecha de 23/12/2021
Versión9.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-16
Título: Eliminar servicio
Texto: El sistema permitirá eliminar los servicios registrados en el sistema.
Detalles de El sistema permitirá eliminar un servicio, si y solo si, el servicio está en

requisitos y estado “F” y el cliente está en estado “P”. Caso contrario no se permitirá
Ambulancias
restricciones: eliminar al servicio.

Los datos requeridos para eliminar:
 Cedula: Deberá ser tipo String y tendrá una longitud de 11
caracteres.
 Estado: Deberá ser tipo String y tendrá una longitud de 5
caracteres.
Restricción:
• Debe tener un acceso vigente.
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: Baja
Número: RF-17
Título: Consultar servicios
Ambulancias
Texto: El sistema permitirá consultar todos los servicios registrados en el sistema.
Detalles de El sistema deberá mostrar una tabla de 8 columnas:

requisitos y • Fecha
restricciones: • Código del servicio
• Código del cliente
• Cédula del cliente
• Código del conductor
• Código del paramédico
• Código de la ambulancia
• Estado del servicio.
El sistema deberá ordenar los servicios por defecto por fecha (desde la
fecha más reciente hasta la más antigua).
Restricción:
 Deberá estar registrado.
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-18
Título: Registrar ambulancia
Texto: El sistema permitirá registrar nuevas ambulancias.
Detalles de El sistema mostrará los campos necesarios para ingresar los datos de la
requisitos y ambulancia. (Ver RF-2)
restricciones:
Ambulancias
Fecha de 23/12/2020
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RF-19
Título: Modificar ambulancia
Texto: El sistema permitirá modificar los datos guardados previamente de las ambulancias registradas en el sistema.
Detalles de El sistema permitirá modificar los datos de la ambulancia. (Ver RF-2).

requisitos y Restricción:
restricciones: El sistema no permitirá modificar el campo Código de la ambulancia, ni Placa vehicular.
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Media>
Número: RF-20
Título: Eliminar ambulancia
Texto: El sistema permitirá eliminar las ambulancias registrados en el sistema.
Detalles de El sistema solo permitirá eliminar una ambulancia si, y solo si, su estado
requisitos y es “D” o “M”. Caso contrario no se permitirá eliminar a la ambulancia.
restricciones: (Ver significado de abreviaturas en el glosario.)
Fecha de 23/12/2021
Versión1.0
Ambulancias
revisión y
versión:
Prioridad: <Baja>
Número: RF-21
Título: Consultar ambulancias
Texto: El sistema permitirá consultar todas las ambulancias registrados en el sistema.
Detalles de • El sistema deberá ordenar las ambulancias por defecto por su

requisitos y código (de manera ascendente).
restricciones:
• El sistema deberá mostrar una tabla de 4 columnas: Código de la
ambulancia, Placa vehicular, Próxima fecha de revisión y Estado
Ambulancias
de la ambulancia.
• El sistema permitirá filtrar las ambulancias por cada campo de la

tabla.
• El sistema permitirá Ver los datos de cada ambulancia en una

nueva ventana. En esta nueva ventana el sistema debe permitir
Modificar y Eliminar a la ambulancia. (Ver RF-19 y RF-20)
• El sistema debe permitir Actualizar el estado de la ambulancia

desde la cuarta columna de la tabla. (Ver RF-40)
Nota: Los campos mencionados se detallan en el RF-2.
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-22
Título: Registrar conductor
Texto: El sistema permitirá registrar nuevos conductores.
requisitos y conductor. (Ver RF-3)
restricciones:
Ambulancias
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-23
Título: Modificar conductor
Texto: El sistema permitirá modificar los datos guardados previamente de los conductores registrados en el sistema.
Detalles de El sistema permitirá modificar los datos del conductor. (Ver RF-3).
requisitos y Restricciones:
restricciones: El sistema no permitirá modificar los campos Código del conductor, Cédula de identidad, ni Nombres y
apellidos.
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Media>
Número: RF-24
Título: Eliminar conductor
Texto: El sistema permitirá eliminar los conductores registrados en el sistema.
Detalles de El sistema solo permitirá eliminar un conductor si, y solo si, su estado es
requisitos y “D” o “F”. Caso contrario no se permitirá eliminar al conductor. (Ver
restricciones: significado de abreviaturas en el glosario.)
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Ambulancias
Prioridad: Baja
Número: RF-25
Título: Consultar conductores
Texto: El sistema permitirá consultar todos los conductores registrados en el sistema.
Detalles de • El sistema deberá ordenar los conductores por defecto por su

restricciones:
• El sistema deberá mostrar una tabla de 4 columnas: Código del
conductor, Cédula del conductor, Nombres y apellidos del
Ambulancias
conductor y Estado del conductor.
• El sistema permitirá filtrar los conductores por cada campo de la

tabla.
• El sistema permitirá Ver los datos de cada conductor en una nueva

ventana. En esta nueva ventana el sistema debe permitir
Modificar y Eliminar al conductor. (Ver RF-23 y RF-24)
• El sistema debe permitir Actualizar el estado del conductor desde

la cuarta columna de la tabla. (Ver RF-41)
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-26
Título: Registrar paramédico
Texto: El sistema permitirá registrar nuevos paramédicos.
requisitos y paramédico. (Ver RF-4)
restricciones:
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Ambulancias
Prioridad: <Alta>
Número: RF-27
Título: Modificar paramédico
Texto: El sistema permitirá modificar los datos guardados previamente de los paramédicos registrados en el sistema.
Detalles de El sistema permitirá modificar los datos del paramédico. (Ver RF-4).
requisitos y Restricciones:
restricciones: El sistema no permitirá modificar los campos Código del paramédico, Cédula de identidad, ni Nombres y
apellidos.
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Media>
Número: RF-28
Título: Eliminar paramédico
Texto: El sistema permitirá eliminar los paramédicos registrados en el sistema.
Detalles de El sistema solo permitirá eliminar un paramédico si, y solo si, su estado es
requisitos y “D” o “F”. Caso contrario no se permitirá eliminar al paramédico. (Ver
restricciones: significado de abreviaturas en el glosario.)
Fecha de 23/12/2021
Versión1.0
revisión y
Ambulancias
versión:
Prioridad: Baja
Número: RF-29
Título: Consultar paramédicos
Texto: El sistema permitirá consultar todos los paramédicos registrados en el sistema.
Detalles de • El sistema deberá ordenar los paramédicos por defecto por su

restricciones:
paramédico, Cédula del paramédico, Nombres y apellidos del
paramédico y Estado del paramédico.
Ambulancias
• El sistema permitirá filtrar los paramédicos por cada campo de la

tabla.
• El sistema permitirá Ver los datos de cada paramédico en una

nueva ventana. En esta nueva ventana el sistema debe permitir
Modificar y Eliminar al paramédico. (Ver RF-27 y RF-28)
• El sistema debe permitir Actualizar el estado del paramédico

desde la cuarta columna de la tabla. (Ver RF-43)
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-30
Título: Generar plantilla de registro de nuevos clientes
Texto: El sistema deberá generar automáticamente la plantilla de registro del nuevo cliente que ha solicitado el
servicio.
Detalles de Cada vez que se registre un servicio, en caso de no haber encontrado

requisitos y coincidencias con los números de cédula de los clientes previamente
restricciones: registrados, el sistema deberá generar automáticamente la plantilla de
registro del nuevo cliente, con los siguientes campos autocompletados:
• “Código del cliente”, “Teléfono”, “Cédula de identidad”, “Nombres

y apellidos” (llenará estos campos con los datos obtenidos al
registrar el servicio), y “Estado del cliente” (Por defecto el estado
Ambulancias
será “D”).
Finalmente, el sistema deberá permitir a la secretaria llenar lo demás

campos necesarios para el registro del cliente (Ver RF-1).
Nota: Solo se podrá registrar un cliente si, y solo si, ha solicitado un

servicio.
Fecha de 23/12/2021
Versión3.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-31
Título: Listar clientes con plantilla de registro
Texto: El sistema deberá mostrar una lista de los clientes a los que se le generó automáticamente una plantilla de
registro.
Detalles de El sistema deberá mostrar una lista de los clientes a los que se le generó
requisitos y automáticamente una plantilla de registro. La lista mostrará:
restricciones: • Código del cliente
Ambulancias
• Número de cédula del cliente

• Nombre y apellidos del cliente
Nota: Los datos mencionados anteriormente describen sus campos con

mayor detalle en el RF-1.
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-32
Título: Generar orden de pago
Texto: El sistema deberá generar una orden de pago para cada cliente que solicitado servicios ese mes.
Detalles de El último día del mes, el sistema debe permitir al gerente generar las órdenes de pago de los clientes que han
solicitado servicios durante ese mes.
requisitos y La orden de pago contendrá los siguientes datos:
restricciones: • ID de orden de pago: El sistema deberá generar el identificador de
cada orden de pago, el cual estará formado por 10 caracteres
numéricos.
Ambulancias
• Fecha de la emergencia (Formato DD/MM/AA)

• Fecha de emisión
• Código del servicio
• Nombres y apellidos del cliente
• E-mail del cliente
• Número de cuenta bancaria del cliente
• Monto a pagar
• Número de cuenta bancaria de Los Rápidos S.A. (0123 4567 8910
1112)
Los datos mencionados anteriormente describen sus campos con mayor

detalle en los RF-1, RF-5.
Nota: La orden de pago necesita datos que solo se obtienen al registrar a

un cliente al sistema (Número de cuenta bancaria e E-mail), por lo tanto,
en caso de haber clientes sin registrar, el sistema no podrá generar las
órdenes de pago de dichos clientes. El sistema permitirá generar las
órdenes de pago de estos clientes (no registrados) el siguiente fin de mes.
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-33
Título: Modificar cliente
Texto: El sistema permitirá modificar los datos guardados previamente de los clientes registrados en el sistema.
Detalles de El sistema permitirá modificar los datos del cliente. (Ver RF-1).
requisitos y Nota:
restricciones:  El sistema no permitirá modificar los campos Código del cliente, Cédula de identidad, ni Nombres y
Ambulancias
apellidos.
 Si la orden de pago del cliente que se está modificando ya ha sido generada, no se permitirá modificar el
campo “Número de cuenta bancaria”.
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-34
Título: Eliminar cliente
Texto: El sistema permitirá eliminar los clientes registrados en el sistema.
Detalles de El sistema solo permitirá eliminar un cliente si, y solo si, su estado es “P”,
requisitos y caso contrario no se permitirá eliminar al cliente.
restricciones:
Nota: Ver significado de abreviaturas en el glosario.
Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: Baja
Número: RF-35
Título: Consultar clientes
Texto: El sistema permitirá consultar todos los clientes registrados en el sistema.
Detalles de • El sistema deberá ordenar los clientes por defecto por su código
requisitos y (de manera ascendente).
restricciones:
cliente, Cédula del cliente, Nombres y apellidos del cliente y Estado
del cliente.
Ambulancias
• El sistema permitirá filtrar los clientes por cada campo de la tabla.
• El sistema permitirá Ver los datos de cada cliente en una nueva

ventana. En esta nueva ventana el sistema debe permitir
Modificar y Eliminar al cliente. (Ver RF-33 y RF-34)
• El sistema debe permitir Actualizar el estado del cliente desde la

cuarta columna de la tabla. (Ver RF-42)
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-36
Título: Consultar órdenes de pago
Texto: El sistema permitirá consultar todas las órdenes de pago de clientes en estado “D”.
Detalles de • El sistema deberá mostrar solo las órdenes de pago de clientes en

requisitos y estado “D”.
restricciones:
• El sistema deberá mostrar una tabla de 4 columnas (Fecha de la
emergencia, ID de orden de pago, Código del servicio, Cédula).
• El sistema deberá ordenar las órdenes de pago por defecto por
Ambulancias
fecha: desde la fecha más reciente hasta la más antigua.
• El sistema permitirá filtrar las órdenes de pago por cada campo de

la tabla.
• El sistema debe permitir Ver el detalle de cada orden de pago en

una nueva ventana.
• El sistema debe permitir Enviar todas las órdenes de pago al

banco. (Ver RF-37)
Las órdenes de pago de clientes en estado “P” no se listarán.
Fecha de 23/12/2021
Versión3.0
revisión y
versión:
Prioridad: <Media>
Número: RF-37
Título: Enviar órdenes de pago al banco
Texto: El sistema permitirá al gerente enviar los órdenes de pago al banco Guayaquil.
Detalles de El último día de cada mes, el sistema deberá permitirle al gerente enviar las órdenes de pago al banco
Guayaquil para que éste se encargue de la gestión del cobro a los clientes.
requisitos y
Nota: Las órdenes de pago son generadas automáticamente por el sistema (Ver RF-32).
restricciones:
Fecha de 23/12/2021
Versión4.0
revisión y
versión:
Ambulancias
Prioridad: <Alta>
Número: RF-38
Título: Generar informe de clientes con deuda
Texto: El sistema permitirá al gerente generar un informe de los clientes que no han pagado el servicio.
Detalles de El último día de cada mes, el sistema del banco Guayaquil enviará una lista de clientes a los que no autorizó el
cobro. El sistema permitirá al gerente generar un informe de dichos clientes, con los siguientes datos:
requisitos y • Código del servicio
restricciones: • Código del cliente
• Fecha de la emergencia
Ambulancias
• Monto a pagar
• Nombres y apellidos del cliente
• Teléfono del cliente
• E-mail del cliente
• Dirección domiciliaria del cliente

mayor detalle en los RF-1, RF-4.
Fecha de 23/12/2021
Versión4.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-39
Título: Agregar servicios a clientes, conductores, paramédicos y ambulancias
Texto: El sistema deberá agregar los nuevos servicios a los clientes ya registrados, conductores, ambulancias y
paramédicos.
Detalles de • Clientes ya registrados en el sistema: Cuando se registre un nuevo

requisitos y servicio, en caso de haber encontrado coincidencias con los
restricciones: números de cédula de los clientes previamente registrados, el
sistema deberá agregar automáticamente este nuevo servicio que
Ambulancias
ha solicitado.
• Conductores, paramédicos y ambulancias: Cuando se registre un

nuevo servicio El sistema deberá agregar automáticamente este
nuevo servicio brindado, al registro de los conductores,
paramédicos y ambulancias asignadas.
Fecha de 23/12/2021
Versión3.0
revisión y
versión:
Prioridad: Media
Número: RF-40
Título: Actualizar estado de la ambulancia
Texto: El sistema permitirá actualizar el estado de las ambulancias.
Detalles de El sistema permitirá actualizar manualmente el estado de cada

requisitos y ambulancia a “M” cuando esté en el taller, “D” cuando termine de brindar
restricciones: el servicio, o cuando regrese del taller.
Nota: El sistema deberá cambiar automáticamente el estado de la

ambulancia a “O” cuando les asigna un servicio; por lo tanto, no se
Ambulancias
permitirá el cambio manualmente a este estado.
(Ver abreviaturas en el glosario)

Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-41
Título: Actualizar estado del conductor
Texto: El sistema permitirá actualizar el estado de los conductores.
Detalles de El sistema permitirá actualizar manualmente el estado de cada conductor

requisitos y a “D” cuando termine de brindar el servicio o cuando empieza a laborar, y
restricciones: “F” cuando termine su jornada laboral.
Nota: El sistema deberá cambiar automáticamente el estado del
conductor a “O” cuando les asigna un servicio; por lo tanto, no se

Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-42
Título: Actualizar estado del cliente
Texto: El sistema actualizará el estado de los clientes.
Detalles de  El último día de cada mes, de acuerdo con la lista de clientes en

requisitos y mora que envía el sistema del Banco Guayaquil, el sistema deberá
restricciones: actualizar el estado de los mismos: los clientes de la lista
mantendrán su estado por defecto de “D”, los demás cambiarán su
estado a “P”.
 El sistema debe permitir cambiar manualmente el estado del cliente
Ambulancias
a “P”.
 El sistema no deberá permitir cambiar manualmente el estado del

cliente a “D”.
Nota: Cuando la secretaria intente cambiar el estado del cliente a “P”, el

sistema deberá buscar a dicho cliente en las listas de clientes en mora de
hasta hace 3 meses atrás. Si el sistema encuentra una coincidencia,
permitirá el cambio de estado a “P”, caso contrario no debe permitir
dicho cambio.

Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
Número: RF-43
Título: Actualizar estado del paramédico
Texto: El sistema permitirá actualizar el estado de los paramédicos.
Ambulancias
Detalles de El sistema permitirá actualizar manualmente el estado de cada

requisitos y paramédico a “D” cuando termine de brindar el servicio, o cuando
restricciones: empieza a laborar, y “F” cuando termine su jornada laboral.
Nota: El sistema deberá cambiar automáticamente el estado del

paramédicos a “O” cuando les asigna un servicio; por lo tanto, no se

Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: <Alta>
Número: RF-44
Título: Actualizar estado del servicio
Texto: El sistema permitirá actualizar el estado del servicio.
Detalles de El sistema permitirá actualizar manualmente el estado de cada servicio a

requisitos y “F” cuando ya se ha terminado de atender.
restricciones:
Nota: El sistema deberá cambiar automáticamente el estado del servicio
a “E” cuando está en espera, y a “A” cuando está siendo atendido; por lo
tanto, no se permitirá el cambio manualmente a estos estados.

Fecha de 23/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RF-45
Título: Contar servicios de conductores
Texto: El sistema registrará la cantidad de servicios por conductor y cliente
Detalles de El sistema deberá tener un registro de la cantidad de servicios que ha
Ambulancias
requisitos y prestado cada conductor, y permitirá visualizarlo mensualmente en el

restricciones: informe de conductores.
Fecha de 23/1/2021
Versión2.0
revisión y
versión:
Prioridad: <Baja>
Número: RF-46
Título: Generar informe de conductores
Texto: El sistema permitirá al gerente generar un informe sobre el trabajo de los conductores.
Detalles de El último día de cada mes, el sistema permitirá al gerente emitir un informe sobre los conductores detallando
los siguientes datos:
requisitos y • Código del conductor
restricciones:
Ambulancias
• Cédula del conductor

• Nombres y apellidos del conductor
• E-mail del conductor
• Cantidad de días laborados en ese mes
• Cantidad de servicios prestados en ese mes

mayor detalle en el RF-3.
Fecha de 23/12/2021
Versión3.0
revisión y
versión:
Prioridad: <Baja>
Número: RF-47
Título: Mostrar mensajes emergentes intuitivos.
Texto: Despliegue de mensajes emergentes.
Detalles de El sistema debe desplegar mensajes emergentes cuando se presente:

requisitos y • Notificar Registro exitoso.
restricciones: • Notificar Registro no exitoso (detallar razón)
Ambulancias
• Notificar Actualización de estado de ambulancias, conductores,

paramédicos, clientes, y servicios.
Fecha de 23/12/2021
Versión2.0
revisión y
versión:
Prioridad: <Media>
4.2. No funcionales
Número: RN-1
Título: Compatibilidad de periféricos con el software.
Texto: El sistema debe de estar preparado para uso de mouse y teclado.
Tipo: No funcional – de usabilidad
Detalles de El sistema debe de estar preparado para soportar los diferentes tipos de
requisitos y periféricos de entrada compatibles con el software, los básicos son:
restricciones: • Teclado
• Mouse
Fecha de 26/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RN-2
Título: Procesamiento de solicitudes de sistema.
Texto: El sistema debe de estar preparado para procesar 200 solicitudes por segundo.
Tipo: No funcional – de eficiencia
Detalles de El sistema debe procesar datos de:

requisitos y • Solicitudes de ambulancias.
Ambulancias
restricciones: • Registro y cambios de estados de conductores y ambulancias.

Para ello se dará la implementación de 5 servidores en donde todas son
cache.
Fecha de 26/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RN-3
Título: Compatibilidad con windows.
Texto: Ejecución y usabilidad en ambiente de Windows 7 o superior.
Tipo: No funcional – de usabilidad
Detalles de El sistema debe estar preparado para su respectivo uso en cualquier

requisitos y ambiente de Windows 7 o superior, cumpliéndose los siguientes
restricciones: requisitos mínimos:
• Resolución de pantalla 800 x 600, o superior.
• Cantidad de memoria RAM: 4Gb o superior.
Fecha de 26/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RN-4
Título: Optimización de memoria.
Texto: El sistema deberá liberar recursos de memoria al momento de cerrar una ventana y finalizar una
funcionalidad.
Tipo: No funcional – Performance
Detalles de El sistema debe liberar memoria al momento de finalizar procesos en

requisitos y general.
restricciones:  El sistema debe hacer un respaldo de la información cada 24
horas para así proteger la información y no llegue a perderse.
Ambulancias
Fecha de 26/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RN-5
Título: Mecanismos para integridad de datos.
Texto: Implementación de mecanismos para la integridad de datos.
Tipo: No funcional – Confiabilidad
Detalles de Detalle: El sistema se bloqueará de manera automática al sufrir algún

requisitos y tipo de ataque ya sea interno como externo o algún tipo de anomalía
restricciones: peligrosa y sola podrá ser desbloqueado por el administrador de
seguridad una vez haya solucionado todo.
Restricción: Solo el administrador de seguridad puede desbloquear el
sistema.
Fecha de 27/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Número: RN-6
Título: Disponibilidad del sistema.
Texto: Asegurar la disponibilidad del sistema.
Tipo: No funcional – Confiabilidad
Detalles de El sistema debe de estar disponible las 24 horas al día, los 7 días de la
requisitos y semana y los 365 días del año. Se tendrá el uso de servidores
restricciones: redundantes en caso de que haya problemas con el servicio.
Fecha de 27/12/2021
Versión1.0
revisión y
versión:
Ambulancias
Prioridad: Alta
Número: RN-7
Título: Redacción y edición
Texto: Correcta redacción y ortografía en las pantallas.
Tipo: No funcional – Documentación
Detalles de Uso de un módulo externo que apoye en la correcta composición de la

requisitos y ortografía empleada por el cliente o usuario al momento que use el
restricciones: sistema.
Fecha de 27/12/2021
Versión1.0
revisión y
versión:
Prioridad: Media
Número: RN-8
Título: Confidencialidad de información.
Texto: Garantizar la confidencialidad de la información.
Tipo: No funcional – Ético
Detalles de Garantizar por medio de un módulo externo la seguridad de los datos del
requisitos y cliente ya sean como: sus datos personales, datos bancarios,
restricciones: movimientos de dinero relacionados con los servicios del sistema.
Fecha de 27/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Ambulancias
Ambulancias
Número: RN-9
Título: Cumplimiento de contratos.
Texto: Garantizar el cumplimiento de términos establecidos en contrato.
Tipo: No funcional – Legal

Detalles de Se debe cumplir los términos establecidos en los Contratos en caso de no
requisitos y haberse cumplido se dará una multa o sanción.
restricciones:
Fecha de 27/12/2021
Versión1.0
revisión y
versión:
Prioridad: Alta
Ambulancias
4.2.1. Tamaño y rendimiento

 Disponibilidad: El sistema debe tener una disponibilidad del 99,99% de las veces en
que un usuario intente accederlo.
 Tiempo de respuesta: El sistema debe presentar un tiempo de respuesta corto. Toda
funcionalidad del sistema debe responder al usuario en menos de 5 segundos.
 Solución a problemas: Si el sistema sufre alguna caída del servidor este será
reparado en un lapso de mínimo 5 minutos, máximo 30 minutos.
 Disposición de memoria RAM: El sistema no debe utilizar más de 1 Gb de memoria
RAM
4.2.2. Calidad
• Tiempo de inactividad: Por seguridad el sistema debe manejar tiempo de inactividad
de 30 minutos máximo para cada uno de los usuarios registrados, si la sesión dura más
de este tiempo el usuario debe volver a iniciar sesión.
• Probabilidad de fallos: La probabilidad de falla del sistema LOS RAPIDOS S.A. no
debe ser mayor al 7%.
4.2.3. Otros
 Consistencia: Para asegurar que el sistema no presente inconsistencias se
tendrá que garantizar, siempre que sea posible, que los datos introducidos por
el usuario son válidos, detectando los posibles errores que éste puede cometer.
 Seguridad: El sistema debe proteger los datos almacenados muy rigurosamente
así mismo se debería bloquear el acceso a módulos que no están permitidos
según su nivel de jerarquía en el sistema para ello solo el DBA tendrá el acceso
de poder cambiar de roles a los usuarios y administradores del sistema.
 Tiempo de aprendizaje: En el sistema el tiempo de aprendizaje no debe ser
mayor de media hora ya que el sistema debe ser intuitivo y fácil de utilizar.
Ambulancias
5. Arquitectura del Producto/Sistema

5.1. Vista de Casos de Uso
5.1.1. Actores
Número: ACT-1
Actor: Secretaria
Descripción: Persona que maneja el sistema de manera directa.
Responsabilidades • Registrar, modificar y eliminar los servicios, clientes, conductores,

: paramédicos y ambulancias en el sistema.
• Cambiar estado de conductores, paramédicos y ambulancias a “D”
cuando terminan de proveer el servicio asignado, y el estado del ser-
vicio a “F”.
• Cambiar estado de ambulancias a “M” cuando estén en el taller en
mantenimiento.
• Cambiar estado de clientes a “P” cuando se cobre exitosamente los
pagos atrasados.
Fuentes: Gerente
Número: ACT-2
Actor: Cliente
Descripción: Persona que solicita el servicio de ambulancias a la empresa Rápidos S.A.
Responsabilidades • Solicitar servicio.

:
• Proporcionar datos personales y de la emergencia.
• Pagar el servicio.
Fuentes: Gerente
Ambulancias
Número: ACT-3
Actor: Gerente
Descripción: Es la persona que gestiona los procesos de la empresa e interactúa

directamente con el sistema.
Responsabilidades • Generar órdenes de pago.

:
• Enviar órdenes de pago.
• Generar informe de clientes en mora.
• Generar informe de conductores.
Fuentes: Gerente
Número: ACT-4
Actor: Sistema bancario
Descripción: Es la entidad encargada de realizar autorizar el cobro a los clientes de la

empresa Rápidos S.A.
Responsabilidades • Recibir las órdenes de pago.

:
• Autorizar cobro.
• Enviar lista de clientes en mora.
Fuentes: Gerente
Ambulancias
Número: ACT-5
Actor: Conductor
Descripción: Persona que conduce la ambulancia. No interactúa directamente con el

sistema.
Responsabilidades • Conducir la ambulancia asignada para proveer el servicio.

:
• Proporcionar datos personales para su registro en el sistema.
• Reportar a la secretaria sus cambios de estado y los de la ambulan-
cia.
Fuentes: Gerente
Número: ACT-6
Actor: Paramédico
Descripción: Persona asiste a los pacientes de la emergencia. No interactúa directamente

con el sistema.
Responsabilidades • Asistir a los pacientes del servicio asignado.

:
• Proporcionar datos personales para su registro en el sistema.
• Reportar sus cambios de estado a la secretaria.
Fuentes: Gerente
Ambulancias
5.1.2. Modelo de casos de Uso
Ilustración 1 Módulo de servicio
Ilustración 2 Módulo de paramédicos
Ambulancias
Ilustración 3 Módulo de conductor
Ilustración 4 Módulo de pagos
Ambulancias
Ilustración 5 Módulo de cliente
Ambulancias
5.1.3. Lista de casos de Uso

Prioridad Prioridad
Id Caso de Uso Complejidad
del cliente Técnica
CU1 Registrar servicio Media Alta Alta
CU2 Registrar cliente Media Alta Alta
CU3 Registrar conductor Baja Media Alta
CU4 Registrar ambulancia Baja Media Alta
CU5 Registrar paramédico Baja Media Alta
CU6 Consultar servicios Baja Media Baja
CU7 Consultar clientes Baja Media Baja
CU8 Consultar conductores Baja Media Baja
CU9 Consultar ambulancias Baja Media Baja
CU10 Consultar paramédicos Baja Media Baja
CU11 Modificar cliente Baja Media Baja
CU12 Modificar conductor Baja Media Baja
CU13 Modificar ambulancia Baja Media Baja
CU14 Modificar paramédico Baja Media Baja
CU15 Eliminar servicio Baja Media Baja
CU16 Eliminar cliente Baja Media Baja
CU17 Eliminar conductor Baja Media Baja
CU18 Eliminar ambulancia Baja Media Baja
CU19 Eliminar paramédico Baja Media Baja
CU20 Actualizar estado de la ambulancia Baja Alta Alta
CU21 Actualizar estado del conductor Baja Alta Alta
CU22 Actualizar estado del cliente Baja Alta Media
CU23 Actualizar estado del servicio Baja Alta Media
CU24 Actualizar estado del paramédico Baja Alta Alta
CU25 Consultar órdenes de pago Baja Alta Alta
CU26 Enviar órdenes de pago al banco Baja Alta Alta
CU27 Autorizar cobro Media Alta Alta
CU28 Enviar lista de clientes en mora Media Alta Alta
CU29 Generar informe de clientes en mora Media Alta Alta
CU30 Generar informe de conductores Baja Baja Baja
CU31 Generar órdenes de pago Media Alta Alta
Ambulancias
5.1.4. Descripción de los Casos de Uso

IDENTIFICADOR CASO DE USO: NOMBRE:
CU-1 Registrar servicio
COMPLEJIDAD: Media PRIORIDAD: Alta
REQUERIMIENTO FUNCIONAL ASOCIADO:
RF-5 Ingresar datos del servicio, RF-6 Validar Número de cédula, RF-9 Generar código del servicio, RF-15
Registrar servicio, RF-14 Priorizar emergencias, RF-30 Generar plantilla de registro de nuevos clientes,
RF-39 Agregar servicios a clientes, conductores, ambulancias y paramédicos.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: No aplica.
DESCRIPCIÓN: La secretaria registra el servicio de acuerdo a los datos que le proporciona el cliente
acerca de la emergencia.
NOTAS:
 La secretaria debe ingresar TODOS los datos que requiere el registro del servicio.
 La secretaria debe ingresar un número de cédula válido.
CRITERIOS DE ACEPTACIÓN: La secretaria registró el servicio o no.
ESCENARIOS:
ES-1.1 DESCRIPCIÓN: Registro del servicio exitoso
SUPOSICIONES/ASUNCIONES:
 El número de cédula ingresado es válido.
 Se ingresaron todos los datos requeridos en el registro del servicio.
RESULTADOS:
 El sistema muestra una notificación del registro exitoso.
 El sistema registra el servicio.
 El sistema cambia el estado de la ambulancia, conductor y paramédicos asignados a
“Ocupado”.
 El sistema agrega el servicio al registro de la ambulancia, conductor y paramédicos
asignados a “Ocupado”.
 El sistema genera una “plantilla de registro” para el nuevo cliente (ver RF-30), o, si es
el caso de un cliente ya registrado, se agrega el servicio al registro de dicho cliente.
ES-1.2 DESCRIPCIÓN: Registro del servicio no exitoso por ingreso de número de cédula no válido.
 El número de cédula ingresado no es válido.
 Se ingresaron todos los datos requeridos en el registro del servicio.
RESULTADOS:
 Se muestra una notificación indicando que el número de cédula ingresado no es
válido.
 No se registra el servicio.
ES-1.3 DESCRIPCIÓN: Registro del servicio no exitoso porque faltan datos por ingresar.
 No se ingresaron todos los datos requeridos en el registro del servicio.
Ambulancias

CU-1 Registrar servicio
RESULTADOS:
 Se muestra una notificación indicando que aún faltan datos por ingresar.
 No se registra el servicio.
REQUERIMIENTOS ESPECIALES - REGLAS DEL NEGOCIO Y DEL SISTEMA: No aplica.
RIESGOS: No aplica.
PROTOTIPO EXPLORATORIO: No aplica.

CU-2 Registrar cliente
RF-1 Ingresar datos del cliente, RF-7 Validar Número de cuenta bancaria, RF-13 Generar código del
cliente, RF-30 Generar plantilla de registro de nuevos clientes, RF-32 Generar orden de pago, RF-31
Listar clientes con plantilla de registro.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-1
DESCRIPCIÓN: La secretaria registra al cliente de acuerdo a los datos personales que le proporciona el
mismo.
NOTAS:
 La secretaria registra al cliente si, y solo si, el sistema ha generado una “plantilla de registro”
para dicho cliente (Ver RF-30 y RF-31).
 La secretaria debe ingresar TODOS los datos que requiere el registro del cliente.
 La secretaria debe ingresar un número de cuenta válido.
CRITERIOS DE ACEPTACIÓN: La secretaria registró al cliente o no.
ESCENARIOS:
ES-2.1 DESCRIPCIÓN: Registro del cliente exitoso
 El número de cuenta ingresado es válido.
 Se ingresaron todos los datos requeridos en el registro del cliente.
RESULTADOS:
 El sistema genera la orden de pago correspondiente a ese cliente.
ES-2.2 DESCRIPCIÓN: Registro del cliente no exitoso por ingreso de número de cuenta no válido.
 El número de cuenta ingresado no es válido.
 Se ingresaron todos los datos requeridos en el registro del cliente.
RESULTADOS:
Ambulancias

CU-2 Registrar cliente
 Se muestra una notificación indicando que el número de cuenta ingresado no es
válido.
 No se registra al cliente.
ES-2.3 DESCRIPCIÓN: Registro del cliente no exitoso porque faltan datos por ingresar.
 El número de cuenta ingresado es válido.
 No se ingresaron todos los datos requeridos en el registro del cliente.
RESULTADOS:
 No se registra al cliente.
RIESGOS: No aplica.

CU-3 Registrar conductor
COMPLEJIDAD: Baja PRIORIDAD: Alta
Ambulancias

CU-3 Registrar conductor
RF-3 Ingresar datos del conductor, RF-6 Validar Número de cédula, RF-11 Generar código del conductor,
RF-22 Registrar conductor.
ACTORES: Secretaria
DESCRIPCIÓN: La secretaria registra al conductor de acuerdo a los datos personales que le proporciona
el mismo.
NOTAS:
 La secretaria debe ingresar TODOS los datos que requiere el registro del conductor.
CRITERIOS DE ACEPTACIÓN: La secretaria registró al conductor o no.
ESCENARIOS:
ES-3.1
DESCRIPCIÓN: Registro del conductor exitoso
 Se ingresaron todos los datos requeridos en el registro del conductor.
RESULTADOS:
ES-3.2 DESCRIPCIÓN: Registro del conductor no exitoso por ingreso de número de cédula no
válido.
 Se ingresaron todos los datos requeridos en el registro del conductor.
RESULTADOS:
válido.
 No se registra al conductor.
ES-3.3 DESCRIPCIÓN: Registro del conductor no exitoso porque faltan datos por ingresar.
 No se ingresaron todos los datos requeridos en el registro del conductor.
RESULTADOS:
 No se registra al conductor.
RIESGOS: No aplica.
Ambulancias

CU-4 Registrar ambulancia
RF-2 Ingresar datos de la ambulancia, RF-8 Validar Número de placas vehiculares, RF-10 Generar código
de la ambulancia, RF-18 Registrar ambulancia
ACTORES: Secretaria
DESCRIPCIÓN: La secretaria registra a la ambulancia de acuerdo a los datos de la misma.
NOTAS:
 La secretaria debe ingresar TODOS los datos que requiere el registro de la ambulancia.
 La secretaria debe ingresar un número de placa vehicular válido.
CRITERIOS DE ACEPTACIÓN: La secretaria registró a la ambulancia o no.
ESCENARIOS:
ES-4.1 DESCRIPCIÓN: Registro de la ambulancia exitoso
 El número de placa vehicular ingresado es válido.
 Se ingresaron todos los datos requeridos en el registro de la ambulancia.
RESULTADOS:
ES-4.2 DESCRIPCIÓN: Registro de la ambulancia no exitoso por ingreso de número de placa
vehicular no válido.
 El número de placa vehicular ingresado no es válido.
 Se ingresaron todos los datos requeridos en el registro de la ambulancia.
RESULTADOS:
 Se muestra una notificación indicando que el número de placa vehicular ingresado
no es válido.
 No se registra a la ambulancia.
ES-4.3 DESCRIPCIÓN: Registro de la ambulancia no exitoso porque faltan datos por ingresar.
 El número de placa vehicular ingresado es válido.
 No se ingresaron todos los datos requeridos en el registro de la ambulancia.
RESULTADOS:
 No se registra a la ambulancia.
RIESGOS: No aplica.
Ambulancias

CU-5 Registrar paramédico
RF-4 Ingresar datos del paramédico, RF-6 Validar Número de cédula, RF-12 Generar código del
paramédico, RF-26 Registrar paramédico.
ACTORES: Secretaria
DESCRIPCIÓN: La secretaria registra al paramédico de acuerdo a los datos personales que le
proporciona el mismo.
NOTAS:
 La secretaria debe ingresar TODOS los datos que requiere el registro del paramédico.
CRITERIOS DE ACEPTACIÓN: La secretaria registró al paramédico o no.
ESCENARIOS:
ES-5.1 DESCRIPCIÓN: Registro del paramédico exitoso
 Se ingresaron todos los datos requeridos en el registro del paramédico.
RESULTADOS:
ES-5.2 DESCRIPCIÓN: Registro del paramédico no exitoso por ingreso de número de cédula no
válido.
 Se ingresaron todos los datos requeridos en el registro del paramédico.
RESULTADOS:
válido.
 No se registra al paramédico.
ES-5.3 DESCRIPCIÓN: Registro del paramédico no exitoso porque faltan datos por ingresar.
 No se ingresaron todos los datos requeridos en el registro del paramédico.
RESULTADOS:
 No se registra al paramédico.
RIESGOS: No aplica.
Ambulancias

CU-6 Consultar servicios
COMPLEJIDAD: Baja PRIORIDAD: Media
RF-5 Ingresar datos del servicio, RF-17 Consultar servicios.
ACTORES: Secretaria, Gerente
DESCRIPCIÓN: La secretaria o el gerente consultan los servicios mediante ciertos campos del servicio.
(Ver RF-17)
NOTAS:
 La consulta de los servicios puede filtrarse por: Fecha, Código del servicio, Código del cliente y
Cédula del cliente, Código del conductor, Código del paramédico y Código de la ambulancia.
 El dato(s) ingresado(s) para realizar el filtro de búsqueda debe existir en el sistema.
CRITERIOS DE ACEPTACIÓN: La secretaria o el gerente consultan los servicios o no.
ESCENARIOS:
ES-6.1 DESCRIPCIÓN: Consulta de servicios exitosa
 El dato(s) ingresado para filtrar la búsqueda existe.
RESULTADOS:
 El sistema muestra la lista de los servicios que coinciden con el campo de búsqueda.
ES-6.2 DESCRIPCIÓN: Consulta de servicios no exitosa por ingreso de datos inexistentes.
 El dato(s) ingresado para filtrar la búsqueda no existe.
RESULTADOS:
 Se muestra una notificación indicando la consulta de servicios no exitosa porque no
existen servicios que coincidan con el campo(s) de búsqueda.
 El sistema no muestra la lista de servicios.
Ambulancias

CU-6 Consultar servicios
ES-6.3 DESCRIPCIÓN: Consulta de servicios no exitosa por fallos en el sistema.
RESULTADOS:
 Se muestra una notificación indicando la consulta de servicios no exitosa porque
existe un fallo en el sistema.
 El sistema no muestra la lista de servicios.
RIESGOS: No aplica.

CU-8 Consultar conductores

RF-3 Ingresar datos del conductor, RF-25 Consultar conductores.

DESCRIPCIÓN: La secretaria o el gerente consultan los conductores mediante ciertos campos del
conductor. (Ver RF-25)
NOTAS:
 La búsqueda puede filtrarse por: Código del conductor, Cédula del conductor, Nombres y
Apellidos del conductor y Estado del conductor.
CRITERIOS DE ACEPTACIÓN: La secretaria o gerente consultan los conductores o no.
ESCENARIOS:
ES-8.1 DESCRIPCIÓN: Consulta de conductores exitosa
RESULTADOS:
 El sistema muestra la lista de los conductores que coinciden con el campo de
búsqueda.
Ambulancias

CU-8 Consultar conductores
ES-8.2 DESCRIPCIÓN: Consulta de conductores no exitosa por ingreso de datos inexistentes.
RESULTADOS:
 Se muestra una notificación indicando la consulta de conductores no exitosa porque
no existen servicios que coincidan con el campo(s) de búsqueda.
 El sistema no muestra la lista de conductores.
ES-8.3 DESCRIPCIÓN: Consulta de conductores no exitosa por fallos en el sistema.
RESULTADOS:
 Se muestra una notificación indicando la consulta de conductores no exitosa porque
 El sistema no muestra la lista de conductores.
RIESGOS: No aplica.

CU-7 Consultar clientes
RF-1 Ingresar datos del cliente, RF-35 Consultar clientes.
DESCRIPCIÓN: La secretaria o el gerente consultan los clientes mediante ciertos campos del cliente.
(Ver RF-35)
NOTAS:
 La consulta puede filtrarse por: Código del cliente, Cédula del cliente y Estado del cliente.
CRITERIOS DE ACEPTACIÓN: La secretaria o gerente consultan los clientes o no.
ESCENARIOS:
Ambulancias

CU-7 Consultar clientes
ES-7.1 DESCRIPCIÓN: Consulta de clientes exitosa
RESULTADOS:
 El sistema muestra la lista de los clientes que coinciden con el campo de búsqueda.
ES-7.2 DESCRIPCIÓN: Consulta de clientes no exitosa por ingreso de datos inexistentes.
RESULTADOS:
 Se muestra una notificación indicando la consulta de clientes no exitosa porque no
existen servicios que coincidan con el campo(s) de búsqueda.
 El sistema no muestra la lista de clientes.
ES-7.3 DESCRIPCIÓN: Consulta de clientes no exitosa por fallos en el sistema.
RESULTADOS:
 Se muestra una notificación indicando la consulta de clientes no exitosa porque
 El sistema no muestra la lista de clientes.
RIESGOS: No aplica.

CU-9 Consultar ambulancias

RF-2 Ingresar datos de la ambulancia, RF-21 Consultar ambulancias.

DESCRIPCIÓN: La secretaria o el gerente consultan las ambulancias mediante ciertos campos de la
ambulancia. (Ver RF-21)
Ambulancias

CU-9 Consultar ambulancias
NOTAS:
• La búsqueda puede filtrarse por: Código de la ambulancia, Numero de placa vehicular y Estado
de la ambulancia.
• El dato(s) ingresado(s) para realizar el filtro de búsqueda debe existir en el sistema.
CRITERIOS DE ACEPTACIÓN: La secretaria o gerente consultan las ambulancias o no.
ESCENARIOS:
ES-9.1 DESCRIPCIÓN: Consulta de ambulancias exitosa
RESULTADOS:
 El sistema muestra la lista de las ambulancias que coinciden con el campo de
búsqueda.
ES-9.2 DESCRIPCIÓN: Consulta ambulancias no exitosa por ingreso de datos inexistentes.
RESULTADOS:
 Se muestra una notificación indicando la consulta de ambulancias no exitosa porque
 El sistema no muestra la lista de ambulancias.
ES-9.3 DESCRIPCIÓN: Consulta ambulancias no exitosa por fallos en el sistema.
RESULTADOS:
 Se muestra una notificación indicando la consulta de ambulancias no exitosa porque
 El sistema no muestra la lista de ambulancias.
RIESGOS: No aplica.

CU-10 Consultar paramédicos

RF-4 Ingresar datos del paramédico, RF-29 Consultar paramédicos
Ambulancias

CU-10 Consultar paramédicos
DESCRIPCIÓN: La secretaria o el gerente consultan las ambulancias mediante ciertos campos de la
ambulancia. (Ver RF-29)
NOTAS:
• La búsqueda puede filtrarse por: Código del paramédico, Cédula del paramédico, Nombres y
apellidos del paramédico y Estado del paramédico.
• El dato(s) ingresado(s) para realizar el filtro de búsqueda debe existir en el sistema.
CRITERIOS DE ACEPTACIÓN: La secretaria o gerente consultan los paramédicos o no.
ESCENARIOS:
ES-10.1 DESCRIPCIÓN: Consulta de paramédicos exitosa
RESULTADOS:
 El sistema muestra la lista de los paramédicos que coinciden con el campo de
búsqueda.
ES-10.2 DESCRIPCIÓN: Consulta de paramédicos no exitosa por ingreso de datos inexistentes.
RESULTADOS:
 Se muestra una notificación indicando la consulta de paramédicos no exitosa porque
 El sistema no muestra la lista de paramédicos.
ES-10.3 DESCRIPCIÓN: Consulta de paramédicos no exitosa por fallos en el sistema.
RESULTADOS:
 Se muestra una notificación indicando la consulta de paramédicos no exitosa porque
 El sistema no muestra la lista de paramédicos.
RIESGOS: No aplica.

CU-11 Modificar cliente
Ambulancias


RF-1 Ingreso de datos del cliente, RF-7 Validar Número de cuenta bancaria, RF-32 Generar orden de
pago, RF-33 Modificar cliente, RF-35 Consultar clientes.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-7 Consultar clientes
DESCRIPCIÓN: El sistema permite a la secretaria modificar los datos guardados previamente de los
clientes registrados en el sistema.
NOTAS:
 Los campos modificables son: Teléfono, Dirección domiciliaria, E-mail, Número de cuenta
bancaria.
 La secretaria debe llenar los campos de acuerdo a las especificaciones detalladas en el RF-1.
 La secretaria debe ingresar un Número de cuenta bancaria válido.
 No se permitirá modificar el campo Número de cuenta bancaria si la orden de pago del cliente
ya ha sido generada.
CRITERIOS DE ACEPTACIÓN: La secretaria modifica los datos del cliente o no.
ESCENARIOS:
ES-11.1 DESCRIPCIÓN: Modificación del cliente exitosa.
 La secretaria ingresa caracteres numéricos en el campo teléfono y el número de
cuenta ingresado es válido.
 Se ingresaron todos los datos requeridos en la modificación del cliente.
RESULTADOS:
 El sistema muestra una notificación de modificación del cliente exitosa.
 El sistema actualiza al cliente con los datos modificados.
ES-11.2 DESCRIPCIÓN: Modificación de los datos del cliente fallida por ingreso de datos no válidos.
 La secretaria ingresa caracteres alfabéticos y/o especiales en el campo teléfono, o el
número de cuenta ingresado no es válido.
 Se ingresaron todos los datos requeridos en la modificación del cliente.
RESULTADOS:
 El sistema muestra una notificación de modificación del cliente no exitosa por
ingreso de datos no válidos.
 No se modifican los datos del cliente.
ES-11.3 DESCRIPCIÓN: Registro del cliente no exitoso porque faltan datos por ingresar.
 La secretaria ingresa caracteres numéricos en el campo teléfono y el número de
cuenta ingresado es válido.
 No se ingresaron todos los datos requeridos en la modificación del cliente.
RESULTADOS:
 Se muestra una notificación de modificación del cliente no exitosa porque aún faltan
Ambulancias

datos por ingresar.
 No se modifican los datos del cliente.
RIESGOS: No aplica.
Ambulancias

CU-12 Modificar conductor
RF-3 Ingresar datos del conductor, RF-23 Modificar conductor, RF-25 Consultar conductores
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-8 Consultar conductores.
conductor registrados en el sistema.
NOTAS:
 Los campos modificables son: Teléfono, Dirección domiciliaria, E-mail.
CRITERIOS DE ACEPTACIÓN: La secretaria modifica los datos del conductor o no.
ESCENARIOS:
ES-12.1 DESCRIPCIÓN: Modificación del conductor exitosa
 La secretaria ingresa caracteres numéricos en el campo teléfono.
 Se ingresaron todos los datos requeridos en la modificación del conductor.
RESULTADOS:
 El sistema muestra una notificación de modificación del conductor exitosa.
 El sistema actualiza al conductor con los datos modificados.
ES-12.2 DESCRIPCIÓN: Modificación de los datos del paramédico fallida por ingreso de datos no
válidos.
 La secretaria ingresa caracteres alfabéticos y/o especiales en el campo teléfono.
 Se ingresaron todos los datos requeridos en la modificación del conductor.
RESULTADOS:
 El sistema muestra una notificación de modificación del paramédico no exitosa
porque se llenó el campo teléfono incorrectamente.
 No se modifican los datos del conductor.
ES-12.3 DESCRIPCIÓN: Registro del paramédico fallido porque faltan datos por ingresar.
 No se ingresaron todos los datos requeridos en la modificación del conductor.
RESULTADOS:
 No se modifican los datos del conductor.
RIESGOS: No aplica.
Ambulancias

CU-13 Modificar ambulancia
RF-2 Ingresar datos de la ambulancia, RF-19 Modificar ambulancia, RF-21 Consultar ambulancias.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-9 Consultar ambulancias.
DESCRIPCIÓN: El sistema permite a la secretaria modificar los datos guardados previamente de las
ambulancias registrados en el sistema.
NOTAS:
 El sistema solo permite la modificación del campo “Próxima fecha de revisión”. (Ver RF-19)
 La secretaria debe ingresar una fecha futura y válida.
CRITERIOS DE ACEPTACIÓN: La secretaria modifica los datos de la ambulancia o no.
ESCENARIOS:
ES-13.1 DESCRIPCIÓN: Modificación de la ambulancia exitosa.
 La Próxima fecha de revisión corresponde a una fecha futura.
RESULTADOS:
 El sistema muestra una notificación de modificación de los datos de la ambulancia
exitosa.
 El sistema actualiza a la ambulancia con los datos modificados.
ES-13.2 DESCRIPCIÓN: Modificación de la ambulancia no exitosa por ingreso de una fecha pasada.
 La Próxima fecha de revisión corresponde a una fecha pasada.
RESULTADOS:
 El sistema muestra una notificación de modificación de la ambulancia no exitosa
porque se debe ingresar una fecha futura.
 No se modifican los datos de la ambulancia.
ES-13.3 DESCRIPCIÓN: Modificación de la ambulancia no exitosa por ingreso de una fecha no válida.
 La Próxima fecha de revisión corresponde a una fecha no válida (ejemplo,
31/02/2020).
RESULTADOS:
 El sistema muestra una notificación de modificación de la ambulancia no exitosa
porque se debe ingresar una fecha válida.
 No se modifican los datos de la ambulancia.
RIESGOS: No aplica.
Ambulancias

CU-14 Modificar paramédico

RF-4 Ingresar datos del paramédico, RF-27 Modificar paramédico, RF-29 Consultar paramédicos.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-10 Consultar paramédicos.
paramédicos registrados en el sistema.
NOTAS:
 Los campos modificables son: Teléfono, Dirección domiciliaria, E-mail.
CRITERIOS DE ACEPTACIÓN: La secretaria modifica los datos del paramédico o no.
ESCENARIOS:
ES-14.1 DESCRIPCIÓN: Modificación del paramédico exitosa
 Se ingresaron todos los datos requeridos en la modificación del paramédico.
RESULTADOS:
 El sistema muestra una notificación de modificación del paramédico exitosa.
 El sistema actualiza al paramédico con los datos modificados.
ES-14.2 DESCRIPCIÓN: Modificación de los datos del paramédico fallida por ingreso de datos no
válidos.
 La secretaria ingresa caracteres alfabéticos y/o especiales en el campo teléfono.
 Se ingresaron todos los datos requeridos en la modificación del paramédico.
RESULTADOS:
 El sistema muestra una notificación de modificación del paramédico no exitosa
porque se llenó el campo teléfono incorrectamente.
 No se modifican los datos del paramédico.
ES-14.3 DESCRIPCIÓN: Registro del paramédico fallido porque faltan datos por ingresar.
 No se ingresaron todos los datos requeridos en la modificación del paramédico.
RESULTADOS:
 No se modifican los datos del paramédico.
Ambulancias

CU-14 Modificar paramédico
RIESGOS: No aplica.
Ambulancias

CU-15 Eliminar servicio

RF-5 Ingresar datos del servicio, RF-16 Eliminar servicio, RF-17 Consultar servicios.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-6 Consultar servicios.
DESCRIPCIÓN: El sistema permite a la secretaria eliminar los servicios registrados en el sistema.
NOTAS:
 El servicio debe estar en estado “F” y el cliente está en estado “P”, caso contrario no se podrá
eliminar el servicio.
CRITERIOS DE ACEPTACIÓN: La secretaria elimina el servicio o no.
ESCENARIOS:
ES-15.1 DESCRIPCIÓN: Eliminación exitosa de un servicio en estado “F”.
 El servicio está en estado “F”
 El cliente está en estado “P”
RESULTADOS:
 El sistema muestra una notificación de que el servicio fue eliminado de manera
exitosa.
 El sistema elimina el servicio.
ES-15.2 DESCRIPCIÓN: Eliminación no exitosa de un servicio en estado “F” porque el cliente está en
deuda con la empresa.
 El servicio está en estado “F”
 El cliente está en estado “D”
RESULTADOS:
 Se envía una notificación de que no se puede eliminar el servicio porque el cliente
aún no paga dicho servicio.
 El sistema no elimina el servicio.
ES-15.3 DESCRIPCIÓN: Eliminación no exitosa de un servicio en estado “A” porque el cliente está
atendiendo en ese momento.
 El servicio está en estado “A”
RESULTADOS:
 Se envía una notificación de que no se puede eliminar un servicio que se encuentra
siendo atendido en ese momento.
Ambulancias

CU-15 Eliminar servicio
 No se elimina el servicio.
RIESGOS: No aplica.
Ambulancias

CU-16 Eliminar cliente

RF-1 Ingresar datos del cliente, RF-34 Eliminar cliente, RF-35 Consultar clientes.
ACTORES: Secretaria
DESCRIPCIÓN: El sistema permite a la secretaria eliminar los clientes registrados en el sistema.
NOTAS:
 El sistema solo permitirá eliminar un cliente si, y solo si, su estado es “P”.
CRITERIOS DE ACEPTACIÓN: La secretaria elimina al cliente o no.

ESCENARIOS:
ES-16.1 DESCRIPCIÓN: Eliminación del cliente exitosa.
 El cliente está en estado “P”
RESULTADOS:
 El sistema muestra una notificación de que el cliente fue eliminado de manera
exitosa.
 El sistema elimina el cliente.
ES-16.2 DESCRIPCIÓN: Eliminación del cliente no exitosa porque el cliente está en estado “D”.
RESULTADOS:
 El sistema muestra una notificación de que el cliente no puede ser eliminado debido
a que aún se encuentra en proceso de pago.
 El sistema no elimina el cliente.
ES-16.3 DESCRIPCIÓN: Eliminación del cliente no exitosa por fallos en el sistema.
 El cliente está en estado “P”.
 Existe un fallo en el sistema.
RESULTADOS:
 Se muestra una notificación indicando que no se pudo eliminar al cliente porque
 No se elimina el cliente.
Ambulancias

CU-16 Eliminar cliente
RIESGOS: No aplica.
Ambulancias

CU-17 Eliminar conductor

RF-3 Ingresar datos del conductor, RF-24 Eliminar conductor, RF-25 Consultar conductores.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-8 Consultar conductores
DESCRIPCIÓN: El sistema permite a la secretaria eliminar los conductores registrados en el sistema.
NOTAS:
 El sistema solo permitirá eliminar un conductor si, y solo si, su estado es “D” o “F”.
CRITERIOS DE ACEPTACIÓN: La secretaria elimina al conductor o no.

ESCENARIOS:
ES-17.1 DESCRIPCIÓN: Eliminación del conductor exitosa.
 El conductor está en estado “D” o “F”.
RESULTADOS:
 El sistema muestra una notificación de que el conductor fue eliminado de manera
exitosa.
 El sistema elimina el conductor.
ES-17.2 DESCRIPCIÓN: Eliminación del conductor no exitosa porque está en estado “O”.
 El conductor está en estado “O”
RESULTADOS:
 El sistema muestra una notificación de que el conductor no puede ser eliminado
debido a que se encuentra ocupado en servicio.
 El sistema no elimina el conductor.
ES-17.3 DESCRIPCIÓN: Eliminación del conductor no exitosa por fallos en el sistema.
 El conductor está en estado “D” o “F”
RESULTADOS:
 Se muestra una notificación indicando que no se pudo eliminar al conductor porque
 No se elimina el conductor.
RIESGOS: No aplica.
Ambulancias

CU-17 Eliminar conductor
Ambulancias

CU-18 Eliminar ambulancia

RF-2 Ingresar datos de la ambulancia, RF-20 Eliminar ambulancia, RF-21 Consultar ambulancias.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-9 Consultar ambulancias
DESCRIPCIÓN: El sistema permite a la secretaria eliminar las ambulancias registrados en el sistema.
NOTAS:
 El sistema solo permitirá eliminar una ambulancia si, y solo si, su estado es “D” o “M”.
CRITERIOS DE ACEPTACIÓN: La secretaria elimina a la ambulancia o no.

ESCENARIOS:
ES-18.1 DESCRIPCIÓN: Eliminación de la ambulancia exitosa.
 La ambulancia está en estado “D” o “M”.
RESULTADOS:
 El sistema muestra una notificación de que la ambulancia fue eliminado de manera
exitosa.
 El sistema elimina la ambulancia.
ES-18.2 DESCRIPCIÓN: Eliminación de la ambulancia no exitosa porque la ambulancia está en
estado “O”.
 La ambulancia está en estado “O”.
RESULTADOS:
 El sistema muestra una notificación de que la ambulancia no puede ser eliminada
debido a que se encuentra ocupada en servicio.
 El sistema no elimina la ambulancia.
ES-18.3 DESCRIPCIÓN: Eliminación de la ambulancia no exitosa por fallo en el sistema.
 La ambulancia está en estado “D” o “M”.
RESULTADOS:
 Se muestra una notificación indicando que no se pudo eliminar a la ambulancia
porque existe un fallo en el sistema.
 No se elimina la ambulancia.
Ambulancias

CU-18 Eliminar ambulancia
RIESGOS: No aplica.
Ambulancias

CU-19 Eliminar paramédico

RF-4 Ingresar datos del paramédico, RF-28 Eliminar paramédico, RF-29 Consultar paramédicos.
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-10 Consultar paramédicos
DESCRIPCIÓN: El sistema permite a la secretaria eliminar los paramédicos registrados en el sistema.
NOTAS:
 El sistema solo permitirá eliminar un paramédico si, y solo si, su estado es “D” o “F”.
CRITERIOS DE ACEPTACIÓN: La secretaria elimina al paramédico o no.

ESCENARIOS:
ES-19.1 DESCRIPCIÓN: Eliminación del paramédico exitosa.
 El paramédico está en estado “D” o “F”.
RESULTADOS:
 El sistema muestra una notificación de que el paramédico fue eliminado de manera
exitosa.
 El sistema elimina el conductor.
ES-19.2 DESCRIPCIÓN: Eliminación del paramédico no exitosa porque el paramédico está en estado
“O”.
 El paramédico está en estado “O”.
RESULTADOS:
 El sistema muestra una notificación de que el paramédico no puede ser eliminado
debido a que encuentra ocupado en servicio.
 El sistema no elimina el paramédico.
ES-19.3 DESCRIPCIÓN: Eliminación del paramédico no exitosa por fallo en el sistema.
 El paramédico está en estado “D” o “F”.
RESULTADOS:
 Se muestra una notificación indicando que no se pudo eliminar al paramédico
porque existe un fallo en el sistema.
 No se elimina el paramédico.
Ambulancias

CU-19 Eliminar paramédico
RIESGOS: No aplica.
Ambulancias

CU-20 Actualizar estado de ambulancia
RF-40 Actualizar estado de la ambulancia, RF-21 Consultar ambulancia
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-9 Consultar ambulancias
DESCRIPCIÓN: La secretaria cambia manualmente el estado de la ambulancia cuando esté disponible o
en mantenimiento.
NOTAS:
 La secretaria debe cambiar el estado de la ambulancia a “D” cuando termine de proveer el servi-
cio asignado.
 La secretaria debe cambiar el estado de la ambulancia a “M” cuando esté en el taller en mante-
nimiento.
(Ver abreviaturas en glosario)
CRITERIOS DE ACEPTACIÓN: El estado de la ambulancia cambió o no.
ESCENARIOS:
ES-20.1 DESCRIPCIÓN: Cambio de estado de ambulancia a “D”.
 El estado actual de la ambulancia es “O” o “M”.
RESULTADOS:
 El sistema notifica que se cambió el estado de la ambulancia a “D”.
 El sistema actualiza el estado de la ambulancia a “D”
 El sistema puede asignar esa ambulancia a un nuevo servicio.
ES-20.2 DESCRIPCIÓN: Cambio de estado de ambulancia a “M”.
 El estado actual de la ambulancia es “O” o “D”.
RESULTADOS:
 El sistema notifica que se cambió el estado de la ambulancia a “M”.
 El sistema actualiza el estado de la ambulancia a “M”
 El sistema no puede asignar esa ambulancia a un nuevo servicio.
ES-20.3 DESCRIPCIÓN: Cambio de estado de ambulancia a “D” / “M” no exitoso por fallos en el sis-
tema.
 La secretaria necesita cambiar el estado de la ambulancia a “D” / “M”.
RESULTADOS:
 El sistema no actualiza el estado de la ambulancia a “D” / “M”.
 El sistema notifica no se pudo cambiar el estado de la ambulancia a “D” / “M” por
Ambulancias

CU-20 Actualizar estado de ambulancia
fallos en el sistema.
RIESGOS: No aplica.
Ambulancias

CU-21 Actualizar estado del conductor
RF-41 Actualizar estado del conductor, RF-25 Consultar conductor
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-8 Consultar conductores
DESCRIPCIÓN: La secretaria cambia manualmente el estado del conductor cuando esté disponible, o
cuando ya esté fuera de su horario laboral.
NOTAS:
 La secretaria debe cambiar el estado del conductor a “D” cuando inicie su jornada laboral o
cuando termine de proveer el servicio asignado.
 La secretaria debe cambiar el estado del conductor a “F” cuando finalice su jornada laboral.
CRITERIOS DE ACEPTACIÓN: El estado del conductor cambio o no.
ESCENARIOS:
ES-21.1 DESCRIPCIÓN: Cambio de estado del conductor a “D”.
 El estado actual del conductor es “O” o “F”.
RESULTADOS:
 El sistema actualiza el estado del conductor a “D”.
 El sistema notifica que se cambió el estado del conductor a “D”.
 El sistema puede asignar ese conductor a un nuevo servicio.
ES-21.2 DESCRIPCIÓN: Cambio de estado del conductor a “F”.
 El estado actual del conductor es “O” o “D”.
RESULTADOS:
 El sistema actualiza el estado del conductor a “F”.
 El sistema notifica que se cambió el estado del conductor a “F”.
 El sistema no puede asignar ese conductor a un nuevo servicio.
ES-21.3 DESCRIPCIÓN: Cambio de estado del conductor a “F” / “D” no exitoso por fallos en el siste-
ma.
 La secretaria necesita cambiar el estado del conductor a “F” o “D”.
RESULTADOS:
 El sistema no actualiza el estado del conductor a “F” / “D”.
 El sistema notifica no se pudo cambiar el estado del conductor a “F” / “D” por fa-
llos en el sistema.
Ambulancias

CU-21 Actualizar estado del conductor
RIESGOS: No aplica.
Ambulancias

CU-22 Actualizar estado del cliente.
RF-42 Actualizar estado del cliente, RF-35 Consultar cliente
ACTORES: Secretaria
DESCRIPCIÓN: La secretaria cambia el estado de los clientes a “P”.
NOTAS:
 Luego de la gestión de cobros que realiza el banco, el mismo envía una lista de clientes en mora.
(Ver RF-39). La secretaria gestiona (de manera externa al sistema) los pagos atrasados de los
clientes que se encuentran dicha lista.
 Cuando los clientes hayan realizado sus pagos atrasados, la secretaria debe cambiar
manualmente el estado de los clientes a “P”.
 Si el cliente no se encuentra en la lista de clientes en mora, quiere decir que el banco aún no
gestiona los cobros, por lo tanto, no se podrá cambiar el estado del cliente a “P”. (Ver RF-44)
(Ver abreviaturas y otros términos en el glosario)
CRITERIOS DE ACEPTACIÓN: La secretaria cambia el estado del cliente o no.
ESCENARIOS:
ES-22.1 DESCRIPCIÓN: Cambio de estado de cliente a “P”, exitoso.
 El cliente se encuentra en lista de clientes en mora.
 El cliente realizó su pago atrasado.
RESULTADOS:
 El sistema notifica que se cambió el estado del cliente a “P”.
 El sistema actualiza el estado del cliente a “P”.
ES-22.2 DESCRIPCIÓN: Cambio de estado de cliente a “P” fallido porque el cliente no se encuentra
en lista de clientes en mora.
 El cliente no se encuentra en lista de clientes en mora.
RESULTADOS:
 El sistema notifica que no se pudo cambiar estado del cliente a “P” porque el cliente
no se encuentra en la lista de clientes en mora.
 El sistema no actualiza de estado al cliente a “P”.
ES-22.3 DESCRIPCIÓN: Cambio de estado de cliente a “P”, fallido por error en el sistema.
 El cliente se encuentra en lista de clientes en mora.
 Se produjo un fallo en el sistema.
Ambulancias

CU-22 Actualizar estado del cliente.
RESULTADOS:
 El sistema notifica que no se pudo cambiar estado del cliente a “P” por fallos en el
sistema.
 El sistema no actualiza de estado al cliente a “P”.
RIESGOS: No aplica.
Ambulancias

CU-23 Actualizar estado del servicio.
RF-44 Actualizar estado del servicio, RF-17 Consultar servicio
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-6 Consultar servicios
DESCRIPCIÓN: La secretaria cambia el estado de los servicios a “F”.
NOTAS:
 Cuando el conductor llegue de proveer el servicio, la secretaria debe cambiar manualmente el
estado del servicio a “F”.
 Solo se permite el cambio de estado a “F” si el estado actual es “A”.
 El sistema no permite el cambio de estado manualmente a “E” ni “A”.

CRITERIOS DE ACEPTACIÓN: La secretaria cambia el estado del servicio o no.
ESCENARIOS:
ES-23.1 DESCRIPCIÓN: Cambio de estado del servicio a “F”, exitoso.
 El estado actual del servicio es “A”.
RESULTADOS:
 El sistema notifica que se cambió el estado del servicio a “F”.
 El sistema actualiza el estado del servicio a “F”.

ES-23.2 DESCRIPCIÓN: Cambio de estado del servicio a “F”, fallido porque el estado actual del
servicio es “E”.
 El estado actual del servicio es “E”.
RESULTADOS:
 El sistema notifica que no se cambió el estado del servicio a “F” porque el servicio
está en espera.
 El sistema no actualiza el estado del servicio a “F”.
Ambulancias

CU-23 Actualizar estado del servicio.
ES-23.3 DESCRIPCIÓN: Cambio de estado de servicio a “F”, fallido por error en el sistema.
 El estado actual del servicio es “A”.
 Se produjo un fallo en el sistema.

RESULTADOS:
 El sistema notifica que no se pudo cambiar estado del servicio a “F” por fallos en el
sistema.
 El sistema no actualiza de estado al servicio a “F”.

RIESGOS: No aplica.
Ambulancias

CU-24 Actualizar estado del paramédico
RF-43 Actualizar estado del paramédico, RF-29 Consultar paramédico
ACTORES: Secretaria
CASOS DE USO ASOCIADOS: CU-10 Consultar paramédicos
DESCRIPCIÓN: La secretaria cambia manualmente el estado del paramédico cuando esté disponible, o
cuando ya esté fuera de su horario laboral.
NOTAS:
 La secretaria debe cambiar el estado del paramédico a “D” cuando inicie su jornada laboral o
cuando termine de proveer el servicio asignado.
 La secretaria debe cambiar el estado del paramédico a “F” cuando finalice su jornada laboral.
CRITERIOS DE ACEPTACIÓN: El estado del paramédico cambio o no.
ESCENARIOS:
ES-24.1 DESCRIPCIÓN: Cambio de estado del paramédico a “D”.
 El estado actual del paramédico es “O” o “F”.
RESULTADOS:
 El sistema actualiza el estado del paramédico a “D”.
 El sistema notifica que se cambió el estado del paramédico a “D”.
 El sistema puede asignar ese paramédico a un nuevo servicio.

ES-24.2 DESCRIPCIÓN: Cambio de estado del paramédico a “F”.
 El estado actual del paramédico es “O” o “D”.
RESULTADOS:
 El sistema actualiza el estado del paramédico a “F”.
 El sistema notifica que se cambió el estado del paramédico a “F”.

 El sistema no puede asignar ese paramédico a un nuevo servicio.
ES-24.3 DESCRIPCIÓN: Cambio de estado del paramédico a “F” / “D” no exitoso por fallos en el sis-
tema.
 La secretaria necesita cambiar el estado del paramédico a “F” o “D”.
RESULTADOS:
Ambulancias

CU-24 Actualizar estado del paramédico
 El sistema no actualiza el estado del paramédico a “F” / “D”.
 El sistema notifica no se pudo cambiar el estado del paramédico a “F” / “D” por
RIESGOS: No aplica.
Ambulancias

CU-25 Consultar órdenes de pago al banco
RF-36 Consultar órdenes de pago
ACTORES: Gerente
DESCRIPCIÓN: El gerente podrá consultar las órdenes de pago mediante los siguientes filtros de
búsqueda: Fecha de la emergencia, ID de orden de pago, Código del servicio y Cédula del cliente.
NOTAS:
 Las órdenes de pago son generadas automáticamente por el sistema (Ver RF-32).
 El gerente debe ingresar datos que existan en el sistema.

CRITERIOS DE ACEPTACIÓN: Sistema muestra el resultado de la consulta o no.
ESCENARIOS:
ES-25.1 DESCRIPCIÓN: Consulta de órdenes de pago exitosa.
 El gerente ingresó correctamente los datos de la orden de pago.
RESULTADOS:
 El sistema muestra el resultado de la consulta.
ES-25.2 DESCRIPCIÓN: Consulta de órdenes de pago no exitosa porque no se encontraron
coincidencias.
 El gerente no ingresó correctamente los datos de la orden de pago.
RESULTADOS:
 El sistema notifica que no se encontraron coincidencias entre los datos ingresados y
las órdenes de pago registras en el sistema.
 El sistema no muestra el resultado de la consulta.

ES-25.3 DESCRIPCIÓN: Consulta de órdenes de pago no exitosa por fallos en el sistema.
 El gerente ingresó correctamente los datos de la orden de pago.

RESULTADOS:
 El sistema notifica que no se pudo conectar con la base de datos para realizar la
consulta.
Ambulancias

CU-25 Consultar órdenes de pago al banco
 El sistema no muestra el resultado de la consulta.
RIESGOS: No aplica.
Ambulancias

CU-26 Enviar órdenes de pago al banco
RF-32 Generar orden de pago, RF-37 Enviar órdenes de pago al banco.
ACTORES: Gerente
CASOS DE USO ASOCIADOS: CU-25 Consultar órdenes de pago, CU-31 Generar órdenes de pago.
DESCRIPCIÓN: El gerente envía las órdenes de pago al banco.
NOTAS:
 Las órdenes de pago son generadas por el gerente. (Ver RF-32, CU).
 El gerente solo puede enviar las órdenes de pago durante el día establecido (Ver RF-37).
CRITERIOS DE ACEPTACIÓN: El gerente envió las órdenes de pago o no.
ESCENARIOS:
ES-26.1 DESCRIPCIÓN: Envío de órdenes de pago exitoso.
 Sistema bancario en servicio.
 Es el día establecido para realizar el envío.

RESULTADOS:
 Se envían las órdenes de pago.
 El sistema notifica que se enviaron las órdenes de pago exitosamente.

ES-26.2 DESCRIPCIÓN: Envío de órdenes de pago no exitoso porque no es el día establecido para
realizar el envío.
 Sistema bancario en servicio.
 No es el día establecido para realizar el envío.

RESULTADOS:
 No se envían las órdenes de pago.
 El sistema notifica que no se enviaron las órdenes de pago exitosamente porque no

es el día establecido para el envío de las mismas.
ES-26.3 DESCRIPCIÓN: Envío de órdenes de pago no exitoso porque el sistema bancario no está en
servicio.
 Sistema bancario no está en servicio.
Ambulancias

CU-26 Enviar órdenes de pago al banco
 Es el día establecido para realizar el envío.
RESULTADOS:
 El sistema notifica que no se enviaron las órdenes de pago debido a la caída del
sistema bancario.
 No se envían las órdenes de pago.

RIESGOS: Caída del sistema bancario.
Ambulancias

CU-27 Autorizar cobro
REQUERIMIENTO FUNCIONAL ASOCIADO: RF-37 Enviar órdenes de pago al banco.
ACTORES: Sistema bancario

CASOS DE USO ASOCIADOS: CU-26 Enviar órdenes de pago.
DESCRIPCIÓN: El sistema bancario autoriza el cobro a los clientes.

NOTAS:
 Para que el sistema bancario autorice el cobro, el gerente debe enviar las órdenes de pago de
los clientes.
 Para que el sistema bancario pueda autorizar el cobro, la cantidad de dinero que el cliente debe
tener en su cuenta bancaria debe ser mayor o igual al monto a pagar.
CRITERIOS DE ACEPTACIÓN: El sistema bancario autorizó el cobro o no.
ESCENARIOS:
ES-27.1 DESCRIPCIÓN: Autorización de cobro exitosa.
 El gerente envió las órdenes de pago.
 El cliente tiene dinero suficiente en su cuenta bancaria.

RESULTADOS:
 El sistema bancario autoriza el cobro al cliente.
ES-27.2 DESCRIPCIÓN: Autorización de cobro no exitosa porque el cliente no tiene dinero suficiente.
 El gerente envió las órdenes de pago.
 El cliente no tiene dinero suficiente en su cuenta bancaria.

RESULTADOS:
 El sistema bancario no autoriza el cobro al cliente.
 El sistema bancario agrega al cliente a la lista de clientes en mora.

ES-27.3 DESCRIPCIÓN: Autorización de cobro no exitosa porque no se enviaron las órdenes de pago
de los clientes.
 El gerente no envió las órdenes de pago.
RESULTADOS:
 El sistema bancario no puede autorizar el cobro a los clientes.
Ambulancias

CU-27 Autorizar cobro
 El sistema muestra una notificación indicando que el sistema bancario no pudo
cobrar a ningún cliente porque no se enviaron las órdenes de pago al banco.

RIESGOS: El gerente no envíe las órdenes de pago al banco.
Ambulancias

CU-28 Enviar lista de clientes en mora
RF-37 Enviar órdenes de pago al banco.
ACTORES: Sistema bancario

CASOS DE USO ASOCIADOS: CU-27 Autorizar cobro
DESCRIPCIÓN: El sistema del banco envía una lista de los clientes a los que no pudo autorizar el cobro.
NOTAS:
 Para generar y enviar la lista, el sistema del banco debe autorizar el cobro a los clientes.
 El sistema del banco envía la lista SOLO de los clientes a los que no se le pudo autorizar el cobro.
CRITERIOS DE ACEPTACIÓN: El banco envía la lista de los clientes en mora o no.
ESCENARIOS:
ES-28.1 DESCRIPCIÓN: Envío de lista de clientes en mora exitoso
 El banco no autorizó el cobro a todos los clientes exitosamente.
RESULTADOS:
 El sistema del banco genera y envía la lista de clientes en mora.
 El sistema muestra una notificación indicando que el banco envió la lista de clientes
en mora.
ES-28.2 DESCRIPCIÓN: Envío de lista de clientes en mora no exitoso porque el sistema bancario
autorizó el cobro exitosamente a todos los clientes.
 El banco autorizó el cobro a todos los clientes exitosamente.
RESULTADOS:
 El sistema del banco no genera ni envía la lista de clientes en mora.
 El sistema muestra una notificación indicando que el sistema del banco autorizó el
cobro a todos los clientes exitosamente y no hay clientes en mora.
ES-28.3 DESCRIPCIÓN: Envío de lista de clientes en mora no exitoso por fallos en el sistema
bancario.
 El banco no autorizó el cobro a los clientes exitosamente.
 Caída del sistema bancario.

RESULTADOS:
Ambulancias

CU-28 Enviar lista de clientes en mora
 El sistema del banco no genera ni envía la lista de clientes en mora.
 El sistema muestra una notificación indicando que el sistema bancario no pudo

enviar la lista de clientes en mora por fallos en el mismo.
RIESGOS: El sistema bancario haya podido realizar el cobro a los clientes.
Ambulancias

CU-29 Generar informe de clientes en mora
RF-38 Generar informe de clientes con deuda
ACTORES: Gerente
CASOS DE USO ASOCIADOS: CU-28 Enviar lista de clientes en mora, CU-27 Autorizar cobro
DESCRIPCIÓN: El gerente genera un informe de los clientes que no han pagado el servicio. Este informe
se basa en una lista de clientes a los que el banco no autorizó el cobro.
NOTAS:
 El informe de clientes en mora se genera si, y solo si, el banco envía la lista de clientes en mora.
 El informe de clientes en mora se genera, solo si es el día establecido para generarlo (Ver RF-
38).
CRITERIOS DE ACEPTACIÓN: El gerente genera el informe de clientes en mora o no.
ESCENARIOS:
ES-29.1 DESCRIPCIÓN: El informe de clientes en mora se genera exitosamente.
 Es el día establecido para generar el informe de clientes en mora.
 El sistema del banco envió la lista de clientes en mora.

RESULTADOS:
 El sistema notifica que se generó exitosamente el informe de clientes en mora.
 Se genera el informe de clientes en mora.

ES-29.2 DESCRIPCIÓN: El informe de clientes en mora no se genera exitosamente porque el sistema
del banco no envió la lista de clientes en mora.
 Es el día establecido para generar el informe de clientes en mora.
 El sistema del banco no envió la lista de clientes en mora.

RESULTADOS:
 El sistema notifica que no se pudo generar el informe de clientes en mora porque el
sistema bancario no envió la lista de clientes en mora por la razón correspondiente
(Ver ES-28.2 y ES-28.3).
 No se genera el informe de clientes en mora.
Ambulancias

CU-29 Generar informe de clientes en mora
ES-29.3 DESCRIPCIÓN: El informe de clientes en mora no se genera exitosamente porque no es el
día establecido para generarlo.
 No es el día establecido para generar el informe de clientes en mora.
 El sistema del banco envió la lista de clientes en mora.

RESULTADOS:
 El sistema notifica que no se pudo generar el informe de clientes en mora porque no
es el día establecido.
 No se genera el informe de clientes en mora.

RIESGOS: El banco no envíe la lista de clientes en mora.
Ambulancias

CU-30 Generar informe de conductores
RF-45 Contar servicios de conductores, RF-46 Generar informe de conductores.
ACTORES: Gerente
CASOS DE USO ASOCIADOS: CU-3 Registrar Conductor
DESCRIPCIÓN: El gerente genera un informe de los conductores, el cual detalla información del trabajo
realizado por los conductores durante todo el mes.
NOTAS:
 El informe de conductores se genera automáticamente con los datos de todos los conductores
registrados en el sistema.
 El informe de conductores se genera si, y solo si, es el día establecido para generarlo. (Ver RF-
46)
CRITERIOS DE ACEPTACIÓN: El gerente genera el informe de conductores o no.
ESCENARIOS:
ES-30.1 DESCRIPCIÓN: El informe de conductores se genera exitosamente.
 Es el día establecido para generar el informe de conductores.
RESULTADOS:
 El sistema notifica que se generó el informe de conductores.
 Se genera el informe de conductores.

ES-30.2 DESCRIPCIÓN: El informe de conductores no se genera exitosamente porque no es el día
establecido para generarlo.
 No es el día establecido para generar el informe de conductores.
RESULTADOS:
 El sistema notifica que no se pudo generar el informe de conductores porque no es
el día establecido.
 No se genera el informe de conductores.

ES-30.3 DESCRIPCIÓN: El informe de conductores no se genera exitosamente por fallos en el
sistema.
 Es el día establecido para generar el informe de conductores.
RESULTADOS:
 El sistema notifica que no se pudo generar el informe porque hubo un fallo en el
Ambulancias

CU-30 Generar informe de conductores
sistema.
 No se genera el informe de conductores.

RIESGOS: No aplica.

CU-31 Generar órdenes de pago
Ambulancias

REQUERIMIENTO FUNCIONAL ASOCIADO: RF-32 Generar orden de pago.
ACTORES: Gerente
CASOS DE USO ASOCIADOS: CU-1 Registrar Servicio
DESCRIPCIÓN: El gerente genera, por medio del sistema, las órdenes de pago de los clientes que han
solicitado servicios en ese mes.
NOTAS:
 El sistema genera las órdenes de pago con los datos de los clientes registrados en el sistema.
(Ver RF-1)
 El sistema genera las órdenes de pago si, y solo si, es el día establecido para generarlo. (Ver RF-
32)
CRITERIOS DE ACEPTACIÓN: El gerente genera el informe de conductores o no.
ESCENARIOS:
ES-31.1 DESCRIPCIÓN: Órdenes de pago generadas exitosamente.
 Es el día establecido para generar las órdenes de pago.
RESULTADOS:
 El sistema notifica que se generaron las órdenes de pago.
 El sistema genera las órdenes de pago de los clientes que solicitaron servicios ese
mes.
 El sistema permite consultar dichas órdenes de pago.

ES-31.2 DESCRIPCIÓN: Órdenes de pago generadas no exitosamente por fallo en la base de datos.
 Es el día establecido para generar las órdenes de pago.
RESULTADOS:
 El sistema notifica que no se generaron las órdenes de pago porque hubo un fallo en
la base de datos.
El sistema no genera las órdenes de pago.
ES-31.3 DESCRIPCIÓN: Órdenes de pago no generadas exitosamente porque no es el día
establecido.
 No es el día establecido para generar las órdenes de pago.
RESULTADOS:
 El sistema notifica que no se generaron las órdenes de pago porque no es el día
establecido.
Ambulancias

 El sistema no genera las órdenes de pago.
RIESGOS: No aplica.
Ambulancias
5.2. Vista Funcional
5.2.1. Modelo de Análisis
ID Ref: DG-02
Descripción: Registro del servicio no exitoso por
ingreso de número de cédula no
válido.
Reqs. asociados: RF-5, RF-6, RF-14, RF-15, RF-30, RF-
39
CU asociados: CU-1
Esc. Asociados: ES-1.2
ID Ref: DG-03
Descripción: Registro del servicio no exitoso
porque faltan datos por ingresar.
Reqs. asociados: RF-5, RF-6, RF-14, RF-15, RF-30, RF-
39
CU asociados: CU-1
Ambulancias
ID Ref: DG-04
Descripción: Registro del cliente exitoso
Reqs. asociados: RF-1, RF-7, RF-30, RF-31, RF-32
CU asociados: CU-2
ID Ref: DG-05
Descripción: Registro del cliente no exitoso por
ingreso de número de cuenta no
válido.
CU asociados: CU-2
ID Ref: DG-06
Descripción: Registro del cliente no exitoso
CU asociados: CU-2
ID Ref: DG-07
Descripción: Registro del conductor exitoso
Reqs. asociados: RF-3, RF-6, RF-22
CU asociados: CU-3
Ambulancias
ID Ref: DG-08
Descripción: Registro del conductor no exitoso
por ingreso de número de cédula
no válido.
CU asociados: CU-3
ID Ref: DG-09
Descripción: Registro del conductor no exitoso
CU asociados: CU-3
ID Ref: DG-10
Descripción: Registro de la ambulancia exitoso
Reqs. asociados: RF-2, RF-18
Nombre del Documento: DOCUMENTO
CU asociados:DE DISEÑO
CU-4
DETALLADO DE SOFTWARE SDD Versión: 1.1
Creación: Sábado 15 de diciembre,2021
Esc. Asociados: ES-4.1 Página: 119
Ambulancias
ID Ref: DG-11
Descripción: Registro de la ambulancia no
exitoso por ingreso de número de
placa vehicular no válido.
CU asociados: CU-4
ID Ref: DG-12
Descripción: Registro de la ambulancia no
exitoso porque faltan datos por
ingresar.
CU asociados: CU-4
ID Ref: DG-13
Descripción: Registro del paramédico exitoso
Ambulancias

CU asociados: CU-5
ID Ref: DG-14
Descripción: Registro del paramédico no exitoso
por ingreso de número de cédula
no válido.
CU asociados: CU-5
ID Ref: DG-15
Descripción: Registro del paramédico no exitoso
CU asociados: CU-5
ID Ref: DG-16
Descripción: Consulta de servicios exitosa
Ambulancias
CU asociados: CU-6
ID Ref: DG-17
Descripción: Consulta de servicios no exitosa por
ingreso de datos inexistentes.
CU asociados: CU-6
ID Ref: DG-18
Descripción: Consulta de servicios no exitosa
por fallos en el sistema.
CU asociados: CU-6
ID Ref: DG-19
Ambulancias
Descripción: Consulta de clientes exitosa

CU asociados: CU-7
ID Ref: DG-20
Descripción: Consulta de clientes no exitosa por
ingreso de datos inexistentes.
CU asociados: CU-7
ID Ref: DG-21
Descripción: Consulta de clientes no exitosa por
CU asociados: CU-7
Ambulancias
ID Ref: DG-22
Descripción: Consulta de conductores exitosa.
CU asociados: CU-8
ID Ref: DG-23
Descripción: Consulta de conductores no exitosa
por ingreso de datos inexistentes.
CU asociados: CU-8
ID Ref: DG-24
Descripción: Consulta de conductores no exitosa
CU asociados: CU-8
ID Ref: DG-25
Ambulancias
Descripción: Consulta de ambulancias exitosa

CU asociados: CU-9
ID Ref: DG-26
Descripción: Consulta ambulancias no exitosa
por ingreso de datos inexistentes.
CU asociados: CU-9
ID Ref: DG-27
Descripción: Consulta ambulancias no exitosa
CU asociados: CU-9
ID Ref: DG-28
Descripción:DE DISEÑO
Nombre del Documento: DOCUMENTO Consulta de paramédicos
DETALLADO DE SOFTWARE exitosa SDD Versión: 1.1
CU asociados: CU-10
Ambulancias
ID Ref: DG-29
Descripción: Consulta de paramédicos no
exitosa por ingreso de datos
inexistentes.
CU asociados: CU-10
ID Ref: DG-30
Descripción: Consulta de paramédicos no
exitosa por fallos en el sistema.
CU asociados: CU-10
Ambulancias
ID Ref: DG-31
Descripción: Modificación del cliente exitosa.
CU asociados: CU-11
ID Ref: DG-32
Descripción: Modificación de los datos del
cliente fallida por ingreso de datos
no válidos.
CU asociados: CU-11
ID Ref: DG-33
Descripción: Registro del cliente no exitoso
porque faltan datos por ingresar
CU asociados: CU-11
ID Ref: DG-34
Descripción: Modificación del conductor exitosa
CU asociados: CU-12
Ambulancias
ID Ref: DG-35
Descripción: Modificación de los datos de
conductor fallida por ingreso de
datos no válidos.
CU asociados: CU-12
ID Ref: DG-36
Descripción: Registro de conductor fallido
CU asociados: CU-12
ID Ref: DG-37
Descripción: Modificación de la ambulancia
exitosa.
CU asociados: CU-13
Ambulancias
ID Ref: DG-38
Descripción: Modificación de la ambulancia no
exitosa por ingreso de una fecha
pasada.
CU asociados: CU-13
ID Ref: DG-39
Descripción: Modificación de la ambulancia no
exitosa por ingreso de una fecha no
válida.
CU asociados: CU-13
ID Ref: DG-40
Descripción: Modificación del paramédico
exitosa.
CU asociados: CU-14
Ambulancias
ID Ref: DG-41
Descripción: Modificación de los datos del
paramédico fallida por ingreso de
datos no válidos.
CU asociados: CU-14
ID Ref: DG-42
Descripción: Registro del paramédico fallido
CU asociados: CU-14
ID Ref: DG-43
Descripción: Eliminación exitosa de un servicio
en estado “F”.
CU asociados: CU-15
Ambulancias
ID Ref: DG-44
Descripción: Eliminación no exitosa de un
servicio en estado “F” porque el
cliente está en deuda con la
empresa.
CU asociados: CU-15
ID Ref: DG-45
Descripción: Eliminación no exitosa de un
servicio en estado “A”.
CU asociados: CU-15
ID Ref: DG-46
Descripción: Eliminación del cliente exitosa.
CU asociados: CU-16
Ambulancias
ID Ref: DG-47
Descripción: Eliminación del cliente no exitosa
porque el cliente está en estado
“D”.
CU asociados: CU-16
ID Ref: DG-48
Descripción: Eliminación del cliente no exitosa
CU asociados: CU-16
ID Ref: DG-49
Descripción: Eliminación del conductor exitosa.
CU asociados: CU-17
Ambulancias
ID Ref: DG-50
Descripción: Eliminación del conductor no
exitosa porque está en estado “O”.
CU asociados: CU-17
ID Ref: DG-51
Descripción: Eliminación del conductor no
CU asociados: CU-17
ID Ref: DG-52
Descripción: Eliminación de la ambulancia
exitosa.
CU asociados: CU-18
Ambulancias
ID Ref: DG-53
Descripción: Eliminación de la ambulancia no
exitosa porque la ambulancia está
en estado “O”.
CU asociados: CU-18
ID Ref: DG-54
Descripción: Eliminación de la ambulancia no
exitosa por fallo en el sistema.
CU asociados: CU-18
ID Ref: DG-55
Descripción: Eliminación del paramédico
exitosa.
CU asociados: CU-19
Ambulancias
ID Ref: DG-56
Descripción: Eliminación del paramédico no
exitosa porque el paramédico está
en estado “O”.
CU asociados: CU-19
ID Ref: DG-57
Descripción: Eliminación del paramédico no
exitosa por fallo en el sistema.
CU asociados: CU-19
ID Ref: DG-58
Descripción: Cambio de estado de ambulancia a
“D”.
Ambulancias
Reqs. asociados: RF-40

CU asociados: CU-20
ID Ref: DG-59
“M”.
CU asociados: CU-20
ID Ref: DG-60
“D” / “M” no exitoso por fallos en
el sistema.
CU asociados: CU-20
ID Ref: DG-61
Descripción: Cambio de estado del conductor a
“D”.
Ambulancias

CU asociados: CU-21
ID Ref: DG-62
“F”.
CU asociados: CU-21
ID Ref: DG-63
“F” / “D” no exitoso por fallos en el
sistema.
CU asociados: CU-21
ID Ref: DG-64
Descripción: Cambio de estado de cliente a “P”,
exitoso.
CU asociados: CU-22
Ambulancias
ID Ref: DG-65
Descripción: Cambio de estado de cliente a “P”
fallido porque el cliente no se en-
cuentra en lista de clientes en
mora.
CU asociados: CU-22
ID Ref: DG-66
Descripción: Cambio de estado de cliente a “P”,
fallido por error en el sistema.
CU asociados: CU-22
ID Ref: DG-67
Descripción: Cambio de estado del servicio a
“F”, exitoso.
CU asociados: CU-23
Ambulancias
ID Ref: DG-68
Descripción: Cambio de estado del servicio a
“F”, fallido porque el estado actual
del servicio es “E”.
CU asociados: CU-23
ID Ref: DG-69
Descripción: Cambio de estado de servicio a “F”,
fallido por error en el sistema.
CU asociados: CU-23
ID Ref: DG-70
Descripción: Cambio de estado del paramédico
a “D”.
CU asociados: CU-24
Ambulancias
ID Ref: DG-71
a “F”.
CU asociados: CU-24
ID Ref: DG-72
a “F” / “D” no exitoso por fallos en
el sistema.
CU asociados: CU-24
Ambulancias
ID Ref: DG-73
Descripción: Consulta de órdenes de pago exito-
sa.
CU asociados: CU-25
ID Ref: DG-74
Descripción: Consulta de órdenes de pago no
exitosa porque no se encontraron
coincidencias.
CU asociados: CU-25
ID Ref: DG-75
Descripción: Consulta de órdenes de pago no
Ambulancias

CU asociados: CU-25
ID Ref: DG-76
Descripción: Envío de órdenes de pago exitoso.
CU asociados: CU-26
ID Ref: DG-77
Descripción: Envío de órdenes de pago no exito-
so porque no es el día establecido
para realizar el envío.
CU asociados: CU-26
ID Ref: DG-78
Descripción: Envío de órdenes de pago no
exitoso porque el sistema bancario
no está en servicio.
Ambulancias

CU asociados: CU-26
ID Ref: DG-79
Descripción: Autorización de cobro exitosa.
CU asociados: CU-27
ID Ref: DG-80
Descripción: Autorización de cobro no exitosa
porque el cliente no tiene dinero
suficiente.
CU asociados: CU-27
ID Ref: DG-81
Descripción: Autorización de cobro no exitosa
porque no se enviaron las órdenes
de pago de los clientes.
Ambulancias

CU asociados: CU-27
ID Ref: DG-82
Descripción: Envío de lista de clientes en mora
exitoso.
CU asociados: CU-28
ID Ref: DG-83
no exitoso porque el sistema
bancario autorizó el cobro
exitosamente a todos los clientes.
CU asociados: CU-28
ID Ref: DG-84
no exitoso por fallos en el sistema
bancario.
Ambulancias

CU asociados: CU-28
ID Ref: DG-85
Descripción: El informe de clientes en mora se
genera exitosamente.
CU asociados: CU-29
ID Ref: DG-86
Descripción: El informe de clientes en mora no
se genera exitosamente porque el
sistema del banco no envió la lista
de clientes en mora.
CU asociados: CU-29
ID Ref: DG-87
Descripción: El informe de clientes en mora no
se genera exitosamente porque no
es el día establecido para
generarlo.
Ambulancias

CU asociados: CU-29
ID Ref: DG-88
Descripción: El informe de conductores se
genera exitosamente.
Reqs. asociados: RF-45,46
CU asociados: CU-30
ID Ref: DG-89
Descripción: El informe de conductores no se
genera exitosamente porque no es
el día establecido para generarlo.
CU asociados: CU-30
ID Ref: DG-90
Descripción: El informe de conductores no se
genera exitosamente por fallos en
el sistema.
Ambulancias

CU asociados: CU-30
5.2.2. Interfaces con el usuario
ID Ref: INT-1
Descripción: Registro del servicio exitoso.
CU asociados: CU-1
Ambulancias
INT-2
ID Ref:
Descripción: Listar clientes con plantilla de registro.
CU asociados: CU-2
Esc. Asociados: ES-2.1, ES-2.2, ES-2.3
Ambulancias
ID Ref: INT-3
Descripción: Registro del cliente exitoso
CU asociados: CU-2
Ambulancias
ID Ref: INT-4
Descripción: Registro del conductor exitoso
Reqs. asociados: RF-3, RF-6, RF-11, RF-22
CU asociados: CU-3
Ambulancias
ID Ref: INT-5
Descripción: Consulta de ambulancias exitosa
CU asociados: CU-9
Ambulancias
ID Ref: INT-6
Descripción: Consulta de paramédicos exitosa
CU asociados: CU-10
Ambulancias
ID Ref: INT-7
Descripción: Cambio de estado del paramédico a “D”.
CU asociados: CU-24
Ambulancias
ID Ref: INT-8
Descripción: Consulta de órdenes de pago exitosa.
CU asociados: CU-25
Ambulancias
ID Ref: INT-9
Descripción: El informe de clientes en mora se genera
exitosamente.
CU asociados: CU-29
Ambulancias
ID Ref: INT-10
Descripción: El informe de conductores se genera
exitosamente.
CU asociados: CU-29
Ambulancias
5.3. Vista Lógica
5.3.1. Descripción
El diseño del sistema respeta el Modelo MVC (Model, View, Controller)n
Capa de Base de Datos (Model), se encarga de almacenar toda la información, y tenerla

disponible para cualquier aplicación.
Para esta capa se utilizará como motor de base de datos SQL. Y como modelo de
persistencia se utiliza el patrón DAO (Data Access Object), este patrón nos proporciona
un objeto de acceso a datos para mantener la persistencia de datos dentro del sistema
que se va a desarrollar.
Capa de Aplicaciones (View y Controller), Donde se instalan todas las aplicaciones, y son
publicadas tanto para los usuarios internos, como los usuarios que ingresan desde
Internet. Escucha requerimientos de los usuarios, y responde, con una aplicación que se
conecta a la base de datos para consultas y/o modificaciones.
Para esta capa se utilizará SQL donde se montarán los .jsp que implementan tanto las
interfaces de usuario como las lógicas de control necesarias. Para la comunicación entre
el servidor de aplicaciones y el motor base de datos que se utilizará es SQL server con la
intención de tener un mejor manejo de las conexiones a la base de datos.
Capa de usuario o cliente (View), es un cliente liviano, no requiere equipos grandes,

únicamente requiere tener un explorador de Internet (Ver Requerimientos No
Funcionales), desde el cual se conecta al servidor de aplicaciones para hacer consultas y
transacciones a la BD mediante los sistemas desarrollados.
Para esta capa se utilizará el lenguaje de programación C#
La ventaja de este tipo de arquitecturas es que las aplicaciones están en un sólo punto, lo
que permite que los administradores sólo hagan cambios en el servidor de aplicaciones y
no así en cada uno de los equipos clientes. Asegura la escalabilidad y alta disponibilidad.
Ambulancias
Ambulancias
5.3.2. Paquetes de Diseño Arquitectónicamente Significativos
Ambulancias
5.3.3. Vista de Implementación - Componentes
5.4. Vista de Despliegue - Ambiente Físico
Ambulancias
5.5. Vista de Datos
5.5.1. Definiciones
NOMBRE OBJETO: Ambulancia
DESCRIPCION: Datos de la empresa que emplea la empresa
Columnas:
PK Nombre Tipo No Nulo Único Longitud Notas
id_ambulancia Integer x 10 Código de la Ambulancia.
Placa x 10 Placa de la ambulancia.
Varchar
Modelo Varchar x 10 Modelo de la ambulancia.
Fecha_registro Datetime
x Fecha de registro de la
ambulancia.
Asignación_Secre- Varchar x 25 Asignación de la
taria_id_secretaria ambulancia.
Asignación_id_asig Integer x 25 Estado de la asignación de
nar la ambulancia.
Relaciones:
Ambulancias
Columnas Asociación Notas

id_ambulancia Ambulancia- Asignación Foreign Key: Código de la tabla que
contiene la Información de la
ambulancia.
NOMBRE ENTIDAD: Asignación
DESCRIPCION:
Columnas:
X id_asignar Integer X 10 Identificador de asignación
id_condcutor Integer X 10 Identificador del conductor
Identificador de la
id_ambulancia Varchar x 15
ambulancia
fecha_registro Varchar X 15 Fecha de la asignación
Estado Varchar X 15 Estado de la asignación
Relaciones:
Foreign Key: Código de la tabla que contiene
Id_asignar Asignar
la Información de asignación
Id_conductor Asignar- Conductor
la Información del conductor
id_ambulancia Asignar- Ambulancia
la Información de la ambulancia
NOMBRE ENTIDAD: Cliente
DESCRIPCION:
Columnas:
X id_persona Integer X 10 Identificador de asignación
Cedula Integer X 10 Identificador del conductor
Nombres Varchar x 25 Nombres del cliente
Apellidos Varchar x 25 Apellidos del cliente
Sexo Varchar X 15 Sexo del cliente
Telefono de contacto del
Telefono Char x 15
cliente
Fecha de Nacimiento del
Fecha_Naci Datetime x
cliente
Fecha_Registro Datetime x Fecha de regsitro del cliente
Estado Varchar x 15 Estado de la asignación
Ambulancias
Relaciones:
Id_Persona Cliente
la Información del cliente
Cedula Cliente
la cedula del cliente.
NOMBRE ENTIDAD: Conductor
DESCRIPCION:
Columnas:
X id_conductor Integer X 10 Identificador del conductor
Id_persona Integer X 10 Identificador de la persona
fecha_contrato Varchar x 25 Fecha de contrato
fecha_registro Varchar x 25 Fecha de registro
Relaciones:
Id_Conductor Conductor - Usuario
la Información del conductor
Id_Persona Conductor - Usuario
la información de la persona.
NOMBRE ENTIDAD: Paramédico
DESCRIPCION:
Columnas:
X id_paramedico Integer X 10 Identificador del conductor
Estado Varchar x 20 Estado del servicio
Relaciones:
Id_Paramédico Paramédico - Usuario
la Información del paramédico
Id_Persona Paramédico - Usuario
Ambulancias
NOMBRE ENTIDAD: secretaria

DESCRIPCION:
Columnas:
X id_secretaria Integer X 10 Identificador de la secretaria
Relaciones:
Id_Secretaria Secretaria - Usuario
la Información de la secretaria.
Id_Persona Usuario
NOMBRE ENTIDAD: Persona

DESCRIPCION:
Columnas:
X id_usuario Integer X 10 Identificador de la secretaria
correo Varchar x 25 Correo del usuario
Contraseña Varchar x 25 Contraseña del usuario
Fecha_registro Varchar x 20 Fecha de registro del usuario
Relaciones:
Id_usuario Paramédico - Usuario
la Información del usuario
Id_Persona Paramédico - Usuario
NOMBRE ENTIDAD: Gerente

DESCRIPCION:
Ambulancias
Columnas:
X id_usuario Integer X 10 Identificador de la secretaria
correo Varchar x 25 Correo del usuario
Contraseña Varchar x 25 Contraseña del usuario
Fecha_registro Varchar x 20 Fecha de registro del usuario
Relaciones:
Id_usuario Gerente-Usuario
la Información del gerente
Id_Persona Usuario
NOMBRE ENTIDAD: Hospital

DESCRIPCION:
Columnas:
X id_hospital Integer X 10 Identificador de la secretaria
Nombre_Hospital Integer x 10 Nombre del hospital
Fecha Varchar x 25 Fecha del servicio
Relaciones:
Id_hospital Hospital - Ambulancia
la Información del hospital
NOMBRE ENTIDAD: Petición

DESCRIPCION:
Columnas:
X id_peticion Integer X 10 Identificador de la petición
Id_cliente Integer x 10 Identificador del cliente
Id_ambulancia Varchar x 25 Identificador de la
Ambulancias
ambulancia
dirección Varchar x 25 Dirección de la petición
Hospital Varchar x 25 Hospital
Fecha Varchar x 25 Fecha del servicio
Relaciones:
Id_hospital Hospital – Petición
la Información del hospital
5.5.2. Diseño de Base de Datos
Ambulancias
5.6. Requisitos de Software/Hardware

Equipamiento y Configuración:
Servidor de Aplicaciones
- Sistema Operativo Linux, tenemos el RedHat Enterprise Linux Server 5.4
- Servidor de Aplicaciones Jboss As 6.0.0.final
- JDK 1.6.0_23 o superior
- Intel Xeon x5570 de 2 procesadores
- Memoria 8 GB, 4 GB reservado
- Disco 30 GB]
Ambulancias
6. Calidad
Dado a la estructura relativamente simple del sistema, principalmente son extraer e ingresar
entidades en la Base de Datos, este no debería presentar fallas al momento de ejecutar de los
diversos servicios que ofrece. La calidad del sistema dependería principalmente de la
funcionabilidad del servidor web, del manejador de Base de Datos y su comunicación entre
ellos. Una arquitectura para aplicaciones describe los patrones y las técnicas que se utilizan
para diseñar y desarrollar aplicaciones. La arquitectura le proporciona un plan y las prácticas
recomendadas que debe seguir al momento de diseñar una aplicación, de modo que obtenga
una aplicación bien estructurada.
7. Observaciones
El uso de las Tecnologías de la Información y Comunicación (TIC) nos permite acelerar todo
tipo de procesos minimizando los tiempos de respuesta de estos, dando una mayor brevedad a
los usuarios. En este caso se suministra el fácil acceso al servicio de ambulancia por medio de
dispositivos móviles o por la aplicación de escritorio. El uso de nuevas tecnologías en el
desarrollo de software permite crear herramientas de innovación que pueden ser muy útiles para
la solicitud de servicios médicos como es la ambulancia. Se desarrolló un sistema distribuido
para la solicitud de ambulancia capaz de soportar un crecimiento individual de cada uno de los
componentes implementados (bases de datos, servicio web, servidor de aplicaciones y
aplicaciones móviles), con el desarrollo de este proyecto se puede mejorar significativamente
los tiempos de respuesta en la asignación de una ambulancia y mejorar el servicio de la atención
ya que se cuenta con un chat donde expone la situación en la que se encuentra el usuario, y se
visualiza la posición exacta donde está el afectado. El registro y conservación de la información
en las bases de datos aumenta la integridad en todo sistema de información ofreciendo servicios
adicionales como la generación de reportes y acceso fácil y rápido a dicha información que se
encuentra alojada allí.

FRPB Das Plantilla Especificacion Diseno2022 (Final)

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

FRPB Das Plantilla Especificacion Diseno2022 (Final)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

FRPB Das Plantilla Especificacion Diseno2022 (Final)

Cargado por

Copyright:

Formatos disponibles

Proyecto: Gestión de

DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE

1.2. Definiciones, Acrónimos y Abreviaturas

Finalizado • Estado que indica que el servicio ya ha sido Finalizado

Secretarias Usuario Registrar Perfeccio -Satisfacción -No se Liberación del

Bancarios de sistema de sistema la a clientes que

2. Presentación del Producto

2.2.1. Planteamiento del problema

El alcance de la DDS comprende la definición de los requerimientos funcionales y no

de interfaz, restricciones de diseño, requerimientos de licencia o componentes comprados

Afecta a: Clientes, secretarias, paramédicos, conductores y gerente de la empresa.

Cuyo impacto es:

Una solución satisfactoria permitirá:

2.2.4. El Sistema no contempla

Cambio del Bajo Alto Personal del soporte Personal

Sobrepasar el Bajo Alto El sistema muestre Equipo de

3.2. Perspectivas futuras del producto

3.3. Reglas y Funciones de Negocio

Gestión de Ambulancias: Situación Propuesta (TO BE)

Gestión de Cobros: Situación Propuesta (TO BE)

Registrar Clientes: Situación Propuesta (TO BE)

Tipo: Funcional - Datos

Detalles de El sistema debe almacenar la siguiente información acerca de los clientes:

requisitos y • Nombres y apellidos: Caja de texto editable con longitud de 50

Texto: Describe los datos requeridos de la ambulancia mantenidos por el sistema.

Tipo: Funcional - Datos

Detalles de El sistema debe almacenar la siguiente información acerca de las ambulancias:

requisitos y • Código de la ambulancia: Caja de texto NO editable con longitud

Tipo: Funcional - Datos

Detalles de El sistema debe almacenar la siguiente información acerca de los conductores:

requisitos y • Nombres y apellidos: Caja de texto editable con longitud de 50

Título: Ingresar paramédico

Tipo: Funcional - Datos

Detalles de El sistema debe almacenar la siguiente información acerca de los paramédicos:

requisitos y • Nombres y apellidos: Caja de texto editable con longitud de 50

Título: Ingresar servicio

Tipo: Funcional - Datos

Detalles de El sistema debe almacenar la siguiente información acerca de los servicios:

Título: Validar Número de cédula

Texto: El sistema validará los Números de cédula.

Tipo: Funcional - Funcionalidad

Texto: El sistema validará los Números de cuenta bancaria.

Tipo: Funcional - Funcionalidad

Texto: El sistema validará los Números de placa vehicular.

Tipo: Funcional - Funcionalidad

Texto: El sistema generará los códigos que dispondrán los servicios.

Tipo: Funcional – Funcionalidad

Detalles de El sistema deberá generar un código único para cada servicio:

requisitos y • Código del servicio: Constará de 6 dígitos aleatorios (4 numéricos

Nota: El sistema no debe generar el mismo código de un servicio

Texto: El sistema generará los códigos que dispondrán las ambulancias.

Tipo: Funcional – Funcionalidad

Detalles de El sistema deberá generar un código único para cada ambulancia:

requisitos y • Código de la ambulancia: Constará de 4 dígitos aleatorios

Nota: El sistema no debe generar el mismo código de una ambulancia

Texto: El sistema generará los códigos que dispondrán los conductores.

Tipo: Funcional - Funcionalidad

Detalles de El sistema deberá generar un código único para cada conductor: