Parra Urrea, Alfredo

Universidad del Bío-Bío.
Red de Bibliotecas - Chile
Universidad del Bío-Bío
Facultad de Ciencias Empresariales
Escuela de Ingeniería Civil Informática
“Especificación de requisitos de software para

el sistema de ficha clínica del CECH.”
Alumno: Alfredo Parra Urrea
Profesor guía: Angélica Caro Gutiérrez
Memoria de Grado para optar al título de Ingeniero Civil en

Informática.
1
Universidad del Bío-Bío. Red de Bibliotecas - Chile
Resumen
Este proyecto se presenta para dar conformidad a los requisitos exigidos por la Universidad del
Bío-Bío en el proceso de titulación para a la carrera de Ingeniería Civil Informática. El proyecto
se titula “Especificación de requisitos de software para el sistema de ficha clínica del CECH”.
El Centro de Estudios de la Comunicación Humana (CECH), es un centro clínico de la Escuela

de Fonoaudiología de la Universidad del Bío Bío. Se encuentra ubicado en el Campus
Fernando May, Chillán, Provincia de Ñuble en la octava región de Chile. Comenzó su
funcionamiento en 2011, para atender de manera gratuita a la comunidad que presenta
alteraciones fonoaudiológicas y poseen un acceso limitado a esta atención.
En este trabajo, se desea plasmar una elicitación de requisitos para el desarrollo de un

software de ficha clínica. Con el objetivo de describir todas las funcionalidades y necesidades
solicitadas por el cliente, para la posterior elaboración de un sistema informático que
permita llevar el control de la información de los pacientes del CECH, a la vez que nos
permita administrar una agenda electrónica para coordinar atenciones de los pacientes y
además que este sistema, entregué información estadística de las atenciones prestadas en el
centro.
Para realizar el levantamiento de requisitos se utiliza el método VOLERE, el cuál fue

seleccionado, previo a un estudio, entre varias metodologías de elicitación de requisitos de
software.
Los beneficios que se destacan en este informe, son entregar prototipos y la especificación de
cada requerimiento, con tal de facilitar la información a los diseñadores y desarrolladores
que vengan más adelante a construir el software final.
2
Índice General
1 INTRODUCCIÓN.............................................................................................................................. 8
2 DEFINICION DE LA EMPRESA O INSTITUCIÓN ................................................................................. 9
2.1 DESCRIPCIÓN DE LA EMPRESA ........................................................................................................ 9
2.2 DESCRIPCIÓN DEL ÁREA DE ESTUDIO .............................................................................................. 9
2.3 DESCRIPCIÓN DE LA PROBLEMÁTICA .............................................................................................. 9
3 DEFINICIÓN PROYECTO ................................................................................................................ 11
3.1 OBJETIVOS DEL PROYECTO .......................................................................................................... 11
3.1.1 OBJETIVO GENERAL .............................................................................................................................. 11
3.1.2 OBJETIVOS ESPECÍFICOS........................................................................................................................ 11
3.2 AMBIENTE DE INGENIERÍA DE SOFTWARE..................................................................................... 11
3.2.1 INGENIERÍA DE REQUISITOS. ................................................................................................................. 11
3.2.2 METODOLOGÍA PARA REALIZAR LA ELICITACIÓN DE REQUISITOS. ........................................................... 13
3.2.3 MÉTODO VOLERE ............................................................................................................................... 15
3.2.4 HERRAMIENTAS Y TECNOLOGÍAS A UTILIZAR ......................................................................................... 20
3.3 DEFINICIONES, SIGLAS Y ABREVIACIONES ..................................................................................... 20
4 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE ................................................................ 22
4.1 ETAPA: PROYECTO BLASTOFF ..................................................................................................... 22
4.1.1 PROPÓSITO DEL PROYECTO ................................................................................................................... 22
4.1.2 EL CLIENTE........................................................................................................................................... 23
4.1.3 USUARIOS DEL PRODUCTO..................................................................................................................... 23
4.2 RESTRICCIONES OBLIGATORIAS DEL PROYECTO ............................................................................ 23
4.2.1 RESTRICCIONES OBLIGATORIAS............................................................................................................. 24
4.2.2 AMBIENTE DE IMPLEMENTACIÓN DEL SISTEMA ACTUAL ........................................................................ 24
4.2.3 RESTRICCIONES CRONOLÓGICAS ............................................................................................................ 24
4.3 ETAPA: CAPTURA DE REQUISITOS. ............................................................................................... 25
4.3.1 ALCANCES DEL PRODUCTO ....................................................................................................................... 25
4.4 ETAPA DE ESCRITURA Y PROTOTIPOS DE REQUISITOS .................................................................... 28
4.4.1 REQUERIMIENTOS FUNCIONALES .......................................................................................................... 29
4.4.2 REQUISITOS NO FUNCIONALES .................................................................................................................. 62
4.4.3 LISTA DE CASOS DE USO DEL PRODUCTO .................................................................................................... 63
4.4.4 MATRIZ RESUMEN DE CASOS DE USO Y REQUERIMIENTOS. ........................................................................... 93
4.5 ETAPA DE CONTROL DE CALIDAD. ...................................................................................................... 94
4.6 ETAPA REVISIÓN DE REQUISITOS. ...................................................................................................... 94
5 ANÁLISIS ...................................................................................................................................... 95
5.1 MODELO DE DATOS CONCEPTUAL ................................................................................................ 95
6 RESUMEN ESFUERZO REQUERIDO................................................................................................ 97
7 CONCLUSIONES ............................................................................................................................ 98
8 BIBLIOGRAFÍA .............................................................................................................................100
9 ANEXO: PLANIFICACIÓN INICIAL DEL PROYECTO .........................................................................101
10 ANEXO: PROTOCOLOS CECH......................................................................................................102
3
10.1 PROTOCOLOS CUANTITATIVOS .................................................................................................102

10.1.1 DOMINIO ACE-R-CH ........................................................................................................................ 102
10.1.2 I.T.P.A.............................................................................................................................................. 103
10.1.3 I.D.E.A. ............................................................................................................................................ 103
10.1.4 MINI MENTAL .................................................................................................................................. 104
10.1.5 MOCA .............................................................................................................................................. 104
10.1.6 EVALUACIÓN FONOAUDIOLÓGICA 4 AÑOS A 4 AÑOS 11 MESES .......................................................... 104
10.1.7 EVALUACIÓN FONOAUDIOLÓGICA 5 AÑOS A 6 AÑOS 11 MESES .......................................................... 105
10.1.8 EVALUACIÓN FONOAUDIOLÓGICA 7 AÑOS A 12 AÑOS ........................................................................ 105
10.1.9 PROTOCOLO DE EVALUACIÓN DEL HABLA (RAFAEL GONZÁLEZ) ....................................................... 105
10.1.10 PROTOCOLO DE EVALUACIÓN DEL HABLA....................................................................................... 106
10.1.11 S.L.A. ............................................................................................................................................. 106
10.1.12 TECAL .......................................................................................................................................... 107
10.1.13 PROTOCOLO TEVI............................................................................................................................. 107
10.1.14 VALORACIÓN Y PROTOCOLOS TOKEN TEST ..................................................................................... 107
10.1.15 PROTOCOLO DE TEST DE WEPMAN .............................................................................................. 107
10.2 PROTOCOLOS CUALITATIVOS ...................................................................................................108
10.2.1 EVALUACIÓN DISFEMIA INFANTIL...................................................................................................... 108
10.2.2 PROTOCOLO EVALUACIÓN MIOFUNCIONAL: ....................................................................................... 108
10.2.3 FICHA EVALUACIÓN RIESGO VOCAL.................................................................................................... 108
10.2.4 EVALUACIÓN VOCAL INFANTIL – CAROLA RIVERA ............................................................................. 109
10.2.5 EVALUACIÓN VOCAL INFANTIL, UBB................................................................................................. 109
10.2.6 EVALUACIÓN CLÍNICA DE LA DEGLUCIÓN ........................................................................................... 109
10.2.7 PAUTA DE EVALUACIÓN PARA TARTAMUDEZ..................................................................................... 110
10.2.8 PROTOCOLO QVV ............................................................................................................................. 110
10.2.9 PROTOCOLO DE EVALUACIÓN DE LA INSUFICIENCIA VELOFARINGEA ................................................... 110
10.2.10 EVALUACIÓN FONOAUDIOLÓGICA CLÍNICA DE LA DISFAGIA OROFARÍNGEA POST-AVE ....................... 110
10.2.11 Q-CHAT........................................................................................................................................ 110
10.2.12 SCREENING TEST OF SPANISH GRAMMAR – S. T. S. G. (COMPRENSIVO) ........................................... 111
10.2.13 SCREENING TEST OF SPANISH GRAMMAR – S. T. S. G. (EXPRESIVO) ................................................ 111
10.2.14 S.A.F.............................................................................................................................................. 111
10.2.15 T.A.R ............................................................................................................................................. 111
10.2.16 T.D.P.E.A....................................................................................................................................... 112
10.2.17 TEPROSIF .................................................................................................................................... 112
11 ANEXO: DIAGNÓSTICOS DEL CECH ............................................................................................113
11.1 TRASTORNOS DEL LENGUAJE EN EL NIÑO (1-7)..................................................................................113
11.2 TRASTORNOS DEL LENGUAJE ADULTO (8-12)....................................................................................114
11.3 TRASTORNOS AUDIOLÓGICOS (13-15) ............................................................................................115
11.4 TRASTORNOS DE LA VOZ (16-19)...................................................................................................116
11.5 TRASTORNOS DEL HABLA Y LA DEGLUCIÓN (20-35) ...........................................................................117
12 ANEXO: CARTA DE APROBACIÓN DE PROYECTO. ......................................................................118
4
Índice Tablas
Tabla 3. 1: Resumen de Metodologías estudiadas. ....................................................................................................... 14
Tabla 3. 2: Descripción gráfica de la Shell de VOLERE(Robertson & Robertson, 2000). ......................... 18
Tabla 4. 1: Usuarios finales del sistema. ............................................................................................................................. 23
Tabla 4. 2: Requerimiento verificar usuario .................................................................................................................... 30
Tabla 4. 3: Requerimiento crear perfil de usuario. ....................................................................................................... 32
Tabla 4. 4: Requerimiento buscar paciente. ..................................................................................................................... 35
Tabla 4. 5: Requerimiento ingresar nuevo paciente.................................................................................................... 37
Tabla 4. 6: Requerimiento crear ficha clínica. ................................................................................................................. 39
Tabla 4. 7: Requerimiento adjuntar consentimiento informado. ......................................................................... 44
Tabla 4. 8: requerimiento programa fonoaudiológico. .............................................................................................. 46
Tabla 4. 9: Requerimiento registrar examen................................................................................................................... 48
Tabla 4. 10: Requerimiento Generar reporte. ................................................................................................................. 52
Tabla 4. 11: Requerimiento asignar horario a paciente............................................................................................. 54
Tabla 4. 12: Requerimiento mostrar agenda horaria del centro........................................................................... 56
Tabla 4. 13: Requerimiento editar registros erróneos. .............................................................................................. 58
Tabla 4. 16: Requerimiento para resguardar la información histórica. ............................................................ 60
Tabla 4. 14: Requerimiento para la visualización del sistema. .............................................................................. 62
Tabla 4. 15: Requerimiento control acceso a estudiantes. ....................................................................................... 62
Tabla 4. 17: Flujo de eventos básicos, login...................................................................................................................... 63
Tabla 4. 18: Flujo de eventos básicos, crear usuario. .................................................................................................. 64
Tabla 4. 19: Flujo de eventos básicos, generar reporte.............................................................................................. 65
Tabla 4. 20: Flujo de eventos básicos, registrar paciente.......................................................................................... 66
Tabla 4. 21: Flujo de eventos básicos, crear ficha clínica. ......................................................................................... 67
Tabla 4. 22: Flujo de eventos básicos, agregar consentimiento informado. ................................................... 68
Tabla 4. 23: Flujo de eventos básicos, listar y buscar paciente. ............................................................................. 69
Tabla 4. 24: Flujo de eventos básicos, ver ficha paciente. ......................................................................................... 71
Tabla 4. 25: Flujo de eventos básicos, agregar informe fonoaudiológico. ........................................................ 72
Tabla 4. 26: Flujo de eventos básicos, agregar historial a ficha clínica. ............................................................. 74
Tabla 4. 27: Flujo de eventos básicos, ver horario. ....................................................................................................... 75
Tabla 4. 28: Flujo de eventos básicos, reservar horario paciente......................................................................... 76
Tabla 4. 29: Flujo de eventos básicos, editar.................................................................................................................... 77
Tabla 4. 30: Flujo de eventos básicos, ver exámenes. ................................................................................................. 78
Tabla 4. 31: Flujo de eventos básicos, ver perfil............................................................................................................. 79
Tabla 4. 32: Flujo de eventos básicos, cambiar contraseña. .................................................................................... 79
Tabla 4. 33: Flujo de eventos básicos, realizar examen. ............................................................................................ 80
Tabla 4. 34: Flujo de eventos básicos, reporte agenda. .............................................................................................. 81
Tabla 4. 35: Flujo de eventos básicos, editar usuario.................................................................................................. 82
Tabla 4. 36: Flujo de eventos básicos, logout................................................................................................................... 83
Tabla 4. 37: Flujo de eventos básicos, modificar horario paciente. ..................................................................... 84
Tabla 4. 38: Flujo de eventos básicos, Protocolos cualitativos. .............................................................................. 85
Tabla 4. 39: Flujo de eventos básicos, Protocolos cuantitativos............................................................................ 86
Tabla 4. 40: Flujo de eventos básicos, Programa fonoaudiológico....................................................................... 88
Tabla 4. 41: Flujo de eventos básicos, ingresar un objetivo..................................................................................... 90
Tabla 4. 43: Tabla matriz de relación casos de uso con requerimientos. ........................................................ 93
5
Tabla 6. 1: Resumen esfuerzo requerido. .......................................................................................................................... 97

Tabla 9. 1: Carta Gantt............................................................................................................................................................... 101
Tabla 10. 1: Datos requeridos protocolo: ACE-R-Ch................................................................................................. 102
Tabla 10. 2: Datos requeridos protocolo: L.T.P.A. ...................................................................................................... 103
Tabla 10. 3: Datos requeridos protocolo: I.D.E.A........................................................................................................ 103
Tabla 10. 4: Datos requeridos protocolo: Mini mental............................................................................................ 104
Tabla 10. 5: Datos requeridos protocolo: MoCA. ........................................................................................................ 104
Tabla 10. 6: Datos requeridos protocolo: Ev. Fonoaudiológica 4 a 4,11 años............................................. 104
Tabla 10. 7: Datos requeridos protocolo: Ev. Fonoaudiológica 5 a 6,11 años............................................. 105
Tabla 10. 8: Datos requeridos protocolo: Ev. Fonoaudiológica 7 a 12 años. ............................................... 105
Tabla 10. 9: Datos requeridos protocolo: Ev. Del Habla (Rafael González). ................................................. 105
Tabla 10. 10: Datos requeridos protocolo: Ev. Del Habla....................................................................................... 106
Tabla 10. 11: Datos requeridos protocolo: S.L.A......................................................................................................... 106
Tabla 10. 12: Datos requeridos protocolo: TECAL. ................................................................................................... 107
Tabla 10. 13: Datos requeridos protocolo: TEVI. ....................................................................................................... 107
Tabla 10. 14: Datos requeridos protocolo: Valoración y Protocolo Token Test. ....................................... 107
Tabla 10. 15: Datos requeridos protocolo: Test de WEPMAN. ........................................................................... 107
Tabla 10. 16: Datos requeridos protocolo: Ev. Disfamia infantil........................................................................ 108
Tabla 10. 17: Datos requeridos protocolo: Ev. Miofuncional. .............................................................................. 108
Tabla 10. 18: Datos requeridos protocolo: Ev. Riesgo vocal................................................................................. 108
Tabla 10. 19: Datos requeridos protocolo: Ev. Vocal Infantil (Carola Rivera). ........................................... 109
Tabla 10. 20: Datos requeridos protocolo: Ev. Vocal Infantil (UBB). ............................................................... 109
Tabla 10. 21: Datos requeridos protocolo: Ev. Clínica de la deglución. .......................................................... 109
Tabla 10. 22: Datos requeridos protocolo: Ev. Tartamudez................................................................................. 110
Tabla 10. 23: Datos requeridos protocolo: QVV.......................................................................................................... 110
Tabla 10. 24: Datos requeridos protocolo: Ev. De la insuficiencia velofaringea. ....................................... 110
Tabla 10. 25: Datos requeridos protocolo: Ev. Fonoaudiológica de la disfagia orofaringea post-ave.
............................................................................................................................................................................................................... 110
Tabla 10. 26: Datos requeridos protocolo: Q-CHAT. ................................................................................................ 110
Tabla 10. 27: Datos requeridos protocolo: S.T.S.G comprensiva. ...................................................................... 111
Tabla 10. 28: Datos requeridos protocolo: S.T.S.G expresivo. ............................................................................. 111
Tabla 10. 29: Datos requeridos protocolo: S.A.F......................................................................................................... 111
Tabla 10. 30: Datos requeridos protocolo: T.A.R........................................................................................................ 111
Tabla 10. 31: Datos requeridos protocolo: T.D.P.E.A................................................................................................ 112
Tabla 10. 32: Datos requeridos protocolo: TEPROSIF............................................................................................. 112
6
Índice Figuras
Figura 3. 1: Mapa simplificado del proceso de requisitos de VOLERE. Fuente: (Robertson &
Robertson, 2000). .......................................................................................................................................................................... 16
Figura 4. 1 Modelo de Caso de Uso: Estudiante. Fuente: propia del autor....................................................... 26

