Documento de requerimientos de software

“Diseño y Desarrollo del Sistema Integral del Hospital de Tetela de Ocampo” (SIHTO)

Fecha: 18 /08/2023

TABLA DE CONTENIDO

DESCRIPCIÓN DEL PROYECTO........................................................................................................................................ 2

LISTA DE USUARIOS.......................................................................................................................................................... 4

REQUERIMIENTOS FUNCIONALES (CLIENTE)................................................................................................................. 4

NOMBRE DE LA FUNCIONALIDAD 1................................................................................................................................................4

NOMBRE DE LA FUNCIONALIDAD 2................................................................................................................................................6

NOMBRE DE LA FUNCIONALIDAD 3................................................................................................................................................6

REQUERIMIENTOS NO FUNCIONALES (SISTEMA).......................................................................................................... 6

OTROS................................................................................................................................................................................. 6

ANÁLISIS COSTO-BENEFICIO.........................................................................................................................................................6

RESTRICCIONES..........................................................................................................................................................................7

CONTRATO.................................................................................................................................................................................8
CRONOGRAMA............................................................................................................................................................................9

DIAGRAMAS UML......................................................................................................................................................................10

Casos de uso..................................................................................................................................................................... 11

Escenarios de caso de uso................................................................................................................................................. 11

Diagrama de actividades.................................................................................................................................................... 11

Diagrama secuencial.......................................................................................................................................................... 11

Diagrama de clase.............................................................................................................................................................. 11

Historial de Versiones
Fecha Versión Autor Organización Descripción

19/08/2023 VR1 Luis Daniel Ceballos Rendon Desarrolladora de

Software “PHANTOM”
S.A. de C.V.

Información general

Empresa / Organización Hospital Regional Tetela de Ocampo

Proyecto
Diseño y Desarrollo del Sistema Integral del Hospital de

Tetela de Ocampo” (SIHTO)

Fecha de preparación

Cliente Director General del Hospital Dr. Erick López Cancino

Gerente / Líder de Proyecto Luis Daniel Ceballos Rendon

Gerente / Líder de Análisis de negocio y Sakura Ceballos Lopez

requerimientos

Aprobaciones

Nombre y Apellido Cargo Departamento u Organización Fecha Firma

Dr. Erick López Cancino Director General Dirección Medica 19/08/2023

 Lic. Silvia Maria Mendoza Enfermera Especialista Dirección de Enfermería 19/08/2023

Ing. Arturo Ceballos Encargado de farmacia Área de Farmacia 19/08/2023

LAE. Irene Cancino Directora de Recursos Área 19/08/2023

Humanos Administrativa

Luis Daniel Ceballos Representante legal Desarrolladora de Software 19/08/2023

Rendon “PHANTOM” S.A. de C.V.

Descripción del proyecto

El sistema Integral del Hospital de Tetela de Ocampo” (SIHTO), versión 0.1, tiene como finalidad optimizar los recursos humanos,
medicamentos, pacientes y el manejo de la agenda, derivado del crecimiento se ha visto en los últimos años, motivo por el cual la Directiva del
Hospital Regional Tetela de Ocampo se ha visto en la necesidad de solicitar se desarrolle un sistema orientado a objetos.
Así mismo el sistema a desarrollar tendrá las funciones de administración de personal que labora dentro del nosocomio, el manejo y administración
adecuada de la farmacia, la administración y control de pacientes, así como el manejo de la agenda.

En esta sección se define el nombre o título del software que se está especificado en el documento, incluyendo su número de versión o
Release.
El sistema Atila ver. 0.1, tiene el propósito de solucionar la problemática de …
Luego se describe cuales componentes o partes del alcance del producto están incluidas en el documento, estableciendo si este documento
cubre la totalidad del software, sólo una parte del sistema, subsistema o subgrupo de procesos.
El sistema abarca los módulos:
1.- Control de personal
2.- Administración de la farmacia
3. Control de pacientes
4. Agenda

Lista de usuarios  identificados

Nombre y Apellidos Tipo usuario Descripción Permisos/Acceso

Dr. Erick López Cancino Administrador Tendrá acceso a todo el sistema Completos

Lic. Silvia Maria Mendoza Administrador El usuario Podrá tener acceso al Completos
Control de pacientes y la agenda

Ing. Arturo Ceballos Administrador El usuario tendrá acceso a la Completos

administración de farmacia

LAE. Irene Cancino Administrador El usuario tendrá acceso al Completos

control de personal

Dulce Maria Rendon Operador El usuario podrá realizar las Limitado

funciones de registro de
pacientes, programación de
citas, facturación, gestión de
registros médicos
 Alejandro Mckineley Operador Limitados

El usuario podra gestionar y

dispensar medicamentos

Requerimientos funcionales (cliente)

