Frpb-Ir-Plantilla-Especificacion-De-Requerimiento (Grupo C)

Proyecto: GESTION DE GUARDIAS DE MEDICOS
Versión Producto: 1.1 Cliente: 0001
Universidad de Guayaquil
Facultad de Ciencias Matemáticas y Físicas
Tercer Semestre
2021
DOCENTE:
Ing. Parrales Bravo Franklin Ricardo
GRUPO C
Integrantes:
• Baquerizo Vera Alejandro Líder de análisis y
mejora.
• Borja Arévalo Viviana Secretaria.
• Hidalgo Robles Brayan Líder de Gestión.
• Proaño Lino Moisés Líder de Verificación y
Validación.
• Solórzano Terán Petter Líder de Elicitacion.
Tabla de contenido
1. INTRODUCCIÓN ............................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
1.1. OBJETIVO............................................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
1.2. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ............................................. ¡ERROR! MARCADOR NO DEFINIDO.
1.3. AUDIENCIA ........................................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
1.4. ALCANCE ............................................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
2. PRESENTACIÓN DEL PRODUCTO .................................................... ¡ERROR! MARCADOR NO DEFINIDO.
2.1. PROPÓSITO DEL SISTEMA ........................................................................ ¡ERROR! MARCADOR NO DEFINIDO.
2.1.1. Planteamiento del problema ........................................................ ¡Error! Marcador no definido.
2.1.2. Objetivo ........................................................................................ ¡Error! Marcador no definido.
2.1.3. Alcance ......................................................................................... ¡Error! Marcador no definido.
2.1.4. El Sistema no contempla ............................................................... ¡Error! Marcador no definido.
2.2. RIESGOS .............................................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
3. DESCRIPCIÓN GENERAL ................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
3.1. CONTEXTO DEL PRODUCTO...................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
3.2. PERSPECTIVAS FUTURAS DEL PRODUCTO ..................................................... ¡ERROR! MARCADOR NO DEFINIDO.
3.3. REGLAS Y FUNCIONES DE NEGOCIO ...........................................................................................................8
4. DESCRIPCIÓN DETALLADA DE REQUERIMIENTOS ........................... ¡ERROR! MARCADOR NO DEFINIDO.
4.1. REQUERIMIENTOS FUNCIONALES .............................................................. ¡ERROR! MARCADOR NO DEFINIDO.
4.2. REQUERIMIENTOS NO FUNCIONALES ......................................................... ¡ERROR! MARCADOR NO DEFINIDO.
4.2.1. Del Producto ................................................................................. ¡Error! Marcador no definido.
4.2.2. Del Ambiente ................................................................................ ¡Error! Marcador no definido.
5. MODELO DE CASOS DE USO ........................................................... ¡ERROR! MARCADOR NO DEFINIDO.
5.1. ACTORES ............................................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
5.2. DIAGRAMA/S DE CASO DE USO ................................................................ ¡ERROR! MARCADOR NO DEFINIDO.
5.3. LISTADO DE CASOS DE USO ..................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
5.4. DETALLE DE CASOS DE USO ..................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
6. MODELO DE ANÁLISIS .................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
6.1. MODELO DEL DOMINIO .......................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
6.2. DIAGRAMAS DE SECUENCIA Y/O COLABORACIÓN ......................................... ¡ERROR! MARCADOR NO DEFINIDO.
7. REQUERIMIENTOS DE INTERFAZ .................................................... ¡ERROR! MARCADOR NO DEFINIDO.
7.1. INTERFACES CON EL USUARIO ................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
7.2. INTERFACES DE HARDWARE ..................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
7.3. INTERFACES DE SOFTWARE ...................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
7.4. INTERFACES DE COMUNICACIÓN ............................................................... ¡ERROR! MARCADOR NO DEFINIDO.
8. MATRIZ DE TRAZABILIDAD ............................................................. ¡ERROR! MARCADOR NO DEFINIDO.
8.1. TRAZABILIDAD DE REQUISITOS .................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
8.2. TRAZABILIDAD DE CASOS DE USO .............................................................. ¡ERROR! MARCADOR NO DEFINIDO.
9. RESTRICCIONES DE DISEÑO ............................................................ ¡ERROR! MARCADOR NO DEFINIDO.
10. REQUERIMIENTOS DE LICENCIA ..................................................... ¡ERROR! MARCADOR NO DEFINIDO.
11. PROCEDIMIENTO DE CONTROL DE CAMBIOS ................................. ¡ERROR! MARCADOR NO DEFINIDO.
12. OBSERVACIONES............................................................................ ¡ERROR! MARCADOR NO DEFINIDO.
1. INTRODUCCION
1.1. OBJETIVO
La presente Especificación de Requerimientos de Software tiene como objetivo
definir con claridad los requerimientos específicos, correspondientes y deseados
para el Proyecto.
Este documento mostrara todo el procedimiento establecido para elaborar el
software que necesita la empresa y se refleje toda la funcionalidad del Sistema, ya
que contendrá toda la información necesaria para que el usuario que lea este
documento y pueda entender claramente los objetivos y funcionamiento del
producto software elaborado para el cliente.
1.2. Definiciones, Acrónimos y Abreviaturas

