DUOC UC - Escuela de informática y telecomunicaciones

Propuesta de Proyecto
y Especificación de
Requisitos de Software
Proyecto: [Sistema Digital Fichas Médicas]
Revisión: [01]
[13/05/2019]

Planificación y Especificación de Requisitos según estándares; IEEE 830, ISO9000 y PMI.

 Especificación de Requisitos, estándar de IEEE 830

Contenido

FICHA DEL DOCUMENTO 3

1. INTRODUCCIÓN 4

1.1. PROPÓSITO 4
1.2. ÁMBITO DEL SISTEMA 4
1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS 4
1.4. REFERENCIAS 4
1.5. VISIÓN GENERAL DEL DOCUMENTO 4

2. DESCRIPCIÓN GENERAL 5

2.1. PERSPECTIVA DEL PRODUCTO 5

2.2. FUNCIONES DEL PRODUCTO 5
2.3. CARACTERÍSTICAS DE LOS USUARIOS 5
2.4. RESTRICCIONES 5
2.5. SUPOSICIONES Y DEPENDENCIAS 6
2.6. REQUISITOS FUTUROS 6

3. REQUISITOS ESPECÍFICOS 7

3.1 REQUISITOS COMUNES DE LAS INTERFACES 8

3.1.1 Interfaces de usuario 8
3.1.2 Interfaces de hardware 8
3.1.3 Interfaces de software 8
3.1.4 Interfaces de comunicación 8
3.2 REQUISITOS FUNCIONALES 8
3.3 REQUISITOS NO FUNCIONALES 9
3.3.1 Requisitos de rendimiento 9
3.3.2 Seguridad 9
3.3.3 Fiabilidad 10
3.3.4 Disponibilidad 10
3.3.5 Mantenibilidad 10
3.3.6 Portabilidad 10
3.4 OTROS REQUISITOS 10

4. PROPUESTA DE PLANIFICACIÓN 11

4.1 DESCRIPCIÓN GENERAL ACERCA DE LA PLANIFICACIÓN 11

4.1.2 Definición del Equipo de Trabajo 11
4.1.3 Definición de Actividades principales del Proyecto 11

2
 Especificación de Requisitos, estándar de IEEE 830

4.1.4 Diagrama EDT 11

4.1.5 Carta Gantt 11
4.1.6 Resumen Costos del Desarrollo del Proyecto 11
4.2 PLAN DE CONTROL DE CAMBIO 12
5. ANEXOS 12
5.1 Acta de Proyecto 12
5.2 Matriz Especificación de Requerimientos 12
5.3 Diagrama de Casos de Uso General 12
5.4 Planilla Casos de Uso 12
5.5 Prototipado de Software 13
5.6 Resultado Análisis de Calidad Diagramas Modelamiento 13
5.7 Resultado Análisis de Calidad Prototipo No funcional del Sistema 13
5.8 Planilla entregables del Proyecto 13
5.9 Matriz de Control de Cambios 13
5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo 13

Ficha del documento

Fecha Revisión Autor Modificación

Documento validado por las partes en fecha:

Integrantes:
Nombre Integrante del Equipo Rol Definido

Jersson Ignacio Silva Soto Lider del Proyecto

Romina Reyes Pino Gerente del Protecto

Alejandro Rodrigo Opazo Navarrete Analista

3
 Especificación de Requisitos, estándar de IEEE 830

Marcelo Antonio Flores Toledo Gestor

1. Introducción
Para la creación de un sistema de información, es muy importante realizar un

estudio detallado, de los problemas que afectan el funcionamiento del centro de salud de Duoc
UC.El problema que surge, está relacionado con el mal funcionamiento que afecta a cada área que
conforma este centro de salud,dentro de esta problemática se destaca las Fichas Médicas.Estas
Fichas Médicas están hechas a Papel lo cual el paciente debe llenarla considerando sus datos
personales , si asiste acompañado o no etc. En algunos casos son los mismos funcionarios
administrativos que se encargan de llenar estas fichas , esto pasa si el paciente ingresa al centro de
salud en estado de discapacidad , ya sea inmovilidad, dificultad al hablar ETC.

¿Como se soluciona este gran problema?

Se desarrollara un software que tendrá como objetivo , ingresar fichas médicas digitalizadas esto
dará un mejor funcionamiento y atención de los médicos a los pacientes que ingresan a diario al
centro de salud de Duoc Uc.

1.1. Propósito
El Propósito de este proyecto es mejorar el funcionamiento del centro de salud de nuestra
institución, por este motivo el software que vamos a desarrollar permitirá que todo el personal
tenga acceso a él , donde podrán revisar sus horarios, pedir permisos , o en el caso de los médicos
podrán acceder a cada ficha médica del paciente que atenderá en el momento.

