Ingenieria de Requisitos Plantilla

SISTEMA DE GESTIÓN Y ADMINISTRACIÓN DE
DISPONIBILIDAD INTELIGENTE
Especificación de Requisitos
Versión: 0100
Fecha: 19/02/2024
[Versión 1.0]
Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación
pública y/o transformación tal o parcial, por cualquier medio, de este documento sin el previo
consentimiento expreso y por escrito de la Junta de Andalucía.
<Nombre Proyecto>
<Unidad Organizativa>
HOJA DE CONTROL
Organismo Universidad Politécnica de Texcoco

Proyecto SISTEMA DE GESTION Y ADMINISTRACION DE DISPONIBILIDAD INTELIGENTE
Entregable 1
Carventes Garduño Alan Daniel
De Hilario Angeles Daniela Michell
Juárez Coria Manuel de Jesús
Autores
Leal Sánchez Juan Marcos
López Serrano Esmeralda
Gomez Garcia Santiago
Versión/Edición 0100 Fecha Versión 19/02/2024
Aprobado por Juan José Cruz Cortés Fecha Aprobación DD/MM/AAAA
Nº Total de Páginas 32
REGISTRO DE CAMBIOS
Versión Causa del Cambio Responsable del Cambio Fecha del Cambio
0100 Versión inicial Juan Marcos Leal Sanchez 19/02/2024
CONTROL DE DISTRIBUCIÓN
Nombre y Apellidos
Alan Daniel Carventes Garduño
Daniela Michell de Hilario Angeles
Manuel de Jesús Juárez Coria
Juan Marcos Leal Sánchez
Esmeralda López Serrano
Página 2 de 32
<Nombre Proyecto>
ÍNDICE
1 INTRODUCCIÓN..................................................................................................................................................... 5
1.1 Alcance .......................................................................................................................................................... 5
1.2 Objetivos........................................................................................................................................................ 5
2 INFORMACIÓN DEL DOMINIO DEL PROBLEMA .................................................................................................... 6
2.1 Introducción al Dominio del Problema ......................................................................................................... 6
2.2 Glosario de Términos ..................................................................................................................................... 6
3 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL [OPCIONAL] ......................................................................................... 7
3.1 Pros y Contras de la Situación Actual ............................................................................................................ 7
3.1.1 Fortalezas de la Situación Actual .......................................................................................................... 7
3.1.2 Debilidades de la Situación Actual........................................................................................................ 8
3.2 Modelos de Procesos de Negocio Actuales .................................................................................................. 8
3.2.1 Descripción de los Actores de Negocio Actuales .................................................................................. 8
3.2.2 Descripción de Procesos de Negocio Actuales ..................................................................................... 9
3.3 Entorno Tecnológico Actual ......................................................................................................................... 10
3.3.1 Descripción del Entorno de Hardware Actual .................................................................................... 10
3.3.2 Descripción del Entorno de Software Actual ...................................................................................... 10
4 NECESIDADES DE NEGOCIO................................................................................................................................. 11
4.1 Objetivos de Negocio .................................................................................................................................. 11
4.2 Modelos de Procesos de Negocio a Implantar [Opcional] .......................................................................... 12
4.2.1 Descripción de los Actores de Negocio a Implantar ........................................................................... 12
4.2.2 Descripción de Procesos de Negocio a Implantar .............................................................................. 12
5 DESCRIPCIÓN DE LOS SUBSISTEMAS DEL SISTEMA A DESARROLLAR [OPCIONAL] ............................................. 14
6 CATÁLOGO DE REQUISITOS DEL SISTEMA A DESARROLLAR................................................................................ 15
6.1 Requisitos Generales del Sistema................................................................................................................ 15
6.2 Casos de uso del Sistema ............................................................................................................................ 16
6.2.1 Diagramas de Casos de Uso del Sistema ............................................................................................ 16
6.2.2 Especificación de Actores del Sistema ................................................................................................ 17
6.2.3 Especificación de Casos de Uso del Sistema ....................................................................................... 18
6.3 Requisitos Funcionales del Sistema............................................................................................................. 21
6.3.1 Requisitos de Información del Sistema............................................................................................... 21
6.3.2 Requisitos de Reglas de Negocio del Sistema ..................................................................................... 22
6.3.3 Requisitos de Conducta del Sistema ................................................................................................... 23
6.4 Requisitos No Funcionales del Sistema ....................................................................................................... 24
6.4.1 Requisitos de Fiabilidad ...................................................................................................................... 25
6.4.2 Requisitos de Usabilidad ..................................................................................................................... 25
6.4.3 Requisitos de Eficiencia ...................................................................................................................... 25
6.4.4 Requisitos de Mantenibilidad ............................................................................................................. 26
6.4.5 Requisitos de Portabilidad .................................................................................................................. 26
Página 3 de 32
<Nombre Proyecto>
6.4.6 Requisitos de Seguridad ..................................................................................................................... 26

6.4.7 Otros Requisitos No Funcionales ........................................................................................................ 26
6.5 Restricciones Técnicas del Sistema .............................................................................................................. 27
6.6 Requisitos de Integración del Sistema......................................................................................................... 27
6.7 Información Sobre Trazabilidad ................................................................................................................... 28
7 ANEXOS [OPCIONAL] ........................................................................................................................................... 29
7.1 Anexo A: Actas de Reuniones ...................................................................................................................... 29
7.2 Anexo B: Documentación Relevante ........................................................................................................... 29
7.3 Anexo C: Glosario de Acrónimos y Abreviaturas ......................................................................................... 29
Página 4 de 32
<Nombre Proyecto>
1 INTRODUCCIÓN
En el contexto actual de la creciente complejidad y demanda en diversas industrias del área de la

salud, la eficiente gestión de recursos y la optimización de la disponibilidad se han vuelto factores
determinantes para el éxito organizacional. "Es importante crear un sistema inteligente que maneje
eficientemente estos retos mencionados, de manera completa y anticipada".
Este sistema se propone como una solución para optimizar la asignación de recursos, es decir, para
asegurarse de que los recursos disponibles tengan el mejor uso posible. Además, ayudará a
programar actividades de manera efectiva y garantizar que los medios estén disponibles cuando se
necesiten, incluso en entornos que cambian rápidamente. Esto se logra mediante la integración de
tecnologías de vanguardia como la inteligencia artificial, el análisis predictivo y el aprendizaje
automático.
Entre las principales características y funcionalidades del sistema se incluyen el análisis predictivo, la
optimización de recursos, la automatización de procesos, una interfaz intuitiva, así como
personalizable y la monitorización en tiempo real.
El desarrollo y uso de este sistema ofrece una oportunidad para que las operaciones sean más
eficientes y competitivas, y abre la puerta a nuevas ideas y oportunidades en un mundo que está en
constante cambio.
1.1 Alcance
El alcance de un sistema de gestión y administración de disponibilidad inteligente es amplio y diverso,

