DUOC UC - Escuela de informática y telecomunicaciones

Propuesta de Proyecto
y Especificación de
Requisitos de Software
Proyecto: [Insertar Nombre de Proyecto]
Revisión: [01]
[Seleccionar fecha]

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. 4
1.2. 4
1.3. 4
1.4. 4
1.5. 4
2. 5
2.1. 5
2.2. 5
2.3. 5
2.4. 6
2.5. 6
2.6. 6
3. 7
3.1 7
3.1.1 7
3.1.2 7
3.1.3 7
3.1.4 7
3.2 7
3.3 7
3.3.1 8
3.3.2 8
3.3.3 8
3.3.4 8
3.3.5 8
3.3.6 8
3.4 8
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 Prototipado 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
Matias Serón Lider de proyecto / Gerente de Proyecto

Cesar Madariaga Ingeniero en software

Alex Meza Diseñador

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

1. Introducción
En esta sección se proporcionará una introducción a todo el documento de Especificación de
Requisitos Software (ERS). Consta de varias subsecciones: propósito, ámbito del sistema,
definiciones, referencias y visión general del documento.

1.1. Propósito
el propósito del sistema es una mejora ya que gracias a nuestro producto se logrará una mayor
facilidad de buscar y almacenar información de una manera correcta y segura

1.2. Ámbito del Sistema

• modernizando el sistema

• el sistema de fichas clinicas digitales sera capas de crear un historial clinico individual de cada
paciente que pase por los centros de salud donde se establecera nuestro proyecto haciendo asi un
mejora continua de los servicios de salud, conectando asi departamentos como atencion primaria
con farmacia.

• el principal beneficio como ya mencionamos anteriormente es crear un historial clínico

para cada paciente teniendo como objetivo conectar con este historial diversos departamentos de
salud como atención primaria con farmacia donde el paciente podrá ingresar su receta médica y el
farmacéutico pueda tener en la ficha clínica la misma información que el paciente acabando asi
con una cadena de problemas que generan las fichas clínicas en papel

1.3. Definiciones, Acrónimos y Abreviaturas

En esta subsección se definirán todos los términos, acrónimos y abreviaturas utilizadas en la ERS.

1.4. Referencias
En esta subsección se mostrará una lista completa de todos los documentos referenciados en la
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.

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

2. Descripción General
Nuestro proyecto parte de la base de modernizar el sistema actual de las fichas en papel, es decir,
crear una ficha electrónica bajo un software. Permitiendo a los usuarios de las diferentes áreas
conectarse entre ellas como por ejemplo conectar el área de las farmacias con el medico que
atendió al paciente. Generando un traspaso de la información correspondiente a los pacientes. Esta
información serán los datos de los pacientes que luego se almacenará en un base de datos, junto
con la ficha de este. Por consiguiente, en esta ficha clínica se va a almacenar la información de
farmacias, y de la cantidad de exámenes que se pueda llegar a efectuar el paciente. Finalizando con
guardar toda la información mencionada anteriormente en un historial clínico digital.
Además, cabe destacar, que este software será implementado y con ello estará
disponible para el personal de salud que se encuentra con la autorización de
entrar, generando con ello la capacidad de poder originar seguridad de la reserva
de datos que se encuentren. Dejando almacenado cada vez que haga ingreso
dicho personal al sistema, con la fecha y con lo que modifico dentro de la ficha
clínica del paciente.

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á 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

lo que se busca con la implantación del sistema es una mejora.

sus funciones más características se enfocarán en un mejor cuidado de informacion y al mismo
tiempo una mayor seguridad y una reducción de errores a nivel hospitalario en pocas palabras se
logrará un mayor orden al momento de buscar o registrar información de los pacientes

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

2.3. Características de los Usuarios

los usuarios que tendrán el acceso al producto son los que se emplearán en los diferentes
hospitales y que contaran con algún nivel de estudio en el área de la salud y que se encuentren
con el nivel de permiso al momento de tratar de ingresar y hacer un cambio

2.4. Restricciones
las diferentes restricciones se enfocarán en el cuidado y manejo de información de cada paciente
ya que esto tomara encuenta en que sector se está abriendo la ficha clínica y quien la está usando.