Figura 4. 2: Modelo de Caso de Uso: Administrador. Fuente: propia del autor............................................. 27
Figura 4. 3: Modelo de Caso de Uso: Fonoaudiólogo. Fuente: propia del autor. ........................................... 28
Figura 4. 4: Ventana de Inicio de la Aplicación. .............................................................................................................. 31
Figura 4. 5: Ingreso de usuario................................................................................................................................................ 33
Figura 4. 6: Lista de Usuarios registrados. ........................................................................................................................ 34
Figura 4. 7: Ventana de lista y búsqueda de pacientes. .............................................................................................. 36
Figura 4. 8: Requerimiento, Ingreso paciente. ................................................................................................................ 38
Figura 4. 9: Ventana Ficha clínica de paciente. ............................................................................................................... 41
Figura 4. 10: Ingreso de historial a paciente. ................................................................................................................... 42
Figura 4. 11: Informes Fonoaudiológicos de pacientes.............................................................................................. 43
Figura 4. 12: Vista conocimiento informado.................................................................................................................... 45
Figura 4. 13: Programa fonoaudiológico............................................................................................................................ 47
Figura 4. 14: Exámenes del paciente.................................................................................................................................... 49
Figura 4. 15: Protocolo Cualitativo........................................................................................................................................ 50
Figura 4. 16: Protocolo Cuantitativo. ................................................................................................................................... 51
Figura 4. 17: Pantalla de Reportes. ....................................................................................................................................... 53
Figura 4. 18: Ventana de asignación de horario a paciente ..................................................................................... 55
Figura 4. 19: Horario general del CECH.............................................................................................................................. 57
Figura 4. 20: Ficha clínica visto desde el fonoaudiólogo............................................................................................ 59
Figura 4. 21: Prototipo para realzar cambios de los estados Histórico de pacientes y usuarios. ........ 61
Figura 5. 1: Modelo de datos conceptual. .......................................................................................................................... 96
7
1 INTRODUCCIÓN
La necesidad de utilizar un software para automatizar información dentro de una institución,

cada vez se hace más recurrente. Muchas compañías poco a poco, han comenzado a solicitar
el apoyo de herramientas informáticas, con el objetivo de llevar un control de la información
de forma correcta y precisa. Es por ello que el desarrollo de software ha tomado fuerza en el
último tiempo, así como otras áreas que también se involucran en el largo proceso que
conlleva la realización de un sistema informático, una de esas áreas es la Ingeniería de
Requisitos (IR). La IR nos permite establecer con el cliente, un estudio previo a la ejecución
de un proyecto, en donde se deben analizar las funciones que se deben trabajar, también
observar aquellos aspectos relevantes y fundamentales, para la ejecución exitosa de dicho
proyecto.
El Centro de Estudios de la Comunicación Humana (CECH), es un centro clínico

fonoaudiológico, de la Universidad del Bío Bío. El centro atiende a personas con alteraciones
fonoaudiológicas de manera gratuita. Con el tiempo, el aumento de pacientes y atenciones
que se realizan, han generado la necesidad de contar con un sistema que ayude a controlar el
registro de los pacientes.
En este proyecto, se realizan dos tareas principalmente. Por un lado, se desarrolla una
especificación de requisitos, que cubre las funcionalidades y necesidades solicitadas por el
CECH, para realizar un sistema de ficha clínica. Y por otro lado, se estudian diferentes
metodologías para llevar a cabo una elicitación de requisitos. Con el objetivo de seleccionar
una metodología acorde a las necesidades y condiciones del proyecto, el método escogido
viene a ser la base del desarrollo de este trabajo.
Este documento está estructurado de la siguiente manera: en el capítulo 2, encontramos una

definición y descripción de la empresa. En el capítulo 3, se hace una revisión del proyecto y
sus aspectos generales. En la capítulo 4, podemos ver la especificación de cada uno de los
requerimientos solicitados junto a sus prototipos. En el capítulo 5, vemos un análisis del
problema que se está abordando, mediante un modelado de datos. En el capítulo 6 se ve un
breve resumen del esfuerzo requerido, en el capítulo 7, aparecen las conclusiones.
8
2 DEFINICION DE LA EMPRESA O INSTITUCIÓN
2.1 Descripción de la empresa
Los antecedentes generales de la empresa son:
 Nombre: Centro de Estudio de la Comunicación Humana.

 Dirección: Av. Andrés Bello s/n.
 Rubro: Servicio Sociales y de Salud.
Entorno:
 Competencia directa: No posee, el centro es único en la provincia y la competencia

más directa, vienen siendo fonoaudiólogos particulares, pero que no alcanzan a
cubrir la cantidad de atenciones realizadas por la institución.
 Cuota de mercado: Dentro de Ñuble, se estima un 5% de pacientes.
El Centro de Estudios de la Comunicación Humana (CECH), es una institución nueva, que

lleva dos años funcionando, por este motivo, aún no cuenta con la definición de una misión,
visión y objetivos del centro. Esto porque aún está en proceso de desarrollo, lo que ha
impedido formular esta información estratégica, que es necesaria.
2.2 Descripción del área de estudio
El CECH, es una clínica de la escuela de fonoaudiología de la Universidad del Bío Bío, fundada
en 2011. En el centro trabajan fonoaudiólogos y estudiantes supervisados por docentes de
la escuela, quienes brindan atención fonoaudiológica gratuita a usuarios de distintas
comunas de Ñuble.
En el Centro se evalúa, diagnostica e interviene los trastornos de la comunicación humana

que se dan en cinco áreas generales: habla, lenguaje, audición, voz y deglución.
2.3 Descripción de la problemática
El CECH, lleva operando desde el año 2011. Con el transcurso del tiempo, se ha visto un
aumento considerable en el número de pacientes, esto implica, mayor flujo de información,
9
lo que ha generado problemas para administrar de manera eficiente los datos de las
personas que se atienden. Con el incremento de pacientes, también se ve afectada el área
administrativa del CECH, porque ellos atienden a las personas de manera gratuita, para
justificar los servicios que entregan, principalmente la atención a pacientes, es necesario
realizar diversos estudios estadísticos sobre los mismos pacientes, por ese motivo, se debe
analizar la información que se ha registrado en el centro: las atenciones, el número de
pacientes existentes, patologías tratadas, ausentismo, entre otras. Por consecuencia, el mayor
número de pacientes, requiere de mayor tiempo para recaudar información, esto a la vez,
significa también, destinar mayor tiempo al análisis de los datos, que permiten generar los
informes estadísticos. Por ello, surge la necesidad de contar con el apoyo de un sistema
informático que ayude a solucionar estos problemas.
El CECH, por el hecho de ser una institución con poca trayectoria, no cuenta con sistemas
informáticos que les sean de ayuda, salvo el uso de la agenda electrónica que proporciona
Google Calendar, mediante su correo electrónico Gmail. Esta permite realizar actualmente la
reserva de horarios a los pacientes del centro de forma coordinada, pero, este es un sistema
externo al centro y en caso de algún error con dicho sistema, el CECH no tiene un control
directo sobre este, para dar solución, se depende de agentes externos, lo que significa un
problema.
Además, cabe mencionar que para el CECH, este proceso es nuevo, no existen precedentes de
otros proyectos similares, lo que da cuenta que no hay registros ni datos que sirvan de
referencia para poner en marcha este trabajo.
10
3 DEFINICIÓN PROYECTO
3.1 Objetivos del proyecto
En esta sección se darán a conocer los objetivos generales y específicos del proyecto.
3.1.1 Objetivo General
Desarrollar una elicitación de requerimientos para la estructuración de un sistema de ficha

clínica para el CECH, que permita gestionar, controlar y entregar resultados pertinentes de
los pacientes.
3.1.2 Objetivos Específicos
Para alcanzar el objetivo general de este proyecto, se debe lograr los siguientes objetivos
específicos:
 Identificar la información que el CECH desea administrar y controlar con el

sistema.
 Identificar cuáles son los procesos de negocios involucrados.
 Buscar dentro de la literatura aquellas metodologías que sirvan para llevar a
cabo una elicitación de requisitos y seleccionar una que se acomode a las
características y necesidades del cliente.
 Aplicar la metodología escogida, para poder construir el informe de
requerimientos, de manera que los futuros desarrolladores, puedan aplicar la
información recabada.
3.2 Ambiente de Ingeniería de Software
En esta sección, se presentan y explican los diferentes conceptos que se utilizan para realizar
este trabajo.
3.2.1 Ingeniería de Requisitos.
La especificación de requisitos es una tarea importante a la hora de realizar cualquier

proyecto, es una de las primeras etapas por las que debe pasar el proyecto antes de su
11
ejecución, una mala captura de los requisitos puede ser fundamental a la hora de evaluar el
proyecto de exitoso o no.
El detalle de los requisitos debe ser correcto, preciso y no ambiguo, es por ello que nace la
Ingeniería de Requisitos (IR). La IR es para Sommerville: “Un proceso que comprende todas
las actividades requeridas para crear y mantener un documento de requisitos del
sistema”(Sommerville, 2002), por otra parte Loucopoulos y Karakostas definen: “la
Ingeniería de Requisitos, es el proceso de obtención de requisitos a través de un proceso
interactivo y cooperativo de análisis del problema, documentando las observaciones en una
variedad de formatos de representación y verificando la exactitud de lo
comprendido”(Loucopoulos & Karakostas, 1995).
El objetivo principal de la IR es obtener una definición clara estructurada y no ambigua para

las especificaciones correctas que demuestren el funcionamiento de un sistema, con el fin de
evitar errores en el desarrollo de algún proceso(Gallardo Arancibia, 2009).
Dentro de la IR se encuentran varios modelos de procesos, que varían según el área en la

cual se trabaja, estos modelos apuntan a las etapas de cómo llevar a cabo la elicitación de
requisitos. Para el área de Ingeniería de Software, que es el área del desarrollo de este
trabajo, las etapas fundamentales son: Elicitación, Análisis, Especificación, Validación.
Bahamonde y Rossel en (Bahamonde & Rossel, 2003) especifica las distintas etapas como
elementos.
 Elicitación: es la etapa donde hay mayor interacción con el usuario y es fundamental

para la extracción de información.
 Análisis: es la etapa donde se realiza la definición más técnica de la información
recaba en la etapa anterior, con el objetivo de evitar inconsistencia y ambigüedades.
 Especificación: es la definición de los requerimientos con el fin de formalizar el
contenido para que sea conocido por todas las partes involucradas del proyecto.
 Validación: es la etapa donde se realiza la confirmación de las etapas anteriores en
conjunto con el usuario.
Existen varios puntos de vista con respecto al desarrollo de estas etapas, entendiéndose que
existen varios modelos de procesos de IR para llevar a cabo las tareas que componen el
proceso.
12
3.2.2 Metodología para realizar la elicitación de requisitos.
En este proyecto la elección de la metodología fue motivo de estudio, dada la necesidad de

encontrar una que se adapte a las necesidades del usuario y a las características de este
proyecto. Las metodologías que se revisaron y analizaron son:
 Documentación de Requisitos Centrada en el Usuario (DoRCU).

 Bibliotecas.
 Análisis de Requisitos Conducentes al Reúso de Artefactos (ANCORA).
 Análisis de Requisitos basado en Preguntas (Inquiry Based Requirements Analisys,
IBRA).
 Definición de requerimiento basado en puntos de vista (Viewpoint Oriented
Requirements Defintion, VORD).
 VOLERE.
A continuación en la tabla 3.1, se muestra un resumen de las características más relevantes

de cada una de ellas.
13
Tabla 3. 1: Resumen de Metodologías estudiadas.
Tipo de
Metodología Descripción Etapas Plantilla Resultados
metodología
DoRCU Documentación de Elicitación. Iterativa. No posee. Documento
Requisitos Centrada en Análisis. Usuario.
el Usuario (Báez & Especificación. Documento
Brunner, 2001). Validación y Técnico.
Certificación.
Biblioteca Usa Técnicas de Adquisición y Iterativa Tabla de Documento en
adquisición de conversión de Usuario- relación entre lenguaje
conocimientos, Requisitos. Desarrollador. requisitos y natural.
utilizando tablas Generación de usuario.
decisión para capturar Conceptos. “Crosstable”.
relación entre atributos Comparación de
y objetos(Richards, conceptos y
2000). detección de
conflictos.
Negociación.
Evaluación.
ANCORA Análisis de Requisitos Entendimiento del Cascada Si posee, Pauta que se
Conducentes al Reúso Dominio y contexto de iterativa. extensas entrega al
de Artefactos (Sumano, la aplicación. planillas y diseñador de
2002). Recolección y diferentes. software.
aplicación de
requisitos.
Reutilización de
requisitos. Resolución
de conflictos,
priorización y
validación.
Cierre.
IBRA Análisis de Requisitos Especificación de Estructura Basada en el No debe
basados en requisitos, (propuesta) Cíclica. estándar IEEE. asociarse a un
preguntas(Potts, análisis (decisión) lenguaje de
Takahashi, & Anton, evaluación (cambios) especificación o
1994). estilo de
expresión.
VORD Definición de Requisitos Identificación y Iterativo. No definida. Documento de
Orientada en puntos de estructuración de los la
vista. puntos de vista. especificación
Enfocado en puntos de Documentación de los de requisitos.
vista del puntos de vista.
usuario(Kotonya, 1999). Análisis y
especificación de los
requisitos de puntos
de vista.
VOLERE Trabaja para la Modelo de trabajo Jerarquía de Planilla de Documentación
adquisición y análisis de como red asíncrona Proceso registros de de requisitos
requisitos usando dos donde se pueden dar iterativos. requisitos. para el usuario.
subsistemas Shell y combinaciones de
plantilla para requisitos procesos.
(VOLERE, 2005).
14
En las metodologías estudiadas se ven identificados los elementos correspondientes al

Modelo de Procesos de Ingeniería de Requisitos para la Ingeniería del Software, donde se
plantea en base a las actividades de elicitación, análisis, especificación y validación de los
requisitos.
Dentro de todas las metodologías, DoRCU e IBRA tienen aspectos interesantes, puesto que
ambas se enfocan principalmente en el usuario, pero se observan puntos en contra, por
ejemplo, DoRCU no presenta una plantilla que estandarice el proceso de captura de
requisitos e IBRA trabaja en base a etapas de manera cíclica de desarrollo, lo que hace difícil
la planificación de los tiempos, porque se desconocen la cantidad de ciclos a realizar. Por otro
lado ANCORA, al ser una metodología en cascada, impide de cierta forma la
retroalimentación con el usuario, además trabaja con reutilización de requisitos, lo que en un
proyecto que está iniciando, no es factible. En tanto, las metodologías Bibliotecas y VORD. La
primera presenta aspectos evaluados como negativos en este estudio, al ocupar
herramientas técnicas que hacen complejas llevarlo a la práctica porque el usuario, no
pertenece al área informática. Por otro lado, la segunda metodología, se enfoca en puntos de
vista del usuario, y como se mencionó anteriormente, el usuario no posee conocimiento del
área informática, por lo que se descartaron estas metodologías.
Por último la metodología VOLERE, es un método que entrega un modelo de aplicación

definido para el desarrollo, contempla a los usuarios como principal agente de interacción
para realizar la elicitación de requisitos, con un formato detallado para realizar el registro de
los requisitos, dado que entrega una Shell y una plantilla para especificar los requisitos. Estas
características, han hecho que VOLERE, sea la metodología seleccionada para realizar el
levantamiento de requisitos para este proyecto.
3.2.3 Método VOLERE
VOLERE es una metodología que apareció por primera vez en el año 1995, desarrollada por
James y Suzanne Robertson. Esta metodología se enfoca en desarrollar las etapas de la
elicitación de requisitos en jerarquía de procesos y el modelo de proceso se focaliza en una
red asíncrona donde se puede desarrollar cualquier proceso, como se presenta en la figura
3.1.
15
Figura 3. 1: Mapa simplificado del proceso de requisitos de VOLERE. Fuente: (Robertson & Robertson,
2000).
Las etapas de este modelo son:
a. Proyecto Blastoff: Denominada como etapa de despegue del proyecto, donde se

realizan las primeras conversaciones con el cliente, para abordar de manera general el
proyecto que se desea llevar a cabo. Se analiza el contexto donde se realizará el proyecto,
los riesgos y los costos iniciales de este.
b. Captura de Requisitos: Esta etapa comienza una vez terminada la etapa Blastoff, y es
aquí donde se capturan los requerimientos y las necesidades de los Stakeholders, se
detallan los casos de usos del negocio asociado, para posteriormente, producir los
requisitos provisionales, en sesiones de lluvias de idea (brainstorming).
c.Etapa Prototipos de Requisitos: en esta etapa, los prototipos provisionales se muestran
gráficamente, dando a conocer los posibles escenarios que se pueden alcanzar.
16
d. Etapa Escritura de Requisitos: Etapa paralela a la generación de prototipos, es la etapa

más compleja, puesto que es donde se debe expresar el requisito solicitado por el
Stakeholder de manera clara y no ambigua. En esta etapa se realiza el uso de las plantillas
ofrecidas por VOLERE.
e. Etapa Control de Calidad: Luego de realizar las etapas de Prototipos y Escritura, se
debe pasar por la etapa de control de calidad, donde el Stakeholder en conjunto con el
ingeniero de requisitos verifican y validan uno a uno los requerimientos desarrollados
en las etapas anteriores. Sólo evalúa si el requisito cumple con los criterios definidos en
la plantilla. De aprobar el requisito, este queda documentado y especificado, para
avanzar a la siguiente etapa, de lo contrario debe volver a la etapa anterior, para repetir
el ciclo, hasta que el requisito pase el control de calidad.
f. Etapa de Revisión de Requisitos: Esta etapa es donde se revisan los requisitos en
conjunto, esta vez desde el punto administrativo y funcional para el sistema, a diferencia
del control de calidad, en esta etapa se verifica si el requisito especificado es necesario
para el negocio, si los costos de implementación son acordes al requisito y cuánto puede
influir para el sistema la existencia o ausencia del requisito en cuestión.
g. Etapa de Reúso de Requisitos: Esta etapa es previa a la captura de requisitos, acá es
donde se indaga sobre los requisitos utilizados en sistemas anteriores, los cuales nos
puedan servir para el proyecto y que pueden estar ya especificados, con el objeto de no
tener que volver a especificarlos. Claramente, esta etapa no se considera, cuando el
proyecto es nuevo.
h. Etapa de Análisis, Diseño y Construcción: Es la etapa de implementación, donde se
analiza el requisito con tal de crear el diseño pensando siempre en la construcción, para
llevar a cabo el desarrollo de los requisitos, con tal de alcanzar el producto final solicitado
por el cliente.
17
VOLERE además de su modelo posee dos subsistemas para realizar la especificación de