ya que tiene un impacto significativo en múltiples aspectos. Consiste principalmente en dar la
eficiencia al garantizar un mejor uso de los recursos disponibles, lo que aumenta la disponibilidad de
servicios y mejora la experiencia del usuario contribuyendo a la reducción de costos al optimizar la
asignación de recursos.
Mejora de la eficiencia operativa: Un sistema de gestión y administración de disponibilidad
Página 5 de 32
<Nombre Proyecto>
inteligente puede optimizar los procesos y recursos, reduciendo los tiempos de inactividad y
aumentando la productividad.
Aumento de la disponibilidad de servicios: Al prever y evitar posibles problemas, este tipo de

sistemas puede garantizar una mayor disponibilidad de servicios y aplicaciones críticas para el
negocio.
Reducción de costos: Al minimizar los tiempos de inactividad y maximizar la eficiencia, un sistema de

gestión y administración de disponibilidad inteligente puede ayudar a reducir los costos operativos.
Mejora de la experiencia del usuario: Al garantizar una mayor disponibilidad y rendimiento de los
servicios, estos sistemas pueden mejorar la experiencia del usuario final.
Gestión proactiva de riesgos: Al identificar y mitigar posibles problemas antes de que ocurran, estos
sistemas pueden ayudar a reducir los riesgos asociados con la interrupción de servicios críticos.
Automatización de tareas: Un sistema de gestión y administración de disponibilidad inteligente

puede automatizar muchas tareas de monitoreo y gestión, liberando recursos humanos para otras
actividades más estratégicas.
El desarrollo de un sistema de gestión y administración de disponibilidad inteligente puede verse

afectado por varios elementos organizativos, que incluyen:
Cultura Organizacional: La cultura de la organización puede influir en la adopción y el éxito del

sistema. Si la organización valora la innovación, la eficiencia y la mejora continua, es más probable
que el sistema tenga éxito.
Recursos Humanos: La disponibilidad de personal capacitado y con experiencia en áreas como la

gestión de sistemas, la inteligencia artificial, el análisis de datos y la ciberseguridad es esencial para el
desarrollo y la implementación exitosa del sistema.
Estructura Organizacional: La estructura de la organización, incluyendo cómo se dividen las

responsabilidades y cómo se toman las decisiones, puede afectar la forma en que se desarrolla y se
implementa el sistema.
Políticas y Procedimientos: Las políticas y procedimientos existentes de la organización pueden

influir en el diseño y la implementación del sistema. Por ejemplo, las políticas de seguridad de la
información pueden afectar cómo se protegen los datos en el sistema.
Ciclo de Vida del Desarrollo de Software: El desarrollo de un sistema de gestión y administración de
Página 6 de 32
<Nombre Proyecto>
disponibilidad inteligente seguirá un ciclo de vida de desarrollo de software, que incluye etapas como
la planificación, el diseño, la implementación, las pruebas y el mantenimiento. Cada etapa puede
verse afectada por factores organizativos.
Gestión del Cambio: La capacidad de la organización para gestionar el cambio y la adopción de

nuevas tecnologías puede influir en el éxito del sistema. Esto incluye la capacitación del personal, la
comunicación efectiva y la gestión de la resistencia al cambio.
Gestión de Proyectos: La gestión efectiva del proyecto, incluyendo la definición clara de los objetivos
y requisitos, la asignación adecuada de recursos, la gestión de riesgos y la comunicación con los
interesados, es esencial para el desarrollo exitoso del sistema.
El desarrollo de un sistema de gestión y administración de disponibilidad inteligente puede verse

afectado por una variedad de factores organizativos, incluyendo la cultura, los recursos humanos, la
estructura, las políticas y procedimientos, el ciclo de vida del desarrollo de software, la gestión del
cambio y la gestión de proyectos.
1.2 Objetivos
OBJETIVO GENERAL: Desarrollar un sistema de gestión y administración para la disponibilidad de
servicios en una organización.
OBJETIVOS ESPECIFICOS:
Optimizar la utilización de recursos: Un SGADI para el área de salud puede ayudar a optimizar la
utilización de recursos, como servidores, almacenamiento y ancho de banda, para garantizar una
mayor disponibilidad de los sistemas y servicios.
Automatizar tareas de monitoreo y gestión: Un SGADI para el área de salud puede automatizar
muchas tareas de monitoreo y gestión, liberando recursos humanos para otras actividades más
estratégicas.
Proporcionar información y análisis en tiempo real: Un SGADI para el área de salud puede
proporcionar información y análisis en tiempo real sobre el estado de los sistemas y servicios,
permitiendo una toma de decisiones más informada y rápida.
Mejorar la experiencia del usuario: Un SGAI para el área de salud puede mejorar la experiencia del
usuario final al garantizar una mayor disponibilidad y rendimiento de los servicios.
Página 7 de 32
<Nombre Proyecto>
2 INFORMACIÓN DEL DOMINIO DEL PROBLEMA

En el dominio del problema de un sistema de gestión y administración de disponibilidad inteligente
en un hospital, se encuentran diversos aspectos fundamentales. Esto incluye la gestión eficiente de
recursos hospitalarios, como camas, quirófanos, personal médico y equipos médicos. La demanda
fluctuante de servicios de salud, influenciada por factores estacionales y emergencias repentinas,
también es relevante. La priorización de pacientes según la gravedad de su condición y la
optimización de la eficiencia operativa son objetivos clave. La implementación de tecnologías
emergentes, como el análisis de datos en tiempo real y la inteligencia artificial, juega un papel crucial
en el desarrollo de sistemas inteligentes para esta gestión. Sin embargo, surgen desafíos éticos y
legales, como la privacidad del paciente y la equidad en el acceso a la atención médica. La
colaboración interdisciplinaria entre profesionales de la salud, expertos en tecnología de la
información y administradores hospitalarios es esencial para abordar estos desafíos y desarrollar
soluciones efectivas.
1.3 Introducción al Dominio del Problema