Los requerimientos funcionales de un sistema son aquellos que describen cualquier actividad que este deba realizar, en otras palabras, el
comportamiento o función particular de un sistema o software cuando se cumplen ciertas condiciones.
En esta sección de la plantilla, se ilustra como organizar los requerimientos funcionales de software por funcionalidad de producto o sistema.
Aquí se listan las funcionalidades y para cada una a su vez se listan los requerimientos funcionales.
Ejemplo de como se muestra como documentar cada funcionalidad:

Nombre de la funcionalidad 1

En el título de la funcionalidad, se recomienda utilizar nombres lo más descriptivo posible para cada funcionalidad. No limitarse a nombrarlas
“Funcionalidad 1”. Un buen ejemplo podría ser :
Autorización de pedido de compra

Descripción: Descripción corta de la funcionalidad.

La funcionalidad de Autorización de pedido de compra permite a los usuarios autorizar o rechazar un pedido de compra que ha sido creado por
otro usuario.

Prioridad: Nivel bajo, medio o alto de prioridad. Esta debe ser establecida por el área funcional.

Prioridad: Alta

Acciones iniciadoras y comportamiento esperado: Secuencia de acciones de usuario y respuestas esperadas del sistema para esta
funcionalidad.

1. El usuario ingresa al sistema y selecciona la opción de "Autorización de pedido de compra".

2. El sistema muestra una lista de los pedidos de compra pendientes de autorización.
3. El usuario selecciona el pedido de compra que desea autorizar o rechazar.
4. El sistema muestra los detalles del pedido de compra seleccionado, incluyendo la información del proveedor, los artículos
comprados y el monto total.
5. El usuario revisa la información y decide si autoriza o rechaza el pedido.
6. Si el usuario decide autorizar el pedido, el sistema actualiza el estado del pedido a "Autorizado" y envía una notificación al usuario
que lo creó.
7. Si el usuario decide rechazar el pedido, el sistema actualiza el estado del pedido a "Rechazado" y envía una notificación al usuario
que lo creó.

Requerimientos funcionales: Lista detallada de los requerimientos funcionales asociados a esta funcionalidad. Cada requerimiento debe ser
identificado unívocamente, para lo cual se recomienda usar un número de secuencia, que tenga algún significado y de formato común a toda
la organización. Por ejemplo:

REQ-1: El sistema debe permitir a los usuarios con permisos de autorización acceder a la funcionalidad de Autorización de pedido de compra.
REQ-2: El sistema debe mostrar una lista de los pedidos de compra pendientes de autorización, incluyendo la información del proveedor, los
artículos comprados y el monto total.

REQ-3: El sistema debe permitir a los usuarios seleccionar un pedido de compra y ver sus detalles.

Para cada requerimiento funcional se establece como debe mostrarse el software y cuales comportamientos debe desempeñar para que el
usuario pueda realizar la función que necesita.
Respuestas esperadas del sistema:

Mostrar una lista de los pedidos de compra pendientes de autorización.

Mostrar los detalles del pedido de compra seleccionado.
Actualizar el estado del pedido a "Autorizado" o "Rechazado".
Enviar una notificación al usuario que creó el pedido.

Nombre de la funcionalidad 2

Nombre de la funcionalidad 3

Requerimientos no funcionales (Sistema)

Listado de reglas y principios que aplican a todo el conjunto de requerimientos de software contenidos en el documento.

Requerimientos no funcionales:

1. El sistema debe ser seguro y proteger los datos de los usuarios contra accesos no autorizados.

2. El sistema debe ser fácil de usar y tener una interfaz intuitiva para los usuarios.

3. El sistema debe ser escalable y capaz de manejar un alto volumen de transacciones.

4. El sistema debe ser compatible con diferentes navegadores web y dispositivos móviles.

5. El sistema debe cumplir con los estándares de accesibilidad web para usuarios con discapacidades.

6. El sistema debe tener una disponibilidad del 99% y ser capaz de recuperarse rápidamente en caso de fallas.

7. Solo los usuarios con permisos adecuados deben tener acceso a funciones críticas del sistema, como la autorización de pedidos

de compra.

8. El sistema debe cumplir con las leyes y regulaciones aplicables, como la protección de datos personales y la privacidad del

usuario.

9. El sistema debe tener un rendimiento óptimo y tiempos de respuesta rápidos para una experiencia de usuario satisfactoria.

Otros

Análisis costo-beneficio
Para implementar la funcionalidad de Autorización de pedido de compra, se requerirá una inversión en recursos y tiempo. Se estima que el
costo total del proyecto será de $50,000. A continuación, se describen los beneficios esperados:

Ahorro de tiempo: Se espera que la funcionalidad de Autorización de pedido de compra ahorre tiempo a los usuarios al permitirles autorizar o
rechazar pedidos de compra de manera más eficiente. Se estima que esto generará un ahorro de tiempo anual de 500 horas, lo que equivale a
$10,000 en costos laborales.

Reducción de errores: Al permitir a los usuarios revisar y autorizar pedidos de compra, se espera que la funcionalidad reduzca los errores en el
proceso de compras. Se estima que esto generará un ahorro anual de $5,000 en costos por errores.

