Especificacin de Requisitos segn el estndar

de IEEE 830
IEEE Std. 830-1998

22 de Mayo de 2017

Resumen
Este documento presenta, en castellano, el formato de Especificacin de
Requisitos Software (ERS) segn la ltima versin del estndar IEEE 830. Segn
IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga
estrictamente la organizacin y el formato da- dos en el estndar 830, si deber incluir,
de una forma o de otra, toda la informacin presentada en dicho estndar. El
estndar de IEEE 830 no est libre de defectos ni de prejuicios, y por ello ha sido
justamente criticado por mltiples autores y desde mltiples puntos de vista,
llegndose a cuestionar incluso si es realmente un estndar en el sentido habitual que
tiene el termino en otras ingenieras. El presente documento no pretende
pronunciarse ni a favor ni en contra de unos u otros: tan solo reproduce, con
propsitos fundamentalmente docentes, como se organizara un Documento de
Requisitos segn el estndar IEEE 830.
INDIC 2
E

ndice
1. Introduccin 3
1.1. Propsito 3
1.2. mbito del Sistema 3
1.3. Definiciones, Acrnimos y Abreviaturas 4
1.4. Referencias 4
1.5. Visin General del Documento 4

2. Descripcin General 4
2.1. Perspectiva del Producto 4
2.2. Funciones del Producto 4
2.3. Caractersticas de los Usuarios 6
2.4. Restricciones 6
2.5. Suposiciones y Dependencias 6
2.6. Requisitos Futuros 6

3. Requisitos Especficos 6
3.1. Interfaces Externas 7
3.2. Funciones 8
3.3. Requisitos de Rendimiento 9
3.4. Restricciones de Diseo 9
3.5. Atributos del Sistema 9
3.6. Otros Requisitos 10
1 INTRODUCCIO 3
N
1. Introduccin
Este documento describe la Especificacin de Requerimientos de
Software (ERS) de la aplicacin web de gestin y control del expediente
mdico para los pacientes de medicina general y odontologa de la ESPAM,
en la cual se proyecta para ser utilizada como un manual durante el
desarrollo y posterior implementacin. Tambin se describe cada uno de los
requerimientos, que se lograron obtener de la investigacin realizada, las
caractersticas del sistema, lo que debe y no realizar, adems se definen los
requerimientos tecnolgicos necesarios para el buen funcionamiento del
sistema.

Esta ERS podr ser utilizada como descripcin, para obtener

informacin sobre la administracin, funcionamiento y mantenimiento,
tambin contendr informacin relevante como gua para cualquier otro
desarrollador, necesite realizar mejoras o modificaciones del subsistema.

1.1. Propsito
El propsito de este documento es registrar los procesos y caractersticas
definidas que debe cumplir el software, de tal forma que estos requisitos
puedan ser verificados y validados objetivamente.

1.2. mbito del Sistema

HEALTHSYS (Sistema de Gestin y Control de Expediente Mdico) es
un mdulo web que se integrara al sistema general de la ESPAM, para
mejorar los procesos referentes a la gestin y control del registro de la ficha
medica de los pacientes de la Universidad.

El objetivo principal de HEALTHSYS es gestionar el historial clnico para

optimizar la atencin de los pacientes en el departamento mdico de la
Escuela Superior Politcnica Agropecuaria de Manab.

Algunas funciones principales que debe realizar este sistema son las
siguientes:

Gestionar correctamente las diferentes cuentas de usuario segn

los perfiles que se establezcan incrementando la seguridad e integridad de la
informacin que maneja la aplicacin.
1 INTRODUCCIO 4
N Permitir al Mdico administrar la identificacin de historiales
clnicos de sus pacientes y obtener reportes instantneos de sus citas
realizadas, suspendidas, pendientes o eliminadas; independientemente del
lugar donde se encuentre.

Permitir al paciente hacer una cita online al centro mdico, as