En el ámbito de la salud, la gestión eficiente de la disponibilidad de recursos es crucial para garantizar
la atención óptima a los pacientes. Los hospitales, en particular, enfrentan constantes desafíos para
administrar de manera eficaz sus recursos, como camas, personal médico, equipos y suministros. En
este contexto, la implementación de un sistema de gestión y administración de disponibilidad
inteligente emerge como una solución innovadora y necesaria. Este sistema combina tecnologías
avanzadas, como el análisis de datos en tiempo real, la inteligencia artificial y el aprendizaje
automático, para optimizar la asignación de recursos y mejorar la calidad de la atención al paciente.
En este contexto, exploraremos los fundamentos, beneficios y desafíos asociados con la
implementación de un sistema de este tipo en un entorno hospitalario.
1.4 Glosario de Términos

En el dominio del problema de un sistema de gestión y administración de disponibilidad inteligente
en un hospital, es fundamental comprender varios aspectos clave:
Análisis de datos en tiempo real: El uso de herramientas y tecnologías para recopilar, analizar y
Página 8 de 32
<Nombre Proyecto>
actuar sobre datos en tiempo real, proporcionando información valiosa para la toma de decisiones.
Aspectos Éticos y Legales: La toma de decisiones automatizada y la gestión de datos médicos

sensibles plantean desafíos éticos y legales, como la privacidad del paciente, la equidad en el acceso
a la atención médica y la responsabilidad en la toma de decisiones.
Colaboración Interdisciplinaria: El diseño e implementación de un sistema efectivo requiere la

colaboración entre profesionales de la salud, expertos en tecnología de la información,
administradores hospitalarios y otros actores relevantes.
Demanda de Servicios de Salud: Se refiere a la variabilidad en la demanda de servicios de salud,

que puede ser influenciada por factores estacionales, epidemias, emergencias repentinas, entre
otros.
Eficiencia Operativa: La optimización de la utilización de recursos y la eficiencia operativa son

objetivos clave. Esto implica minimizar los tiempos de espera, evitar la subutilización de recursos y
garantizar una distribución equitativa de los mismos.
Inteligencia artificial y aprendizaje automático: El uso de algoritmos y modelos de inteligencia

artificial para optimizar la asignación de recursos, predecir la demanda futura y mejorar la eficiencia
operativa.
Interoperabilidad de sistemas: La capacidad de diferentes sistemas y dispositivos de compartir y

utilizar datos entre sí de manera efectiva, facilitando la integración y la colaboración en la gestión de
la disponibilidad de recursos.
Planificación de la capacidad: La capacidad de prever y planificar la demanda de servicios de

salud, ajustando la capacidad de los recursos en consecuencia para evitar subutilización o sobrecarga.
Priorización de Pacientes: En función de la gravedad de la enfermedad, el tipo de tratamiento

necesario y otros criterios médicos, es esencial priorizar la asignación de recursos para garantizar que
los pacientes reciban la atención adecuada en el momento adecuado.
Recursos Hospitalarios: Esto incluye camas de hospital, quirófanos, personal médico y de

enfermería, equipos médicos (como ventiladores, monitores, etc.) y suministros (medicamentos,
material quirúrgico, etc.).
Tecnologías Emergentes: La implementación de tecnologías como el análisis de datos en tiempo
Página 9 de 32
<Nombre Proyecto>
real, la inteligencia artificial y el aprendizaje automático son fundamentales para desarrollar sistemas
inteligentes de gestión y administración de disponibilidad en hospitales.
Página 10 de 32
<Nombre Proyecto>
3 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL
1.5 Pros y Contras de la Situación Actual

Pros
Optimización de Recursos: Permite una asignación eficiente de personal, camas y equipos médicos,
asegurando una utilización adecuada de los recursos disponibles.
Mejora en la Atención al Paciente: Facilita la rápida asignación de camas y servicios médicos,

reduciendo tiempos de espera y mejorando la experiencia del paciente.
Prevención de Sobrecargas: Identifica y gestiona la carga de trabajo en tiempo real, evitando la

sobrecarga en áreas específicas del hospital y mejorando la respuesta a emergencias.
Mayor Eficiencia Operativa: Ayuda a minimizar los tiempos de inactividad y a optimizar los procesos
internos, mejorando la eficiencia global del hospital.
Contras
Costos de Implementación: La adopción de tecnologías avanzadas puede implicar inversiones
significativas en hardware, software y capacitación del personal.
Dependencia Tecnológica: La fiabilidad del sistema está sujeta a la tecnología, lo que podría generar
problemas en caso de fallos técnicos o interrupciones.
Resistencia al Cambio: El personal hospitalario puede enfrentar resistencia al cambio al adaptarse a

nuevas tecnologías, lo que podría afectar la eficiencia durante la transición.
Privacidad y Seguridad: La gestión de datos sensibles de pacientes requiere altos estándares de

seguridad para evitar posibles brechas de privacidad y accesos no autorizados.
Posible Complejidad en la Integración: La integración del sistema con otras plataformas y sistemas
existentes en el hospital podría plantear desafíos técnicos y de compatibilidad.
1.5.1 Fortalezas de la Situación Actual

En el ámbito de la salud, la implementación de un sistema de gestión y administración de
disponibilidad inteligente ofrece diversas fortalezas. Esto incluye la eficiente gestión de recursos
hospitalarios, adaptabilidad a la fluctuación de la demanda de servicios de salud y la priorización
efectiva de pacientes según la gravedad de su condición. Además, el sistema optimiza la eficiencia
operativa mediante tecnologías avanzadas como el análisis de datos en tiempo real y la inteligencia
Página 11 de 32
<Nombre Proyecto>
artificial. La colaboración interdisciplinaria entre profesionales de la salud y expertos en tecnología es

esencial para abordar desafíos éticos y legales. En resumen, este enfoque innovador busca mejorar la
calidad de la atención médica a través de soluciones tecnológicas avanzadas.
id 1 Primer version para la documentación
[0.1] <0.1>(<19-02-24>)
Descripción Se recapituló información sobre los antecedentes de este tipo de sistema y se