Termino Definición Alias Abreviatura
Es un lenguaje de modelado
de desarrollo de propósito
general en el campo de la
Notación ingeniería de software que
UML UML
UML está destinado a
proporcionar una forma
estándar de visualizar el
diseño de un sistema.
Personas que se encarga de
asignar y modificar las
Planificadores Planificadores N/A
guardias de un
departamento específico.
Personas que se encarga de
revisar y consultar el
Supervisores Supervisores N/A
movimiento dentro el
hospital.
Representación de datos
que su objetivo es informar
Estadísticas Estadísticas N/A
los resultados de un
progreso o perdida.
Son los turnos que hacen los
doctores donde realizan
todas sus labores
Guardia Guardia N/A
profesionales en el hospital,
puede ser de 5 horas hasta
12 horas
Señala la acción o cargo que
Asignar debe ejecutar un doctor en Asignar N/A
este caso las guardias
Se refiere a la acción que

Cargo cumple el doctor en el Cargo N/A
horario establecido
Indica una tarea que tiene
Rol permiso y ejecuta el usuario Rol N/A
al hacer uso del sistema
1.3. Audiencia
Competencias
técnicas /
Criterios de
Stakeholder Rol Responsabilidad Intereses Preocupación Relación de
éxito
ambiente de
trabajo
Construyas Cumplir las
Doctores
Departamento criticas expectativas Tiempo de
Médicos Aprobar proyecto N/A
medico fundamentales del demora
Enfermeras
del proyecto departamento
Perfeccionar
Ingeniero Aprobar el Satisfacer las
Administrador las mejoras Alguna falla de
encargado proceso del necesidades del N/A
del sistema requeridas del el programa
del sistema programa departamento
proyecto
Validar el Comprobar el
Aprobar la Fallas de
Supervisor Medico funcionamiento funcionamiento N/A
funcionabilidad diseño
del programa obtenido
Proporcionar
Comprobar la
Dep. los turnos de Fallas de
Planificadores Aprobar la eficacia eficacia del N/A
medico que son registro
programa
establecidos
Aprobar el Proveer buenas
Aprobar el Problemas de
Médicos Usuarios software cosas N/A
software ingreso
elaborado establecidas
1.4. Alcance
El alcance de la ERS comprende la definición de todos los requerimientos
funcionales y los no funcionales, como También otros aspectos que se definen en el
software que emplearemos como el objetivo del software, sus restricciones, los
rasgos que no contempla el software, reglas de negocio, requerimientos de la
interfaz, restricciones del modelo e diseño, la licencia o componentes obtenidos
para el software a desarrollarse, entre otras cosas más que el software tendrá.
2. Presentación del Producto