requisitos, la Shell y la Plantilla. La Shell, cuenta con varios componentes que se pueden ver
claramente en la Tabla 3.2, donde se presenta la estructura, formato y una breve descripción
de cada componente.
Tabla 3. 2: Descripción gráfica de la Shell de VOLERE(Robertson & Robertson, 2000).
Número Se indica el Tipo Se basa según Eventos / Se mencionan

Requisito: número Requerimiento: el tipo de Casos de los eventos o
identificador requisito de Uso casos de usos
del requisito. acuerdo con la que tienen
plantilla relación con el
requerimiento.
Descripción: Se realiza un breve descripción del requerimiento que se desarrollará
Fundamentos: Se presenta los motivos de por qué es necesario realizar.
Autor: Es quién solicita el requerimiento
Criterio: Es el registro que permite realizar una medición de exigencia de tal manera que
sea posible poner a prueba si la solución coincide con el requisito.
Satisfacción Se hace un registro con una Insatisfacción Se hace un registro con una
del cliente: escala de 1 a 5, donde 1 es muy del cliente: escala de 1 a 5, donde 1 es
insatisfecho y 5 es muy poca importancia y 5 es
satisfecho, determina la muy disgustado.
satisfacción del cliente
Prioridad: Se realiza un registro donde se Conflictos: Se mencionan los otros
especifica si el requisito es de requerimientos que pueden
prioridad: Alta, Media o Baja. tener conflictos con el
requerimiento que se está
tratando.
Materiales de Soporte: Se registra información de información externa, que permita
desarrollar de mejor forma el requisito
Historia: Se registra la fecha de la creación, modificaciones o cambios que se han hecho en
el requisito.
A continuación se describirán los componentes de la Shell, presentados en la tabla 3.2.
18
 Número de Requisito: Es el código identificador único del requisito, con la intención

de tener fácil y rápido acceso al requisito.
 Tipo de Requisito: Indica el número según la sección a la que corresponde el
requisito basado en la plantilla.
 Evento/Caso de Uso: Es el número del caso de uso o evento con el que se relaciona
el requisito.
 Descripción: Se realiza una descripción breve y general del requisito.
 Fundamento: Se registran los motivos de porque es importante y necesario realizar
el requisito, con el fin de que las personas que lo vean, entiendan la real importancia
y sentido que tiene el requisito.
 Autor: Es el registro de quién o quiénes solicitaron el requisito.
 Criterios: Es el ítem que permite definir si el requisito cumple lo solicitado de
manera adecuada.
 Satisfacción del Cliente e Insatisfacción del Cliente: Estos campos muestran el estado
del cliente, a la hora de verificar si el requisito se llevó a cabo o no, donde la
satisfacción indica que tan satisfecho quedará el cliente con la implementación del
requisito. Por otra parte el campo de insatisfacción del cliente, indica que sentirá el
cliente si el requisito no se lleva a cabo. Los índices deben ser altos si el requisito es
importante, dado que eso significa que el cliente quedará muy satisfecho por el
desarrollo y quedará muy disgustado si es que no se desarrolla el requisito.
 Prioridad: Indica que tan necesario es realizar el requisito para el sistema, con el fin
de saber la importancia que tiene.
 Conflictos: Se detallan todos aquellos requisitos que presentan un problema para el
desarrollo del requisito que se está especificando.
 Materiales de soporte: Este es un registro de información que apuntan a otros
materiales de información, que sean relevantes para el requisito.
 Historia: Se guarda el historial de los cambios efectuados al requisito.
Por otra parte, la planilla de VOLERE se divide en los siguientes puntos:
 Guías del Proyecto: se define el propósito del proyecto, definen los clientes,
Stakeholder y los usuarios involucrados en el sistema.
 Restricciones del Proyecto: Se describen e identifican las restricciones del proyecto,
centrándose en las de tipo técnico y económico.
19
 Requisitos Funcionales: Son los requisitos primordiales del producto y deben ser
medibles por métodos concretos.
 Requisitos no funcionales: Son aquellos que poseen propiedades las cuales son
difíciles y complejas de cuantificar.
 Aspectos del negocio: Se describen los factores que pueden influir en el desarrollo
del negocio a la hora de lograr el éxito o el fracaso del proyecto.
En este proyecto se realizará una aplicación modificada a la plantilla VOLERE, dado que este
método se utiliza para el desarrollo completo de una aplicación y para este caso sólo se
realizó hasta la etapa de revisión de requisitos, es por ello que se hizo cambios y se
extrajeron aquellas partes que no cumplen con lo que esta etapa solicita. Las etapas que no
fueron consideradas para este trabajo: “reúso de requisitos” y “análisis, diseño y
construcción”, la primera no fue considerada por no existir, ningún sistema previo. La
segunda es porque este proyecto sólo aborda el levantamiento de requerimientos, no el
desarrollo de la aplicación.
3.2.4 Herramientas y tecnologías a utilizar
 Balsamiq Mockups: Es un software que permite realizar el esquema de una página

o aplicación, en este caso, se utilizó para desarrollar los prototipos del sistema.
3.3 Definiciones, Siglas y Abreviaciones
Box: Sala, lugar físico donde se atienden los pacientes en el centro, de momento, sólo existen
4 en el CECH.
Crosstable: También se conoce como tabulación cruzada, es una tabla que permite registrar
información, la cual puede ser tabulada y se utiliza para obtener datos estadísticos.
Estudiante: equivalente a interno, en el texto se utilizan ambos conceptos, con el fin de

evitar las redundancias.
Google Calendar: Es una agenda y calendario electrónico desarrollado por Google. Permite
compartir un calendario y así pueden interactuar varios usuarios dentro de este mismo,
además los usuarios pueden editar la información, siempre que tengan los permisos.
20
IEEE: Siglas que significa Institute of Electrical and Electronics Engineers, que corresponde
en español Instituto de Ingenieros en Electricidad y Electrónica.
Instrumento de Evaluación: Se denomina al conjunto de protocolos que se aplican a un

paciente para obtener la evaluación médica de dicho paciente.
Interno: Equivalente a estudiante de la carrera de fonoaudiología, es quien realiza práctica

en el CECH.
Protocolos: Denominación que se da en el CECH, a los procedimientos que permiten

descubrir una patología del paciente, equivalente a un examen médico.
Proyecto Blastoff: Es la primera etapa del proyecto donde se reúnen los desarrolladores,
clientes y usuarios para definir el contexto, propósito del proyecto, los riesgos principales,
estimación inicial de esfuerzo, identificación de los interesados, se definen grupos de trabajo,
etc.
Rotación: Se le denomina al cambio de estudiantes que se realiza en el CECH, cada dos

meses, dado que es el tiempo de práctica que realizan los internos en el centro.
Shell: Se denomina a una interfaz que permite a los usuarios realizar actividades o tareas de
manera más fácil y ordenada.
Stakeholders: “Quienes pueden afectar o son afectados por las actividades de una
empresa”1.
1 Freeman, R. E. (1984). Strategic planning: A stakeholder approach. Boston: Pitman.
21
4 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE
A continuación, en este capítulo, se presenta el desarrollo de cada etapa que se llevó a cabo
para realizar la elicitación de requisitos.
4.1 Etapa: Proyecto Blastoff
La primera etapa comenzó coordinando una reunión con el cliente, en la cual se habló acerca
de las necesidades y objetivos que se quieren alcanzar con este proyecto, los cuales son, crear
un sistema de ficha clínica para los pacientes del CECH. Luego, se prosiguió a la
estructuración de un plan de trabajo, en donde se acordó realizar reuniones periódicas
semanalmente. En un segundo encuentro, realizado en las dependencias del centro, se
observó la situación actual del centro y se discutió acerca de las actividades que se realizan
en el CECH.
Se deben definir dentro del contexto general, los costos iniciales y los riesgos analizados,
para llevar a cabo este proyecto, dentro de esos términos no encontramos con:
- La necesidad de incorporar equipamiento computacional, ya sean computadores, un

escáner y una impresora.
- Una conexión a una red de internet.
- Un servidor web que permita almacenar la aplicación a desarrollar.
- Este es un proceso nuevo para la empresa, por lo que su implementación puede
generar algún impacto negativo en los usuarios que lo utilizarán.
4.1.1 Propósito del Proyecto
Este proyecto, es una etapa para desarrollar una aplicación web que permita realizar un
sistema de control de ficha clínica para el CECH. Sólo se contempla el levantamiento de
requisitos y la demostración de prototipos del sistema. Para cumplir el propósito, se debe
entregar un documento, con el detalle de las funciones y tareas que debe hacer el sistema, las
que debieron ser solicitadas por el cliente, para que pase posteriormente, a la siguiente
etapa de diseño y desarrollo donde se lleve a cabo la implementación.
22
4.1.2 El Cliente.
En este proyecto, solamente cuenta con un cliente directo, y es con quien se realiza el
desarrollo del levantamiento de requisitos. El profesor de fonoaudiología de la Universidad
del Bío Bío, el Señor Rodolfo Peña Chávez, es él, quien solicita, valida y aprueba los
requerimientos.
4.1.3 Usuarios del producto
Los usuarios del producto final los podemos ver en la Tabla 4.1:
Tabla 4. 1: Usuarios finales del sistema.
Experiencia Experiencia Prioridad

Nombre/Categoría Rol
sobre el tema tecnológica
Administrador Administrar el Profesional Competente Clave
funcionamiento del sistema.
Fonoaudiólogo Usuario limitado del sistema Profesional Competente Clave
con facultad de realizar
ingreso y edición de la
información
correspondiente a sus
permisos.
Interno/Estudiante Usuario limitado del sistema Competente Competente Clave
con facultad de realizar
ingreso de la información
correspondiente a sus
permisos.
4.2 Restricciones Obligatorias del Proyecto
En esta sección se indican las restricciones que debe tener el proyecto, con tal de
proporcionar información suficiente para que los diseñadores tengan presente las
condiciones que se deben cumplir, para satisfacer al cliente.
23
4.2.1 Restricciones Obligatorias.
El software para que sea factible, debe cumplir ciertos requerimientos obligatorios,
solicitados por el cliente. Sin estos requisitos el producto final, será incompleto y no cumplirá
el objetivo, por el cual se está desarrollando.
El producto final debe ser una aplicación web, capaz de almacenar la información completa
de un paciente, esto quiere decir que debe contener los datos personales, datos clínicos,
informes fonoaudiológicos y protocolos aplicados al paciente. Además toda la información
debe ser administrada por personas autorizadas. El objetivo es eliminar la actual ficha
clínica del centro que se trabaja en forma manual.
El producto final debe permitir coordinar la reserva de horas para la atención de los
pacientes. El objetivo es administrar el calendario dejando de lado el uso de sistemas
externos al centro.
El sistema debe entregarnos información automatizada de los pacientes, para obtener datos
estadísticos que permitan crear informes de las actividades realizadas a los pacientes del
centro.
4.2.2 Ambiente de implementación del sistema actual
Esta restricción, indica el ambiente que debe existir para llevar a cabo este proyecto, el
centro debe contar con un computador por box, con conexión a internet, además deben estar
conectados a una impresora y a un escáner, para poder imprimir información o cargarla
mediante un registro tomado desde un escáner.
4.2.3 Restricciones cronológicas
La única restricción, surgida de este tipo, hace referencia a los usuarios registrados como
interno, estos usuarios solamente deben tener acceso al sistema, durante el horario
establecido por el cliente, con el fin de que la información de los pacientes sea vista
solamente en el centro y no fuera de él.
24
4.3 Etapa: Captura de requisitos.
Si bien, la captura de requisitos, comienza desde el primer contacto con el cliente, es en esta
etapa en donde comienza la documentación más detallada de esos requisitos, que se han
abordado de manera general en la etapa anterior.
La etapa se construye, luego de diversas reuniones con el cliente, donde éste realiza el listado
de las necesidades que se solicitan para la construcción del producto final. Junto a esto se
proponen ideas para lograr consensos y comenzar a detallar en el documento los
requerimientos formalmente.
La especificación de estos requisitos se realiza, de conversaciones donde se extraen los

detalles que índica el cliente, para luego desarrollar la escritura en la Shell, siguiendo la
plantilla, en paralelo con el prototipo y los casos de usos referentes a ese requerimiento. De
esta forma se hace un trabajo cíclico con cada requerimiento tratado, como se presenta en el
mapa simplificado de proceso, visto anteriormente (figura 3.1).
4.3.1 Alcances del Producto
Los alcances del producto, se enfoca en el diagrama de casos de uso, de esta forma, conocer la
relación de los usuarios con respecto al producto. También sirve para decidir cuáles de estos
casos de usos son apropiados que se deben desarrollar en la aplicación.
25
A continuación, en la figura 4.1, se presenta el modelo de casos de uso, donde se describen las
funcionalidades del producto para el actor estudiante.
Figura 4. 1 Modelo de Caso de Uso: Estudiante. Fuente: propia del autor.
26
Siguiendo con el esquema, en la figura 4.2, se muestra el modelo de casos de uso, donde se
describen las funcionalidades del producto para el actor administrador.
Figura 4. 2: Modelo de Caso de Uso: Administrador. Fuente: propia del autor.
27
Para finalizar con el diagrama de casos de uso, en la figura 4.3 se presenta el esquema, donde
se describen las funcionalidades del producto para el actor estudiante.
Figura 4. 3: Modelo de Caso de Uso: Fonoaudiólogo. Fuente: propia del autor.
En la figura 4.1, 4.2 y 4.3 se aprecian 3 actores, que fueron descritos en la sección 4.1.3.
4.4 Etapa de escritura y prototipos de requisitos
En esta etapa se desarrolla la escritura de los requisitos basados en la documentación de

VOLERE. También se presenta en paralelo al requisito, el prototipo que exprese de manera
gráfica el requerimiento que se está desarrollando. Posteriormente, se realiza la descripción
de los casos de usos asociados a cada requerimiento, todo este desarrollo siguiendo el
proceso cíclico de VOLERE.
28
4.4.1 Requerimientos Funcionales
Los requerimientos funcionales son aquellos que poseen un criterio de aceptación o de

prueba con tal que los clientes puedan comprobar si el requisito se ha cumplido o no.
VOLERE define los requisitos funcionales como: “los sujetos fundamentales o esenciales que
constituyen la médula del producto. Ellos describen lo que el producto tiene que hacer o
cuáles acciones de procesamiento debe tomar”2 .
Ahora veremos los requerimientos funcionales que se registraron utilizando la Shell de

VOLERE y el(los) respectivo(s) prototipo(s) para ejemplificar el requerimiento descrito en la
Shell.
2 James & Suzanne Robertson (2006). Volere. Plantilla de especificación de requisitos. Edición 11.
29
1. Autorizar ingreso a usuario
Tabla 4. 2: Requerimiento verificar usuario
Requerimiento: RF01 Tipo Acceso Eventos / CU01, CU20

Requerimiento: Casos de Uso
Descripción: El sistema verifica, sólo a aquellos usuario que estén registrados.
Fundamentos: La información de los pacientes debe ser protegida para cualquier agente
externo al sistema, por lo que se debe verificar quién ingresa al sistema y saber
quién trabaja la información.
Autor: Rodolfo Peña
Criterio: El usuario al ingresar al sitio, debe identificarse, para ello ingresa su correo
electrónico y su contraseña.
El sistema debe ser capaz de diferenciar el tipo de usuario que está entrando en
el sistema, un usuario no puede poseer dos perfiles de usuario.
El sistema debe avisar si el usuario no ha sido registrado, no ha ingresado algún

campo o los datos ingresados son incorrectos, impidiendo el ingreso al sistema.
El sistema debe dar una opción de reenviar la contraseña al correo de contacto

del usuario, en caso de que el usuario olvido la contraseña.
El sistema debe dar la opción de cerrar la sesión en cualquier momento, si se está

editando alguna información, el sistema debe preguntar si desea cerrar sin
guardar o cancelar la opción de salida de sistema.
Satisfacción del cliente: 5 Insatisfacción de los clientes: 4
Prioridad: Alta Conflictos
Materiales de Soporte
Historia: 23-10-2013
30
A continuación en la figura 4.4, podemos apreciar la Ventana Inicio de la aplicación, esta

ventana permite la opción de identificarse mediante el correo y contraseña, para poder
ingresar al sistema, también muestra un link en caso de que un usuario olvidó la contraseña,
esta es enviada al correo.
Olvido contraseña
Figura 4. 4: Ventana de Inicio de la Aplicación.
31
2. Crear perfil de usuarios
Tabla 4. 3: Requerimiento crear perfil de usuario.
Requerimiento: RF02 Tipo Funcional. Eventos / CU02, CU19