4
 Especificación de Requisitos, estándar de IEEE 830

1.2. Ámbito del Sistema

En esta subsección:
• Sistema digital de Fichas Médicas Fost.
• La función principal de este sistema es principalmente eliminar en su totalidad
las fichas médicas de papel , esto dará un mejor acceso a estas a la hora de
atención de los médicos y de administración. Con este software se digitaliza todo
este proceso para hacer una experiencia más completa y un funcionamiento más
eficaz.
• Este sistema se espera que sea de gran ayuda para todo el personal de la clínica
tanto administradores, doctores , farmacéuticos y también para toda clase de
paciente.

1.3. Definiciones, Acrónimos y Abreviaturas

1. Requisito: Es la descripción de los servicios y restricciones que tiene el proyecto.
2. Funcionalidad: Descripción y funciones que el software debe tener.
3. Interfaces Externas: Cómo debe interactuar el sistema con las personas, el sistema de
hardware, o con otros sistemas (software y hardware).
4. Rendimiento: Indicación de la velocidad, disponibilidad, tiempos de respuesta, tiempos de
recuperación, tiempos de determinadas funciones.
5. Cliente/Usuarios: Son todas las personas quienes hacen uso de los servicios que ofrece la
empresa.

1.4. Referencias
1) Acta Kick Off
2) Acta de Constitución
3) Planilla de Requerimientos
4) Cuestionario ERS
5) Informe ERS

1.5. Visión General del Documento

En esta subsección se describe brevemente los contenidos y la organización del resto de la ERS.

5
 Especificación de Requisitos, estándar de IEEE 830

2. Descripción General
Hoy en día la problemática que afecta al centro de salud de Duoc Uc está centrado en las Fichas
Médicas, que tienen que ser llenadas por los pacientes al hacer el ingreso.

El Software debe funcionar de la siguiente manera: primero el usuario debe autenticarse al

sistema con su User y Password. Luego podrá acceder al portal de personal dependiendo si sea
médico administrativo informático o funcionario de farmacia, hay encontrara una variedades de
secciones como por ejemplo , horarios , permisos , en el caso del que el médico ingrese , va
encontrar la sección de fichas médicas , funcionario de farmacia podrá acceder a las recetas de
medicamentos.

1. El Funcionario de Farmacia: Encargado de hacer entrega al paciente los Medicamentos

recetados por el médico.
2. Médico: Es el encargado de realizar el reconocimiento médico a los nuevos pacientes
además redactar el historial médico, así como las certificaciones profesionales sobre el
tipo de vida más acorde a seguir, la rehabilitación necesaria y su tratamiento. Programa y
supervisa (junto al nutricionista en caso de que el centro disponga de esta figura) los
menús y dietas alimentarias de los usuarios e informa a los familiares sobre su estado de
salud.
3. Funcionario de Bodega: Encargado de controlar la rotación y el vencimiento de los
productos de bodega. Es decir que el bodeguero es la persona encargada de recibir y
revisar todo el producto que ingresa al Centro de Salud.
4. Informático: Encargado de Desarrollar el Software , instalar equipos computacionales , y
mejorar funcionamiento del sistema
5. Funcionario Administrativo : EL Funcionario Administrativo es el encargado de ingresar a
los pacientes que hacen ingreso al centro de salud además ingresar datos del paciente al
sistema en el caso de que este último tenga alguna discapacidad.
6. Administrador: EL Funcionario Administrativo maneja el financiamiento de cada área del
hospital especialmente el área de farmacia , equipos tecnológicos e instrumentos médicos.
7. Informe: Documento exclusivamente para estadísticas del centro de salud ya sea historial
de atenciones , ingresos de pacientes etc.

6
 Especificación de Requisitos, estándar de IEEE 830

2.1. Perspectiva del Producto

Esta subsección debe relacionar el futuro sistema (producto software) con otros productos. Si el
producto es totalmente independiente de otros productos, también debe especificarse aquí. Si la
ERS define un producto que es parte de un sistema mayor, esta subsección relacionarán los
requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se
identificarán las interfaces entre el producto mayor y el producto aquí descrito. Se recomienda
utilizar diagramas de bloques.

2.2. Funciones del Producto

El Software debe funcionar de la siguiente forma: primero el usuario debe autenticarse al sistema
con su User y Password. Luego podrá acceder al portal de personal dependiendo si sea médico
administrativo informático o funcionario de farmacia, hay encontrara una variedades de secciones
como por ejemplo , horarios , permisos , en el caso del que el médico ingrese , va encontrar la
sección de fichas médicas , funcionario de farmacia podrá acceder a las recetas de medicamentos.