2.1. Propósito del Sistema
2.1.1. Planteamiento del problema
El Problema del cliente es que necesita organizar las asignaciones de guardias
médicas en las diferentes unidades en lo que afecta seriamente a los asistentes
del departamento médico que laboran hay. El impacto de esto es la gestión de
guardias de médicos correctamente para que los empleados puedan coordinar
sus actividades con el departamento de trabajo y sean más flexible al momento
de sus turnos y actividades que realice dentro y fuera del departamento.
2.1.2. Objetivo
Para el personal administrativo y supervisores del departamento médico ,
quienes registran y realizan actividades que se generan dentro del
departamento medico el sistema de gestión de guardias médicas es una
aplicación que registra las solicitudes de turnos, cambios de guardia, tareas de
alta prioridad y consultas serán directamente en el aplicativo disponible en el
departamento médico, define los turnos establecidos días y horas de turno, la
consulta de esto y si tienen tareas asignadas de gran prioridad lo que también
pueden realizar consultas y cambios de turnos.
2.1.3. Alcance
. Nuestra solución permitirá:
• Que los médicos podrán revisar sus turnos de guardia.
• Si los médicos registrados tendrán actividades de alta prioridad
• El cambio de turno
• Consultar sus turnos
• En lo que compete a los supervisores podrán realizar sus funciones como
ingresos, eliminaciones lógicas y actualización de datos
• La asignación y eliminación de roles
• Actualización cada vez que haiga un cambio
2.1.4. El Sistema no contempla
El sistema no contemplará con requisitos adicionales hasta que el proveedor lo
designe en cuanto al diseño se empleará según el avance que tendrá, pero el
resto de los requerimientos si están dentro de lo ya analizado.
2.2. Riesgos
Estrategia de
Factor de Riesgo Probabilidad Impacto Responsable
mitigación
Informar sobre la
Falta por motivos situación lo más
intrapersonales en plena Media Alto pronto posible con Secretaria
elaboración del proyecto. datos
especificados
Mantener en
Poca comunicación sobre los cordial contexto
días libres que se pueden dar en las Líder de mejoramiento y
Media Alto
momentos de elaboración del especificaciones análisis
producto. dadas y chequeo
de estas.
Coordinar y
mantener un
informe acorde de
Poco interés de centrar las ideas
Alta Alto lo planteado en el Líder de gestión
concretamente.
proyecto como un
respaldo de esto
adicional.
Llevar un informe
acorde de lo
No involucramiento dentro del sucedido dentro
Media Alto Líder de licitación
grupo de trabajo. del proyecto y
cambios que se
realicen en el.
Procurar que el
producto sea
bueno y no posea
Faltos de días dentro de las márgenes de error Líder De verificación y
Media Alto
pruebas del producto. durante su validación
ejecución y
mantener un
informe de este.
Cualquier defecto
encontrado con el
Poca comunicación con el producto software
desarrollador al momento de deberá ser Proveedor del producto
Alta Alta
presentar alguna falla en el reportado de software
software. inmediato con el
desarrollador y el
equipo de trabajo.
3. Descripción General
3.1. Contexto del Producto
A diferencia del proceso llevado a cabo para registrar los turnos y designación
de actividades estos se hacían de manera presencial con el supervisor y
planificador encargado, pero en si no existe un flujo de actividades
debidamente controlado para guardar esa información ahora con la
implementación del aplicativo la eficacia de mantener un registro de las
actividades dentro del departamento sea mas precisa y fiable que pueda hacer
de manera mas amplia lo que trataremos de hacer al designar los turnos y las
actividades designadas para el departamento lleve una buena rentabilidad
dentro de su área de trabajo.
3.2. Perspectivas futuras del producto
Con este producto esperamos poder mejorar el rendimiento dentro de un
departamento y este no tenga complicaciones al momento de ejecutarse como
base de apoyo y los usuarios puedan consultar, modificar e implementar las
necesidades que ellos requieran y sigan el flujo del área de normal donde puedan
mostrar el trabajo dentro del departamento establecido.
3.3. Reglas y Funciones de Negocio

Gestión de turnos
4. Descripción Detallada de Requerimientos