Descripción: El sistema ofrece al administrador la opción de crear tres perfiles de usuario
diferentes.
Fundamentos: El sistema será utilizado para registrar información de pacientes atendidos, el
ingreso de dicha información puede ser suministrada al sistema por
fonoaudiólogos profesionales, como por estudiantes de fonoaudiología, por ello
se requiere hacer diferencias. Además de proteger el sistema de agentes
externos.
Autor: Rodolfo Peña.
Criterio: El administrador del sistema es el encargado de gestionar las cuentas de usuario,
para ello el administrador debe estar autentificado en el sistema mediante su
nombre de usuario y contraseña.
El administrador posee las opciones de crear, editar o eliminar un usuario.
El administrador puede crear tres tipos diferentes de usuario: un nuevo
administrador, un fonoaudiólogo y un estudiante.
El administrador al crear un usuario debe seleccionar el tipo de usuario que
creará y registrar para cualquiera los siguientes datos:
- Nombres.
- Apellido Paterno.
- Apellido Materno.
- RUN.
- Correo electrónico.
- Asignar una contraseña por defecto.
Siendo estos campos obligatorios que permitan ingresar un máximo de 32
caracteres, salvo el correo electrónico que por estándar internacional permite
320 caracteres. Por otra parte la única excepción la tiene el estudiante con un
campo extra, donde se indique el número entero positivo de la rotación a la que
pertenece del CECH.
El perfil de administrador, otorga permisos para acceder a toda las funciones del
sistema.
El perfil estudiante tiene acceso a las funcionalidades que se relacionan con el
paciente, pero no puede editar la información ya registrada, sólo puede agregar.
Para editar información el estudiante debe informar a un fonoaudiólogo para que
realice los cambios.
El perfil fonoaudiólogo tiene acceso a las mismas funcionalidades que el
estudiante, con la diferencia que estos si pueden editar información almacenada.
El sistema debe mostrar todos los usuarios registrados y dar la opción al
administrador para corregir algún dato de un usuario, salvo su identificación y su
contraseña.
Prioridad: Alta Conflictos: Usuario con dos perfiles.
32
A continuación se presentan las pantallas para el perfil de administrador, en la figura 4.5 se

puede ver el ingreso de un nuevo usuario.
Figura 4. 5: Ingreso de usuario.
33
Luego el administrador puede revisar los usuarios registrados, como se ve en la figura 4.6.
Figura 4. 6: Lista de Usuarios registrados.
34
3. Buscar Paciente
Tabla 4. 4: Requerimiento buscar paciente.
Requerimiento: RF03 Tipo Funcional Eventos / CU07

Descripción: El sistema permite a los usuarios buscar un paciente.
Fundamentos: A medida que aumentan los pacientes, será más compleja la localización dentro
del sistema de éste. Encontrar un paciente de forma automática ayuda a ahorrar
tiempo.
Criterio: Se debe entregar una opción de búsqueda de pacientes, la cual permita acceder a
un usuario registrado, ya sea por su número de RUN, nombre, apellido, número
de ficha.
De no existir el paciente, se debe indicar que el paciente buscado no se encuentra
en los registros.
Una vez encontrado, debe permitir el acceso a la ficha clínica de este.
Prioridad: Alta Conflictos No posee
35
En la siguiente figura 4.7 se presenta el listado de pacientes que están registrados en CECH,
debe permitir, realizar filtros de estos y una opción para buscar de manera rápida algún
paciente, ya sea por nombre, apellido, Rut o número de Ficha, se supone que la tabla sólo
debe mostrar las coincidencias de la búsqueda.
Figura 4. 7: Ventana de lista y búsqueda de pacientes.
36
4. Ingresar un nuevo paciente
Tabla 4. 5: Requerimiento ingresar nuevo paciente.
Requerimiento: RF04 Tipo funcional Eventos / CU04

Descripción: El sistema permite ingresar un nuevo paciente.
Fundamentos: La principal función del sistema es automatizar la información de los pacientes,
es por ello que se hace necesario, crear la instancia para agregar nuevos
pacientes al sistema.
Criterio: El paciente debe ser ingresado por un estudiante (interno) o un fonoaudiólogo
registrado en el sistema.
Antecedentes de Identificación, es donde se registran los siguientes datos:
a) Número de ficha: único para el paciente y automático.
b) RUN: Rol único nacional del paciente.
c) Nombres.
d) Apellido Paterno.
e) Apellido Materno.
f) Fecha de nacimiento.
g) Edad de ingreso del paciente al centro.
h) Edad actual: calculada a partir de la fecha de nacimiento.
i) Procedencia: Lugar del que fue derivado.
j) Motivo de Consulta: párrafo que indique el por qué llegó el paciente.
k) Dirección: lugar de residencia del paciente.
l) Años de estudios.
m) Fecha de ingreso: fecha de la primera atención.
n) Nombre del Evaluador: registro del interno o fonoaudiólogo que lo
atendió.
Los usuarios deben ingresar la información solicitada por el sistema para la
creación de un paciente, RUN, Fecha de Nacimiento, edad, edad de ingreso,
pueden ser campos en blanco, dado que existen pacientes que desconocen esa
información. El resto de los campos deben estar completados.

Prioridad: Alta Conflictos Un paciente cuente con 2
fichas clínicas. Existe la opción
de registrar un paciente sin
datos personales como RUN,
fecha de nacimiento, (bebes
recién nacidos, indigentes), y
que en una nueva atención
lleguen con una identificación
y se realice una nueva ficha a
una misma persona.
Materiales de Soporte No posee
37
En la siguiente figura 4.8, se presenta una pantalla donde el estudiante o fonoaudiólogo

selecciona ingresar un paciente y se muestra el formulario para el ingreso de un nuevo
paciente.
Allí se deben ingresar los datos del paciente, pero la edad actual, la fecha de evaluación y el
número de ficha son datos que debe entregar el sistema de forma automática.
Figura 4. 8: Requerimiento, Ingreso paciente.
38
5. Crear ficha clínica
Tabla 4. 6: Requerimiento crear ficha clínica.
Requerimiento: RF05 Tipo funcional Eventos / CU05, CU08,

Requerimiento: Casos de Uso CU09, CU10,
CU26
Descripción: Crear un ficha clínica única y que este asociada a un único paciente.
Fundamentos: El CECH necesita almacenar el historial de actividades que se realizan a un
paciente, de modo que en una futura sesión del paciente, se conozca los
tratamientos que ya se le han aplicado.
Criterio: Cuando se ingresa un nuevo paciente al sistema, éste de manera automática crea
una nueva ficha clínica, la que se encargará de llevar el registro de cada sesión.
En la ficha clínica se debe ingresar uno o varios diagnósticos que se obtienen una
vez hecho los exámenes, estos están determinados y poseen un código y nombre.
(Ver Anexo 11).
Debe permitir visualizar el documento de consentimiento informado, firmado
por el paciente, el cual debe ser escaneado y subido al sistema. Si no posee, debe
dar la opción de subir el documento al sistema.
Debe registrar el día de atención y la hora de inicio de la sesión con el paciente,
también la hora y día de la próxima sesión.
Se debe permitir realizar una evaluación del paciente para realizar un programa
fonoaudiológico. El programa fonoaudiológico, consiste en definir un plan de
trabajo para un paciente. Este plan consiste en alcanzar un objetivo general, para
ello, este objetivo general, se divide en varios específicos, los cuales están
compuestos por objetivos operacionales, que son simplemente tareas a
desarrollar con un paciente. Los objetivos operacionales, indican el desarrollo de
una terapia y se registrar en el sistema, a través de las sesiones.
Se debe mostrar el historial de las sesiones que ha realizado el paciente, dentro
de esa muestra se debe contemplar:
- Número de sesión: número (valor entero) que indica la cantidad de sesiones
que se han realizado.
- Fecha: se ingresa la fecha (formato fecha) de cuando se realizó el registro.
- Objetivos Operacionales: área de texto (1200 caracteres) que permita dos
opciones, una es que permita ingresar un párrafo, tomado de la selección de
un objetivo operacional seleccionado y la segunda es, en el caso de que no
sea un tratamiento operacional, debe permitir ingresar el valor de:
evaluación del paciente.
- Descripción de la(s) actividad(es): cuadro de texto (1200 caracteres) que se
presentan las actividades llevadas a cabo por el fonoaudiólogo.
- Logro esperado: es un valor significativo que se desea alcanzar en la sesión
de acuerdo al objetivo. Puede ser un porcentaje, un valor dicotómico, entre
otros.
- Logro Obtenido: es el valor real, acorde al objetivo planteado. Debe ser
consistente con el valor de logro esperado.
- L, D, NL: siglas que significan Logrado (L), en Desarrollo (D), No Logrado
(NL) las cuales determinan la calificación que el paciente obtiene en la
sesión realizada.
39
- Observaciones: un cuadro de texto (1200 caracteres) donde se registra

información adicional a la sesión.
- Interno: muestra el nombre completo del estudiante o fonoaudiólogo quien
realizó la sesión.
- Fecha edición: muestra la última fecha (formato fecha) que se ha editado.
- Fonoaudiólogo: muestra el nombre completo del fonoaudiólogo que realizó
la edición.
- En conjunto con la información antes mencionada, se debe dar la opción
para crear un programa terapéutico, donde se definan los objetivos
generales, específicos y operacionales, que se deben aplicar en la terapia del
paciente.
- En la ventana de Ficha clínica debe estar la opción para registrar un
instrumento de evaluación (protocolo), este debe permitir elegir algún
protocolo de los presentados en el anexo 10, para ingresarlos al sistema.
Cada nuevo historial que se agregue debe llevar el número de la sesión que le
corresponde.
Adjunto a toda la ficha clínica, debe tener asociado un informe fonoaudiológico
que realizan los estudiantes, los cuales deben subir al sistema y este tiene que
poder ser visualizado por los demás usuarios, es necesario que además del
informe quede registrado quién lo subió y en qué fecha.
Prioridad: Alta Conflictos No posee
Materiales de Soporte Anexo 10 y Anexo 11
40
En la siguiente figura 4.9, se puede ver el prototipo de la ficha clínica de un paciente

seleccionado.
Figura 4. 9: Ventana Ficha clínica de paciente para el estudiante.
La figura 4.9, se puede dividir en dos partes, una que posee información del paciente (parte
superior) y otra sección, que posee un cuadro con pestañas, donde se muestran tablas
dinámicas de información (parte inferior). En la primera parte podemos ver tres opciones,
agregar consentimiento informado, la que nos permite buscar un archivo y almacenarlo en el
sistema. Ingresar uno o varios diagnósticos, asignar o modificar un horario de atención al
paciente.
41
En la segunda parte, se pueden observar una sección de registro que se divide en cuatro
partes: Historial paciente, Programa fonoaudiológico, Instrumentos fonoaudiológicos,
Informe Fonoaudiológico. En historial paciente, nos encontramos con una tabla que indica la
historia clínica del paciente, además nos da la opción de agregar un nuevo historial, el
formulario que se ve en la figura 4.10, se puede acceder desde 2 partes diferentes, el primero
es de manera directa, escogiendo la opción nuevo registro de la figura 4.9, la que nos
indicará que se está realizando una atención evaluativa al paciente, la otra opción es
mediante la selección de un objetivo operacional, que será revisado más adelante.
Figura 4. 10: Ingreso de historial a paciente.
42
Al seleccionar la cuarta pestaña, “Informe fonoaudiológico”, se presenta una nueva tabla que
muestra los informes fonoaudiológicos que se le han realizado al paciente, en esta pestaña,
existe la opción de subir un nuevo informe al paciente, como se muestra en la figura 4.11:
Figura 4. 11: Informes Fonoaudiológicos de pacientes.
43
6. Agregar consentimiento informado a la ficha clínica del paciente.
Tabla 4. 7: Requerimiento adjuntar consentimiento informado.
Requerimiento: RF06 Tipo funcional Eventos / CU06

Descripción: El sistema permite agregar adjunto a la ficha clínica del paciente, una copia
digital del documento de consentimiento informado.
Fundamentos: El consentimiento informado es un contrato que firma el paciente, para que los
fonoaudiólogos y estudiantes puedan realizar las terapias bajo el consentimiento
del paciente. Puede darse el caso que en la primera sesión no se registre el
consentimiento informado, pero en una segunda sesión debe ingresarse a la
ficha. Si en una tercera instancia donde el paciente acude por una atención y no
posee consentimiento informado el sistema no debe permitir que se tenga
acceso a la ficha clínica del paciente, sólo debe permitir adjuntar el
consentimiento informado del paciente.
Criterio: El consentimiento informado es un documento impreso que debe proporcionar
el sistema para que sea firmado por el paciente.
El conocimiento informado debe estar adjunto a un paciente. El sistema debe

proporcionar la relación del documento con el paciente de forma directa.
El documento original debe ser escaneado para poder cargarlo en la ficha clínica
del paciente en el sistema.
Todo documento informado debe estar asociado a un paciente previamente

registrado en el sistema.
Prioridad: Alta Conflictos No contar con el hardware
para escanear el documento y
no poder acceder a la ficha
clínica del paciente.
44
En la figura 4.12, se visualiza el documento de Consentimiento Informado, con los datos del
paciente y la firma,
Figura 4. 12: Vista conocimiento informado.
45
7. Agregar programa fonoaudiológico a ficha clínica
Tabla 4. 8: requerimiento programa fonoaudiológico.
Requerimiento: RF07 Tipo Funcional Eventos / CU24,CU25

Descripción: El sistema permite crear un programa fonoaudiológico.
Fundamentos: Luego de realizar una revisión a un paciente, el estudiante o el fonoaudiólogo
debe crear el programa fonoaudiológico, de esta forma la próxima vez que se
atienda a dicho paciente se sepa qué es lo que está pendiente por hacer y qué es
lo que se realizó
Criterio: El programa cuenta con la descripción de objetivos generales, los cuales se
desarrollan en base a varios objetivos específicos, a su vez los objetivos
específicos, poseen objetivos operacionales, que son aquellos que se realizan en
una atención terapéutica a un paciente, cuando se cumplen todos los objetivos
operacionales el objetivo específico se cumple, una vez realizado todos los
objetivos específicos, el objetivo general está concluido.
Para desarrollar esto, se deben mostrar los objetivos generales, al momento de

seleccionar un objetivo general se desplieguen los objetivos específicos, y luego
al seleccionar un objetivo operacional, nos envíe al ingreso de un nuevo historial
del paciente, para desarrollar dicho objetivo.
A la vez es importante señalar la cantidad de objetivos completados y

pendientes, para controlar cuantas terapias y sesiones hacen falta para alcanzar
dichos objetivos.
Prioridad: Alta Conflictos: No posee.
46
Al seleccionar la segunda pestaña de la ficha clínica, “programa fonoaudiológico”, permite

agregar un objetivo general, luego los objetivos específicos de ese objetivo general que a su
vez contienen uno o varios objetivos operacionales, los cuales permiten seguir la
programación creada para ese paciente y se puede registrar una sesión a partir de la
aplicación de dicho objetivo, en la siguiente figura 4.13, se ve que existe la opción de crear
nuevos objetivos o aplicar estos objetivos.
Figura 4. 13: Programa fonoaudiológico.
47
8. Aplicar instrumento de evaluación
Tabla 4. 9: Requerimiento registrar examen.
Requerimiento: RF08 Tipo Funcional Eventos / CU14, CU17,

Requerimiento: Casos de Uso CU22, CU23
Descripción: El sistema permite registrar la información de un instrumento de evaluación
aplicado a un pacientes
Fundamentos: El tratamiento de los pacientes, se basa principalmente en el desarrollo de
actividades que permitan avanzar en la recuperación. Los exámenes que se
aplican permiten identificar además de una patología, nos permiten controlar la
evolución de esta, si hay avances o retrocesos, por ello es importante tener el
registro de cada uno que se aplique.
Criterio: El sistema debe permitir registrar el resultado de un protocolo aplicado a un
paciente. Para ello debe entregarnos información de que protocolos existen y el
detalle de estos.
Realizado un análisis a los protocolos se pueden obtener dos clasificaciones
generalizadas: protocolos cuantitativos y protocolos cualitativos, los primeros
son los que se pueden automatizar, debido a que son pruebas que entregan un
puntaje una vez finalizado el desarrollo, esto permite obtener un resultado para
calcular un diagnóstico, dado las respuestas entregadas por el paciente y por otra
parte están los protocolos que sólo requieren de un ingreso de información que
analiza el interno o fonoaudiólogo una vez realizado el protocolo.
El protocolo cuantitativos consta de:
- Nombre: nominación por la que se conoce el protocolo.
- Conclusión: Detalles del desarrollo del protocolo (1200 caracteres).
- Observación: Apreciación personal del paciente. (1200 caracteres).
- Puntaje total: valor numérico que se obtiene de los pacientes una vez
terminado la aplicación del protocolo.
- Diagnóstico: valor obtenido según el puntaje total obtenido.
- Descripción: Breve descripción relevante del protocolo.
- Fecha: cuando se aplicó el protocolo.
El protocolo cualitativo sólo contiene: Nombre, fecha, descripción, observaciones
y conclusiones. Estos mantienen la misma estructura que los cuantitativos, salvo
que los datos ingresados, son netamente de apreciación del usuario quien está
registrando los datos.
En el anexo 10, se especifica detalladamente el nombre y la información que se
debe recoger de cada protocolo.
Prioridad: Alta Conflictos Existen protocolos que
requieren la edad para calcular
un diagnóstico, como existe la
posibilidad de ingresar
pacientes si este dato, habrán
problemas.
Materiales de Soporte Ver anexo 10.
48
Relacionada con la ficha clínica, en la tercera pestaña nos encontramos con los protocolos, en
esta sección se registran los resultados de los protocolos una vez aplicado a un paciente,
figura 4.14.
Figura 4. 14: Exámenes del paciente.
49
De manera generalizada se puede visualizar el formulario para un protocolo de tipo

cualitativo, como se ve en la figura 4.15.
Figura 4. 15: Protocolo Cualitativo.
50
En la figura 4.16. Se aprecia el formulario para registrar un protocolo cuantitativo, a

diferencia de la anterior, esta requiere de más información, para registrar el puntaje
obtenido después de haber aplicado un protocolo y el sistema con la información entregada
debe dar una respuesta.
Figura 4. 16: Protocolo Cuantitativo.
51
9. Generar reporte estadístico
Tabla 4. 10: Requerimiento Generar reporte.
Requerimiento: RF09 Tipo Funcional Eventos / CU03