implementó dentro de la documentación hasta el punto número 3.
Comentarios El documento alcanzo la primera fase de entrega de la documentación para
autorización.
Tabla 1: Fortalezas de la situación actual.
Los atributos entre corchetes son opcionales
1.5.2 Debilidades de la Situación Actual

En el ámbito de un sistema de gestión y administración de disponibilidad inteligente en hospitales, se
presentan desafíos y debilidades importantes. Estos incluyen costos considerables de
implementación, generando presiones financieras. La dependencia tecnológica introduce riesgos de
fallos técnicos, afectando la continuidad de la atención médica. La resistencia al cambio por parte del
personal puede impactar negativamente en la eficiencia durante la transición. Además, los desafíos
éticos y legales, como la privacidad del paciente, plantean preocupaciones significativas. La
complejidad en la integración con sistemas existentes y la necesidad de colaboración
interdisciplinaria añaden capas de dificultad a la implementación exitosa del sistema. Estas
debilidades resaltan la importancia de abordar cuidadosamente estos desafíos para garantizar el
rendimiento efectivo del sistema en el entorno hospitalario.
<id>1 Primer version para la documentación
[0.1] <0.1>(<19-02-24>)
Descripción Se recapituló información sobre los antecedentes de este tipo de sistema y se

implementó dentro de la documentación hasta el punto número 3.
Comentarios El apartado alcanzo los aspectos de la primera fase
Tabla 2: Debilidades de la situación actual.

Página 12 de 32
<Nombre Proyecto>
1.6 Modelos de Procesos de Negocio Actuales

<Introduzca contenido y borre cuadro>
Esta sección debe contener información sobre los modelos de procesos de negocio actuales, que
suelen ser la base de los modelos de procesos de negocio a implantar. Se divide en las secciones
que se describen a continuación.
1.6.1 Descripción de los Actores de Negocio Actuales

<Introduzca contenido, cumplimente tabla y borre cuadro>
Esta sección debe contener información sobre los actores de negocio (organizaciones, roles o
responsabilidades) de los modelos de procesos de negocio actuales especificados mediante las
plantillas para actores del negocio actual que se muestran a continuación.
<id>999 <nombre descriptivo>
[Versión] <nº versión>(<fecha de versión>)
[Dependencias] • <procesos de negocio actuales en los que participa>

• ...
Descripción Este actor de negocio actual representa a <descripción de la organización, rol

o responsabilidad a la que representa el actor de negocio actual>
Comentarios <comentarios adicionales sobre el actor de negocio actual>
Tabla 3: Actores de negocio.

1.6.2 Descripción de Procesos de Negocio Actuales

Esta sección debe contener información sobre los procesos de negocio actuales, tal y como se
realizan en la organización del cliente antes del comienzo del desarrollo del sistema software.
Para cada proceso de negocio se incluirá una descripción textual usando las plantillas para
procesos de negocio actuales que se muestran a continuación, y un diagrama en la notación que
se considere oportuna, por ejemplo diagramas BPMN o diagramas de actividad UML.
Página 13 de 32
<Nombre Proyecto>
[Dependencias] • <procesos de negocio actuales de los que depende>

• ...
Descripción <descripción del proceso de negocio actual en términos del dominio del
problema>
[Importancia] <importancia del proceso de negocio para el cliente>
[Actores] • <actor que participa en el proceso de negocio>

• ...
Comentarios <comentarios adicionales sobre el proceso de negocio actual>
Tabla 4: Procesos de Negocio actuales.

1.7 Entorno Tecnológico Actual

Esta sección debe contener información general sobre el entorno tecnológico en la organización
del cliente antes del comienzo del desarrollo del sistema software, incluyendo hardware, redes,
software, etc. Se prestará especial atención a la arquitectura de servicios ( servicios web SOAP,
REST, buses de servicios, etc.) en funcionamiento o en desarrollo que puedan tener impacto en el
sistema software a desarrollar. El objetivo es ofrecer una visión general, por lo que para los
detalles más técnicos se debe remitir al lector a los documentos técnicos oportunos. Para facilitar
la comprensión, se recomienda el uso de diagramas donde sea posible. Esta sección se divide en
las secciones que se describen a continuación, que pueden fusionarse si se considera oportuno.
1.7.1 Descripción del Entorno de Hardware Actual

Esta sección debe contener información sobre el entorno de hardware actual, incluyendo
servidores, estaciones de trabajo, redes, etc., que pueda tener impacto sobre el sistema software
a desarrollar. Para los detalles más técnicos se debe remitir al lector a los documentos técnicos
oportunos. Para facilitar la comprensión, se recomienda el uso de diagramas donde sea posible.
1.7.2 Descripción del Entorno de Software Actual

Página 14 de 32
<Nombre Proyecto>
Esta sección debe contener información sobre el entorno de software actual, incluyendo sistemas
operativos, sistemas de gestión de bases de datos, servidores de aplicaciones, etc., que pueda
tener impacto sobre el sistema software a desarrollar. Para los detalles más técnicos se debe
remitir al lector a los documentos técnicos oportunos. Para facilitar la comprensión, se
recomienda el uso de diagramas donde sea posible.
Página 15 de 32
<Nombre Proyecto>
2 NECESIDADES DE NEGOCIO
Esta sección obligatoria debe contener información sobre los objetivos de negocio de clientes y
usuarios, incluyendo los modelos de procesos de negocio a implantar. Esta sección se divide en
las secciones que se describen a continuación.
La información de esta sección puede que ya se encuentre total o parcialmente en
documentación previa como el Pliego de Prescripciones Técnicas, la Oferta seleccionada o el
Estudio de Viabilidad del Sistema, en cuyo se podrá reutilizar y se hará referencia a dichos
documentos como fuente de la misma.
2.1 Objetivos de Negocio
Esta sección debe contener los objetivos de negocio que se esperan alcanzar cuando el sistema software a desarrollar esté en
producción, especificados mediante las plantillas de objetivos de negocio que se muestran a continuación. En el caso de que se
considere necesario, los objetivos de negocio se pueden descomponer jerárquicamente para facilitar su comprensión y representar
dicha jerarquía de forma gráfica.
[Dependencias] • <procesos de negocio actuales o a implantar de los que depende>