4.1. Requisitos Funcionales
Numero: RF-1
Titulo: Administrador del sistema
Texto: Se codificará un solo usuario administrador, el que asignará
los roles para cada tipo usuario.
Tipo: Funcional
Detalles de El usuario administrador realizara roles como:
requisitos y • Ingresar datos de usuarios.
restricciones: • Asignar roles a los usuarios.
• Asignar guardias.
• Modificar las guardias asignadas.
• Asignaciones de tareas de prioridad como
emergencias, terapia intensiva, cirugía, cuidados
medios.
• Consultar ingresos y salidas del personal
• Consultar las guardias cumplidas
• Consultar el personar operativo
• Consultar los roles de los usuarios.
• (REPORTE DE USUARIOS)
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-2
Titulo: Supervisor de guardias
Texto: El sistema tendrá un tipo de usuario supervisor, que deberá
poder hacer realizar roles como consultar y modificar
Tipo: Funcional – Datos
Detalles de El usuario supervisor deberá realizar los siguientes roles:
requisitos y • Ingresar datos de usuarios.
restricciones: • Asignar guardias.
medios.
• Consultar el personar operativo.

Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-3
Titulo: Planificadores de guardias.
Texto: El sistema tendrá un tipo de usuario planificador, que
deberá asignar a los doctores varias tareas relacionadas a
las guardias, este usuario, solo será uno por especialidad.
Tipo: Funcional
Detalles de El planificador de guardias deberá tener los siguientes
requisitos y roles:
• Asignar guardias.
restricciones:
medios.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-4
Titulo: Botón guardar
Texto: Existirá un botón guardar que aplicará los datos registrados
al sistema
Tipo: Funcional
Detalles de • El botón: Guardar, establecerá los datos
requisitos y registrados.
restricciones: • Al hacer clic en el botón Guardar, aparecerá un
aviso con la pregunta: Desea guardar, ¿Si o No?, y
las opciones Si o No. Si da clic en Si, guardara los
datos.
• Si da clic en No, no guardará los datos y permitirá
seguir editando.
• Estos datos, se actualizarán a todos los usuarios del

sistema.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RF-5
Titulo: Botón modificar
Texto: Existirá un botón que cambiara los datos registrados en el
sistema, por los que se acabaran de registraron es ese
momento.
Tipo: Funcional
Detalles de El botón se llamará: Modificar, este cambiará los datos
requisitos y registrados por los nuevos datos tecleados.
restricciones: Al hacer clic en el botón Modificar, aparecerá un aviso con
la pregunta: Desea modificar, ¿Si o No?, y las opciones: Si o
No.
Si da clic en Si, modificara los datos.
Si da clic en No, no modificará nada y permitirá seguir
modificando.
Estos datos, se actualizarán a todos los usuarios del
sistema.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RF-6
Titulo: Botón cancelar
Texto: Se codificará un botón que anulara los datos que se
estaban llenando en ese instante.
Tipo: Funcional
Detalles de El botón se llamará: Cancelar, este botón apartará los
requisitos y datos de los cambios u asignaciones.
restricciones: Al hacer clic en el botón Modificar, aparecerá un aviso con
la pregunta: Desea Cancelar y volver a la vista anterior, ¿Si
o No?, y las opciones: Si o No.
Si da clic en Si, cancelara los datos y regresar a la vista

anterior.
Si da clic en No, no se cancelará y permitirá seguir
editando.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Baja
Numero: RF-7
Titulo: Botón exportar
Texto: Existirá un botón Exportar, que podrá generará un
documento de Microsoft Excel con el listado de dicha tabla
(ADMINISTRADOR y PLANIFICADOR)
Tipo: Funcional
Detalles de • Al hacer clic en el botón Exportar, aparecerá un
requisitos y aviso con la pregunta: Desea exportar, ¿Si o No?, y
las opciones: Si o No.
restricciones:
• Si da clic en Si, exportara la tabla.
• Si da clic en No, no exportará la tabla y permitirá
continuar consultando.
• El botón generará un documento de tipo: .xls y se
guardará con el nombre del tipo de tabla, como
nombre del documento y la fecha de descarga.
• Se guardará el documento en la carpeta por defecto
del sistema operativo: Descargas.
• Solo estos usuarios tendrán el botón Exportar:
Administrador, Planificador
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RF-8
Titulo: Asignación de guardias
Texto: El sistema permitirá, asignar guardias dependiendo la
especialidad
Tipo: Funcional - Datos
Detalles de El planificador deberá asignar guardias de una especialidad