Para que el usuario pueda autenticarse al sistema , debe ingresar sus Datos Personales (Nombre ,
Apellido, Rut) Correo Electronico y Contraseña , esto permitirá al usuario ingresar al sistema y
hacer función del software ingresando a las variedades de Secciones.

El Médico tendrá su propio portal donde podrá revisar las Fichas Médicas del Paciente, Registrar
datos, registrar receta de medicamentos, Temperatura del Paciente y Diagnóstico

El Funcionario de Farmacia al igual que el Médico tendrá su propio portal , El Funcionario de

Farmacia podrá ingresar al portal donde revisará los medicamentos recetados por el médico ya
registrados en el sistema solo ingresando el Rut del Paciente.

El Paciente podrá ingresar al Portal donde podrá acceder a los horarios de atencion , contactos del
centro de saludo , mapa etc

7
 Especificación de Requisitos, estándar de IEEE 830

2.3. Características de los Usuarios

Esta subsección describe las características generales de los usuarios del producto, incluyendo
nivel educacional, experiencia y experiencia técnica. Además debes definir los Tipos de Usuarios
con sus perfiles.

8
 Especificación de Requisitos, estándar de IEEE 830

2.4. Restricciones
Esta subsección describe aquellas limitaciones que se imponen sobre los desarrolladores del
producto:

• Políticas de la empresa.

• Limitaciones del hardware.

• Interfaces con otras aplicaciones.

• Operaciones paralelas.

• Funciones de auditoría.

• Funciones de control.

• Lenguaje(s) de programación.

• Protocolos de comunicación.

• Requisitos de habilidad.

• Criticidad de la aplicación.

• Consideraciones acerca de la seguridad.

2.5. Suposiciones y Dependencias

Esta subsección de la ERS describe aquellos factores que, si cambian, pueden afectar a los
requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organización de ciertas
unidades de la empresa, o pueden presuponer que el sistema correrá sobre cierto sistema
operativo. Si cambian dichos detalles en la organización de la empresa, o si cambian ciertos
detalles técnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.

2.6. Requisitos Futuros

Los requisitos que tendrá este sistema son los siguientes:

1. Mejorar El Funcionamiento de las Áreas de conforman el centro de salud especialmente

Area de Farmacia Administración y Médico.
2. Acceder de forma más Eficaz a las Fichas Clínicas de los Pacientes
3. Mejorar el ingreso de datos de los pacientes

9
 Especificación de Requisitos, estándar de IEEE 830

10
 Especificación de Requisitos, estándar de IEEE 830

3. Requisitos Específicos
Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los
diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo
requisito aquí especificado describe comportamientos externos del sistema, perceptibles por parte
de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la ERS.
Deberán aplicarse los siguientes principios:

• El documento debería ser perfectamente legible por personas de muy distintas

formaciones e intereses.

• Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia

sobre los requisitos.

• Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de
numeración adecuado.

• Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las
siguientes características:

− Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y que será
implementado en el sistema) refleja alguna necesidad real. La corrección de la ERS implica
que el sistema implementado será el sistema deseado.
− No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad
inherente a los requisitos expresados en lenguaje natural, se deberán utilizar gráficos o
notaciones formales. En el caso de utilizar términos que, habitualmente, poseen más de
una interpretación, se definirán con precisión en el glosario.
− Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir
todas las posibles respuestas del sistema a los datos de entrada, tanto válidos como no
válidos.
− Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos
contradictorio no es implementable.
− Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los
requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) o
por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo,
para no emplear excesivos recursos en implementar requisitos no esenciales.
− Verificables: La ERS es verificable si y sólo si todos sus requisitos son verificables. Un
requisito es verificable (testable) si existe un proceso finito y no costoso para demostrar
que el sistema cumple con el requisito. Un requisito ambiguo no es, en general,
verificable. Expresiones como a veces, bien, adecuado, etc. Introducen ambigüedad en los

11
 Especificación de Requisitos, estándar de IEEE 830

requisitos. Requisitos como “en caso de accidente la nube tóxica no se extenderá más allá
de 25 Km" no es verificable por el alto costo que conlleva.
− Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los
cambios a los requisitos pueden realizarse de forma fácil, completa y consistente. La
utilización de herramientas automáticas de gestión de requisitos facilitan enormemente
esta tarea.
− Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la
referencia de cada requisito a los componentes del diseño y de la implementación. La
trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito. La
trazabilidad hacia delante de un requisito R indica qué componentes del sistema son los
que realizan el requisito R.