• <objetivo de negocio padre, si lo tiene>(padre)
• <otros objetivos de negocio de los que depende>
• ...
Descripción <descripción del objetivo de negocio en términos del problema>
Subobjetivos • <objetivos de negocio hijos (subobjetivos), si los tiene>

• ...
[Importancia] <importancia del objetivo de negocio para el cliente>
[Prioridad] <prioridad del objetivo de negocio para la dirección del proyecto>
Comentarios <comentarios adicionales sobre el actor de negocio actual>
Tabla 5: Objetivos de Negocio.

Página 16 de 32
<Nombre Proyecto>
2.2 Modelos de Procesos de Negocio a Implantar [Opcional]

Esta sección opcional, debe contener los modelos de procesos de negocio a implantar, que
normalmente son los modelos de procesos de negocio actuales con ciertas mejoras. Si las
diferencias con los modelos de procesos actuales son pequeñas, se puede optar por describir
únicamente dichas diferencias siempre que se hayan incluido los modelos de procesos actuales
en la sección 3.2.
Esta sección podrá omitirse si se han incluido los modelos de procesos de negocio actuales en la
sección 3.2 y no se van a introducir cambios significativos en dichos modelos. En cualquier otra
situación, esta sección debe considerarse como obligatoria, ya que los modelos de procesos de
negocio son la base para un buen desarrollo de sistemas de información, especialmente si se
quieren aplicar arquitecturas orientadas a servicios.
2.2.1 Descripción de los Actores de Negocio a Implantar

Esta sección debe contener información sobre los actores de negocio (organizaciones, roles o
responsabilidades) de los modelos de procesos de negocio a implantar, especificados mediante
las plantillas para actores del negocio a implantar que se muestran a continuación.
[Dependencias] • <actores de negocio actual relacionados>

• ...
Descripción Este actor de negocio actual representa a <descripción de la organización, rol o

responsabilidad a la que representa el actor de negocio actual>
Comentarios <comentarios adicionales sobre el actor de negocio a implantar>
Tabla 6: Actores de negocio a implantar.

2.2.2 Descripción de Procesos de Negocio a Implantar

Página 17 de 32
<Nombre Proyecto>
Esta sección debe contener información sobre los procesos de negocio a implantar, tal y como se espera que se realicen
en la organización del cliente una vez que el sistema software a desarrollar esté en producción. Para cada proceso de
negocio se incluirá una descripción textual usando las plantillas para procesos de negocio a implantar que se muestran
a continuación, y un diagrama en la notación que se considere oportuna, por ejemplo diagramas BPMN o diagramas de
actividad UML.
[Dependencias] • <procesos de negocio actuales que modifica o sustituye>

• ...
Descripción <descripción del proceso de negocio a implantar en términos del dominio del
problema>
Actores • <actor que participa en el proceso de negocio>

• ...
Comentarios <comentarios adicionales sobre el proceso de negocio a implantar>
Tabla 7: Procesos de Negocio a implantar.

Página 18 de 32
<Nombre Proyecto>
3 DESCRIPCIÓN DE LOS SUBSISTEMAS DEL SISTEMA A DESARROLLAR

[OPCIONAL]
Esta sección opcional debe contener una descripción de los subsistemas del sistema a desarrollar,
especificados mediante las plantillas para subsistemas que se muestran a continuación. En el
contexto de este documento, los subsistemas son agrupaciones lógicas de requisitos cuya
finalidad es facilitar la comprensión de los mismos, por lo que no implican necesariamente la
existencia de subsistemas o módulos software correspondientes en las siguientes fases de
desarrollo. Para facilitar la comprensión, se recomienda el uso de diagramas donde sea posible.
Los subsistemas a los que se hace referencia en esta sección puede que ya se hayan definido total
o parcialmente en documentación previa como el Pliego de Prescripciones Técnicas, la Oferta
seleccionada o el Estudio de Viabilidad del Sistema, en cuyo se podrán reutilizar y se hará
referencia a dichos documentos como fuente de los mismos.
[Dependencias] • <objetivos de negocio de los que depende>

• <proceso de negocio a implantar del que depende>
• ...
Descripción Este subsistema agrupa los requisitos relacionados con <descripción del
subsistema>
[Prioridad] <prioridad del subsistema para la dirección del proyecto>
Comentarios <comentarios adicionales sobre el subsistema>
Tabla 8: Subsistemas a desarrollar.

Esta sección podrá omitirse si el sistema software a desarrollar es lo suficientemente sencillo como
para no ser dividido en subsistemas.
Página 19 de 32
<Nombre Proyecto>
4 CATÁLOGO DE REQUISITOS DEL SISTEMA A DESARROLLAR

Esta sección obligatoria debe contener la descripción de la solución que el ingeniero de requisitos
propone al cliente para satisfacer sus necesidades de negocio. Esta solución se define mediante
los requisitos del sistema a desarrollar ( requisitos de producto en terminología CMMI-DEV), que
se organizan según la taxonomía de requisitos de producto propuesta en Madeja.
Esta sección se divide en las secciones que se describen a continuación, cada una de las cuales
puede organizarse internamente como se considere oportuno para facilitar la legibilidad del
documento, siendo la organización más habitual la división en los subsistemas descritos en la
sección 5, en cuyo caso la estructura del índice para la sección sería la que puede verse en la
siguiente figura.
Figura 1. Ejemplo del ïndice.
4.1 Requisitos Generales del Sistema

Esta sección debe contener la especificación de los requisitos generales del sistema, también
denominados características del sistema (system features) u objetivos del sistema, especificados
mediante las plantillas para requisitos generales que se muestran a continuación.
Los requisitos generales puede que ya se encuentren especificados total o parcialmente en
documentación previa como el Pliego de Prescripciones Técnicas, la Oferta seleccionada o el
Estudio de Viabilidad del Sistema, en cuyo se podrán reutilizar y se hará referencia a dichos
documentos como fuente de los mismos. En el caso de que se considere necesario, los requisitos
generales se podrán descomponer jerárquicamente para facilitar su comprensión.
Página 20 de 32
<Nombre Proyecto>
[Dependencias] • <objetivos de negocio de los que depende>

• <requisito general padre, si lo tiene>(padre)
• <otros requisitos generales de los que dependa>
• ...
Descripción El sistema deberá <descripción del requisito general del sistema>
Requisitos hijos • <requisitos generales hijos, si lo tiene>