requisitos y con los siguientes datos:
• Nombres: los nombres y apellidos del doctor,
restricciones:
considerando mayúsculas y minúsculas.
• Especialidad: contendrá la especialidad donde el
empleado está trabajando activamente,
• Cargo: contendrá el tipo de cargo que tiene el
doctor, considerando mayúsculas y minúsculas
• Jornada: asignara la jornada de la guardia
Matutina, Vespertina o Nocturna.
• Horario: asignara el horario en un formato de 24
horas, con el siguiente formato: 12:00 a 19:00
• Fecha de asignación: presentara la fecha de la
asignación con el formato: DD/MM/AA
Tendrá el botón de Guardar que establecerá los cambios.
Cada tipo de dato tendrá un rectángulo para poner teclear
los datos
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-9
Titulo: Modificar los guardias asignados.
Texto: El sistema permitirá modificar las guardias asignadas
Tipo: Funcional
Detalles de El sistema deberá poder modificar cualquier guardia de su
requisitos y especialidad con los siguientes datos:
• Nombres: los nombres y apellidos del doctor,
restricciones:
empleado está trabajando activamente,
doctor, considerando mayúsculas y minúsculas.
• Jornada: asignara la jornada de la guardia
• Horario: asignara el horario en un formato de 24
horas, con el siguiente formato: 12:00 a 19:00

Tendrá el botón de Modificar que establecerá los cambios.
Cada tipo de dato tendrá un rectángulo para poner teclear
los datos.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-10
Titulo: Consultar los ingresos y salidas del personal
Texto: El supervisor deberá hacer consultas de los ingresos a las
guardias y salidas de las guardias
Tipo: Funcional
Detalles de • Se ordenará las consultas en orden ascendente.
requisitos y • Se permitirá consultar por Fecha desde, que será
restricciones: una fecha anterior y Fecha hasta, que será una
fecha posterior hasta la actual.
• Agregara un comboBox donde estarán todos los
índices, donde al seleccionar uno, solo permitirá
buscar por el índice seleccionado con una barra
para la escritura de la consulta
El sistema deberá presentar en forma de tabla con los
siguientes índices:
• Nombres: presentara los nombres y apellidos del
doctor
empleado está trabajando activamente.
• Jornada: presentara la jornada de la guardia
• Horario: presentara el horario en un formato de 24
horas de la siguiente forma: 12:00 a 19:00
• Hora de entrada: la hora de entrada de un doctor a
la guardia en formato de 24 horas
• Hora de salida: la hora que termina un doctor a la
guardia en formato de 24 horas
• Tendrá el botón Exportar que guardará la tabla en

un archivo.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Hacer una integracion con recursos humanos que tiene el reloj biometrico
Numero: RF-11
Titulo: Consultar las guardias complidas
Texto: El supervisor deberá hacer consultas de las guardias
cumplidas e incumplidas con un día de retraso
requisitos y • Las consultas se presentarán con un día de retraso,
restricciones: es decir, solo presentaran las consultas desde el día
anterior.
índices, donde al seleccionar uno, solo permitirá
para la escritura de la consulta
doctor
matutina, vespertina y nocturna.
• Cumplido: presentara un visto si y solo si la guardia
ha sido cumplida en su totalidad, ósea con la hora
de entrada y la hora de salida cumplidas. De lo
contrario el recuadro estará vacío.
un archivo.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-12
Titulo: Consultar el personal operativo
Texto: Se codificará consultas del todo el personal operativo del
hospital.
requisitos y • Agregara un comboBox donde estarán todos los
restricciones: índices, donde al seleccionar uno, solo permitirá
para la escritura de la consulta.
doctor
• Cedula: presentara únicamente el número de cedula
un archivo.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
Numero: RF-13
Titulo: Consultar roles de los usuarios
Texto: Se presentará una tabla para consultar cada rol que hay en
el sistema y los usuarios que existen en el sistema