3.1 Requisitos comunes de las interfaces

Descripción detallada de todas las entradas y salidas del sistema .

3.1.1 Interfaces de usuario

Describir los requisitos del interfaz de usuario para el producto. Esto puede estar en la forma de
descripciones del texto o pantallas del interfaz. Por ejemplo, posiblemente el cliente ha
especificado el estilo y los colores del producto. Describa exacto cómo el producto aparecerá a su
usuario previsto.

3.1.2 Interfaces de hardware

Especificar las características lógicas para cada interfaz entre el producto y los componentes de
hardware del sistema. Se incluirán características de configuración.

3.1.3 Interfaces de software

Indicar si hay que integrar el producto con otros productos de software.

− Para cada producto de software debe especificarse lo siguiente:

− Descripción del producto software utilizado
− Propósito del interfaz
− Definición del interfaz: contenido y formato

3.1.4 Interfaces de comunicación

La interfaz de Comunicación del software será una plataforma donde el usuario podrá enviar
mensajes al sistema ingresando su correo electrónico nombre, apellido, Rut y ademas el asunto
del mensaje.

3.2 Requisitos funcionales

Definición de acciones fundamentales que debe realizar el software al recibir información,
procesarla y producir resultados.

En ellas se incluye:

12
 Especificación de Requisitos, estándar de IEEE 830

− Comprobación de validez de las entradas

− Secuencia exacta de operaciones
− Respuesta a situaciones anormales (desbordamientos, comunicaciones, recuperación de
errores)
− Parámetros
− Generación de salidas
− Relaciones entre entradas y salidas (secuencias de entradas y salidas, fórmulas para la
conversión de información)
− Especificación de los requisitos lógicos para la información que será almacenada en base
de datos (tipo de información, requerido)

Los requisitos funcionales principales pueden ser divididos en sub-secciones.

3.2.1 Requisito funcional 1

3.2.2 Requisito funcional 2

3.2.3 Requisito funcional 3

3.2.4 Requisito funcional n

Nota: Los Requerimientos específicos se detallarán en los anexos de Planillas de

Requerimientos.

3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento

Especificación de los requisitos relacionados con la carga que se espera tenga que soportar el
sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente
conectados, número de transacciones por segundo que deberá soportar el sistema, etc.

Todos estos requisitos deben ser mensurables. Por ejemplo, indicando “el 95% de las
transacciones deben realizarse en menos de 1 segundo”, en lugar de “los operadores no deben
esperar a que se complete la transacción”.

3.3.2 Seguridad
Especificación de elementos que protegerán al software de accesos, usos y sabotajes maliciosos,
así como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos pueden
especificar:

− Empleo de técnicas criptográficas.

− Registro de ficheros con “logs” de actividad.
− Asignación de determinadas funcionalidades a determinados módulos.
− Restricciones de comunicación entre determinados módulos.

13
 Especificación de Requisitos, estándar de IEEE 830

− Comprobaciones de integridad de información crítica.

3.3.3 Fiabilidad
Especificación de los factores de fiabilidad necesaria del sistema. Esto se expresa generalmente
como el tiempo entre los incidentes permisibles, o el total de incidentes permisible.

3.3.4 Disponibilidad
Especificación de los factores de disponibilidad final exigidos al sistema. Normalmente expresados
en % de tiempo en los que el software tiene que mostrar disponibilidad.

3.3.5 Mantenibilidad
Formateo del Sistema.

El Informático que es el que desarrolló el software tendrá conocimiento absoluto del sistema
donde podrá solucionar o mejorar funciones ante un eventual fallo o caída del sistema.

Especificación de cuándo debe realizarse las tareas de mantenimiento. Por ejemplo, generación de
estadísticas de acceso semanales y mensuales.

3.3.6 Portabilidad
Especificación de atributos que debe presentar el software para facilitar su traslado a otras
plataformas y entornos. Pueden incluirse:

− Porcentaje de componentes dependientes del servidor.

− Porcentaje de código dependiente del servidor.
− Uso de un determinado lenguaje por su portabilidad.
− Uso de un determinado compilador o plataforma de desarrollo.
− Uso de un determinado sistema operativo.

3.4 Otros Requisitos

Cualquier otro requisito que no encaje en otra sección.

14
 Especificación de Requisitos, estándar de IEEE 830

4. Propuesta de Planificación

4.1 Descripción general acerca de la Planificación

[Insertar una descripción de cómo se abordará el trabajo en cuanto a los días totales estimados y
las personas involucradas en su ejecución, las buenas prácticas y condiciones necesarias a
considerar para implementar para su buen término]