• ...
[Importancia] <importancia del requisito para el cliente>
[Prioridad] <prioridad del requisito para la dirección del proyecto>
[Estado] <estado del requisito según el ciclo de vida adoptado por el proyecto>
Comentarios <comentarios adicionales sobre el requisito general>
Tabla 9: Requisitos generales del sistema.

4.2 Casos de uso del Sistema

Esta sección debe contener la especificación de los casos de uso del sistema, denominados
escenarios operacionales en terminología CMMI-DEV, incluyendo los correspondientes
diagramas, la especificación de los actores y la especificación de los propios casos de uso. Los
casos de uso deben describir cómo se utilizará el sistema a desarrollar por sus futuros usuarios
para realizar sus procesos de negocio.
Esta sección se divide en las secciones que se describen a continuación.
4.2.1 Diagramas de Casos de Uso del Sistema

Esta sección debe contener los diagramas de casos de uso del sistema que se hayan identificado.
Se debe tener en cuenta que los diagramas de casos de uso no son más que un índice visual de
los casos de uso identificados, ya que la información relevante de los casos de uso (la interacción
entre los actores y el sistema) no se ve reflejada en los diagramas sino en la especificación de los
propios casos de uso del sistema.
Página 21 de 32
<Nombre Proyecto>
Figura 2. Ejemplo de Diagrama de Caso de Uso
4.2.2 Especificación de Actores del Sistema

Esta sección debe contener las especificaciones de los actores que se hayan identificado en los
casos de uso, es decir, los diferentes tipos de usuarios y otros sistemas con los que deba
interactuar el sistema a desarrollar. Los actores deben especificarse mediante la plantilla para
actores propuesta en Madeja.
Es probable que muchos de los actores que se especifiquen en esta sección se correspondan con
alguno de los actores de negocio de los modelos de procesos de negocio de las secciones 3.2.1 o
4.2.1. En ese caso, la especificación del actor de sistema en esta sección deberá trazarse hacia el
actor de negocio oportuno.
[Dependencias] • <actores de negocio a implantar relacionados>

• ...
Descripción Este actor de negocio actual representa a <descripción del rol que representa el
actor en los casos de uso del sistema>
Comentarios <comentarios adicionales sobre el actor del sistema>
Tabla 10: Actores del sistema.
Página 22 de 32
<Nombre Proyecto>
4.2.3 Especificación de Casos de Uso del Sistema

Esta sección debe contener las especificaciones de los casos de uso del sistema que se hayan
identificado, especificados mediante las plantillas para casos de uso propuestas en Madeja. El
nivel de detalle de la especificación de cada caso de uso deberá decidirse en función de su
importancia y de las necesidades del proyecto. Por este motivo existen dos plantillas, la plantilla
simplificada para casos de uso y la plantilla detallada, que se muestran a continuación.
[Dependencias] • <requisitos generales del sistemas de los que depende>

• <lista de casos de uso que invoca>
• <otros requisitos de los que depende>
• ...
Precondición <precondición del caso de uso del sistema>
Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso

[abstracto] cuando {<evento de activación>, sea necesario para la realización de
otros caso de uso}.
Postcondición <postcondición del caso de uso del sistema>
[Importancia] <importancia del caso de uso para el cliente>
[Prioridad] <prioridad del caso de uso para la dirección del proyecto>
[Estado] <estado del caso de uso según el ciclo de vida adoptado por el proyecto>
Comentarios <comentarios adicionales sobre el caso de uso del sistema>
Tabla 11: Plantilla simplificada de Casos de Uso.

Página 23 de 32
<Nombre Proyecto>
[Dependencias] • <requisitos generales del sistemas de los que depende>

• <lista de casos de uso que invoca>
• ...
Precondición <precondición del caso de uso del sistema>
Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso [abstracto] cuando
{<evento de activación>, sea necesario para la realización de otros caso de uso}.
Secuencia Normal Paso Acción
1 {El actor <actor del sistema>, El sistema}<acción/es realizada/s por el actor del sistema>
2 Se realiza el <caso de uso del sistema>
3 Si <condición>,
... ...
3.n. {El caso de uso termina con éxito,Se cancela el caso de uso}
... ...
Postcondición <postcondición del caso de uso del sistema>
Excepciones Paso Acción
P Si <condición de excepción>
E.m {El caso de uso continua,Se cancela el caso de uso}
… ...
Rendimiento Paso Cota de tiempo
q k<unidad de tiempo>
… ...
Frecuencia <nº veces / unidad de tiempo>
[Importancia] <importancia del caso de uso para el cliente>
[Prioridad] <prioridad del caso de uso para la dirección del proyecto>
[Estado] <estado del caso de uso según el ciclo de vida adoptado por el proyecto>
Comentarios <comentarios adicionales sobre el caso de uso del sistema>
Página 24 de 32
<Nombre Proyecto>
Tabla 12: Plantillla Completa de Casos de Uso.
4.3 Requisitos Funcionales del Sistema

Esta sección debe contener los requisitos funcionales del sistema que se hayan identificado a
partir de los requisitos generales, de los casos de uso del sistema o de otras fuentes. Se divide en
las secciones que se describen a continuación.
4.3.1 Requisitos de Información del Sistema

Esta sección debe contener los requisitos de almacenamiento de información ( requisitos de

información para abreviar) que se hayan identificado, especificados mediante las plantillas para
requisitos de información que se muestran a continuación.
Estos requisitos deben especificar qué información debe almacenar el sistema para poder ofrecer
la funcionalidad descrita en los casos de uso del sistema o en otros requisitos.
Esta sección podrá omitirse total o parcialmente si la dirección del proyecto recomienda seguir un
enfoque muy centrado en los casos de uso. Esto se debe a que, en ese caso, gran parte de los
requisitos de información pueden deducirse de los casos de uso.
[Dependencias] • <requisitos generales de los que depende>

• ...
Descripción El sistema deberá almacenar la información correspondiente a <concepto

relevante>. En concreto:
Datos específicos • <datos específicos sobre el concepto relevante>

• ...
Comentarios <comentarios adicionales sobre el requisito de información>
Página 25 de 32
<Nombre Proyecto>
Tabla 13: Requisitos de información.

4.3.2 Requisitos de Reglas de Negocio del Sistema

