Análisis de Ingeniería de Requisitos del

proyecto:

Sistema de localización de atención médica

(SLAM)”
Aplicación móvil

Versión 1.0
 
Revisiones
Fecha Versión Descripción Autores
Pliego Muratalla José Luis
Ramírez Torres Iñaki Sebastián
20/09/2019 1.0 Creación del documento.
Ruiz Tique Erick Alberto
Tapia Rivero Sergio Iván
Pliego Muratalla José Luis
03/11/2019 1.0 Análisis de requerimientos Ramírez Torres Iñaki Sebastián
Ruiz Tique Erick Alberto
Tapia Rivero Sergio Iván
09/12/2019 2.0 Interfaz Pliego Muratalla José Luis
Ramírez Torres Iñaki Sebastián
Ruiz Tique Erick Alberto
Tapia Rivero Sergio Iván
 Índice
Índice de Formatos Pág.
1.- Formato para acuerdos y compromisos 4
2.- Histórico de Revisión 5
3.- Reporte de Seguimiento 6
4.- Análisis de requerimientos 10
5.- Diagramas de casos de uso y de clases 13
6.- Interfaz de usuario 14
Formato para acuerdos y compromisos

Asistentes
Tema Acuerdos de aplicación
Fecha 27/Agosto/2019
Lugar División de Ingeniería en
Sistemas

Acuerdos
Llegar a la conclusión para saber cuánto capital usaremos.

Distribución y para en que plataforma se desarrollará la aplicación.

Compromisos
Plazo Responsable Acción Condiciones de
Satisfacción
3 meses Pliego Muratalla Dirigir y supervisar Todos los puntos
José Luis el proyecto señalados se
realicen de manera
correcta

Próxima Reunión
Temas a tratar
Fecha 5/Septiembre/2019 Desarrolladores de aplicación.
Lugar Biblioteca TESE
Histórico de Revisión
Fecha Versión Descripción Autor
17/Septiembre/2019 1.0 Introducción del Erick
trabajo a realizar, así
como su análisis.
03/Noviembre/2019 1.0 Análisis de Iñaki
requerimientos
REPORTE DE SEGUIMIENTO

Nombre del Proyecto: Touch Medic

Responsable de Administración
del Proyecto Específico:
Producto: Aplicación móvil
Responsable de elaborar el Responsable de la evaluación:
producto:
Fecha: 13/09/2019
Lugar: Biblioteca TESE

1. Avance de las actividades

Fase Actividad Fechas % de % de Fecha de Observaciones

Real de avanc avanc finalización
inicio e real e estimada
espera
do
1 Evaluación de 14/09/19 30 30 18/09/19 Ninguna
costos y
planificación
2 Análisis de 28/10/19 30 30 03/11/19 Ninguna
requerimientos

2. Costo real del proyecto (Para esta etapa):

Fase Actividades Costo estimado Costo real acumulado a

según avance la fecha

1 Evaluación de costos y $0.00 MNX $0.00 MNX

planeación del sistema
que se utilizara para el
registro médico y
usuarios del servicio.
2 Análisis de $0.00 MNX $0.00 MNX
requerimientos

3. Esfuerzo realizado, en términos de horas-hombre invertidas.

Fase Actividades Horas-hombre Horas hombre reales

 estimadas según invertidas
avance
1 Elaboración de la 22 hrs. 10 hrs
documentación que
plantee el problema
principal y posibles
soluciones.
2 Elaboración de los 20 hrs. 10 hrs.
requerimientos de sistema
y usuario, así como los
diagramas de clase y de
caso de uso.

4. Tiempo real invertido:

Fase Actividades Fecha real Fecha de Tiempo real

de inicio finalización, si invertido
la actividad ya (diferencia de
culminó; fecha las columnas
de seguimiento, previas)
en otro caso

1 Construcción de pasos a 12/09/2019 17/09/2019 5 días.

seguir para lograr el
objetivo de elaborar
documentación y
aplicación a tiempo y
forma.
2 Obtención de los 31/10/2019 03/11/2019 3 días.
requerimientos y
desarrollo de diagramas
para si fácil
entendimiento.

5. Cambios implementados y clasificados por tipo:

Identificador Tipo de cambio Descripción del cambio Fecha de la

implementación
Estructura. Estructural. Que todo vaya acorde a 16/09/19
lo establecido.

6. Defectos encontrados:

Entregables Defectos encontrados

Documentación. En verificación En evaluación
 Errores en código. Manejo de plataforma. Tipo de sistema.
Tiempo de entrega. Manejo de bd Errores de bd.

7. Obtención de Requisitos:

Entregables Defectos encontrados

En verificación En evaluación
Permisos de operaciones Zona de operaciones Alcaldías de la Ciudad de
México

8.- Problemas de ámbito/ problemas de comprensión:

Entregables Defectos encontrados

En verificación En evaluación
Contrato de personal Vacantes. Vacantes disponibles.

9.- Negociación:

Entregables Opciones y /o soluciones