4.1.2 Definición del Equipo de Trabajo

Nuestro equipo de trabajo esta conformado por 4 integrantes teniendo en consideración los roles
asignados indicados en la siguiente tabla:

Nombre Integrante del Equipo Rol Definido

Jersson Ignacio Silva Soto Líder del Proyecto / Diseñador de Software

Romina Reyes Pino Gerente de Proyecto

Alejandro Rodrigo Opazo Navarrete Analista

Marcelo Antonio Flores Toledo Gestor

4.1.3 Definición de Actividades principales del Proyecto

[Descripción de las Principales fases y actividades que considera nuestra Programación de la
Planificación argumentando bajo que estándares y buenas prácticas se basan (Gestión de la
planificación PMI e Ingeniería de Software – es sólo enunciarlas]

4.1.4 Diagrama EDT

[Insertar la Estructura EDT en formato diagrama consolidada que resolviste con tu equipo]

15
 Especificación de Requisitos, estándar de IEEE 830

4.1.5 Carta Gantt

[Insertar y Describir la Carta Gantt resultante de la programación estimada a modo de
PLANIFICACIÓN donde se debe explicar la lógica aplicada para reducir el total de días lineales
resultantes en la EDT y como las llevaste a la economía de calendario de la Carta Gantt que
programaste con actividades paralelas y porqué.]

4.1.6 Resumen Costos del Desarrollo del Proyecto

[OBS.

Crear una tabla resumen extraída del EDT de cálculo de esfuerzo que desglose los principales
costos asociados al proyecto: en base a la Hora hombre y roles profesionales definidos

● Costo total base esfuerzo hora hombre

● Costos por FASE
● Costos por Actor o Rol

4.2 Plan de Control de Cambio

[Se recomienda primero describir los tipos de cambio que se podrán resolver y sus alcances]

[Insertar Tabla de Control de Cambios]

[ Obs.

Insertar Descripción de los aspectos del desarrollo en los que se permitirá aplicar cambios como
parte del Desarrollo del Software definiendo sus alcances y limitaciones asociadas.

El control de cambios es una actividad paralela al desarrollo del proyecto que responde a eventos
que surgen del mismo, sea por requerimientos propios del usuario o por mejoras o correcciones
detectadas por el mismo equipo del proyecto.

 Se describe de manera independiente de las demás fases de la metodología pues puede ser
aplicada indistintamente a proyectos en marcha o proyectos ya implementados, y porque es
necesario resaltar su importancia y no delegarla como una actividad posterior al desarrollo, sino
reconocerla como una actividad que debe estar definida, presente y es crítica desde el inicio del
proyecto.  Deberá describir qué tipo aspectos Funcionalidades y no funcionales se podrán
modificar con cambio, en qué instancia de proyecto se podrán aplicar y qué motivos los validaron
para ser aplicables y en qué caso no será posible aplicar cambios.

Luego esto se debe complementar con la observación de que en el anexo encontrarán la Planilla
de Control de Cambio con los Tipos de Cambio que podrán aplicarse en la cual posteriormente se
debe completar la planilla al ejecutarse la instancia. ]

16
 Especificación de Requisitos, estándar de IEEE 830

5. Anexos

5.1 Acta de Proyecto

Insertar Acta de Constitución del Proyecto

5.2 Matriz Especificación de Requerimientos

Matriz en formato planilla sobre la especificación de Requerimientos con su identificador y
columnas de datos correspondiente. RF1. O RNF.1

5.3 Diagrama de Casos de Uso General

Insertar Diagrama de Caso de Uso General.

5.4 Planilla Casos de Uso

Insertar Planilla detallada de Caso de Uso para cada Actor o acción clave del proceso que lleva el
sistema.

5.5 Prototipado de Software

Insertar Mockups y Warframe de las interfaz de usuario del Sistema

5.6 Resultado Análisis de Calidad Diagramas Modelamiento

Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de Análisis de
Calidad de modelado de Software.

5.7 Resultado Análisis de Calidad Prototipo No funcional del Sistema

Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de Análisis de
Calidad de Prototipo de Interfaz de Usuario.

5.8 Planilla entregables del Proyecto

Insertar la Planilla que define los Módulos y Artefactos asociados al Caso de Uso a los que se
pueden aplicar cambios en un punto de su desarrollo.

5.9 Matriz de Control de Cambios

Insertar la Planilla que define los Módulos y Artefactos asociados al Caso de Uso a los que se
pueden aplicar cambios en un punto de su desarrollo.

5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo

[Insertar matriz EDT en formato Planilla que nos permite realizar el cálculo de estimación de
esfuerzo en base a jornadas laborales.]

17