requisitos y Se presentará una matriz con los ejes X, Y.
restricciones: Se presentará en los índices del eje X:
• Ingresar de datos
• Asignar guardias
• Modificar guardias
• Ingresos y salidas
• Guardias cumplidas
• Personal operativo
• Creación de usuarios
Se presentará en los índices del eje Y:

doctor.
• Cedula: presenta únicamente el número de cedula.

índices de eje Y, donde al seleccionar uno, solo
permitirá buscar por el índice seleccionado con una
barra para la escritura de la consulta.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RN- 14
Titulo: Datos de los doctores
Texto: El sistema debe saber los datos de los doctores,
también sus funciones en el hospital
Detalles de El sistema debe saber:
requisitos y • El nombre de los doctores del hospital, tipo
restricciones: cadena de máximo 38 caracteres incluyendo
mayúsculas, minúsculas y espacios.
• El rol de cada doctor, tipo cadena de
máximo 25 caracteres incluyendo
• La especialidad de cada doctor, tipo cadena

de máximo 17 caracteres incluyendo
• La fecha de guardias de los doctores será
tipo fecha de máximo 10 caracteres con el
formato: DD/MM/AA.
• La hora será de tipo cadena de máximo 5
caracteres. En el formato de 24 horas, que
solo contenga números e incluyendo los dos
puntos (:).
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Alta
4.2. Requisitos no Funcionales

Numero: RN- 1
Titulo: Facilidad de uso
Texto: El sistema estará construido de manera que las nuevas
actualizaciones, funcionalidades y requerimientos
relacionados que puedan ser incorporados sin afectar el
código existente.
Tipo: No functional
Detalles de El sistema deberá permitir el uso:
requisitos y • 1 mouse
restricciones: • 1 teclado
• Reutilizacion possible de Código
• Alerta de cambios en el programa
• Lista de actualizaciones
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RN- 2
Titulo: Facilidad en control de pruebas e rendimiento
Texto: El sistema constara con facilidad para poder identificar y

localizar errores durante su uso e informar el error
encontrado para revisión inmediata.
Tipo: No funcionales
requisitos y • 1 mouse
restricciones: • 1 teclado
• Ordenador
• Lista de operaciones realizada
• Notificacion del error encontrado
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RN- 3
Titulo: Desempeño
Texto: El sistema garantizara la confiabilidad, velocidad y agilidad
del programa requerido
Tipo: No funcional
requisitos y • Garantizara el desempeño, seguridd y confiabilidad
restricciones: • 1 mouse
• 1 teclado
• Lenguaje e idiomas preestablecidos para los
usuarios
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RN- 4
Titulo: Flexibilidad
Texto: El sistema esta diseñado y construido con mayores niveles
de flexibilidad en cuanto a los parámetros de los tipos de
datos integrados este permitirá que los datos administrales
del departamento sea realizada y configurada por uno de
los administradores o el departamento del sistema.
Tipo: No funcional

• 1 teclado
usuarios
• Lista generada de los procesos durante la jornada
laboral
• Ingreso solo del administrador
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
Numero: RN- 5
Titulo: Tamaño, interfaz y operatividad
Texto: El sistema garantizará la confiabilidad, velocidad y agilidad
del programa requerido, su tamaño dependerá sobre el
computador que estará establecido al igual que su interfaz
en caso de su operabilidad será de manera eficiente.
Tipo: No funcional
• 1 teclado
usuarios
• Tipo de computador
• Sistema operativo compatible
• Interfaz ligada al servidor.
Fecha de 14/06/2021
revisión y
versión:
Prioridad: Media
5. Modelo de Casos de Uso.

5.1. Actores.
Número: ACT-#
Actor: <nombre del Actor>
Descripción: <descripción del actor>
Responabilidades: • <Responsabilidad 1>
• <Responsabilidad 2>
Fuentes: <Stakeholders que identificaron y contribuyeron a definir al

actor>
5.2. Diagrama/s de Caso de Uso.