Mayor visibilidad: La funcionalidad de Autorización de pedido de compra proporcionará una mayor visibilidad del proceso de compras y
permitirá a los gerentes tomar decisiones más informadas. Se espera que esto genere un beneficio anual de $7,500 en mejores decisiones
comerciales.

Por lo tanto, el beneficio total anual esperado es de $22,500. Si se divide este beneficio por el costo total del proyecto, se obtiene un índice de
costo-beneficio (BCR) de 0.45. Esto indica que el proyecto tiene un retorno esperado menor al costo total y puede no ser rentable en términos
financieros. Sin embargo, se deben considerar otros factores, como los beneficios no financieros y la importancia estratégica del proyecto para
la organización.

Restricciones

1. La funcionalidad de Autorización de pedido de compra solo estará disponible para usuarios con permisos específicos y autorizados
por la organización.
2. Los usuarios solo podrán autorizar o rechazar pedidos de compra que estén pendientes de autorización y que hayan sido creados
por otros usuarios.
3. Los usuarios no podrán modificar los detalles del pedido de compra, solo podrán autorizar o rechazar el pedido tal como se
presentó.
4. La funcionalidad de Autorización de pedido de compra solo estará disponible durante las horas laborables y días hábiles de la
organización.
5. El sistema debe cumplir con las políticas y regulaciones internas y externas de la organización, como la política de privacidad y
protección de datos personales.
6. El sistema debe tener medidas de seguridad adecuadas para proteger los datos del usuario y prevenir accesos no autorizados.
7. El sistema debe tener un registro de auditoría para rastrear las acciones realizadas por los usuarios en la funcionalidad de
Autorización de pedido de compra.

Contrato

Contrato de software

Este contrato de software (en adelante, el "Contrato") se establece entre la empresa [nombre de la empresa] (en adelante, "Licenciante") y el
usuario final (en adelante, "Licenciatario") para el uso del software [nombre del software] (en adelante, el "Software").
Licencia de uso: Licenciante otorga al Licenciatario una licencia no exclusiva e intransferible para utilizar el Software en un solo dispositivo. El
Licenciatario no podrá vender, alquilar, sublicenciar o transferir la licencia a terceros.

Propiedad intelectual: El Software es propiedad exclusiva de Licenciante y está protegido por las leyes de propiedad intelectual. El
Licenciatario no podrá modificar, copiar, distribuir o reproducir el Software sin el consentimiento previo y por escrito de Licenciante.

Soporte técnico: Licenciante proporcionará soporte técnico al Licenciatario durante el período de vigencia del Contrato.

Actualizaciones: Licenciante proporcionará actualizaciones del Software al Licenciatario durante el período de vigencia del Contrato.

Confidencialidad: El Licenciatario se compromete a mantener la confidencialidad del Software y no divulgar su contenido a terceros.

Responsabilidad: Licenciante no será responsable por daños directos o indirectos causados por el uso del Software. El Licenciatario acepta
utilizar el Software bajo su propio riesgo.

Duración: El Contrato tendrá una duración de [plazo] años a partir de la fecha de firma.

Terminación: El Contrato podrá ser terminado por cualquiera de las partes mediante notificación por escrito con [plazo] días de anticipación.

Ley aplicable: El Contrato se regirá e interpretará de acuerdo con las leyes del país de residencia de Licenciante.

Al aceptar este contrato, el Licenciatario reconoce haber leído y entendido los términos y condiciones establecidos en el mismo.

Cronograma

Actividad Duración estimada Fecha de inicio Fecha de finalización

Análisis de requerimientos 4 semanas 2023-08-01 2023-08-31

Diseño del software 6 semanas 2023-09-01 2023-10-15

 Desarrollo del software 10 semanas 2023-10-16 2023-12-31

Pruebas del software 4 semanas 2024-01-01 2024-01-31

Implementación del software 2 semanas 2024-02-01 2024-02-14

Capacitación y documentación 2 semanas 2024-02-15 2024-02-28

Evaluación y ajustes finales 2 semanas 2024-03-01 2024-03-14

Este cronograma de proyecto de software tiene una duración total de 32 semanas, comenzando en agosto de 2023 y finalizando en marzo de
2024. El análisis de requerimientos y el diseño del software son las fases iniciales del proyecto y se llevarán a cabo durante un total de 10
semanas. A continuación, se realizará el desarrollo del software, que tomará un total de 10 semanas. Las pruebas del software se realizarán
durante un período de cuatro semanas para garantizar que el software sea estable y funcione correctamente. La implementación del software
se llevará a cabo durante dos semanas, seguida de dos semanas para la capacitación y documentación. Finalmente, se llevará a cabo una
evaluación y ajustes finales durante dos semanas antes de la finalización del proyecto.

Diagramas UML
Casos de uso

Escenarios de caso de uso

Diagrama de actividades

Diagrama secuencial

Diagrama de clase

Diagrama de gráfico de estado