Descripción: El sistema debe entregar información de las atenciones que se realizan en el
CECH.
Fundamentos: El CECH ofrece servicios de forma gratuita, por lo que requieren el desarrollo de
información estadística que les permita justificar su labor.
Criterio: El sistema debe entregar un reporte estadístico anual, mensual y/o diario, con
información relevante para el centro, además de gráficos que sirvan de apoyo
visual a la interpretación de los datos. Los datos requeridos para analizar son:
- Número de usuarios atendidos: cantidad de pacientes de los que se
tiene registro.
- Número de atenciones realizadas: cantidad total de atenciones que
se realizan según el rango de fecha.
- Grupo etario atendido: se presenta un gráfico de barra, donde se
utiliza la información propuesta por el Departamento de Estadísticas
e informaciones en Salud, que entrega un lista con rango de edades y
se debe indicar la cantidad de personas que hay dentro de ese rango
de edad.
- Sectores de Residencia involucrados: en una gráfico circular, donde
se registra cuantos pacientes hay por las comunas de la provincia.
- Número de pacientes por Diagnóstico: gráfico de barra, que muestra
por cada diagnóstico, la cantidad de pacientes que sufren dicha
patología.
- Número de atenciones por diagnóstico: gráfico de barra que muestra
cuantas atenciones se han realizado de las patologías, dentro del
rango de la fecha.
- Lugar de derivación de los pacientes: gráfico circular, con cuantos
pacientes han sido derivados bajo el mismo motivo.
- Tipo de terapia realizada: Gráfico de barra con la información de
cuantas evaluaciones y tratamientos se han realizado dentro del
rango de fecha.
- Ausentismo de pacientes: número de inasistencias de pacientes.
- Pacientes atendidos por fonoaudiólogo o interno: gráfico de barra
que indica cantidad de atenciones de cada interno y fonoaudiólogo.
Prioridad: Alta Conflictos Falta estandarizar algunos
campos, como el Lugar de
derivación. Esto dificulta el
procesamiento de la
información.
52
El administrador puede generar reportes, la idea es generar una pantalla que entregue los
resultados, pero que también de la opción para registrar las conclusiones percibidas por
administrador, por ello se define la ventana con la opción de observación, como se ve en la
figura 4.17.
Figura 4. 17: Pantalla de Reportes.
53
10. Coordinar horario
Tabla 4. 11: Requerimiento asignar horario a paciente.
Requerimiento: RF10 Tipo Funcional Eventos / CU10, CU11

Descripción: El sistema coordina la atención de los pacientes en conjunto a la disposición de
los internos, fonoaudiólogos y la disposición de box del centro.
Fundamentos: Llevar la calendarización de la atención que se realiza a los pacientes permite
coordinación y una mejor atención, dado que no se perderán horas y cada
paciente recibirá su debida atención.
Criterio: El sistema debe contar con un calendario que permita el registro de las horas de
los pacientes para la próxima sesión.
Se dan tres posibles casos para entregar un horario de atención:
a) El paciente solicita una hora de atención por primera vez y es
atendido de forma inmediata por el fonoaudiólogo o interno que
recibió al paciente, luego se registra en la agenda una fecha, hora y
box para la próxima sesión.
b) El paciente solicita una hora por primera vez, pero no se puede
atender de manera inmediata, el fonoaudiólogo o interno verifica su
disponibilidad, de tener cupos, le asigna una fecha, hora y box. De no
tener disponibilidad, busca un cupo de otro estudiante o
fonoaudiólogo y le asigna fecha, hora y box.
c) El paciente está registrado y se le agenda una nueva sesión dando
fecha, hora y box, todo a través de su ficha clínica.
Este calendario debe mostrar las horas que están reservadas y los cupos
disponibles de cada interno y fonoaudiólogo del centro.
Prioridad: Alta Conflictos Cuando se trate de ingresar un
horario ocupado, el sistema
debe ser capaz de avisar que
no se puede realizar la reserva
de horario.
54
El usuario puede agendar una hora a un paciente registrado para la próxima sesión, como se
ve en la figura 4.18. En el caso de atención por primera vez, el paciente debe ser ingresado al
sistema y a partir de ahí asignar un horario de atención.
Figura 4. 18: Ventana de asignación de horario a paciente
55
11. Mostrar agenda horaria
Tabla 4. 12: Requerimiento mostrar agenda horaria del centro.
Requerimiento: RF11 Tipo funcional Eventos / CU11, CU12,

Requerimiento: Casos de Uso CU18, CU21
Descripción: El sistema permite mostrar la agenda completa del centro.
Fundamentos: El centro debe atender a los pacientes, para ellos es importante poder saber que
fonoaudiólogo o estudiante tiene disponible una hora para asignarle a un
paciente que solicite atención.
Criterio: El sistema debe presentar un horario semanal, con la agenda diaria de cada box.
El CECH cuenta con cuatro box, por lo que sólo se podrán realizar cuatro
atenciones a la misma hora y en un mismo día.
Se estima en promedio que la atención a un paciente es de 45 minutos, por lo que
se debe registrar en la agenda un paciente cada 45 minutos.
El sistema debe desplegar una tabla donde se indique la fecha, el box y en las filas
se indique la hora correspondiente a la atención, el paciente que será atendido y
el fonoaudiólogo o interno que atenderá a ese paciente, así también mostrar los
bloques disponibles para asignar un nuevo horario.
Además debe permitir poder imprimir dicho calendario.
Se debe dar la opción al interno o fonoaudiólogo de modificar una hora que tiene
reservada, ya que existe la posibilidad de que un paciente cancele la hora.
Prioridad: Alta Conflictos: No posee.
Materiales de Soporte:
56
Cuando ocurre el caso de que el paciente no posee ficha clínica se debe verificar el horario del
CECH, como se ve en la figura 4.19. Para destinar el paciente a un Interno o Fonoaudiólogo
que pueda atender e ingresar al paciente.
Figura 4. 19: Horario general del CECH
57
12. Editar ficha clínica
Tabla 4. 13: Requerimiento editar registros erróneos.
Requerimiento: RF12 Tipo Funcional Eventos / CU15, CU16

Descripción: El sistema debe permitir a los usuarios registrados como fonoaudiólogos editar
información almacenada en el sistema.
Fundamentos: En el CECH mayoritariamente trabajan estudiantes en práctica, estos pueden
ingresar información errónea, la que debe ser corregida, para no perder el
control de quien modifica cambios en la información de un paciente, sólo un
usuario con perfil de fonoaudiólogo puede realizar un cambio.
Criterio: El sistema debe permitir realizar cambios a todos los registros que acceda un
estudiante, estas modificaciones que realiza el fonoaudiólogo debe registrar la
última fecha y la identificación de quién realizó el cambio. Esta facultad se aplica
en el ingreso de un historial médico de un paciente, el diagnóstico de un paciente,
los datos personales de un paciente, los resultados de un examen.
Prioridad: Alta Conflictos Se perderá el registro de la
última modificación.
58
Si comparamos la figura 4.9, que es la ficha clínica vista por el estudiante, con la figura 4.18.
En la figura 4.18, se aprecian nuevos botones editar diagnóstico, editar historial. Botones que
el estudiante no posee. Esto con el fin de resguardar la información de los pacientes.
Figura 4. 20: Ficha clínica visto desde el perfil fonoaudiólogo.
59
13. Control Histórico de fichas y usuarios
Tabla 4. 14: Requerimiento para resguardar la información histórica.
Requerimiento: RF13 Tipo Funcional/ Eventos / CU27

Requerimiento: Seguridad Casos de Uso
Descripción: El sistema debe permitir un estado para que la información de un paciente y de
un Usuarios en particular, pueda ser restringida en el sistema.
Fundamentos: Los pacientes irán aumentando mediante el pasar de los años, habrá nuevas
fichas clínicas, así como también quedarán fichas obsoletas de pacientes que ya
no se atienden. Para resguardar la información de aquellos pacientes que
dejaron el centro y su ficha quedó sin uso, es necesario indicar un estado del
paciente, con el fin de que la información de ese paciente, sólo sea utilizada con el
fin de tener el registro. Así mismo pasaran varios Usuarios, fonoaudiólogos e
internos, los cuales, una vez que hayan terminado su participación en el CECH,
deben quedar bloqueados para acceder el sistema.
Criterio: El sistema, permite al administrador buscar y seleccionar un paciente y da la
opción de cambiar el estado de activo a pasivo o viceversa, de manera que la
ficha clínica sólo pueda ser visualizada por el resto de los usuarios, sólo si el
paciente es activo.
También, el sistema permite al administrador, buscar y seleccionar un usuario

(fonoaudiólogo o interno) y cambiar el estado asociado a ese usuario, de activo a
inactivo o viceversa.
Prioridad: 4 Conflictos
Este requerimiento viene a cubrir la necesidad de asegurar aquella información de paciente

que no estén activos, de igual forma pasa con los usuarios del centro. En la figura 4.21, se
visualiza el caso de que el administrador desee dejar inactivo un usuario o si quiere reactivar
60
uno que se encuentre fuera de la actividad. Al seleccionar en la pestaña de paciente, deben

ser similares los campos y permite realizar el mismo procedimiento.
Figura 4. 21: Prototipo para realzar cambios de los estados Histórico de pacientes y usuarios.
61
4.4.2 Requisitos No funcionales
1. Visualizar aplicación.
Tabla 4. 15: Requerimiento para la visualización del sistema.
Requerimiento: NF01 Tipo Apariencia Eventos /

Descripción: El sistema debe llevar una combinación de colores, basado en el manual de
comunicación corporativa de la Universidad del Bío Bío (UBB).
Fundamentos: El CECH, es una institución perteneciente a la Universidad del Bío Bío, por ello se
sugiere que el diseño cumpla con las normas.
Criterio: Se pide una propuesta de la aplicación con la combinación de colores acorde a las
normas gráficas y conceptuales de la UBB. Además se debe considerar los logos
de la escuela de fonoaudiología y del propio CECH.
Prioridad: Media Conflictos
Materiales de Soporte http://www.ubiobio.cl/mcc/index.html
2. Control acceso de internos.

Tabla 4. 16: Requerimiento control acceso a estudiantes.
Requerimiento: NF02 Tipo Seguridad Eventos /

Descripción: El sistema debe permitir a los usuarios registrados como estudiantes (internos),
que pueden ingresar al sistema, sólo en el horario que trabaja el CECH.
Fundamentos: Existe la posibilidad de que el estudiante pueda acceder a la aplicación en otro
horario y utilizar información de los pacientes, acción que no está permitida.
Criterio: Se pide que el sistema sólo permita ingresar a los estudiantes mientras estos
estén en el centro. Para desarrollar esto, la aplicación debe dar acceso a los
estudiantes, durante el horario de atención de pacientes que posee el CECH.
Prioridad: Alta Conflictos
62
4.4.3 Lista de Casos de Uso del Producto
En la sección 4.3.1, alcances del producto, se presentaron tres figuras, correspondientes a los
diagramas de casos de uso. Estos casos de usos muestran de manera gráfica la relación
existente entre las funciones del sistema y los actores. A continuación se realizará la
descripción de cada caso de uso presentado en aquellos esquemas, con tal de detallar, la
función que cumple cada uno, dentro del sistema.
1. ID: CU01. Caso de Uso: Login.
 Descripción: El sistema debe controlar el acceso de los usuarios registrados y los que
no lo están.
 Pre-Condiciones: no posee.
 Actor Principal: Administrador, Estudiantes, Fonoaudiólogos.
 Flujo de Eventos Básicos:
Tabla 4. 17: Flujo de eventos básicos, login.
Administrador/Estudiante/Fonoaudiólogo El sistema
1. El usuario registrado decide ingresar al 2. El sistema muestra los campos
sistema. necesarios para validar, Rut y
contraseña.
3. El usuario registrado ingresa sus datos, 4. El sistema valida los campos
en los campos correspondientes. introducidos por el usuario.
5. El usuario ingresa al sistema. 6. El sistema muestra la pantalla de
inicio.
 Flujo de Eventos Alternativo:
1. El usuario no se ha registrado, debe contactar al administrador.
3a. El usuario olvidó contraseña, debe solicitarla mediante opción de olvidar

contraseña.
4a. No existe usuario, contraseña incorrecta o el usuario olvidó contraseña.
63
4a.1. El sistema avisa al usuario con un mensaje de error si la contraseña o

el usuario son erróneos.
4a.2. El sistema reenvía una nueva contraseña al correo del usuario

almacenado en el sistema, si el usuario lo solicita.
 Post-Condiciones: no posee.
2. ID: CU02. Caso de Uso: Crear usuario.
 Descripción: El sistema debe entregar la opción al administrador para crear más

usuarios.
 Pre-Condiciones: El usuario debe estar registrado en el sistema e ingresar con perfil
de administrador.
 Actor Principal: Administrador.
Tabla 4. 18: Flujo de eventos básicos, crear usuario.
Administrador El sistema
1. El administrador decide registrar un 2. El sistema muestra las opciones de
nuevo usuario crear tres tipos de usuarios
diferentes, un nuevo administrador,
un fonoaudiólogo, un estudiante
(interno) presentando los campos que
deben ser llenados para registrar un
nuevo usuario.
3. El administrador selecciona el tipo de 4. El sistema crea el nuevo usuario,
usuario e ingresa los datos del nuevo además de asignar una contraseña por
usuario solicitados por el sistema, en los defecto.
campos correspondientes.
3a. El usuario cancela la operación.
64
4a. El usuario ya está registrado con el mismo perfil en el sistema. Un usuario puede
ser registrado con diferentes perfiles.
3. ID: CU03. Caso de Uso: Generar reportes.
 Descripción: El sistema da la opción de generar reportes estadísticos.

 Pre-Condiciones: El usuario debe estar registrado en el sistema.
Tabla 4. 19: Flujo de eventos básicos, generar reporte.
1. El administrador quiere obtener un 2. El sistema presenta la opción de
reporte. generar reporte dado un rango, dado
un mes, año y día.
3. El administrador selecciona: 4. El sistema solicita:
3.1. Generar reporte con rango de 4.1. una fecha de inicio y una fecha
fecha. de fin, para realizar el reporte
3.2. Generar reporte del día, mes o dado el rango definido por esas
año actual. fechas.
4.2. Genera el reporte del día, mes o
año actual. Y accede al flujo 7.
5. El usuario: 6. El sistema genera el reporte dentro del
5.1. Ingresa las fechas en los campos rango solicitado.
requeridos.
7. El administrador puede seleccionar:
7.1. Guardar el documento en el
computador.
7.2. Imprimir el documento.
65
6a. El sistema muestra mensaje de error, por fechas no válidas.
4. ID: CU04. Caso de Uso: Registrar paciente.
 Descripción: El sistema debe permitir registrar un paciente.

 Actor Principal: Fonoaudiólogo, Estudiantes.
Tabla 4. 20: Flujo de eventos básicos, registrar paciente.
Fonoaudiólogo/Estudiante Sistema
1. El fonoaudiólogo/estudiante quiere 2. El sistema muestra los campos
ingresar un paciente. necesarios para registrar un nuevo
paciente.
3. El fonoaudiólogo/estudiante ingresa los 4. El sistema crea el nuevo paciente, este
datos del nuevo paciente que solicita el caso de uso incluye, caso de uso: Crear
sistema. ficha clínica
3a. El fonoaudiólogo/estudiante cancela la operación.
4a. El sistema despliega un mensaje si el usuario que se está creando ya existe.
 Post-Condiciones: El sistema debe crear una ficha clínica para el paciente creado.
5. ID: CU05. Caso de Uso: Crear ficha clínica.
 Descripción: El sistema crea y asocia una ficha clínica a un paciente.

 Actor Principal: Fonoaudiólogo, Estudiante.
66
Tabla 4. 21: Flujo de eventos básicos, crear ficha clínica.
Fonoaudiólogo/Estudiante El sistema
1. El sistema crea la ficha clínica a partir
de un paciente registrado.
2. El fonoaudiólogo ingresa los datos 3. El sistema guarda los datos.
solicitados por la nueva ficha clínica.
2a.1. El sistema arroja un mensaje de error, especificando que no se puede cancelar,

dado que no ha terminado el proceso.
6. ID: CU06. Caso de Uso: Agregar consentimiento informado.
 Descripción: El sistema debe permitir subir en formato digital el conocimiento

informado de un paciente, este es un documento firmado por el paciente el cual
otorga a los fonoaudiólogo trabajar bajo ciertas normas que conoce el paciente.
 Pre-Condiciones:
- El usuario debe estar registrado en el sistema.

- El paciente debe estar registrado en el sistema.

67
Tabla 4. 22: Flujo de eventos básicos, agregar consentimiento informado.
1. El fonoaudiólogo/estudiante desea 2. El sistema despliega una ventana de
adjuntar el documento digitalizado a la búsqueda de archivos, la que permite
ficha clínica, para ello selecciona el buscar dentro de los dispositivos de
paciente, luego la ficha clínica y almacenamiento (disco duro, CD, DVD
selecciona adjuntar consentimiento o memoria externa), aquel archivo del
informado. documento informado en formato
digital.
3. El fonoaudiólogo/estudiante busca el 4. El sistema despliega que el archivo ha
archivo en el dispositivo donde está sido subido exitosamente. Despliega una
almacenado el documento de opción de visualización.
conocimiento informado, lo selecciona
para subirlo al sistema.
2a. El sistema ya cuenta con un registro de consentimiento informado. El sistema

consulta si desea sobrescribir el documento.
2a.1. El usuario selecciona que desea sobrescribir. El sistema envía al flujo

3.
2a.2. El usuario selecciona que no desea sobrescribir. El sistema envía al

flujo 3a.
3a. El fonoaudiólogo/estudiante cancela la opción.
4a. El archivo no válido. El sistema muestra un error.
4a.1. El archivo no posee el formato indicado.
4a.2. El archivo excede el tamaño establecido.
68
7. ID: CU07. Caso de Uso: Listar y buscar pacientes.
 Descripción: El sistema debe permitir ver un listado de pacientes además de

realizar filtros de búsquedas para los pacientes.
Tabla 4. 23: Flujo de eventos básicos, listar y buscar paciente.
1. El fonoaudiólogo/estudiante necesita 2. El sistema despliega por pantalla un
visualizar uno o varios pacientes. listado de todos los pacientes
registrados.
3. El fonoaudiólogo/estudiante puede: 4. El sistema actúa según la opción elegida
3.1. Seleccionar un paciente. por el usuario:
3.2. Buscar un paciente. 4.1. Si es seleccionado un paciente el
3.3. Filtrar los datos de un paciente. sistema debe direccionar a una
página con el perfil del paciente.
4.2. El sistema busca un paciente
determinado, por Rut o Apellido
Paterno, y en el listado de
pacientes solamente se
muestran aquellos resultados
que coinciden con la búsqueda.
4.3. Las filas del listado se ordenan
de acorde al filtro utilizado
3a. El fonoaudiólogo/estudiante cancela la operación.
 Post-Condiciones: El sistema debe crear una ficha clínica para el paciente creado.