Esta sección debe contener las reglas de negocio que deba cumplir el sistema a desarrollar,
especificadas mediante las plantillas para reglas de negocio que se muestran a continuación.
Estos requisitos deben especificar qué reglas de negocio debe respetar el sistema, evitando que
se incumplan durante su funcionamiento.

• ...
Descripción El sistema deberá respetar la siguiente regla de negocio:<descripción de la regla

de negocio del sistema>
Comentarios <comentarios adicionales sobre el requisito>
Tabla 14: Requisitos de reglas de negocio.

4.3.3 Requisitos de Conducta del Sistema

Esta sección debe contener los requisitos de conducta que se hayan identificado, especificados
mediante las plantillas de requisitos de conducta que se muestran a continuación.
Estos requisitos deben especificar cualquier otro comportamiento deseado del sistema que no se
haya especificado mediante los casos de uso del sistema, como generación de informes,
funcionalidades transversales a varios casos de uso del sistema, etc.
Página 26 de 32
<Nombre Proyecto>

• ...
Descripción El sistema deberá <descripción de conducta del sistema>[,cuando <evento de

activación>]
Interfaz de Servicio {Sí,No}
Tabla 15: Requisitos de conducta.

4.4 Requisitos No Funcionales del Sistema

Esta sección debe contener los requisitos no funcionales que se hayan identificado, especificados
mediante las plantillas para requisitos no funcionales que se muestran a continuación.
Esta sección se divide en las secciones que se describen a continuación, acorde a la taxonomía de
requisitos de producto propuesta en Madeja.

• ...
Descripción El sistema deberá <descripción no funcional del sistema>
Página 27 de 32
<Nombre Proyecto>
Tabla 16: Requisitos no funcionales del sistema.

4.4.1 Requisitos de Fiabilidad

Esta sección debe contener los requisitos de fiabilidad que se hayan identificado, especificados
mediante las plantillas para requisitos no funcionales propuestas en Madeja.
Estos requisitos deberán establecer, de la manera más objetiva y medible posible, los niveles que
debe cumplir el sistema a desarrollar en aspectos como recuperabilidad y tolerancia a fallos.
4.4.2 Requisitos de Usabilidad

Esta sección debe contener los requisitos de usabilidad que se hayan identificado, especificados
debe cumplir el sistema a desarrollar en aspectos como facilidad de aprendizaje, comprensión,
operatividad y atractividad.
4.4.3 Requisitos de Eficiencia

Esta sección debe contener los requisitos de eficiencia que se hayan identificado, y que no hayan
podido expresarse asociados a pasos de casos de uso del sistema, especificados mediante las
plantillas para requisitos no funcionales propuestas en Madeja.
debe cumplir el sistema a desarrollar en aspectos como tiempo de respuesta.
4.4.4 Requisitos de Mantenibilidad

Página 28 de 32
<Nombre Proyecto>
Esta sección debe contener los requisitos de mantenibilidad que se hayan identificado,
especificados mediante las plantillas para requisitos no funcionales propuestas en Madeja.
debe cumplir el sistema a desarrollar en aspectos como estabilidad, facilidad de análisis, facilidad
de cambio, facilidad de pruebas.
4.4.5 Requisitos de Portabilidad

Esta sección debe contener los requisitos de portabilidad que se hayan identificado, especificados
mediante las plantillas para requisitos de no funcionales propuestas en Madeja.
debe cumplir el sistema a desarrollar en aspectos relacionados con la escalabilidad: capacidad de
instalación, capacidad de sustitución, adaptabilidad, coexistencia, compatibilidad con hardware o
software, etc.
4.4.6 Requisitos de Seguridad
Esta sección debe contener los requisitos de seguridad que se hayan identificado, especificados
debe cumplir el sistema a desarrollar en aspectos como accesos al sistema, identificación y
autenticación, protección de datos y privacidad.
4.4.7 Otros Requisitos No Funcionales

Esta sección debe contener los requisitos no funcionales que se hayan identificado y que no
pertenezcan a ninguna de las categorías anteriores. Al igual que los anteriores, deberán
especificarse mediante las plantillas para requisitos no funcionales propuestas en Madeja.
4.5 Restricciones Técnicas del Sistema

Esta sección debe contener las restricciones técnicas que se imponen al sistema software a
desarrollar (tecnología a usar, protocolos de comunicaciones, compatibilidad con navegadores,
etc.), especificadas mediante las plantillas para restricciones técnicas que se muestran a
continuación.
Página 29 de 32
<Nombre Proyecto>

• ...
Descripción El sistema deberá respetar la siguiente restricción técnica: <descripción de la

restricción técnica del sistema>
[Importancia] <importancia de la restricción técnica para el cliente>
[Prioridad] <prioridad dela restricción técnica para la dirección del proyecto>
[Estado] <estado dela restricción técnica según el ciclo de vida adoptado por el
proyecto>
Comentarios <comentarios adicionales sobre la restricción técnica>
Tabla 17: Restricciones técnicas del sistema.

4.6 Requisitos de Integración del Sistema

Esta sección debe contener los requisitos de integración que se hayan identificado, especificados
mediante las plantillas para requisitos de integración que se muestran a continuación.
Estos requisitos deben identificar aquellos servicios disponibles en el entorno tecnológico de
producción o componentes software (por ejemplo, librerías enlazables) cuya funcionalidad sea
relevante para el sistema a desarrollar y deban ser consumidos por el mismo.

• ...
Descripción El sistema deberá utilizar el {servicio, componente software} <nombre del

elemento a integrar> para aquellos aspectos relacionados con <funcionalidad
prestada por el elemento a integrar>
Página 30 de 32
<Nombre Proyecto>
Tabla 18: Requisitos de integración del sistema.

4.7 Información Sobre Trazabilidad