En verificación En evaluación
Contrato de permisos. Permisos de aplicación. Reglas de la aplicación.
Contrato de entrega. Fechas establecidas. Procesos de app.

10.-Tamaño de los productos

Entregables Tamaño estimado según Tamaño real

avance
Documentación del diseño. 3 semanas. 7 meses.
Diseño de base de datos. 4 semanas. 6 meses.

11.- Especificación

Entregables Tamaño estimado según Tamaño real

avance
Características del producto 30% 20%
en desarrollo

12.- Validación
 Entregables Tamaño estimado según Tamaño real
avance
Acreditación de permisos Obtención de la En proceso de verificación
necesarios para la aplicación documentación sellada y
autorizada

13.- Gestión

Entregables Tamaño estimado según Tamaño real

avance, rastreo y tipo de
rastreo
Formatos de aplicación. Rastreo local. Local.
Desarrollos de app. En una entidad. Puede crecer hasta ser
global.

14.- Trabajo duplicado

Tarea duplicada En qué parte del proceso Causa de la duplicación

se produjo
Formatos de trabajo. El inicio. Copia en caso de errores
futuros.

15.- Tabla Genérica de requisitos

Requisito/Actividad, ACT01/ ACT02/ ACT02/ ACT0n/

aspecto ASP01 ASP02 ASP02…… ASP0n
Programar apk Diseño Código Base de
Implementació datos
n
Base de datos
Usuario.
R03 BD de datos de
medicos.
Análisis
Requerimientos de usuario:
Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el
sistema provea y de las restricciones bajo las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles
por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente
especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las
características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben
definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural,
representaciones y diagramas intuitivos sencillos.
Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: falta de
claridad, confusión de requerimientos y conjunción de requerimientos.
Requerimientos de usuario:
Sistema de localización a atención médica (SLAM)
ID Descripción Tipo
1 El sistema permitirá el registro de los usuarios y de los médicos. F
2 El sistema podrá desplegar un mapa de la región del usuario. F
3 El sistema será capaz de localizar a todos los médicos registrados de la F
zona.
4 El usuario podrá seleccionar a un médico cercano para solicitar atención F
médica (ya sea a domicilio o que el usuario se dirija al consultorio).
5 El sistema será capaz de mandar dicha petición al médico solicitado por el F
usuario.
6 El sistema será capaz de regresar respuesta al usuario indicando que tipo F
de servicio será (a domicilio o en consultorio).
7 Rapidez: El sistema será capaz de ejecutar las peticiones del usuario de NF
manera rápida y eficaz.
8 Facilidad: El sistema se diseñará de tal forma que el usuario pueda NF
interactuar con la aplicación sin ningún problema.
9 Fiabilidad: El sistema será capaz de operar las 24 horas del día los 7 días NF
de la semana sin problemas
10 Portabilidad: Se podrá tener acceso al sistema desde cualquier dispositivo NF
móvil conectado a internet.

Requerimientos de sistema:
Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos
del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve
como un contrato entre el comprador del sistema y el desarrollador del software.
Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir
el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y
consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida
para el diseño del sistema.
La especificación de requerimientos del sistema incluye diferentes modelos del sistema como el de
objetos o el de flujo de datos.
En principio, los requerimientos del sistema deberán establecer lo que éste hará y no la manera en
que se implementará. Sin embargo, en el nivel de detalle requerido para especificar el sistema
completamente, es casi imposible excluir toda la información de diseño.
Una especificación del diseño del software
Es una descripción abstracta del diseño del software, que es una base para un diseño e
implementación detallados; agrega detalle a la especificación de requerimientos del sistema.

ID 1 (Funcional)  Registro de los médicos y usuarios:

 Los médicos se registrarán proporcionando los siguientes datos:
a) Nombre completo
b) Dirección
 c) Teléfono
d) Correo (junto con una contraseña)
e) Cedula Profesional
f) Especializado o general
 Los usuarios se registrarán proporcionando los siguientes datos:
a) Nombre completo
b) Dirección
c) Teléfono
d) Correo (junto con una contraseña)
e) Método de pago

ID 2 (Funcional)  Desplegado de un mapa de la zona y/o región:

 El sistema desplegara un mapa (ya sea con ayuda de Google Maps) de la zona
donde el usuario está solicitando atención médica, donde se mostrara:
a) Zona del usuario (Dirección)
b) Total de médicos en la zona

ID 3 (Funcional)  Localización de los médicos:

 El sistema localizara a todos los médicos registrados en la zona para que el
usuario pueda identificar cual es la mejor opción, donde un icono en la pantalla
indicara:
a) Nombre del médico
b) Dirección
c) Teléfono
d) Cedula

ID 4 (Funcional)  Solicitar a un médico para consulta:

 El usuario seleccionara al médico que desea solicitar (dependiendo si requiere una
visita especializada o general).

ID 5 (Funcional)  Se le envía la petición al medico seleccionado por el usuario:

 EL usuario al momento de solicitar a un médico, el medico recibirá la información