5.3. Listado de Casos de Uso.
5.4. Detalle de Casos de Uso.
6. Modelo de Análisis.
6.1. Modelo del Dominio.
6.2. Diagramas de Secuencia y/o Colaboración.

ID Ref: DG-# donde # debe ser reemplazado por un nº
Descripción: <Título del caso de uso y escenario>
Reqs. asociados:
CU asociados:
Esc. Asociados:
7. Requerimientos de Interfaz.
Se deberán definir todas las interfaces que deberá soportar la aplicación. En lo que
deberá contener una adecuada especificidad, protocolos, puertos, direcciones
lógicas, entre otras más, tal que el producto software pueda ser desarrollado y
verificado contra los estándares de requerimientos establecidos por el cliente.
7.1. Interfaces con el Usuario.
ID Ref: INT – 01
Descripción: Inicio de sesión

Reqs. asociados: RF-
CU asociados:
Esc. Asociados:
ID Ref: INT - 02
Descripción: Consultar Turno
CU asociados:
Esc. Asociados:
ID Ref: INT – 03
Descripción: Consultar Actividades de AP
CU asociados:
Esc. Asociados:
7.2. Interfaces de Hardware.

<Define cualquier interfaz de hardware que deberá ser soportada por el software,
incluyendo estructura lógica, direcciones físicas y comportamiento esperado. Es decir,
aquí se debe especificar las características lógicas de cada interfaz entre el producto del
software y los componentes del hardware del sistema. Esto incluye las características de la
configuración (el número de puertos, la instrucción set, etc.), también cubre como qué
dispositivos serán apoyados, cómo ellos serán apoyados y protocolos. Por ejemplo, el
apoyo de las terminales puede especificarse cuando tienen full-screen>
7.3. Interfaces de Software.

ID Ref: INT - 01
Descripción: Asignación de turnos
CU asociados:
Esc. Asociados:
ID Ref: INT - 02
Descripción: Guardar Asignación de Turno
CU asociados:
Esc. Asociados:
ID Ref: INT - 03
Descripción: Revisión de Asignación de Turnos
CU asociados:
Esc. Asociados:
ID Ref: INT - 04
Descripción: Modificar turnos.
CU asociados:
Esc. Asociados:
ID Ref: INT - 05
Descripción: Eliminar Turnos Asignados
CU asociados:
Esc. Asociados:
ID Ref: INT - 06
Descripción: Asignación de Actividades de AP (ALTA PRIORIDAD)
CU asociados:
Esc. Asociados:
7.4. Interfaces de comunicación.

<Describe las interfaces de comunicación u otros requerimientos de restricción o
dispositivos, tales como redes de área local o dispositivos seriales remotos>.
8. Matriz de Trazabilidad.
8.1. Trazabilidad de requisitos.
Req.id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 X X
1.2 X X X
1.3 X X
2.1 X X X
2.2 X
2.3 X X
3.1 X
3.2 X
8.2. Trazabilidad de Casos de Uso.

CU 1 2 3 4 5 6 7 8
Req.id
1.1 X X
1.2 X X X
1.3 X X
2.1 X X X
2.2 X
2.3 X X
3.1 X
3.2 X
9. Restricciones de Diseño.
Las restricciones de diseño en el sistema del producto software son las que se
representan decisiones de diseño que se deben adherirse en el producto los cuales
constan con los siguientes:
➢ Lenguajes de software,
➢ Requerimientos del proceso de software,
➢ Uso prescripto de las herramientas de desarrollo,
➢ Restricciones arquitectónicas y de diseño,
➢ Seguridad
➢ Rendimiento
➢ Tiempo
➢ Usabilidad
➢ Eficacia
10. Requerimientos de Licencia.
Para este producto software en el tema de los requerimientos de la licencia se van a
requerir 1 licencia de software para ejecutarse usando ya sea recursos lógicos para
representar la disponibilidad de las licencias, en lo cual el departamento medico
garantizara el cumplimiento de los requisitos de la licencia para la cual el producto
software funcionara de manera eficaz y buena.
11. Procedimiento de Control de Cambio.