69
8. ID: CU08. Caso de Uso: Ver ficha paciente.
 Descripción: El sistema muestra un perfil del paciente, con datos personales y

clínicos.

- El usuario debe estar registrado en el sistema

70
Tabla 4. 24: Flujo de eventos básicos, ver ficha paciente.
1. El fonoaudiólogo/estudiante busca o 2. El sistema despliega un perfil del
selecciona un paciente y desea ver los paciente, con los datos personales y el
antecedentes clínicos del paciente historial médico. Además de entregar
varias opciones.
2.1. Agregar diagnóstico.
2.2. Agregar Consentimiento
informado.
2.3. Reservar Hora.
2.4. Agregar Historial a Ficha Clínica
2.5. Aplicar instrumentos de
evaluación
2.6. Agregar informe
fonoaudiológico.
3. El fonoaudiólogo/estudiante selecciona 4. El sistema responde según la opción del
una opción: fonoaudiólogo/estudiante.
3.1. Agregar diagnóstico. 4.1. Extiende al caso de uso: CU26.
3.2. Agregar Consentimiento 4.2. Extiende al caso de uso: CU06.
informado. 4.3. Ejecuta el caso de uso: CU21.
3.3. Reservar Horario 4.4. Extiende al caso de uso: CU10.
3.4. Agregar nuevo historial al 4.5. Extiende al caso de uso: CU17.
paciente. 4.6. Extiende al caso de uso: CU09.
3.5. Aplicar instrumentos de
evaluación.
3.6. Agregar informe
fonoaudiológico.
3a.1. El fonoaudiólogo termina el proceso.
71
9. ID: CU09. Caso de Uso: Agregar informe fonoaudiológico.
 Descripción: El sistema debe permitir subir en formato digital el informe

fonoaudiológico de un paciente, este es un documento creado por los estudiantes,
dado un estudia a un paciente.
 Pre-Condiciones: El paciente al que se adjunta el informe fonoaudiológico debe
estar registrado en el sistema.
 Actor Principal: Estudiante, Fonoaudiólogo.
Tabla 4. 25: Flujo de eventos básicos, agregar informe fonoaudiológico.
Estudiante/Fonoaudiólogo El sistema
1. El estudiante/fonoaudiólogo debe 2. El sistema realiza dos acciones.
adjuntar el documento digitalizado a la 2.1. Primero muestra un listado con
ficha clínica, para ello selecciona el los informes anteriores de otros
paciente, luego la ficha clínica y estudiantes, que han hecho un
selecciona adjuntar informe informe fonoaudiológico al
fonoaudiológico. mismo paciente, para que
puedan ser visualizados.
2.2. El sistema ofrece un botón que
despliega una ventana de
búsqueda de archivo, para que
se ubicado en archivo digital.
3. El estudiante/fonoaudiólogo tiene dos 4. El sistema:
opciones: 4.1. El sistema abre y muestra el
3.1. El estudiante puede seleccionar documento seleccionado.
un archivo previo del listado 4.2. El sistema despliega que el
para visualizar. archivo ha sido subido
3.2. Busca en la dirección donde está exitosamente. Agrega el nuevo
almacenado el documento del archivo al resto de los archivos
informe fonoaudiológico, lo previos que han sido subidos. Y
selecciona para subirlo al despliega la opción de
sistema. visualización.
72
3a. El estudiante/fonoaudiólogo cancela la opción.
4.2a. El archivo no válido. El sistema muestra un error.
4.2a.1. El archivo no posee el formato indicado.
4.2a.2. El archivo excede el tamaño establecido.
10. ID: CU10. Caso de Uso: Agregar historial a ficha clínica.
 Descripción: El sistema presenta la opción de Agregar historial a la ficha clínica de

un paciente seleccionado, a partir del registro diario que se le hace a dicho
paciente.
 Pre-Condiciones: El paciente debe estar registrado en el sistema.
73
Tabla 4. 26: Flujo de eventos básicos, agregar historial a ficha clínica.
1. El fonoaudiólogo/estudiante busca o 2. El sistema crea una fila dentro de la
selecciona un paciente y requiere: tabla del historial, que permita
1.1. Agregar una revisión a la ficha ingresar los datos para realizar un
clínica de ese paciente. registro diario del paciente.
1.2. Aplicar un procedimiento 2.1. Si es una revisión, el campo de
terapéutico al paciente. objetivo operacional debe
quedar vacío.
2.2. Si se trata de un procedimiento
terapéutico, el campo de
objetivo operacional, debe
mostrar una lista con los
objetivos operacionales
pendientes, del programa
terapéutico.
3. El fonoaudiólogo/estudiante completa 4. El sistema almacena la información y
los campos requeridos por el sistema y direcciona a la página del paciente.
guarda el registro diario del paciente.
3a.1. El fonoaudiólogo/estudiante cancela el proceso.
11. ID: CU11. Caso de Uso: Ver horario.
 Descripción: El sistema muestra una tabla con el horario de una semana

seleccionada de todos los estudiantes y fonoaudiólogos del centro.
 Pre-Condiciones: no posee.
74
Tabla 4. 27: Flujo de eventos básicos, ver horario.
1. El fonoaudiólogo/estudiante desea 2. El sistema presenta:
revisar la disponibilidad de horarios del 2.1. Solicita una determinada fecha
centro. de inicio y una de fin, luego
1.1. El fonoaudiólogo/estudiante muestra por cada día, la
puede ver el horario general del disponibilidad horaria del
CECH. centro, las horas reservadas y en
1.2. El fonoaudiólogo/estudiante que box fue registrada dicha
puede ver solamente su horario hora, además del paciente y
fonoaudiólogo que la reservo.
2.2. El sistema muestra el horario del
fonoaudiólogo/estudiante.
 Flujo de Eventos Alternativo: no posee.

12. ID: CU12. Caso de Uso: Reservar horario paciente.
 Descripción: El sistema permite seleccionar un paciente, para que se le asigne una

reserva de horario de atención
 Pre-Condiciones: Los usuarios deben estar registrados en el sistema.
 Actor Principal: Fonoaudiólogo, Estudiantes.
75
Tabla 4. 28: Flujo de eventos básicos, reservar horario paciente.
1. El Fonoaudiólogo/Estudiante decide 2. El sistema muestra el horario de la
realizar una reserva para un paciente. semana, día, horas y salas disponibles,
además muestra las horas reservadas,
el fonoaudiólogo o estudiante que la
reservó y el paciente a quien se le
reservo. Además solicita una fecha
para realizar una nueva reservación.
3. El usuario, selecciona un box y una hora 4. El sistema registra la reserva de
disponible del horario en la semana o horario y queda a la vista para el resto
selecciona una nueva semana para de los usuarios.
reservar el horario.
3a. El usuario seleccionó un box ocupado.
3b. El usuario seleccionó un paciente que ya tenía un horario asignado ese día.
3c. El usuario selecciono un horario que estaba ocupado
4a. Para todos los flujos alternativos que se de en 3, el sistema debe avisar que no
puede registrar la hora al paciente, indicando el motivo del error si es por box,
paciente u horario.
 Post-Condiciones: No posee
13. ID: CU13. Caso de Uso: Editar ficha clínica.
 Descripción: El sistema permite editar alguna información incorrecta de un

paciente.
 Pre-Condiciones: Debe existir un paciente para editar la información.
 Actor Principal: Fonoaudiólogo.
76
Tabla 4. 29: Flujo de eventos básicos, editar.
Fonoaudiólogo El sistema
1. El fonoaudiólogo desea editar ficha 2. El sistema permite:
clínica: 2.1. Modificar la información
1.1. Ficha de un paciente. registrada de un paciente en la
1.2. Exámenes de un paciente. ficha clínica.
1.3. La reserva de horario de un 2.2. Realizar alguna corrección en
paciente. algún examen tomado a un
paciente.
2.3. Cambiar la reserva horaria de un
paciente
3. El fonoaudiólogo/estudiante selecciona 4. El sistema muestra un formulario con
una opción. los campos completos acordes a la
selección, permitiendo modificar
dichos campos y la opción de guardar
dichos cambios.
5. El usuario guarda los cambios. 6. El sistema informa que se han
guardado los cambios correctamente
y registra que usuario realizó los
cambios.
3a. El fonoaudiólogo/estudiante cancela la opción
5a. El usuario no guarda los cambios, el sistema no sufre modificación.
6a. El sistema no guardó los cambios, faltan datos.
77
14. ID: CU14. Caso de Uso: Ver exámenes.
 Descripción: El sistema ofrece una opción para visualizar los exámenes de un

paciente determinado.
 Pre-Condiciones: El usuario debe estar registrado en el Sistema.
Tabla 4. 30: Flujo de eventos básicos, ver exámenes.
1. El fonoaudiólogo/estudiante: 2. El sistema:
1.1. Selecciona un paciente de la lista 2.1. Despliega una lista con los
de pacientes exámenes del paciente
1.2. Busca un paciente por su RUN, seleccionado.
número de ficha o Nombre 2.2. El sistema busca el paciente y
despliega el listado de los
exámenes del paciente.
3. El fonoaudiólogo visualiza los exámenes 4. El sistema muestra el detalle del examen
realizados y puede ver detalles del que se desea visualizar.
examen.
2a.2. el sistema no encuentra al paciente, informa al usuario y lo direcciona al flujo

1.
2b.2 el sistema encuentra más de un resultado para la búsqueda por nombre,

solicita al usuario que seleccione uno de los encontrados, direccionando al flujo 1.
3a. El fonoaudiólogo cancela el proceso.
78
15. ID: CU15. Caso de Uso: Ver perfil.
 Descripción: El sistema muestra los datos del usuario registrado en el sistema.

 Actor Principal: Todos.
Tabla 4. 31: Flujo de eventos básicos, ver perfil.
Usuarios El sistema
1. El usuario desea verificar los datos 2. El sistema muestra todos los datos
de su cuenta. registrados del usuario, excepto la
contraseña. Además la opción de
cambiar contraseña actual
3. El usuario desea cambiar la contraseña. 4. El Sistema envía al usuario a una
página de cambio de contraseña.
 Flujo de Eventos Alternativo: no posee.

16. ID: CU16. Caso de Uso: Cambiar contraseña.
 Descripción: El sistema permite a los usuarios cambiar su contraseña de ingreso.

Tabla 4. 32: Flujo de eventos básicos, cambiar contraseña.
Usuarios El sistema
1. El usuario accede a cambiar su 2. El sistema muestra los campos para
contraseña. realizar el cambio, solicitando la
contraseña actual, y la nueva
contraseña.
3. El usuario ingresa la información 4. El Sistema notifica que la contraseña
solicitada por el sistema y guarda. ha sido cambiada con éxito.
79
4a. Error en el cambio de contraseña:
4a.1. La contraseña ingresada no es válida.
4a.2. La nueva contraseña no cumple los requisitos solicitados.
17. ID: CU17. Caso de Uso: Realizar examen.
 Descripción: El sistema permite a los estudiantes o fonoaudiólogos a registrar el

resultado de los exámenes aplicados al paciente.
 Actor Principal: Estudiante, Fonoaudiólogos.
Tabla 4. 33: Flujo de eventos básicos, realizar examen.
Usuarios El sistema
1. El Estudiante/Fonoaudiólogo desea 2. El sistema hace un registro de la fecha
realizar un examen. y muestra una lista con los exámenes
clasificados en:
2.1. Protocolos cuantitativos.
2.2. Protocolos cualitativos
3. El usuario selecciona un tipo de 4. El sistema almacena el tipo de
protocolo y luego busca el que desea examen seleccionado y según la
aplicar. selección incluye a los casos de uso:
4.1. Protocolos cualitativos (CU23).
4.2. Protocolos cuantitativos (CU22).
5. El usuario realiza lo solicitado por los 6. El sistema presenta un campo donde
casos de usos que están incluidos. se pueden agregar observaciones al
protocolo. Además da la opción para
guardar la información
7. El usuario guarda la información. 8. El sistema informa que se ha
guardado correctamente.
80
3a. El usuario cancela la opción.
18. ID: CU18. Caso de Uso: Reporte Horario.
 Descripción: El sistema permite obtener un reporte del horario de atención del

CECH dentro de una fecha solicitada.
 Actor Principal: Estudiante, Fonoaudiólogos.
Tabla 4. 34: Flujo de eventos básicos, reporte agenda.
Usuarios El sistema
1. El Estudiante/Fonoaudiólogo desea 2. Ofrece a partir de la inclusión del caso
obtener un reporte del horario de de uso: Ver Horario, una opción para
atención. exportar a un archivo el horario
generado.
3. El usuario acepta y ahora puede 4. El Sistema genera un reporte con los
imprimir el archivo o almacenarlo. horarios de atención definidos dentro
de las fechas solicitadas.
4a. La fecha no es válida:
4a.1.La fecha no existe o tiene un formato erróneo.
4a.2. La fecha de inicio es después de la fecha de término.
81
19. ID: CU19. Caso de Uso: Editar usuario.
 Descripción: El sistema permite cambiar la información de un usuario registrado,

salvo la contraseña de ese usuario.
 Pre-Condiciones: El usuario debe estar registrado en el sistema y contar con perfil
de administrador.
Tabla 4. 35: Flujo de eventos básicos, editar usuario.
1. El administrador desea cambiar 2. El sistema muestra una lista con
información de un usuario. usuarios, además ofrece buscar un
usuario por su RUN.
3. El usuario selecciona un paciente de la 4. El Sistema:
lista o realiza una búsqueda. 4.1. Carga los datos del paciente
seleccionado.
4.2. El sistema busca al paciente
solicitado y carga los datos.
5. El administrador puede realizar 6. El sistema almacena la información,
cambios en la información del usuario avisa que los cambios han sido
seleccionado o buscado y guardar. guardados.
4a.2. El sistema no encontró al usuario buscado y envía al administrador al flujo 3.
5a. El administrador debe corregir la búsqueda para un usuario válido y vuelve al

flujo 4.
6a. El sistema no guarda los datos, el usuario ingresó mal algún dato. Debe
especificar que dato es erróneo y ejemplificar como debe ser ingresado. Direcciona
al flujo 5.
82
20. ID: CU020. Caso de Uso: Logout.
 Descripción: El sistema debe entregar la opción a los usuarios que estén dentro del
sistema, para cerrar su sesión.
Tabla 4. 36: Flujo de eventos básicos, logout.
Usuarios El sistema
1. El sistema muestra a los usuarios que
ingresaron al sistema, la opción para
cerrar sesión.
2. El usuario decide cerrar sesión. 3. El sistema cierra la sesión y direcciona
a la página de inicio del sistema.
4a. El Sistema tiene un formulario abierto y no puede cerrar la sesión, muestra un

mensaje que indique al usuario a finalizar el formulario.
 Post-Condiciones: Una vez cerrada la sesión el usuario no puede volver a entrar,

mientras no ingrese los datos solicitados por el caso de uso login.
21. ID: CU021. Caso de Uso: Modificar horario paciente.
 Descripción: El sistema debe permitir cambiar la hora de un paciente o eliminarla.

83
Tabla 4. 37: Flujo de eventos básicos, modificar horario paciente.
1. El usuario desea realizar un 2. El sistema muestra dos opciones:
cambio de horario de un paciente. 2.1. Eliminar Hora.
2.2. Cambiar Hora.
3. El usuario debe escoger una 4. El sistema actuará de acuerdo a la
opción: opción seleccionada:
4.1. El sistema elimina el registro de la
hora reservada y muestra un
mensaje informando que ha sido
eliminada. Fin de este flujo.
4.2. El sistema presenta un campo que
solicita una fecha, otro campo que
solicita una nueva hora y un
campo donde solicita el box.
5.2. Ingresa los datos solicitados por el 6.2. El sistema almacena el nuevo día, hora
sistema. y sala para la nuevo horario de
atención del paciente.
5.2a. El usuario cancela la opción.
6.2a. El sistema no puede realizar el cambio de horario, existe un conflicto con la

fecha, hora o sala del nuevo registro.
84
22. ID: CU022. Caso de Uso: Protocolos Cualitativos.
 Descripción: Este caso de uso proviene del caso de uso CU17. El sistema debe
permitir registrar los protocolos del anexo 10.2, que sólo registren información
cualitativa.

- El usuario debe querer realizar un examen.

Tabla 4. 38: Flujo de eventos básicos, Protocolos cualitativos.
1. El sistema despliega los siguientes
campos: Descripción y conclusión.
Además indica el nombre del examen
que se está realizando y da lo opción
de guardar.
2. El usuario ingresa una descripción 3. El sistema almacena la información
y una conclusión del examen que del examen e indica que el examen ha
realizó, luego guarda. sido almacenado con éxito.
2a. El usuario cancela la operación
85
23. ID: CU023. Caso de Uso: Protocolos Cuantitativos.
 Descripción: Este caso de uso proviene del caso de uso CU17. El sistema debe
permitir ingresar información de los protocolos aplicados del anexo 10.1, y dada
esa información nos entregue algún resultado.

- El usuario debe querer realizar un examen.

Tabla 4. 39: Flujo de eventos básicos, Protocolos cuantitativos.
1. El sistema despliega los siguientes
campos: Puntaje total y conclusión.
Además indica el nombre del
protocolo que se está realizando, y
genera una diagnóstico a partir del
puntaje ingresado, además da lo
opción de guardar.
2. El usuario ingresa una descripción 3. El sistema almacena la información
y un puntaje total del protocolo del examen e indica que el examen ha
aplicado, luego guarda. sido almacenado con éxito.
86
24. ID: CU024. Caso de Uso: Programa Fonoaudiológico.
 Descripción: El sistema debe permitir ingresar un programa fonoaudiológico,