2.5. Suposiciones y Dependencias

aquí se observará cómo el usuario de los servicios de salud interactúan con la nueva ficha para ver
si están conformes y si es amigable con los trabajadores y si es necesario un cambio de algún
requisito mediante el uso de ella

2.6. Requisitos Futuros

Esto se tomará en cuenta al cabo de un tiempo y con una serie de estudios de cómo los
trabajadores han interactuado con la ficha en los diferentes tipos de servicio donde ellos la operan

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

3. Requisitos Específicos
este punto es uno de los más importantes ya que como trabajador se implementan
distintos requisitos que pide el cliente , ya como por ejemplo.

*Que sea legible

* Que cubra los diferentes factores que abarca las instituciones

*Que sea modificable

3.1 Requisitos comunes de las interfaces

ser funcionario del servicio de salud

3.1.1 Interfaces de usuario

el usuario tendrá la oportunidad de entrar a la ficha clínica dependiendo de su trabajo en el centro
de salud , logrando una mayor facilidad para el usuario donde podra encontrar un mayor registro
de cada paciente

3.1.2 Interfaces de hardware

tendrá la capacidad de guardar , editar y de ver los archivos del paciente dependiendo del área en
cual el funcionario trabaje

3.1.3 Interfaces de software

la ficha clínica poseerá diferentes funciones ,interfaces ,requisitos ,programas donde se podra
adecuar al uso que tiene cada sector de los hospitales ya sea como en el sector de leche o
urgencias.

3.1.4 Interfaces de comunicación

-windows 10 ,windows xp

3.2 Requisitos funcionales

-son los diferentes funciones que se pueden ejecutar en el sistema y que está a disposición del
usuaria , estas por lo general son

-tener la capacidad de editar

-guardar la información (autoguardado)

-imprimir

3.3 Requisitos no funcionales

seguridad, restricción de uso , usuario y contraseña

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

3.3.1 Requisitos de rendimiento

será capaz de poder tener una cantidad considerable de usuarios ya que se trata de un trabajo
donde habrá diferentes funciones y funcionarios realizandolas y que abarcara para todos los
diferentes sectores de los hospitales

3.3.2 Seguridad
el sistema poseerá:
− usuarios con contraseña
− Registro de cada actividad al momento de abrir la ficha
− un respaldo por una destrucción de información por algún agente externo
− diferentes permisos de acceso dependiendo del usuario
− etc

3.3.3 Fiabilidad
cada usuario poseerá un número determinado de errores al momento de estar dentro de la ficha
clínica y también se tendrá un respaldo por motivos de intento de hackeo o de eliminación de
información por error.

3.3.4 Disponibilidad
el usuario tendrá una disponibilidad de la ficha clínica en cualquier momento si se encuentra
dentro del servicio de salud y pasando por todos los requisitos de seguridad nombrados
anteriormente

3.3.5 Mantenibilidad
el sistema tendrá dos tipos de mantencion una cada 6 meses (para observar si se presenta algún
problema en el sistema ) y al momento de que el paciente recurra a los diferentes centros de salud
que posee la ficha clínica

3.3.6 Portabilidad
el servicio poseerá diferentes tipos de compatibilidad dependiendo de las especificaciones del
cliente al momento de la planificación del proyecto

3.4 Otros Requisitos

aqui se tratara de aplicar diferentes requisitos que no se tomaron en cuenta al momento de hacer
el producto es decir que si a los 6 meses de uso el cliente pide una mejora o pide una
implementación el sistema será capaz de ser modificado dependiendo de lo que pida el cliente

8
 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

Nombre Integrante del Equipo Rol Definido
Matias Serón

Cesar Madariaga

Alex Meza

[Describir el equipo de trabajo definido para el Proyecto e insertar Tabla de definición de Roles y
funciones]

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]

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.

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

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 relegarla 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 que tipo aspectos Funcionalidades y no funcionales se podrán modificar
con cambio, en que instancia de proyecto se podrán aplicar y que motivos los validarían 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. ]

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

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

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 Wareframe 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 Prototipado 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.]

11