<Esta sección permite establecer el procedimiento de control de cambios. Se deberá
añadir el diagrama de flujo del proceso de gestión de cambios. Pueden valerse del
siguiente ejemplo:>
<Para gestionar los cambios de requerimientos se seguirán los siguientes pasos:
1. Todo requerimiento debe ser conocido, aprobado y enviado por el jefe inmediato
del área antes de realizar su solicitud.
2. Debe ser enviada con la prioridad sugerida, dicha prioridad debe estar enfocada
desde el punto de vista empresarial.
3. Una vez me hagan llegar el requerimiento, será canalizada a mi equipo de trabajo
para ser evaluada. Posteriormente solicitaremos una reunión con todo el equipo
funcional y técnico relacionado en torno al requerimiento, para complementar
información funcional y específica de la solicitud (Validar del alcance del
requerimiento)
4. Dpto. Tecnología realizará un análisis y presentará una propuesta de solución la
misma que será validada y aprobada por el jefe y/o jefes relacionados con el
requerimiento.
5. Se realizarán reuniones con las jefaturas para informar del estado de avances de
los requerimientos, del manejo de prioridades y fechas de entrega.>
Diagrama de flujo de la gestión de cambios en los requisitos
12. Observaciones.
<Esta sección permite incorporar cualquier información que se considera de
importancia, que no haya sido especificada con anterioridad>

Frpb-Ir-Plantilla-Especificacion-De-Requerimiento (Grupo C)

Cargado por

Información del documento

Descripción original:

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-Ir-Plantilla-Especificacion-De-Requerimiento (Grupo C)

Cargado por

Copyright:

Formatos disponibles

Proyecto: GESTION DE GUARDIAS DE MEDICOS

Versión Producto: 1.1 Cliente: 0001

1.2. Definiciones, Acrónimos y Abreviaturas

Se refiere a la acción que

2. Presentación del Producto

3.3. Reglas y Funciones de Negocio

4. Descripción Detallada de Requerimientos

• Consultar el personar operativo.

• Estos datos, se actualizarán a todos los usuarios del

Si da clic en Si, cancelara los datos y regresar a la vista

Detalles de El planificador deberá asignar guardias de una especialidad

• Fecha de asignación: presentara la fecha de la

• Tendrá el botón Exportar que guardará la tabla en

Detalles de • Se ordenará las consultas en orden ascendente.

Se presentará en los índices del eje Y:

• Agregara un comboBox donde estarán todos los

• La especialidad de cada doctor, tipo cadena

4.2. Requisitos no Funcionales

Texto: El sistema constara con facilidad para poder identificar y

Detalles de El sistema deberá permitir el uso:

5. Modelo de Casos de Uso.

Actor: <nombre del Actor>

Descripción: <descripción del actor>

Responabilidades: • <Responsabilidad 1>

Fuentes: <Stakeholders que identificaron y contribuyeron a definir al

5.2. Diagrama/s de Caso de Uso.

6.2. Diagramas de Secuencia y/o Colaboración.

Descripción: <Título del caso de uso y escenario>

Descripción: Inicio de sesión

Reqs. asociados: RF-

Descripción: Consultar Turno

Reqs. asociados: RF-

Descripción: Consultar Actividades de AP

Reqs. asociados: RF-

7.2. Interfaces de Hardware.

7.3. Interfaces de Software.

Descripción: Asignación de turnos

Reqs. asociados: RF-

Descripción: Guardar Asignación de Turno

Reqs. asociados: RF-

Descripción: Revisión de Asignación de Turnos

Reqs. asociados: RF-

Descripción: Modificar turnos.

Reqs. asociados: RF-

Descripción: Eliminar Turnos Asignados

Reqs. asociados: RF-

Descripción: Asignación de Actividades de AP (ALTA PRIORIDAD)

Reqs. asociados: RF-

7.4. Interfaces de comunicación.

8.2. Trazabilidad de Casos de Uso.

11. Procedimiento de Control de Cambio.

Diagrama de flujo de la gestión de cambios en los requisitos

También podría gustarte