1 REQUERIMIENTOS FUNCIONALES
IDENTIFICADOR: NOMBRE:
R1 Registro cuenta para doctores
Tipo: REQUERIMIENTO QUE LO ¿CRÍTICO?
(NECESARIO/DESEABL UTILIZA O ESPECIALIZA: Si
E)
Necesario
PRIORIDAD D Actor: Doctor
DESARROLLO: E
Alta
ENTRADA: SALIDA:
Número y tipo de documento Registro correcto de un Doctor
Apellidos y
Nombres
completos
Teléfono
Contraseña
Identificador de doctor
DESCRIPCIÓN:
Precondición: El doctor debe trabajar en el hospital
Descripción: Se registrará en el sistema toda la información necesaria para
llevar a cabo el registro de un doctor
Postcondición: Se realizará el registro de un doctor
MANEJO DE SITUACIONES ANORMALES
1. Doctor ya registrado en el sistema (se mostrará en pantalla un mensaje
que dirá que la persona ya está registrada en el sistema)
2. Campos obligatorios solicitados quedaron sin diligenciar (mensaje que
indique los campos que eran obligatorios quedaron sin diligenciar)
CRITERIOS DE ACEPTACIÓN
Se supondrá por defecto que hay al menos dos criterios de aceptación:
1. Los datos ingresados al sistema en el momento de realizar el registro de
una persona son correctos y los indicados y establecidos para llevar a cabo
su correcto registro en el sistema y poder realizar sus trámites dentro del
mismo.
Pag.1
2 REQUERIMIENTOS FUNCIONALES
IDENTIFICADOR: NOMBRE:
R2 Registro cuenta para usuario
Tipo: REQUERIMIENTO QUE LO ¿CRÍTICO?
(NECESARIO/DESEABL UTILIZA O ESPECIALIZA: Si
E)
Necesario
PRIORIDAD D Actor: Usuario
DESARROLLO: E
Alta
ENTRADA: SALIDA:
Número y tipo de documento Registro correcto de un usuario
Apellidos y
Nombres
completos
Teléfono
Contraseña
Identificador de usuario
DESCRIPCIÓN:
Precondición: El usuario debe estar afiliado en el hospital
Descripción: Se registrará en el sistema toda la información necesaria para
llevar a cabo el registro de un usuario
Postcondición: Se realizará el registro de un usuario
MANEJO DE SITUACIONES ANORMALES
1. Usuario ya registrado en el sistema (se mostrará en pantalla un mensaje
que dirá que la persona ya está registrada en el sistema)
2. Campos obligatorios solicitados quedaron sin diligenciar (mensaje que
indique los campos que eran obligatorios quedaron sin diligenciar)
Pag.2
CRITERIOS DE ACEPTACIÓN
Se supondrá por defecto que hay al menos dos criterios de aceptación:
Los datos ingresados al sistema en el momento de realizar el registro de
una persona son correctos y los indicados y establecidos para llevar a cabo
su correcto registro en el sistema y poder realizar sus trámites dentro del
mismo.
IDENTIFICADOR: NOMBRE: Ingreso a lista de espera
R3
Tipo: REQUERIMIENTO QUE LO ¿CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O ESPECIALIZA: Si
) Permisos de chat
Necesario
PRIORIDAD Usuarios: Doctor, usuario
DE
DESARROLLO:
Alta
ENTRADA: SALIDA:
Usuario Acceder a las listas del administrador
Contraseña
DESCRIPCIÓN:
Precondición: Estar registrado
Descripción: Agrega al usuario o doctor a una lista de administrador
Postcondición: El usuario o doctor estarán en una lista
MANEJO DE SITUACIONES ANORMALES
1. Campos obligatorios solicitados quedaron sin diligenciar (mensaje que
indique los campos que eran obligatorios quedaron sin diligenciar)
2. El usuario ya esta en lista de espera
Pag.3
CRITERIOS DE ACEPTACIÓN
Los datos ingresados al sistema en el momento de realizar el ingreso de un
Doctor o usuario sean correctos y los indicados y establecidos para llevar a
cabo el ingreso a las listas de espera.
IDENTIFICADOR: NOMBRE:
R4 Distribución de parejas
Tipo: REQUERIMIENTO QUE LO ¿CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O ESPECIALIZA: Si
)
Necesario
PRIORIDAD Usuario: Administrador
DE
DESARROLLO:
Alta
ENTRADA: SALIDA:
Lista de pacientes Pacientes asignados a doctores
Lista de usuarios
DESCRIPCIÓN:
Precondición: Ambos deben estar en su lista correspondiente
Descripción: Se asignarán a los doctores con la capacidad de ayudar a los
pacientes.
Postcondición: Los doctores serán asignados a los pacientes
MANEJO DE SITUACIONES ANORMALES
1. El doctor o paciente ya se encuentre asignado
2. Lista sin actualizar
3. El doctor se encuentre mal asignado al paciente
CRITERIOS DE ACEPTACIÓN
Los datos ingresados al sistema en el momento de realizar la asignación de las
parejas son correctos y los indicados y establecidos para llevar a cabo su
correcta asignación de parejas
Pag.4
IDENTIFICADOR: NOMBRE:
R5 Permisos de chat
Tipo: REQUERIMIENTO QUE LO ¿CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O Si
) ESPECIALIZA:
Necesario
PRIORIDAD Usuario: Doctores y usuario
DE
DESARROLLO:
Alta
ENTRADA: SALIDA:
Doctor Capacidad de escribir y leer el chat
Usuario
DESCRIPCIÓN:
Precondición: Estar en pareja dos.
Descripción: Capacidad de escribir y leer el chat.
Postcondición: Procede con normalidad la cita.
MANEJO DE SITUACIONES ANORMALES
1. No se puede leer o escribir de un lado o de ambos lados en el chat
Pag.5
CRITERIOS DE ACEPTACIÓN
1. El doctor y el usuario pueden leer y escribir
EJERCICIO 3
Pag.6
IDENTIFICADOR: NOMBRE:
R1 historial de las habitaciones
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O ESPECIALIZA: Si
) R2 ,R3
Necesario
PRIORIDAD Actores:
-usuario
DE
DESARROLLO:
Alta
ENTRADA: SALIDA:
-numeros de habitación Lista con las habitaciones
-estado=(ocupado/desocupado)
DESCRIPCIÓN:
Precondición: tener habitaciones
Descripción: obtener el estado de las habitaciones
Postcondición: lista con todas las habitaciones y su estado
MANEJO DE SITUACIONES ANORMALES
1. Error en el estado de la habitación(Actualizar lista)
2. Habitación en mantenimiento(se elimina de la lista)
CRITERIOS DE ACEPTACIÓN
1. cada habitación este registrada junto con su estado
IDENTIFICADOR: NOMBRE:
R2 Reserva usuarios
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O ESPECIALIZA: si
)
Necesario R1
PRIORIDAD D ACTORES
E
DESARROLLO: Usuarios
Alta
ENTRADA: SALIDA:
-nombre/apellido
-cedula Usuario con habitación reservada
-teléfono
-tarjeta
-habitacion
DESCRIPCIÓN:
Precondición: habitación disponible .
Descripción: el usuario reservara su habitacion
Postcondición: el usuario reservo su habitación y su habitación cambio a estado
ocupado
MANEJO DE SITUACIONES ANORMALES
1. Habitación ocupada(actualiza lista de habitaciones)
2. Tarjeta rechazada(ventana emergente que diga tarjeta errónea)
CRITERIOS DE ACEPTACIÓN
1. que el usuario haya reservado su habitación y se actualice el estado
IDENTIFICADOR: NOMBRE:
R3 Vizualizar habitaciones
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O ESPECIALIZA: SI
) R2
Necesario
PRIORIDAD Actores:
Usuario
DE
DESARROLLO:
ALta
ENTRADA: SALIDA:
Lista de habitaciones Lista de habitaciones actualizada
Precondición: Lista previamente llenada
Descripción: permite consultar el estado de una habitación y actualizar en caso
de cambios en las habitaciones del hotel
Postcondición: se mostrara la lista con la información correcta
1
IDENTIFICADOR: NOMBRE:
R9 generar información de usuario
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O Si
) ESPECIALIZA: R1
Necesario R
2
R
3
R
5
R7
PRIORIDAD DOCUMENTOS DE VISUALIZACIÓN ASOCIADOS:
DE
DESARROLLO:
Alta
ENTRADA: SALIDA
:
Consulta registro de usuario d registr efectuad p e
Repor el o o or l
te
usuari
o
DESCRIPCIÓN:
Precondición: haber realizado una consulta previa del registro del usuario y
solicitar la generación del reporte con los datos diligenciados
Descripción: permitirá ver en pantalla los datos diligenciados e ingresados por el
usuario para su correspondiente registro en el sistema
Postcondición: se generará el reporte correspondiente a la consulta del usuario
con sus datos previamente diligenciados en el sistema
MANEJO DE SITUACIONES ANORMALES
1. El sistema no genera la información del usuario
2. Los datos del usuario no existen en el sistema
CRITERIOS DE ACEPTACIÓN
1. La generación del reporte de la información de un usuario es generada
por el sistema correctamente
IDENTIFICADOR: NOMBRE:
R10 Generar información del vehículo
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O Si
) ESPECIALIZA: R4
Necesario R6
R8
PRIORIDAD DOCUMENTOS DE VISUALIZACIÓN ASOCIADOS:
DE
DESARROLLO:
Alta
ENTRADA: SALIDA:
Consulta registro de vehículo Reporte del registro del vehículo
DESCRIPCIÓN:
Precondición: haber realizado una consulta previa del registro del vehículo y
solicitar la generación del reporte con los datos diligenciados
Descripción: permitirá ver en pantalla los datos diligenciados e ingresados por el
usuario en el registro en el sistema
Postcondición: se generará el reporte correspondiente a la consulta del vehículo
con sus datos previamente diligenciados en el sistema
MANEJO DE SITUACIONES ANORMALES
1. El sistema no genera la información del vehículo
2. Los datos del vehículo no existen en el sistema
CRITERIOS DE ACEPTACIÓN
1. La generación del reporte de la información de un vehículo es generada
por el sistema correctamente
IDENTIFICADOR: NOMBRE:
R11 Actualizar información del usuario
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O ESPECIALIZA: No
)
Necesario R1
R2
R3
R7
PRIORIDAD D DOCUMENTOS DE VISUALIZACIÓN ASOCIADOS:
E
DESARROLLO:
Media
ENTRADA: SALIDA:
Registro de usuario Actualización de la información de usuario
exitosa
DESCRIPCIÓN:
Precondición: : haber realizado el registro de usuario y haber realizado una
consulta previa de la información para actualizarla
Descripción: permitirá hacer cambios en la información ingresada durante el
registro de un usuario y así guardar y actualizar cambios en el sistema
Postcondición: se actualizará la información necesaria correctamente
MANEJO DE SITUACIONES ANORMALES
1. Los datos en el sistema no fueron configurados
CRITERIOS DE ACEPTACIÓN
1. La actualización de la información en el sistema fue exitosa
IDENTIFICADOR: NOMBRE:
R12 Actualizar información del vehículo
Tipo: REQUERIMIENTO QUE LO CRÍTICO?
(NECESARIO/DESEABLE UTILIZA O No
) ESPECIALIZA: R4
Necesario R8
PRIORIDAD DOCUMENTOS DE VISUALIZACIÓN ASOCIADOS:
DE
DESARROLLO:
Media
ENTRADA: SALIDA:
Registro de vehículo Actualización de la información de
vehículo exitosa
DESCRIPCIÓN:
Precondición: : haber realizado el registro de vehículo y haber realizado una
consulta previa de la información para actualizarla
Descripción: permitirá hacer cambios en la información ingresada durante el
registro de un vehículo y así guardar y actualizar cambios en el sistema
Postcondición: se actualizará la información necesaria correctamente
MANEJO DE SITUACIONES ANORMALES
2. Los datos en el sistema no fueron configurados
CRITERIOS DE ACEPTACIÓN
2. La actualización de la información en el sistema fue exitosa
Identificador: Nombr
e:
R13 comprobante único de pago
Consult
ar
TIPO: REQUERIMIENTO QUE LO ¿Crític
UTILIZA O ESPECIALIZA:
Necesario o? no
R12
R7
R8
PRIORIDAD D Documentos de visualización Asociados:
DESARROLLO: E
Media
ENTRADA: SALIDA:
Registro de usuario, registro Se muestra en pantalla el comprobante
de vehículo, registro de de pago.
pago.
DESCRIPCIÓN:
Precondición: El sistema realizara la búsqueda del comprobante de pago en un
registro actualizado, mediante el ingreso de datos del usuario o del vehículo.
Descripción: Con el ingreso de los datos del usuario o vehículo se realizara la
búsqueda en el sistema y se mostrara el comprobante de pago.
Postcondición: El sistema realizará la verificación de datos e información del
cliente o vehículo para así realizar la búsqueda del comprobante de pago.
MANEJO DE SITUACIONES ANORMALES
1. Datos de usuario o vehículo inválidos (mensaje mostrando que los datos
no son correctos).
2. No se encuentra el comprobante (mensaje mostrando que no ha sido
generado).
3. El formato del archivo no se puede abrir (mensaje mostrando que no se
encuentra el programa necesario para abrir el siguiente formato).
CRITERIO DE ACEPTACIÓN
1. Al validar la consulta de los datos de los usuarios el sistema realizara la
búsqueda del comprobante y luego lo mostrara en pantalla.
2. Se realiza la muestra en pantalla del comprobante de pago.
3. La verificación de los datos de usuario o del vehículo serán aceptados.
Identificador: Nombre:
R14 Buscar parqueadero
TIPO: REQUERIMIENTO QUE LO ¿Crítico?
UTILIZA O ESPECIALIZA: si
Necesario
PRIORIDAD Documentos de visualización Asociados:
DE
DESARROLLO:
Alta
ENTRADA: SALIDA:
Dirección parqueadero Ubicación del parqueadero en el mapa
DESCRIPCIÓN:
Precondición: ingresar dirección para ubicar el parqueadero
Descripción: se ingresa la dirección del parqueadero y en el mapa se ubica el
mismo para validar las bahías disponibles
Postcondición: la dirección ingresada es correcta y ubicada en el mapa para
validar el parqueadero
MANEJO DE SITUACIONES ANORMALES
1. No se encuentra dirección en el mapa
2. No es posible ubicar el parqueadero en el mapa
CRITERIOS DE ACEPTACIÓN
1. Mapa validado con la dirección indicada por el usuario
3 REQUERIMIENTOS NO FUNCIONALES
3.1 ATRIBUTOS DE CALIDAD
Listado de los atributos de calidad y la descripción y su respectiva ficha (puede
utilizar la ficha de requerimientos funcionales con algunas modificaciones).
Requisito Descripción
Eficiencia Conjunto de atributos que relacionan el desempeño y la
cantidad de recursos necesitados bajo condiciones
establecidas
Fiabilidad Conjunto de atributos relacionados con la capacidad del
software de mantener su nivel de prestación bajo
condiciones establecidas durante un periodo de tiempo
establecido.
Confiabilidad Este término es necesario sea separado en varios
elementos que permiten darle al software el matiz de
fiable. Sus componente son :
Completitud
Consistencia y
precisión Solidez
Simplicidad
Calidad en los procesos de desarrollo
Seguridad y Verificabilidad, estas dos últimas que se
determinan con el sistema en uso.
Disponibilidad Grado en el cual un sistema o componente
es operacional y accesible cuando es requerido
para su uso.
Usabilidad Conjunto de atributos relacionados con el esfuerzo
necesario para el uso, y en la valoración individual de
tal uso, por un establecido o implicado conjunto de
usuarios.
Mantenibilidad Conjunto de atributos relacionados con la facilidad de
extender, modificar o corregir errores en un sistema o
software.
Flexibilidad Facilidad con la que un sistema o componente puede
ser modificado para ser usado en ambientes diferentes
para los cuales fue diseñado inicialmente.
Extensibilidad Consiste en la facilidad de adaptación del software a
nuevos requisitos o cambios en la especificación.
REUTILIZACIÓN es otro factor de calidad que consiste
en crear elementos de software que sirvan para
construir distintas aplicaciones.
Seguridad Propiedad de un sistema para salvaguardar la
privacidad e integridad de la información.
Integridad No ocurrencia de alteraciones no autorizadas
de información.
Interoperabilida Es la condición mediante la cual
d sistemas heterogéneos pueden intercambiar procesos o
datos.
Concurrencia Capacidad que tiene un sistema para que ingresen
múltiples usuarios al mismo tiempo.
Accesibilidad Éste no se refiere a la facilidad de uso, sino a la
posibilidad de acceso. En concreto a que el diseño,
como prerrequisito imprescindible para ser usable,
posibilite el acceso a todos sus potenciales usuarios,
sin excluir a aquellos con limitaciones individuales
(discapacidades, dominio del idioma, etc.) o
limitaciones derivadas del contexto de acceso (software
y hardware empleado para acceder, ancho de banda de
la conexión empleada, etc.)
En la siguiente figura se pueden evidenciar claramente en el árbol de utilidad los
aspectos de calidad identificados y que son de suma importancia para cumplir con
los requerimientos funcionales.
DIAGRAMAS UML
A continuación se detallarán los diagramas que se validaron en el proceso del
sistema y que fueron necesarios para el diseño y la implementación del mismo.
Los diagramas que se realizaron y fueron pertinentes y necesarios para esto son
los siguientes:
Diagrama de casos de uso
Diagrama de secuencias
Diagrama de componentes
Modelo entidad – relación
Diagrama de casos de uso
Se realizó un diagrama de caso de uso para los principales requerimientos y
funcionalidades del sistema, ya que mas adelante se detalla cada uno de ellos en
los casos de uso.
Diagrama de secuencias
Muestra la secuencia de los pasos que sigue el ususario en el sistema para
realizar y llevar a cabo las funcionalidades del mismo.
Diagrama de componentes
En el diagrama de componentes se modelan los componentes del sistema y las
interrelaciones que tienen. De esta manera, se da un panorama general del diseño
del sistema. A continuación, se presenta en la Figura el diagrama de componentes
del sistema propuesto. En este diagrama se identifican los componentes y
dependencias que existen entre ellos.
Como se puede observar en la figura, hay una interfaz web que da acceso a los
requerimientos funcionales del sistema. Además, existe otra interfaz de
administración que da acceso a características de seguridad y control del sistema.
En la Lógica de Negocio, se encuentran las características de los requerimientos
funcionales del sistema, además de los módulos de administración de usuarios,
roles y permisos que pertenecen al módulo que maneja la seguridad del sistema.
En la capa de documentación se encuentra todo lo relacionado a la gestión de
documentos y datos de los usuarios, y también se realizo la creación de un bean,
que permite evitar la reprogramación de todos los componentes del sistema y
realizar la conexión viable con la base de datos. Por último, las capas son
soportadas por un servidor de base de datos.
Diseño del modelo Entidad – Relación
Es un modelo de datos para representar las Entidades de información (Conjunto
de datos) y las relaciones que las componen. En este modelo, se considera la
base de datos como un conjunto de relaciones, las cuales se almacenan en una
tabla (Conjunto de filas).
A continuación, se presenta el diseño del modelo relacional de la base de datos
para el subsistema de seguridad con la respectiva especificación.