donde se plantean objetivos generales del tratamiento, luego para cada objetivo
general se detalla los objetivos específicos y estos a la vez poseen varios objetivos
operacionales.

- El usuario debe crear un programa asociado a un paciente.

87
Tabla 4. 40: Flujo de eventos básicos, Programa fonoaudiológico.
1. El fonoaudiólogo/estudiante desea 2. El sistema :
crear un programa fonoaudiológico a 2.1. Despliega una lista con los
un paciente determinado y selecciona objetivos generales y da la opción
en la ficha del paciente, programa para seleccionar uno.
fonoaudiológico. 2.2. El sistema ofrece la opción de
crear un nuevo objetivo general.
3. El usuario: 4. El sistema:
3.1. El usuario selecciona un objetivo 4.1. El sistema presenta un listado
general. con los objetivos específicos
3.2. El usuario decide ingresar un asociados al objetivo general
nuevo objetivo general. seleccionado.
4.2. El sistema abre una ventana e
incluye el caso de uso: CU25.
5.1. El usuario selecciona un objetivo 6.1. Despliega una nueva tabla con los
específico. objetivos operacionales, cuáles
5.2. El usuario decide ingresar un de estos están completados y
nuevo objetivo específico, para el cuáles están pendientes, asignado
objetivo general seleccionado al objetivo específico
previamente. seleccionado.
6.2. El sistema abre una ventana e
inicia el caso de uso: CU25.
7.1. El usuario selecciona un objetivo 8.1. El sistema direcciona a la
operacional que este pendiente y creación de un nuevo historial
puede aplicar el objetivo. del paciente, CU10, registrando
7.2. El usuario desea ingresar un el objetivo operacional en el
nuevo objetivo operacional, para campo con el mismo nombre.
le objetivo específico 8.2. El sistema abre una ventana e
seleccionado. inicia el caso de uso: CU25.
88
25. ID: CU025. Caso de Uso: Ingresar un objetivo.
 Descripción: El sistema debe permitir ingresar objetivos ya sea generales,

específicos y operacionales.

- El usuario debe crear un objetivo relacionado a un programa
fonoaudiológico de un paciente.

89
Tabla 4. 41: Flujo de eventos básicos, ingresar un objetivo.
1. El sistema despliega un formulario
con el campo para ingresar la
descripción del objetivo. Además debe
entregar el número correspondiente
del objetivo.
2. El usuario ingresa una descripción del 3. El sistema almacena la información
objetivo. del objetivo, si es un objetivo
operacional, lo guarda referenciando
una objetivo específico. Si es un
objetivo específico, este se almacena
referenciando a un objetivo general y
el objetivo general se referencia a un
paciente.
26. ID: CU026. Caso de Uso: Registrar diagnóstico.
 Descripción: El sistema debe permitir el registro de uno o varios diagnósticos para

un paciente.


90
1. El usuario, requiere ingresar un nuevo 2. El sistema presenta una tabla con el
diagnóstico a un paciente. código y nombre del diagnóstico,
además quién lo diagnosticó y en qué
fecha. Además el sistema ofrece
agregar un nuevo diagnóstico.
3. El usuario selecciona agregar 4. El sistema despliega un formulario
diagnóstico. con el listado de todos los
diagnósticos.
5. El usuario selecciona el diagnóstico 6. El sistema almacena y muestra la
del paciente. tabla actualizada con todos los
diagnósticos del paciente.
27. ID: CU027. Caso de Uso: Administrar Registros de usuarios y pacientes.
 Descripción: El sistema debe permitir buscar un paciente o usuario registrado y da

la opción de cambiar el estado de la persona buscada.

91
1. El administrador requiere cambiar el 2. El sistema presenta dos pestañas:
estado de un paciente o usuario del
2.1. Usuario.
centro.
2.2. Paciente.
3. El usuario selecciona una de las 4. El sistema presenta una opción para

pestaña. Siendo por defecto la de que el usuario decida el filtro para
usuario. buscar.
5. El usuario selecciona un filtro e 6. El sistema despliega un listado con las
ingresa el dato que desea buscar coincidencias de la búsqueda y
muestra la opción para cambiar el
estado de la búsqueda.
7. El usuario cambia el estado de la 8. El sistema informa que los cambios
persona buscada. han sido almacenados correctamente.
3. El usuario cancela la operación.
4. El sistema no encontró coincidencias.
5. El usuario cancela la operación
7. El usuario cancela la operación
92
4.4.4 Matriz resumen de Casos de uso y Requerimientos.
A continuación se presenta una matriz donde se muestra en las columnas los requerimientos
anteriormente desarrollados y en las filas se presentarán los casos de uso, con el fin de
indicar la relación de los casos de uso en los requerimientos.
Tabla 4. 44: Tabla matriz de relación casos de uso con requerimientos.
RF RF RF RF RF RF RF RF RF RF RF RF RF NF NF
01 02 03 04 05 06 07 08 09 10 11 12 13 01 02
CU01 X
CU02 X
CU03 X
CU04 X
CU05 X
CU06 X
CU07 X
CU08 X
CU09 X
CU10 X X
CU11 X X
CU12 X
CU14 X
CU15 X
CU16 X
CU17 X
CU18 X
CU19 X
CU20 X
CU21 X
CU22 X
CU23 X
CU24 X
CU25 X
CU26 X
CU27 X
93
4.5 Etapa de Control de Calidad.
Esta etapa se desarrolló en conjunto con el cliente, aquí se presentan cada prototipo de
manera detallada, junto con la definición del requisito. El cliente, aprueba aquellos requisitos,
con los que estaba conforme, hacía sugerencias y también intervenía en el desarrollo,
solicitando modificaciones para aquellos requerimientos que no cumplen con las verdaderas
necesidades del centro o que simplemente no abarcaban toda la necesidad que solicita el
CECH.
Aprobado el requisito, los documentos quedan listos para pasar a la siguiente etapa de
revisión.
4.6 Etapa Revisión de requisitos.
El cliente revisó todos los requisitos en conjunto, para ver si cumplen las expectativas y
necesidades solicitadas, además de cerciorarse de que no haga falta nada. Cabe mencionar
que al trabajar con un solo cliente, facilitó la revisión, ya que al momento de realizar el
control, desde ya, se iban realizando correcciones pertinentes y al momento de asociar todas
las funcionalidades requeridas, ya existía una idea del usuario acerca del funcionamiento.
Los riesgos para este proyecto van asociados al futuro incierto que tienen las siguientes
etapas de análisis, diseño y construcción, debido a que está es sólo una primera etapa del
proyecto, correspondiente a la elicitación de requerimientos.
Por otro lado los costos significativos del proyecto se enfocan en la necesidad de
infraestructura y equipos computacionales para poder utilizar el producto una vez que esté
finalizado.
A modo de comprobar esta información, el Cliente emitió una carta de aprobación a todos los
requerimientos desarrollados a lo largo de este informe. (Ver Anexo 12).
94
5 ANÁLISIS
5.1 Modelo de Datos Conceptual
El modelo de datos conceptual es un esquema que permite describir gráficamente los

requerimientos recopilados y como estos se relacionan entre sí. En la figura 5.1, se aprecia el
esquema obtenido después de realizar el estudio. Este esquema es un modelo entidad
relación que ayuda a los futuros desarrolladores a visualizar la información que el sistema
necesita para trabajar.
95
Figura 5. 1: Modelo de datos conceptual.
96
6 RESUMEN ESFUERZO REQ UERIDO
En este capítulo, se presenta la cantidad de horas destinadas (aproximadamente) a cada fase

de este proyecto, en la tabla 6.1 se aprecia el detalle.
Tabla 6. 1: Resumen esfuerzo requerido.
Actividades/Fases N° de Horas
Definición del Método de Trabajo 12 horas.
Requisitos 80 horas.
Prototipos 48 horas.
Análisis y Diseño 28 horas.
Documentación 70 horas.
Total 238 horas.
97
7 CONCLUSIONES
Realizar este trabajo, fue con el objetivo de hacer una captura de requisitos que plasme todos
los requerimientos necesarios para el desarrollo de un software, que permita gestionar la
información de los pacientes del Centro Fonoaudiológico CECH.
Para llevar a cabo este trabajo, fue necesario revisar varias metodologías de ingeniería de
requisitos. Una vez estudiadas las metodologías se prosiguió a realizar una selección, mediante
un análisis que contempló aspectos como las etapas de trabajo, los resultados que entrega, las
herramientas que posee, entre otras cualidades, para definir una metodología que permita
hacer una elicitación de requisitos acorde con las características del cliente. Producto de ese
estudio se definió trabajar con la metodología VOLERE. La metodología VOLERE, posee una
trayectoria de varios años, pero lo más importante son las etapas del proceso de requisitos y
las herramientas que entrega mediante su Shell y su plantilla, estos permiten realizar un
documento con la información estructurada y con la aprobación del cliente, la cual es un
respaldo que permite solucionar los errores al instante de ser detectados y no cuando los
programadores comienzan a desarrollar la aplicación.
Durante todo este proyecto, el trabajo fue desarrollado de acuerdo a la estructura de la

metodología antes mencionada, mediante una serie de reuniones periódicas con el cliente se
obtuvo toda la información reflejada en este documento. Estas reuniones permitieron, sin
lugar a duda, una comunicación con el cliente que generó una retroalimentación para ambas
partes, dado que ambos compartimos un área nueva, así como para mí fue, el área de
fonoaudiología, para el cliente lo fue la informática. La falta de experiencia de ambas partes, en
esta clase de proyectos, puede implicar que hayan puntos que no se hayan considerados y que
al momento del desarrollo de la aplicación sean necesarios discutir, si fuese de esa forma, las
personas que continúen este proyecto, deben consultar al cliente las dudas que tengan al
respecto, él es quien debe decidir cualquier cambio que requiera este documento.
También se debe considerar, que dentro de los posibles cambios y mejoras que se pueden
aplicar en este proyecto, está la opción de modificar algunos prototipos de acorde a las
circunstancias del desarrollo, siempre y cuando la funcionalidad no se vea afectada y el cliente
apruebe la decisión.
98
Del ámbito académico, debo mencionar aquellos cursos que me permitieron realizar este
proyecto, fueron asignaturas que están relacionadas con la ingeniería de software y
metodología de la investigación, ya que me entregaron los conocimientos para realizar una
buena recopilación de información y el desarrollo de los requerimientos, por otro lado la
realización de la práctica profesional en un centro hospitalario, facilita la comprensión de los
procesos llevado a cabo en el CECH. Las diferentes asignaturas de talleres de desarrollo de
proyecto informáticos fueron fundamentales para el desarrollo de prototipos, dada la
experiencia que aquello aporta, la que me permitió plantear ideas y evaluar si las solicitudes
del cliente son pertinentes o no y de esa manera dar justificación acorde a las dudas.
Desde el punto de vista personal, significa el término de una etapa como estudiante de la
Universidad del Bío Bío, además es el comienzo de un nuevo ciclo, lleno de desafíos
profesionales y personales. También existe una satisfacción de haber logrado este gran desafío,
finalizar el proceso de estudio, es algo que en muchas ocasiones se vio difícil y lleno de
incertidumbre.
Para terminar, quiero decir que los objetivos planteados en un principio se han alcanzado
satisfactoriamente y espero que este trabajo pueda servir como una herramienta para aquellos
que deseen continuar este proyecto en la etapa de desarrollo, así también a aquellos que
desean investigar sobre la ingeniería de requisitos y para los que requieran realizar o tener
una noción de lo que es una elicitación de requisitos.
99
8 BIBLIOGRAFÍA
Báez, M. G., & Brunner, S. I. B. (2001). Metodología DoRCU para la Ingeniería de Requerimientos. Paper
presented at the WER.
Bahamonde, J. M., & Rossel, R. (2003). Un Acercamiento a la Ingenierıa de Requerimientos.
Gallardo Arancibia, J. A. (2009). Metodología para la definición de requisitos en proyectos de data

mining (er-dm). Universidad Politécnica de Madrid.
Kotonya, G. (1999). Practical experience with viewpoint-oriented requirements specification.

Requirements engineering, 4(3), 115-133.
Loucopoulos, P., & Karakostas, V. (1995). System requirements engineering: McGraw-Hill, Inc.
Potts, C., Takahashi, K., & Anton, A. I. (1994). Inquiry-based requirements analysis. Software, IEEE,
11(2), 21-32.
Richards, D. (2000). A process model for requirements elicitation. Paper presented at the Proceedings
of The 11th Australasian Conference on Information Systems, Brisbane, Australia.
Robertson, J., & Robertson, S. (2000). Volere: Requirements specification template: Technical Report
Edition 6.1, Atlantic Systems Guild.
Sommerville, I. (2002). Ingeniería de Software, 6ta (6a Edición ed.): Ed. Addison Wesley,.
Sumano, M. d. l. Á. (2002). Método para el Análisis de Requerimientos de Software con enfoque

conjunto psicológico, social y lingüístico conducente al reuso. Instituto Politécnico Nacional,
Centro de Investigación en Computación, Laboratorio de Tecnología de Software, México, DF.
VOLERE. (2005). http://www.volere.uk/ Retrieved 10-10-2013, 2013
100
9 ANEXO: PLANIFICACIÓN INICIAL DEL PROYECTO
A continuación se presenta la Carta Gantt donde se establecen las iteraciones y actividades

desarrolladas.
Tabla 9. 1: Carta Gantt.
Id Nombre Duración Comienzo Fin

Reunión Usuario, Definición de Metodología a
1 6 días 8/26/13 9/2/13
Usar
2 Primera Iteración 15 días 9/2/13 9/20/13
3 Identificación, Elicitación de Requisitos 4 días 9/2/13 9/5/13
4 Análisis de Requisitos 4 días 9/5/13 9/10/13
5 Especificación de Requisitos 6 días 9/9/13 9/16/13
6 Realizar Prototipos 10 días 9/9/13 9/20/13
7 Validación y Negociación de Requisitos 4 días 9/17/13 9/20/13
8 Segunda Iteración 20 días 9/23/13 10/18/13
14 Tercera Iteración 10 días 10/21/13 11/1/13
20 Creación de Prototipos 10 días 11/4/13 11/15/13
21 Revisión y Ajustes 10 días 11/4/13 11/15/13
22 Documentación 60 días 8/26/13 11/15/13
101
10 ANEXO: PROTOCOLOS CECH
Los protocolos son las herramientas que permiten determinar la condición de un paciente,
existen varios tipos por lo que hacer una estandarización es algo complejo, de igual manera se
logró identificar dos grandes grupos: Cuantitativos y Cualitativos.
Al realizar un protocolo cuantificable, se obtiene un puntaje, que dado un serie de información

se puede obtener un resultado del estado del paciente y están aquellos, cualitativos, que sólo
con la aplicación del protocolo, se puede determinar un diagnóstico del paciente, por
percepción del fonoaudiólogo o interno.
Este anexo se concentra en rescatar los datos relevantes de cada protocolo para que los
desarrolladores puedan hacerse una idea, de que es lo que se desea registrar del protocolo.
10.1 Protocolos cuantitativos
Para estos protocolos se consideró aquellos que entregan un resultado basado en puntaje para
determinar una consecuencia de ese resultado, están aquellos que sólo se registra el puntaje
total y están aquellos que se registra la resolución del protocolo dado el puntaje obtenido.
10.1.1 Dominio ACE-R-Ch

Tabla 10. 1: Datos requeridos protocolo: ACE-R-Ch
Fecha: Puntuaciones máximas

Orientación y Atención 18
Memoria 26
Fluencias Verbales 14
Lenguaje 26
Habilidades Visoespaciales 16
Total ACE-R-Ch 100
Observaciones:
Resultado según calificación:
Normal DCL (deterioro cognitivo Demencia
leve)
91 a 100 81-90 0-80
102
10.1.2 I.T.P.A.
Tabla 10. 2: Datos requeridos protocolo: L.T.P.A.
Fecha
Perfil de Aptitudes DP (Puntaje)
1. Comprensión auditiva
2. Comprensión visual
Memoria secuencial visomotora
Asociación auditiva
Memoria secuencial auditiva
Asociación visual
Integración Visual
Expresión Verbal
Integración gramatical
Expresión Motora
Integración Auditiva
Observaciones:
10.1.3 I.D.E.A.
Tabla 10. 3: Datos requeridos protocolo: I.D.E.A.
Fecha
Inventario de espectro autista Puntaje Total
Escala: Relación Social
Escala: Comunicación y Lenguaje
Escala: Anticipación/Flexibilidad
Escala: Simbolización
Observaciones:
103
10.1.4 Mini Mental

Tabla 10. 4: Datos requeridos protocolo: Mini mental.
Fecha Tabla de puntaje

Edad edad Básica Medio Superior Universitaria
Puntaje total 18-69 22-25 26-27 28-29 29
Diagnóstico 70-79 21-22 25 27 28
Observaciones 79- 19-20 23-25 25-26 27
10.1.5 MoCA
Tabla 10. 5: Datos requeridos protocolo: MoCA.
Fecha
Edad
Puntaje >26 normal
Resultado
Observación
10.1.6 Evaluación Fonoaudiológica 4 años a 4 años 11 meses
Tabla 10. 6: Datos requeridos protocolo: Ev. Fonoaudiológica 4 a 4,11 años.
Fecha
CATEGORÍA DE RENDIMIENTO PUNTAJE TOTAL
Insuficiente 0- 29 puntos
Suficiente 30- 49 puntos
Bueno 50-68 puntos
Muy Bueno 69-98 puntos
Observaciones
104
10.1.7 Evaluación Fonoaudiológica 5 años a 6 años 11 meses

Tabla 10. 7: Datos requeridos protocolo: Ev. Fonoaudiológica 5 a 6,11 años.
Fecha
Bueno 50-68 puntos
Observaciones
10.1.8 Evaluación Fonoaudiológica 7 años a 12 años

Tabla 10. 8: Datos requeridos protocolo: Ev. Fonoaudiológica 7 a 12 años.
Fecha
Bueno 50-68 puntos
Observaciones
10.1.9 Protocolo de Evaluación del Habla (Rafael González)