Esta sección obligatoria debe contener el conjunto de matrices de trazabilidad que se considere
oportuno para identificar las relaciones entre los requisitos identificados. Al menos deberá incluir
la siguiente matriz:
• Matriz de trazabilidad de Requisitos Generales frente a Objetivos de Negocio.
• Matriz de trazabilidad de Casos de Uso frente a Requisitos Generales.
• Matriz de trazabilidad de Requisitos de Información frente a Requisitos Generales.
• Matriz de trazabilidad de Reglas de Negocio frente a Requisitos Generales.
• Matriz de trazabilidad de Requisitos de Conducta frente a Requisitos Generales.
• Matriz de trazabilidad de Requisitos no Funcionales frente a Requisitos Generales.
• Matriz de trazabilidad de Restricciones Técnicas frente a Requisitos Generales.
• Matriz de trazabilidad de Requisitos de Integración frente a Requisitos Generales.
Página 31 de 32
<Nombre Proyecto>
5 ANEXOS [OPCIONAL]
Los anexos se usarán para proporcionar información adicional a la documentación obligatoria del
documento. Sólo deben aparecer si se consideran oportunos y se identificarán con letras
ordenadas alfabéticamente: A, B, C, etc.
A continuación se describen algunos anexos habituales.
5.1 Anexo A: Actas de Reuniones

Este anexo debe contener el catálogo de actas de reuniones que se hayan mantenido, registradas
mediante el documento para acta de reuniones propuesto en Madeja.
5.2 Anexo B: Documentación Relevante

Este anexo debe contener cualquier documentación que se considere relevante para el sistema a
desarrollar. Por ejemplo, documentos que deriven de la actividad normal del negocio, leyes o
referencias a leyes de aplicación en la organización, fotografías que ilustren la forma de trabajar,
informes que genera el software actual, etc.
5.3 Anexo C: Glosario de Acrónimos y Abreviaturas

Este anexo debe contener una lista ordenada alfabéticamente de los acrónimos y abreviaturas
que aparezcan en el documento.
Para facilitar la reutilización entre proyectos, los acrónimos y abreviaturas comunes a la mayoría
de los proyectos aparecerán en este glosario separados de los términos específicos del dominio
del problema.
Página 32 de 32

Ingenieria de Requisitos Plantilla

Cargado por

Copyright:

Formatos disponibles

Ingenieria de Requisitos Plantilla

Cargado por

Información del documento

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

Ingenieria de Requisitos Plantilla

Cargado por

Copyright:

Formatos disponibles

SISTEMA DE GESTIÓN Y ADMINISTRACIÓN DE

Organismo Universidad Politécnica de Texcoco

6.4.6 Requisitos de Seguridad ..................................................................................................................... 26

En el contexto actual de la creciente complejidad y demanda en diversas industrias del área de la

El alcance de un sistema de gestión y administración de disponibilidad inteligente es amplio y diverso,

Mejora de la eficiencia operativa: Un sistema de gestión y administración de disponibilidad

Aumento de la disponibilidad de servicios: Al prever y evitar posibles problemas, este tipo de

Reducción de costos: Al minimizar los tiempos de inactividad y maximizar la eficiencia, un sistema de

Automatización de tareas: Un sistema de gestión y administración de disponibilidad inteligente

El desarrollo de un sistema de gestión y administración de disponibilidad inteligente puede verse

Cultura Organizacional: La cultura de la organización puede influir en la adopción y el éxito del

Recursos Humanos: La disponibilidad de personal capacitado y con experiencia en áreas como la

Estructura Organizacional: La estructura de la organización, incluyendo cómo se dividen las

Políticas y Procedimientos: Las políticas y procedimientos existentes de la organización pueden

Ciclo de Vida del Desarrollo de Software: El desarrollo de un sistema de gestión y administración de

Gestión del Cambio: La capacidad de la organización para gestionar el cambio y la adopción de

El desarrollo de un sistema de gestión y administración de disponibilidad inteligente puede verse

2 INFORMACIÓN DEL DOMINIO DEL PROBLEMA

1.3 Introducción al Dominio del Problema

1.4 Glosario de Términos

Aspectos Éticos y Legales: La toma de decisiones automatizada y la gestión de datos médicos

Colaboración Interdisciplinaria: El diseño e implementación de un sistema efectivo requiere la

Demanda de Servicios de Salud: Se refiere a la variabilidad en la demanda de servicios de salud,

Eficiencia Operativa: La optimización de la utilización de recursos y la eficiencia operativa son

Inteligencia artificial y aprendizaje automático: El uso de algoritmos y modelos de inteligencia

Interoperabilidad de sistemas: La capacidad de diferentes sistemas y dispositivos de compartir y

Planificación de la capacidad: La capacidad de prever y planificar la demanda de servicios de

Priorización de Pacientes: En función de la gravedad de la enfermedad, el tipo de tratamiento

Recursos Hospitalarios: Esto incluye camas de hospital, quirófanos, personal médico y de

Tecnologías Emergentes: La implementación de tecnologías como el análisis de datos en tiempo

3 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL

1.5 Pros y Contras de la Situación Actual

Mejora en la Atención al Paciente: Facilita la rápida asignación de camas y servicios médicos,

Prevención de Sobrecargas: Identifica y gestiona la carga de trabajo en tiempo real, evitando la

Resistencia al Cambio: El personal hospitalario puede enfrentar resistencia al cambio al adaptarse a

Privacidad y Seguridad: La gestión de datos sensibles de pacientes requiere altos estándares de

1.5.1 Fortalezas de la Situación Actual

artificial. La colaboración interdisciplinaria entre profesionales de la salud y expertos en tecnología es

id 1 Primer version para la documentación

Descripción Se recapituló información sobre los antecedentes de este tipo de sistema y se

1.5.2 Debilidades de la Situación Actual

<id>1 Primer version para la documentación

Descripción Se recapituló información sobre los antecedentes de este tipo de sistema y se

Tabla 2: Debilidades de la situación actual.

1.6 Modelos de Procesos de Negocio Actuales

1.6.1 Descripción de los Actores de Negocio Actuales

<id>999 <nombre descriptivo>

[Versión] <nº versión>(<fecha de versión>)

[Dependencias] • <procesos de negocio actuales en los que participa>

Descripción Este actor de negocio actual representa a <descripción de la organización, rol

Comentarios <comentarios adicionales sobre el actor de negocio actual>

Tabla 3: Actores de negocio.

1.6.2 Descripción de Procesos de Negocio Actuales

<id>999 <nombre descriptivo>

[Versión] <nº versión>(<fecha de versión>)

[Dependencias] • <procesos de negocio actuales de los que depende>

[Importancia] <importancia del proceso de negocio para el cliente>

[Actores] • <actor que participa en el proceso de negocio>

Comentarios <comentarios adicionales sobre el proceso de negocio actual>

Tabla 4: Procesos de Negocio actuales.