como su identificacin del historial clnico o expediente de forma
personalizada.

Emitir informes cuando los usuarios, directivos o pacientes lo

necesiten (diarios, semanales, mensuales, etc.).

1.3. Definiciones, Acrnimos y Abreviaturas

Abreviaturas:

UPS: Unidad de Produccin de Software.

ERS: Especificacin de requerimientos de software.

Definiciones:

Cliente. - Organizacin, persona o personas que definen los

requerimientos, operan o interactan directamente con el software.

Gua. - Manual o conjunto de indicaciones que sirven para

orientarse.

Pacientes. - Individuo que es examinado medicamente o al que se

administra un tratamiento, en este caso a los estudiantes, docentes,
administrativos y comunidad cercana a la ESPAM MFL.

1.4. Referencias
IEEE (Institute of Electrical and Electronics Engineers), 2009. IEEE
Recommended Practice for Software Requirements Specifications Standard
IEEE-830-1998. New York, USA.
2 DESCRIPCIO N 4
GENERAL
1.5. Visin General del Documento
El siguiente documento muestra informacin sobre los requisitos de
la aplicacin web, de manera general, lo que permitir al usuario operar
con mucha facilidad el sistema. Entre los temas generales del documento
se detallarn los requerimientos especficos del sistema de manera
profunda, para permitir un diseo del sistema que cumplan las
necesidades del usuario y luego realizar pruebas que corroboren que el
sistema efectu los requisitos planteados en este documento.

2. Descripcin General

La perspectiva de HEATLSYS es agilizar y simplificar el trabajo que se

realiza en los departamentos de Medicina General y Odontologa que la
ESPAM MFL posee, adems de hacerlo mucho ms ordenado y seguro,
cambiando en papel a informacin digital, lo que a su vez tambin ayuda a
ahorrar espacio en los consultorios.
Este producto tiene como funcionalidad llevar un control adecuado de
todos los procesos concernientes en la administracin online de citas
mdicas.
Los usuarios del sistema estarn divididos en:
- Usuario Administrador
- Usuario Doctor
- Usuario Paciente
Las caractersticas de los usuarios se indican en el punto 2.3 de este
documento.
En cuanto a los factores de seguridad se utilizar un sistema de logueo
para restringir ciertas partes de la aplicacin a los usuarios de la misma,
permitiendo solo el acceso total al usuario master.

2.1. Perspectiva del Producto

HEALTHSYS es una aplicacin web independiente de la ESPAM
MFL, que ser desarrollada como requerimiento de parte de
Vicerrectorado de bienestar politcnico. Est orientado a la gestin y
control del historial clnico de los estudiantes de la institucin.

2.2. Funciones del Producto

HEALTHSYS deber contar con procesos necesarios para la correcta
gestin de los servicios mdicos que se realizan en los departamentos de
 2 DESCRIPCIO N 5
GENERALGeneral y Odontologa en la ESPAM MFL. Mediante el acuerdo
Medicina
que se efectu con la Vicerrectora de Extensin y Bienestar, el Sistema
estar conformado de las siguientes funciones:

-Atencin mdica para los estudiantes y personal administrativo de la ESPAM

MFL,
-Registro del historial mdico de cada estudiante de la universidad basndose
en el formato que entrego la Vicerrectora de Extensin y Bienestar al equipo
de desarrollo,
-La descripcin mdica deber contar con el diagnstico de la enfermedad en
base a la nomenclatura internacional,
-Certificacin mdica,
-Recetarios,
-Funcin de realizar derivaciones mdicas en base al UNI CDIGO de los
centros hospitalarios,
-Prescripcin mdica,
-Agendamiento de citas,
-Farmacia,
-Suministros mdicos,
-Reportera:
Reporte atencin mdica por Carrera,
Reportes de atenciones por diagnstico,
Reporte de historial clnico en el sistema acadmico,
Otros reportes necesarios por los doctores.
2.3. Caractersticas de los Usuarios