de la petición que desea el usuario, desplegada de la siguiente manera:
a) Tipo de consulta (domicilio, consultorio (internet))
b) Nombre del usuario
c) Dirección (si es a domicilio)
d) Teléfono

ID 6 (Funcional)  Confirmación de la cita al usuario:

 El usuario recibirá la respuesta del medico y confirmar la cita con los siguientes
datos:
a) Nombre del médico
b) Dirección (si es en consultorio)
c) Dirección del usuario (si es a domicilio)
d) Teléfono
e) Cedula profesional
 f) Tiempo estimado de llegada (si es a domicilio)

ID 7 (No Funcional)  Rapidez:

 El sistema será capaz de realizar las peticiones de los usuarios de una manera
rápida, ya que nuestra aplicación depende de ello.

ID 8 (No Funcional)  Facilidad:

 El sistema será capaz de mostrar un entorno agradable y de fácil entendimiento
para el usuario.

ID 9 (No Funcional)  Fiabilidad:

 El sistema será capaz de operar las 24 horas del día los 7 días de la semana sin
ninguna falla latente que pueda afectar el servicio.

ID 10 (No Funcional)  Portabilidad:

 El sistema podrá utilizarse en cualquier dispositivo conectado a internet.

Diagrama de clases:
Diagrama de clases de uso

Interfaz de usuario:
Aplicación en pc
Caso de uso. Registro de Usuario/Médico.
Actores. Usuario/Médico.
Propósito. Registro para poder utilizar el sistema.
Tipo. Principal y esencial.
Descripción. El Usuario/Médico se registrará en el sistema

proporcionando ciertos datos solicitados (dependiendo

el tipo de usuario), para posteriormente ser

almacenados en la base de datos del sistema y pueda

iniciar sesión para utilizar la aplicación.

Referencias cruzadas. Ninguna.
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1.- Este caso de uso

comienza cuando un

usuario nuevo

(Usuario/Médico) desea

registrarse para utilizar

la aplicación.
2.- El Usuario/Médico 3.- El sistema almacenara todos los datos solicitados en

ingresa los datos que se una base de datos para posteriormente avisarle al

le solicitan para usuario que se ha registrado correctamente.

completar el registro. En caso contrario se le notificara que hubo un error y se

mandara un mensaje con dicho error.

4.- Al término del

proceso de registro, el

Usuario/Médico podrá

iniciar sesión y utilizar la

aplicación.
Aplicación móvil:
Consulta de ubicación:
Caso de uso. Inicio de sesión y despliegue del mapa.
Actores. Usuario/Médico.
Propósito. Desplegar un mapa al iniciar sesión.
Tipo. Principal y esencial.
Descripción. El Usuario/Médico al iniciar sesión, se desplegará un

mapa donde se muestre su posición geográfica y así

poder interactuar con la aplicación.

Referencias cruzadas. Caso de uso: Primero el Usuario/Médico debieron de

haberse registrado en el sistema.

Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1.- Interactuara con el 2.- El sistema deberá responder a las peticiones

mapa en busca de una realizadas por el Usuario/Médico en tiempo real.

consulta/consultorio

cercano (Usuario) o el

paciente que solicito la

atención a domicilio

(Médico).
3.- Si el Usuario/Médico 3.- El sistema realizara el procedimiento para contactar

activa un evento, deberá al Usuario/Médico que solicito.

ser notificado al

Usuario/Médico para

poder realizar la acción.

 4.- El Usuario/Médico 5.- El sistema trazara una ruta para llegar al destino

vera la información solicitado.

necesaria para poder

atender (Médico) o ser

atendido (Usuario).

Nombre: Registro
Actor(es): Usuario Sistema:
1.- El caso de uso inicia cuando un nuevo
usuario al dar clic en registrar, se activara el
evento de registro para así poder acceder a
las funciones de Touch Medic.
2.- Se desplegaran varias casillas donde el
usuario ingresara los datos solicitados para
poder ser registrado en la base de datos.
3.- El nuevo usuario ingresara los datos
solicitados para ser registrado.
4.- El sistema mostrara y guardara esos datos
de manera temporal.
5.- El usuario dará clic en registrar.
5.- El sistema guardara la información del
usuario en la base de datos y se le notificara
al usuario que ya ha sido registrado. En caso
contrario, se mostrara un mensaje diciendo
que el registro no se ha completado, si algún
campo fue llenado de manera incorrecta y/o
falta algún campo.
6.- El usuario

Referencias:
https://eduardorene.wordpress.com/2012/08/17/1-2-requerimientos-de-usuarios/
https://es.slideshare.net/IsraelRey/requerimientos-de-usuario-y-del-sistema
https://www.cimat.mx/Eventos/seminariodetecnologias/castillo.pdf
Nomenclatura:
R01: Listado de requisitos
R02: Conformación de equipo de análisis
.
.
.
.
.
.
.R0n tareas, entregables

Recibió Recibió Revisó

Líder de Proyecto Líder de Proyecto Representante Legal

Touch Medic