Tabla 10. 9: Datos requeridos protocolo: Ev. Del Habla (Rafael González).
Respiración. 5 Definición de puntaje

Fonación. 5 1 Normal
Resonancia. 5 2 Deficiencia Leve
Control Motor Oral y Articulación 5 3 Deficiencia Moderada
Prosodia. 5 4 Deficiencia Moderada a Severa
Inteligibilidad 5 5 Deficiencia Severa
Sensibilidad Oral 5
Fecha
Observaciones
Diagnóstico Fotobiológico
Indicaciones:
105
10.1.10 Protocolo de Evaluación del Habla

Tabla 10. 10: Datos requeridos protocolo: Ev. Del Habla.
Fecha:
Síntesis Puntaje
1. Respiración 5
2. Pofación 5
3. Resonancia 5
4. C. Mot. Oral y Art. 5
5. Prosodia 5
6. Inteligibilidad 5
Total
Disartria Si No Grado L M S
Apraxia del Habla Si No Grado L M S
Apraxia Fonatoria Si No
Apraxia Oral si No Grado L M S
Tipo
Observaciones
10.1.11 S.L.A.
Tabla 10. 11: Datos requeridos protocolo: S.L.A.
Fecha
Subprueba Trastorno Normal
Discriminación de Fonemas 0-8 9
Decisión de Palabras 0-7 8
Emparejamiento Palabra Hablada- Dibujo 0-9 10
Fluidez Verbal Categorial 0-9 10
Denominación de Imágenes 0-8 9-10
Repetición de Palabras 0-7 8
Repetición de No Palabras 0-7 8
Observaciones
106
10.1.12 TECAL
Tabla 10. 12: Datos requeridos protocolo: TECAL.
NORMAL EN RIESGO DEFICIENTE

PUNTAJE INTERPRETACIÓN
(X +/- 1 DS) (entre X – 1 DS Y X – 2 DS) (bajo el X – 2 DS)
TOTAL
VOCABULARIO
(1 – 41)
MORFOLOGÍA
(42 – 89)
SINTAXIS (90 –
101)
Fecha:
Observaciones:
Conclusiones:
10.1.13 Protocolo TEVI

Tabla 10. 13: Datos requeridos protocolo: TEVI.
Fecha Forma Techo Errores Puntaje Obtenido
Observaciones
10.1.14 Valoración y Protocolos Token Test

Tabla 10. 14: Datos requeridos protocolo: Valoración y Protocolo Token Test.
Fecha Edad Puntaje total Percentil Observaciones
10.1.15 Protocolo de Test de WEPMAN

Tabla 10. 15: Datos requeridos protocolo: Test de WEPMAN.
Fecha
Resultado Respuesta correctas * 2,5 %
Edad
Conclusiones
Observaciones
107
10.2 Protocolos Cualitativos

Los protocolos cualitativos y son aquellos que se registra como resultada la apreciación del
fonoaudiólogo o interno al momento de aplicar el protocolo.
10.2.1 Evaluación disfemia infantil
Tabla 10. 16: Datos requeridos protocolo: Ev. Disfamia infantil.
Fecha
Tipo de tartamudez 1. Tónica
2. Clónica
3. Mixta
Severidad 1. Leve (Logra Comunicarse)
2. Moderada (A veces no se le entiende)
3. Severa (No logar emitir la idea)
Observaciones
10.2.2 Protocolo evaluación miofuncional:
Tabla 10. 17: Datos requeridos protocolo: Ev. Miofuncional.
Fecha
Diagnostico fonoestomatognatico:
Plan de tratamiento:
10.2.3 Ficha evaluación riesgo vocal
Tabla 10. 18: Datos requeridos protocolo: Ev. Riesgo vocal.
Fecha
Puntaje Total
Evaluación de resultados
Observaciones
108
10.2.4 Evaluación vocal infantil – Carola Rivera
Tabla 10. 19: Datos requeridos protocolo: Ev. Vocal Infantil (Carola Rivera).
Fecha
Observaciones
Derivaciones
Diagnóstico
10.2.5 Evaluación vocal Infantil, UBB
Tabla 10. 20: Datos requeridos protocolo: Ev. Vocal Infantil (UBB).
Fecha
Cefalización
Sedestación
Marcha
Esfínter vesical Diurno: Logrado (L) / logrado (NL) Nocturno:
Esfínter anal Diurno: Nocturno:
Vocalización
Balbuceo
1° Palabra
Holofrase
1° frase
Enfermedades Importantes:
10.2.6 Evaluación clínica de la deglución

Tabla 10. 21: Datos requeridos protocolo: Ev. Clínica de la deglución.
Fecha:
Observaciones:
Síntesis:
Disfagia Orofaríngea Si No
Posible aspiración Si No
Grado L M S
Plan
109
10.2.7 Pauta de evaluación para Tartamudez
Tabla 10. 22: Datos requeridos protocolo: Ev. Tartamudez.
Fecha
Síntesis
Derivación
10.2.8 Protocolo QVV
Tabla 10. 23: Datos requeridos protocolo: QVV.
Fecha Dominio socio- Funcionamiento físico total Observaciones

emocional
10.2.9 Protocolo de evaluación de la insuficiencia velofaringea
Tabla 10. 24: Datos requeridos protocolo: Ev. De la insuficiencia velofaringea.
Fecha Puntaje Evaluación Sugerencias Observaciones
10.2.10 Evaluación fonoaudiológica clínica de la disfagia orofaríngea post-ave
Tabla 10. 25: Datos requeridos protocolo: Ev. Fonoaudiológica de la disfagia orofaringea post-ave.
Fecha
Definición de la conducta
Indicaciones
Observaciones
10.2.11 Q-CHAT
Tabla 10. 26: Datos requeridos protocolo: Q-CHAT.
Fecha
Observaciones
110
10.2.12 Screening Test of Spanish Grammar – S. T. S. G. (Comprensivo)
Tabla 10. 27: Datos requeridos protocolo: S.T.S.G comprensiva.
Fecha
Total de Puntos:
Percentil
Rango de Edad:
Conclusiones
Observaciones
10.2.13 Screening Test Of Spanish Grammar – S. T. S. G. (expresivo)
Tabla 10. 28: Datos requeridos protocolo: S.T.S.G expresivo.
Fecha
Total de Puntos:
Percentil
Rango de Edad:
Conclusiones
Observaciones
10.2.14 S.A.F
Tabla 10. 29: Datos requeridos protocolo: S.A.F.
Fecha Resultado Observaciones
10.2.15 T.A.R
Tabla 10. 30: Datos requeridos protocolo: T.A.R.
Fecha
Observaciones
Conclusiones
111
10.2.16 T.D.P.E.A.
Tabla 10. 31: Datos requeridos protocolo: T.D.P.E.A.
Fecha
Observaciones:
Conclusiones:
10.2.17 TEPROSIF
Tabla 10. 32: Datos requeridos protocolo: TEPROSIF.
Fecha
Respuesta Dislalia E. Silábica Sustitución Asimilación Total
Observaciones
112
11 ANEXO: DIAGNÓSTICOS DEL CECH
En este anexo se presenta los diagnósticos que se utilizan en el CECH, estos son estándar y
poseen un código identificador único.
11.1 Trastornos del Lenguaje en el Niño (1-7)
1. Desarrollo Normal del Lenguaje

2. Déficit de Lenguaje
2.1. Fonológico
2.2. Morfosintáctico
2.3. Semántico
2.4. Pragmático
3. Inicio tardío (IT)
4. Retraso en el desarrollo del Lenguaje (RDL)
5. Trastorno especifico del lenguaje (TEL)
5.1. Expresivo (TEL-E)
5.1.1. Rapin Dispraxia verbal
5.1.2. Déficit de programación fonológica
5.1.3. Conti Formulación sintáctica semántica
5.2. Mixto (TEL-ER)
5.2.1. Rapin Agnosia Auditivo Verbal
5.2.2. Déficit fonológico sintáctico
5.2.3. Conti sintáctico fonológico
5.2.4. Gramatical
5.3. Orden superior/Complejo
5.3.1. Rapin Síndrome de déficit léxico sintáctico
5.3.2. Síndrome Semántico Pragmático
5.3.3. Conti Impedimento pragmático puro
5.3.4. Impedimento pragmático plus
6. Trastorno del lenguaje Asociado/Secundario (TL)
6.1. Retardo Mental
6.2. Parálisis Cerebral
6.3. Trastorno Generalizado del Desarrollo
6.4. Síndrome de Down
6.5. Sd. De William
6.6. Sd. Moebius
6.7. Déficit Auditivo.
7. Trastorno Fonológico
113
11.2 Trastornos del Lenguaje Adulto (8-12)
8. Clasificación Clásica de las Afasias

8.1. Afasia Global
8.2. Afasia No Fluente Mixta
8.3. Afasia de Wernicke
8.4. Afasia de Broca
8.5. Afasia de Conducción
8.6. Afasia Anómica
8.7. Afasia Transcortical Motora
8.8. Afasia Transcortical Sensorial
8.9. Afasia Transcortical Mixta
9. Clasificación Cognitiva de las Afasias
9.1. Sordera Verbal Pura
9.2. Sordera para la forma de la palabra
9.3. Sordera para el significado de la palabra
9.4. Agnosia Fonológica
9.5. Disfasia Profunda
9.6. Agnosia Semántica
9.7. Demencia Semántica
9.8. Anomia Pura
9.9. Jergafasia
9.10. Anomia FonológicaTrastorno en el retén fonológico
10. Trastornos de Lectura
10.1. Alexia Pura
10.2. Dislexia Fonológica
10.3. Dislexia Superficial
10.4. Ceguera para el significado de las palabras
10.5. Dislexia de acceso semántico
10.6. Dislexia Profunda
11. Trastornos de la escritura
11.1. Disgrafia Superficial
11.2. Disgrafia Fonológica
11.3. Disgrafia de acceso semántico
11.4. Disgrafia profunda
12. Trastorno Cognitivo Comunicativo
12.1. Secundario a Demencia
12.2. Secundario a TEC
114
11.3 Trastornos Audiológicos (13-15)
13. Normoacusia
14. Hipoacusia
14.1. Conductivas
14.1.1. Leve
14.1.2. Moderada
14.1.3. Severa
14.2. Sensoriales
14.2.1. Leve
14.2.2. Moderada
14.2.3. Severa
14.2.4. Profunda
14.3. Neurales
14.3.1. Leve
14.3.2. Moderada
14.3.3. Severa
14.3.4. Profunda
14.4. Mixtas
14.4.1. Leve
14.4.2. Moderada
14.4.3. Severa
14.4.4. Profunda
14.5. Anacusia o Cofosis
15. Disfunción Tubaria
15.1. Mala
15.2. Regular
15.3. Permeable
115
11.4 Trastornos de la Voz (16-19)
Clasificación según Le Huche

16. Disfonía Disfuncional Simple
16.1. Patrón de tensión muscular (Tipo 1: Trastorno Isométrico Laríngeo, de Morrison)
16.2. Tipo 2: Contracción lateral
16.3. Tipo 3: Contracción supraglótica anteroposterior
16.4. Tipo 4: Afonía/Disfonía de conversión
16.5. Tipo 5: Disfonía psicógena con cuerdas vocales arqueadas
16.6. Tipo 6: Disfonía de transición del adolescente
16.7. Laringitis
17. Disfonía Disfuncional Complicada
17.1. Nódulo
17.2. Pólipo
17.3. Edema
17.4. Edema de Reinke
17.5. Hemorragia submucosa (hematoma cordal)
17.6. Granuloma de Contacto
18. Formas Particulares de Disfonías Disfuncionales
18.1. Ronquera Infantil
18.2. Disodea por inhibición vocal
18.3. Disfonía Espástica
18.4. Alteraciones vocales en la patología psiquiátrica
18.5. Presbifonía
18.6. Trastorno de la muda vocal
18.7. Disfonías de origen endocrino
19. Disfonías de origen orgánico
19.1. Laringitis
19.2. Traumatismos
19.3. Parálisis de cuerda vocal
19.4. Anomalías congénitas (lesiones estructurales mínimas)
19.5. Alteración orgánica extralaríngeas
19.6. Disfonías endocrinas
19.7. Papiloma
19.8. Cáncer Laríngeo
19.9. Quiste
19.10. Laringofísura
116
11.5 Trastornos del Habla y la Deglución (20-35)
20. Dislalia
20.1. Orgánica
20.2. Funcional
20.3. Audiógena
21. Disartria
21.1. Espástica
21.2. Fláccida
21.3. Mixta
21.4. Hipocinética
21.5. Hipercinética
21.6. Atáxica
21.7. Motoneurona Superior
21.8. Unilateral
22. Tartamudez
22.1. Primaria
22.2. Secundaria
23. Apraxia del Habla
24. Dispraxia Verbal
25. Disfagia
25.1. Oral
25.1.1. Leve
25.1.2. Moderada
25.1.3. Severa
25.2. Faríngea
25.2.1. Leve
25.2.2. Moderada
25.2.3. Severa
25.3. Esofágica
25.4. Orofaríngea
25.4.1. Leve
25.4.2. Moderada
25.4.3. Severa
26. Presbifagia
27. Trastorno Succión-Deglución
28. Insuficiencia Velofaríngea
29. Incompetencia Velofaríngea
30. Deglución Atípica
31. Respirador Oral
32. Trastorno de la Alimentación.
33. Taquilalia
34. Bradilalia
35. Farfulleo
117
12 ANEXO: CARTA DE APRO BACIÓN DE PROYECTO.
En la siguiente hoja, se presenta una carta enviada por el Cliente y Coordinador del CECH,
Rodolfo Peña, para dar validez a este proceso de elicitación de requisitos.
118
119

Parra Urrea, Alfredo

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

Parra Urrea, Alfredo

Cargado por

Copyright:

Formatos disponibles

Universidad del Bío-Bío.

Red de Bibliotecas - Chile

Universidad del Bío-Bío

Facultad de Ciencias Empresariales

Escuela de Ingeniería Civil Informática

“Especificación de requisitos de software para

Alumno: Alfredo Parra Urrea

Profesor guía: Angélica Caro Gutiérrez

Memoria de Grado para optar al título de Ingeniero Civil en

El Centro de Estudios de la Comunicación Humana (CECH), es un centro clínico de la Escuela

En este trabajo, se desea plasmar una elicitación de requisitos para el desarrollo de un

Para realizar el levantamiento de requisitos se utiliza el método VOLERE, el cuál fue

10.1 PROTOCOLOS CUANTITATIVOS .................................................................................................102

Tabla 6. 1: Resumen esfuerzo requerido. .......................................................................................................................... 97

Figura 4. 1 Modelo de Caso de Uso: Estudiante. Fuente: propia del autor....................................................... 26

Figura 5. 1: Modelo de datos conceptual. .......................................................................................................................... 96

La necesidad de utilizar un software para automatizar información dentro de una institución,

El Centro de Estudios de la Comunicación Humana (CECH), es un centro clínico

Este documento está estructurado de la siguiente manera: en el capítulo 2, encontramos una

2 DEFINICION DE LA EMPRESA O INSTITUCIÓN

2.1 Descripción de la empresa

Los antecedentes generales de la empresa son:

 Nombre: Centro de Estudio de la Comunicación Humana.

 Competencia directa: No posee, el centro es único en la provincia y la competencia

El Centro de Estudios de la Comunicación Humana (CECH), es una institución nueva, que

2.2 Descripción del área de estudio

En el Centro se evalúa, diagnostica e interviene los trastornos de la comunicación humana

2.3 Descripción de la problemática

3.1 Objetivos del proyecto

3.1.1 Objetivo General

Desarrollar una elicitación de requerimientos para la estructuración de un sistema de ficha

3.1.2 Objetivos Específicos

 Identificar la información que el CECH desea administrar y controlar con el

3.2 Ambiente de Ingeniería de Software

3.2.1 Ingeniería de Requisitos.

La especificación de requisitos es una tarea importante a la hora de realizar cualquier

El objetivo principal de la IR es obtener una definición clara estructurada y no ambigua para

Dentro de la IR se encuentran varios modelos de procesos, que varían según el área en la

 Elicitación: es la etapa donde hay mayor interacción con el usuario y es fundamental

3.2.2 Metodología para realizar la elicitación de requisitos.

En este proyecto la elección de la metodología fue motivo de estudio, dada la necesidad de

 Documentación de Requisitos Centrada en el Usuario (DoRCU).

A continuación en la tabla 3.1, se muestra un resumen de las características más relevantes

Tabla 3. 1: Resumen de Metodologías estudiadas.

En las metodologías estudiadas se ven identificados los elementos correspondientes al

Por último la metodología VOLERE, es un método que entrega un modelo de aplicación

3.2.3 Método VOLERE

Las etapas de este modelo son:

a. Proyecto Blastoff: Denominada como etapa de despegue del proyecto, donde se

d. Etapa Escritura de Requisitos: Etapa paralela a la generación de prototipos, es la etapa

VOLERE además de su modelo posee dos subsistemas para realizar la especificación de

Tabla 3. 2: Descripción gráfica de la Shell de VOLERE(Robertson & Robertson, 2000).

Número Se indica el Tipo Se basa según Eventos / Se mencionan

A continuación se describirán los componentes de la Shell, presentados en la tabla 3.2.

 Número de Requisito: Es el código identificador único del requisito, con la intención

Por otra parte, la planilla de VOLERE se divide en los siguientes puntos:

3.2.4 Herramientas y tecnologías a utilizar

 Balsamiq Mockups: Es un software que permite realizar el esquema de una página

3.3 Definiciones, Siglas y Abreviaciones

Estudiante: equivalente a interno, en el texto se utilizan ambos conceptos, con el fin de

Instrumento de Evaluación: Se denomina al conjunto de protocolos que se aplican a un

Interno: Equivalente a estudiante de la carrera de fonoaudiología, es quien realiza práctica

Protocolos: Denominación que se da en el CECH, a los procedimientos que permiten

Rotación: Se le denomina al cambio de estudiantes que se realiza en el CECH, cada dos