Existen tres tipos de usuarios los cuales participaran en el uso de la aplicacin

web:

Usuario master: la persona que ser usuario master deber contar con nivel de
educacin profesional y conocimientos informticos avanzados ya que es el que
controlara la aplicacin empleando mantenimiento o configuraciones para conservar
el correcto funcionamiento del sistema. Su experiencia es de gran apoyo al momento
de efectuar dichos trabajos.

Usuario administrador: su nivel educacional estar basado acerca de las ciencias

mdicas y estudios odontolgicos de nivel profesional ya que la aplicacin web va
dirigida a los departamentos de Medicina General y Odontologa de la institucin.
adems, deber contar con experiencia tcnica para utilizar el sistema y gestionar los
datos necesarios para la consulta al paciente.

Usuario paciente: este usuario podr variar en lo que respecta su nivel

educacional y su experiencia tcnica (alto, medio y bajo), ya que utilizar el sistema
para obtener informacin sobre su historial mdico y odontolgico para su uso
personal.

2.4. Restricciones
Cada usuario tiene varios tipos de restricciones, a diferencia del primer usuario.
Se indica lo siguiente:

Para el usuario master, que son los encargados de mantenimiento y

actualizaciones del sistema, no tendrn restricciones de ningn tipo, ya que ellos
tendrn privilegios de administracin sobre la aplicacin y podrn acceder al cdigo
fuente del mismo.

El usuario administrador, en este caso los mdicos de cada departamento

(Medicina General y Odontologa), podrn acceder a toda la aplicacin web donde se
realizarn las gestiones y procesos que se efectan en un consultorio mdico. Estarn
restringidos del cdigo fuente de la aplicacin

El usuario paciente si tendr restringido una gran parte de la aplicacin ya que

solo podrn acceder a su historial mdico y odontolgico por medio de la pgina
oficial de la ESPAM MFL (espam.edu.ec), para obtener su informacin si requiere del
uso de la misma.

2.5. Suposiciones y Dependencias

 La implementacin de un nuevo reglamento que afecte los procesos que
se realizan en los departamentos de medicina y odontologa de la institucin.

El sistema debe interactuar con navegadores web de terceros, por lo cual

algn cambio o actualizacin en ellos puede afectar en el diseo o uso de
elementos vinculados al mismo.
 3 REQUISITOS ESPEC 6
IFICOS

2.6. Requisitos Futuros

Los requisitos planteados pueden ser posibles mejoras, que luego de
estudio y anlisis pueden generar cambios en el sistema:

- Mejoras en la plantilla del sistema general de la institucin.

- Implementacin de nuevos mecanismos de seguridad en el ingreso del

sistema.

3. Requisitos Especficos

Esta seccion contiene los requisitos a un nivel de detalle suficiente

como para permitir a los disenadores disenar un sistema que satisfaga
estos requi- sitos, 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 es- pecificado describira comportamientos externos del
sistema, perceptibles por parte de los usuarios, operadores y otros
sistemas. Esta es la seccion mas larga e importante de la ERS. Deberan
aplicarse los siguientes principios:

El documento debera ser perfectamente legible por personas de

muy distintas formaciones e intereses.

Deberan referenciarse aquellos documentos relevantes que poseen algu-

na influencia sobre los requisitos.

Todo requisito debera ser unvocamente identificable mediante algun

codigo o sistema de numeracion adecuado.

Lo ideal, aunque en la practica no siempre realizable, es que los

requi- sitos posean las siguientes caractersticas:

Correccion: La ERS es correcta si y solo si todo requisito

que figura aqu (y que sera implementado en el sistema) refleja
alguna necesidad real. La correccion de la ERS implica que
el sistema implementado sera el sistema deseado.
3 REQUISITOS ESPEC 7
IFICOS No ambiguos: Cada requisito tiene una sola interpretacion.
Para eliminar la ambiguedad inherente a los requisitos
expresados en lenguaje natural, se deberan utilizar graficos o
notaciones forma- les. En el caso de utilizar terminos que,
habitualmente, poseen mas de una interpretacion, se definiran
con precision 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 validos como no validos.
 Consistentes: Los requisitos no pueden ser contradictorios. Un
con- junto 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 (cam- bios 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 solo si todos sus
requisitos son verificables. Un requisito es verificable
(testeable) si existe un proceso finito y no costoso para
demostrar que el sistema cumple con el requisito. Un requisito
ambiguo no es, en general, verifi- cable. Expresiones como a
veces, bien, adecuado, etc. introducen ambiguedad en los
requisitos. Requisitos como en caso de acci-
dente la nube toxica no se extendera mas alla de 25Km no es
verificable por el alto costo que conlleva.
Modificables: La ERS es modificable si y solo si se encuentra
es- tructurada de forma que los cambios a los requisitos
pueden rea- lizarse de forma facil, completa y consistente. La
utilizacion de herramientas automaticas de gestion de
requisitos (por ejemplo RequisitePro o Doors) facilitan
enormemente esta tarea.
Trazables: La ERS es trazable si se conoce el origen de cada
requi- sito y se facilita la referencia de cada requisito a los
componentes del diseno y de la implementacion. La
trazabilidad hacia atras indica el origen (documento, persona,
etc.) de cada requisito. La trazabilidad hacia delante de un
requisito R indica que compo- nentes del sistema son los que
realizan el requisito R.

3.1. Interfaces Externas

INTERFACES CON EL HARDWARE

El usuario ser capaz de utilizar la aplicacin en Windows, Linux y OSX.

El usuario ser capaz de utilizar la aplicacin sin necesidad de instalacin

de cualquier SO adicional, excepto el navegador web.
 Tecnologa mnima que debe disponer el servidor.

Las caractersticas mnimas que debe de tener el servidor para que pueda
soportar las herramientas y permita funcionar la aplicacin son los
siguientes:

Procesador Pentium Dual Core 1.7. GHz.

Memoria RAM de 1 GB.

Disco Duro de 50 Gb-

Tarjeta de Red 10/100 Mbps

Monitor, mouse, teclado, CD-ROM

Tecnologa mnima que debe disponer los clientes (HOST).

Las caractersticas mnimas que debe de tener los computadores de los

usuarios-clientes para que pueda funcione correctamente el mdulo web:

Procesador Pentium III 700 MHz.

Memoria RAM de 128 Mb.

Disco Duro de 15 Gb-

Tarjeta de Red 10/100 Mbps

Monitor, mouse, teclado.

INTERFACES DE COMUNICACIN

El Sistema ser accedido de manera implcita por el usuario final, a travs de

una comunicacin por internet.

El protocolo de comunicacin a usar es TCP/IP y sobre este protocolo se

manejar un sistema Web definido por protocolos de la World Wide Web
Consortium [w3c2010] (23).

3.2. Funciones
especificar
Esta subseccion (quiza la mas larga del documento)
debera

todas aquellas acciones (funciones) que debera llevar a cabo el software. Nor-
malmente (aunque no siempre), son aquellas acciones expresables como
el sistema debera . . . . Si se considera necesario, podran utilizarse
notaciones graficas y tablas, pero siempre supeditadas al lenguaje natural, y
no al reves. Es importante tener en cuenta que, en 1983, el Estandar de
IEEE 830 estableca que las funciones deberan expresarse como una jerarqu
a funcional (en paralelo con los DFDs propuestos por el analisis
estructurado). Pero el Estandar de IEEE 830, en sus ultimas versiones,
ya permite organizar esta
subseccion de multiples formas, y sugiere, entre otras, las siguientes:

Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Pa-

ra cada clase de usuario que exista en la organizacion, se especificaran
los requisitos funcionales que le afecten o tengan mayor relacion
con sus tareas.

Por objetos: Los objetos son entidades del mundo real que seran
refle- jadas en el sistema. Para cada objeto, se detallaran sus
atributos y sus funciones. Los objetos pueden agruparse en clases.
Esta organizacion de la ERS no quiere decir que el diseno del
sistema siga el paradigma de Orientacion a Objetos.

Por objetivos: Un objetivo es un servicio que se desea que ofrezca el

sistema y que requiere una determinada entrada para obtener su
resul- tado. Para cada objetivo o subobjetivo que se persiga con el
sistema, se detallaran las funciones que permitan llevarlo a cabo.

Por estmulos: Se especificaran los posibles estmulos que recibe el

sis- tema y las funciones relacionadas con dicho estmulo.

Por jerarqua funcional: Si ninguna de las anteriores alternativas resulta

de ayuda, la funcionalidad del sistema se especificara como una jerar-
qua de funciones que comparten entradas, salidas o datos
internos. Se detallaran las funciones (entrada, proceso, salida) y las
subfunciones del sistema. Esto no implica que el diseno del
sistema deba realizarse segun el paradigma de Diseno
Estructurado.

Para organizar esta subseccion de la ERS se elegira alguna de las ante-

riores alternativas, o incluso alguna otra que se considere mas conveniente.
Debera, eso s, justificarse el porque de tal eleccion.
 9

3.3. Requisitos de Rendimiento

No se han determinado Requisitos de eficiencia, aunque es recomendable
que se intente optimizar todo lo posible el servidor web Microsoft IIS y la
base de datos Microsoft SQL Server, puesto que HealthSys es una aplicacin
web donde tendrn acceso muchos usuarios y se llevaran a cabo diferentes
procesos con mucha informacin.

3.4. Restricciones de Diseo

El desarrollo de la aplicacin tiene ciertas restricciones bajo las cuales se
debe llevar a cabo el proceso de diseo. A continuacin, se enlistan las
restricciones relacionadas con el diseo:

El anlisis y diseo de la aplicacin se hace bajo los principios de

paradigma Programacin por tres capas (datos, negocio, presentacin).

El lenguaje de programacin, en coherencia con el paradigma, es C#.

Adicionalmente se elige este lenguaje de programacin porque dentro de los
que estn orientados a objetos es el que el equipo de desarrollo maneja con
mayor destreza.

3.5. Atributos del Sistema

HEALTHSYS ser una aplicacin web fiable al momento de manejar toda

clase de informacin que es necesaria para la toma de datos de los
pacientes, adems de la seguridad que se empleara para cada uno de los
tipos de usuarios. El mantenimiento del sistema se realizar siempre y
cuando existan cambios que se desean aplicar y as obtener un producto
actualizado conforme transcurre el tiempo de uso. tambin, HEALTHSYS
ser un software cmodo gracias a su diseo agradable, lo que facilitar
los procesos para los usuarios.
Los usuarios que estarn autorizados para realizar varios tipos de tareas
estn divididos en 3 tipos:
- Usuario master: es la persona que desarrolla el front-end y el back-end
de la aplicacin, es decir, una vez entregado el sistema, el usuario
master ser el encargado de realizar el mantenimiento respectivo al
mismo.
- Usuario administrador: es la persona que se encargara de gestionar
todos los procesos que se realizan en los departamentos (Medicina
 1
General y Odontologa) por medio de la aplicacin web,0
automatizndose el procedimiento gracias al mismo.
- Usuario paciente: son todas las personas que desean revisar su
historial clnico, el cual ingresara por medio de una opcin en la pgina
oficial de la ESPAM MFL (espam.edu.ec).
Todos los usuarios mencionados anteriormente contaran con
mecanismos de seguridad, es decir, a cada uno se le proporcionara un
login y una password, por medio del cual podrn utilizar la aplicacin
web y realizaran las respectivas tareas en el mismo.

3.6. Otros Requisitos

No se especifica otro tipo de requisito.