1

Software

Requirements

Specification

201430

SRS VÍCTOR HUGO VELA PINZÓN

PONTIFICIA UNIVERSIDAD JAVERIANA – FACULTAD DE INGENIERÍA –INGENIERÍA DE SISTEMAS

2

PÁGINA DE FIRMAS

Directora del Trabajo de Grado:

Ing. Luisa Fernanda Barrera León

__________________________________________________________

Estudiante de Ingeniería de Sistemas:

Víctor Hugo Vela Pinzón

__________________________________________________________

Coordinador de Sede Chapinero – CMD Bodytech:

Oscar Alfredo Bahamón

__________________________________________________________

3

HISTORIAL DE CAMBIOS Tipo de Documento: SRS

Estándares de referencia: IEEE 29148:2011l; IEEE 830:1993; IEEE 830:1998

Versión Fecha Secciones Modificadas Descripción Responsable

0.1 28/7/2014 Estructuración y contenido del documento

Se realizó la plantilla de trabajo del documento, con revisión de ítems que se incluirán

Víctor Vela

0.2 3/8/2014 PLAN MANEJO DE REQUERIMIENTOS, DESCRIPCIÓN GLOBAL

Se organizó el contenido del documento. Se definieron los ítems referidos en cada una de estas secciones.

Víctor Vela

0.3 9/8/2014 ANÁLISIS DEL SISTEMA – MODELO DEL MUNDO - DOCUMENTACION

Se integró el modelo del mundo del sistema MV LIFE Gym Mobile y se desarrolló documentación.

Víctor Vela

0.4 9/8/2014 MODELO DEL MUNDO - CORRECCIÓN Se realizaron cambios en el modelo del mundo del sistema.

Víctor Vela

0.5 7/9/2014 MODELO DEL MUNDO – DOCUMENTACION

REREFENCIAS

Se realiza la documentación completa del modelo del mundo, complementando lo que se había realizado anteriormente. Se ingresan las referencias

Víctor Vela

0.6 9/9/2014 REFERENCIAS – TRAZABILIDAD Se agregan referencias utilizadas para el desarrollo del proyecto. Se definen los formatos de trazabilidad para los requerimientos funcionales y no funcionales.

Víctor Vela

0.7 11/9/2014 REVISIÓN DOCUMENTO – REFERENCIAS

Se revisa el documento y las referencias usadas para el desarrollo del mismo

Víctor Vela

0.8 9/11/2014 RESTRICCIONES Se revisan las restricciones del proyecto Víctor Vela

4

TABLA DE CONTENIDO

PÁGINA DE FIRMAS ................................................................................................................................... 2

HISTORIAL DE CAMBIOS ............................................................................................................................ 3

TABLA DE CONTENIDO .............................................................................................................................. 4

LISTA DE TABLAS ....................................................................................................................................... 6

LISTA DE ILUSTRACIONES .......................................................................................................................... 6

1. INTRODUCCIÓN ..................................................................................................................................... 7

1.1 Propósito ......................................................................................................................................... 7

1.2 Alcance ............................................................................................................................................ 7

1.3 Definiciones, Acrónimos y Abreviaciones ....................................................................................... 7

1.4 Referencias ...................................................................................................................................... 8

1.5 Visión Global del Documento........................................................................................................ 10

2. DESCRIPCIÓN GLOBAL ......................................................................................................................... 10

2.1 Perspectiva del Producto .............................................................................................................. 10

2.1.1 Interfaces con el Sistema ....................................................................................................... 10

2.1.2 Interfaces con el Usuario ....................................................................................................... 11

2.1.3 Interfaces con el Hardware .................................................................................................... 11

2.1.4 Interfaces con el Software ..................................................................................................... 12

2.1.5 Interfaces de Comunicación ................................................................................................... 12

2.1.6 Restricciones de Memoria ..................................................................................................... 12

2.1.7 Operaciones ........................................................................................................................... 13

2.1.8 Requisitos de Adaptación del Sitio ........................................................................................ 13

2.2 Funciones del Producto................................................................................................................. 13

2.3 Características del Usuario ............................................................................................................ 14

2.4 Restricciones ................................................................................................................................. 15

3. PLAN DE MANEJO DE REQUERIMIENTOS............................................................................................ 16

3.1 Levantamiento de Requerimientos............................................................................................... 16

3.1.1 Requerimientos Funcionales .................................................................................................. 16

3.1.2 Requerimientos No Funcionales ............................................................................................ 16

3.1.3 Verificación y Validación de Requerimientos ........................................................................ 16

5

3.2 Tipos de Requerimientos .............................................................................................................. 17

3.3 Atributos de los Requerimientos .................................................................................................. 17

3.4 Mecanismo de Control de Estado de los Requerimientos ............................................................ 18

3.5 Mecanismo de priorización de los requerimientos ...................................................................... 18

3.6 Trazabilidad ................................................................................................................................... 19

3.6.1 Requerimientos Funcionales .................................................................................................. 19

3.6.2 Requerimientos No Funcionales ............................................................................................ 19

4. REQUERIMIENTOS ESPECIFICOS ......................................................................................................... 19

4.1 Requerimientos Funcionales ......................................................................................................... 19

4.2 Requerimientos No Funcionales ................................................................................................... 20

5. ANÁLISIS DEL SISTEMA - MODELO DE DOMINIO ................................................................................ 20

5.1 Modelo de Dominio ...................................................................................................................... 20

5.2 Documentación Modelo de Dominio ............................................................................................ 20

6

LISTA DE TABLAS

Tabla 1 - Características de Usuario Móvil .................................................................................................. 14

Tabla 2. Características de Usuario Web .................................................................................................... 14

Tabla 3. Restricciones ................................................................................................................................. 15

Tabla 4 - Clasificación de los Requerimientos ............................................................................................. 17

Tabla 5 - Control de Estado de Requerimientos ......................................................................................... 18

Tabla 6 - Priorización de Requerimientos ................................................................................................... 19

Tabla 7 - Trazabilidad Requerimientos Funcionales ................................................................................... 19

Tabla 8 - Trazabilidad Requerimientos No Funcionales .............................................................................. 19

Tabla 9 - Atributos Módulo Entrenador ...................................................................................................... 20

Tabla 10 - Atributos Rutinas Generadas por la Aplicación.......................................................................... 21

Tabla 11 - Atributos Seguimiento por Usuario ........................................................................................... 21

Tabla 12 - Atributos Tipo Entrenamiento ................................................................................................... 21

Tabla 13 - Atributos Equipamiento ............................................................................................................. 22

Tabla 14 - Atributos Lugar Entrenamiento ................................................................................................. 22

LISTA DE ILUSTRACIONES

Ilustración 1 - Modelo del Mundo MV LIFE Gym Mobile ............................................................................ 23

7

1. INTRODUCCIÓN A continuación se presentará el presente documento, en donde se detallará su propósito, alcance y una

visión global del proyecto MV LIFE Gym Mobile.

1.1 Propósito

El presente documento de Especificación de Requerimientos de Software tiene como propósito presentar

una descripción detallada del sistema MV LIFE Gym Mobile, el cual es una aplicación móvil personalizada

para Usuarios de Gimnasio. Este asiste a los usuarios de los gimnasios, por medio del registro y control de

sus rutinas personalizadas. Además, brinda una explicación detallada de los ejercicios y uso de los equipos

disponibles en el gimnasio, por medio de videos instructivos e interacción dispositivo móvil – máquina de

ejercicio. Como valor agregado, la aplicación incluirá listas de reproducción de música que se ajusten a su

gusto y ritmo de entrenamiento. El proyecto es presentado como Trabajo de Grado del estudiante Víctor

Hugo Vela Pinzón en el período académico 201430, en la Pontificia Universidad Javeriana de Bogotá,

Colombia.

Este documento SRS está dirigido a la Directora del Trabajo de Grado, Ing. Luisa Fernanda Barrera León,

al profesional del ejercicio y Coordinador de Sede Chapinero del Bodytech [16], Oscar Alfredo Bahamón,

al estudiante Víctor Hugo Vela Pinzón y a los usuarios finales del sistema.

El documento tiene como finalidad explicar el propósito y características del sistema, sus restricciones de

operatividad, interfaces y comportamiento. Además, reflejar de manera detallada el proceso de Ingeniería

de Requerimientos desarrollado para el proyecto y dar un análisis general al sistema.

1.2 Alcance

Se tendrá un prototipo funcional de la aplicación Móvil MV LIFE Gym Mobile, específicamente para un

grupo muscular, el cual generará rutinas y listas de reproducción de música partiendo de las características

físicas y restricciones médicas de los usuarios de los gimnasios. Esto permitirá el tratamiento,

rehabilitación y recuperación de lesiones, por medio de la personalización de la actividad física que guiará

al usuario a cumplir los objetivos físicos personales.

Para ello, el presente documento reflejará las herramientas utilizadas durante el desarrollo del proyecto,

las características esenciales que se tuvieron en cuenta para la ejecución del prototipo, la toma de

requerimientos y la especificación de cada uno de ellos.

1.3 Definiciones, Acrónimos y Abreviaciones

SRS: Software Requirements Specification.

Android: Sistema operativo basado en el kernel de Linux diseñado principalmente para dispositivos

móviles con pantalla táctil, como teléfonos inteligentes o tabletas.

Rutina de ejercicios: Actividad física que mejora y mantiene la aptitud física, la salud y el bienestar de la

persona.

8

Modelo: Representación abstracta, conceptual, gráfica o visual, física, de fenómenos, sistemas o procesos

a fin de analizar, describir, explicar, simular, explorar, controlar y predecir esos fenómenos o procesos.

GPS: Global Position System o Sistema de Posicionamiento Global.

Códigos QR: Es un módulo para almacenar información en una matriz de puntos o un código de barras

bidimensional [14].

Web Service: Es una interface que describe una colección de operaciones que son accesibles a través de

la red usando mensajes estándares, independiente de plataforma y lenguaje, basado en estándares

abiertos, y es publicado, localizado y accedido a través de internet. [17]

GoogleMaps: Es una solución para localizar objetos, localizar direcciones, instrucciones, e información de

localización todo a través de un mapa. [19]

1.4 Referencias

[1] IEEE Std. 830-1998, IEEE recommended practice for software requirements specifications, IEEE,

1998.

[2] IEEE Std. 830-1993, IEEE recommended practice for software requirements specifications, IEEE,

1993.

[3] IEEE Std. 29148-2011, IEEE Systems and software engineering — Life cycle processes —

Requirements engineering, IEEE, 2011.

[4] L. Barrera, A. Carrillo, A. Barraza, y S. Martínez, «ZuRoutine: Modelo Personalizado de

Rutinas de Ejercicios», Sexto Congreso Colombiano de Computación (6CCC), Manízales,

Colombia: 2011, pág. 6.

[5] Barrera, L. ZUGYM: Análisis y diseño de una herramienta que ofrece servicios personalizados a usuarios

de gimnasio, Ingeniería de Sistemas, Facultad de Ingeniería, Pontificia Universidad Javeriana, 2011,

Documento de Memoria, págs. 30 y. 48, [Online] Available:

http://pegasus.javeriana.edu.co/~CIS0930IS08/Documentos/MemoriaZuGym_Final.pdf [Accessed: 18-

May-2014]

[6] W3C. Hypertext Transfer Protocol. [Online] Disponible en:

http://www.w3.org/Protocols/rfc2616/rfc2616.html

[7] Azeddine Chikh, and Mashael Aldayel, “A New Traceable Software Requirements Specification

Based on IEEE 830”, Abril 2014; http://www.dgp.toronto.edu/~ppacheco/course/444/spec.pdf

[8] Android Developers. Software Development Kit. [Online] Disponible en:

http://developer.android.com/sdk/index.html

9

[9] Java Standard Edition. Oracle. [Online] Disponible en: http://docs.oracle.com/javase/

[10] Diapositivas Larman, Modelo Del Dominio, [Online],

http://lsi.ugr.es/~ig1/isoo/larman/Modelo%20del%20dominio.pdf

[11] Android. [Online] Available: http://www.android.com/

[12] Michael P. Papazoglou, Web Services, 1st Edition, Pearson Education Limited 2008

[13] Gabriel Svennerberg, “Introducing the Google Maps API - Springer.” [Online]. Available:

http://link.springer.com/chapter/10.1007/978-1-4302-2803-5_1.

[14] Códigos QR, ¿Qué son y para qué sirven?, 14 July, 2013, [Online], Available:

http://www.vanguardia.com/actualidad/tecnologia/216321-codigos-qr-que-son-y-para-que-sirven

[Accessed: 18-May-2014]

[15] TECNOPROJECT, ¿Qué es GPS?, [Online] Available:

http://www.tecnoprojectltda.com/QUEESGPS.htm [Accessed: 21-May-2014]

[16] Centro Médico Deportivo Bodytech, [Online] http://www.bodytech.com.co/

[17] W3C. Web Services Architecture. [Online] Available: http://www.w3.org/TR/ws-arch/

[18] Google Play. Android Market. [Online] Available: https://play.google.com/store

[19] Google Maps, [Online] Available: https://maps.google.com

[20] PostgreSQL, [Online], Available: http://www.postgresql.org.es/

[21] Essential Software Architecture. Ian Gorton. Springer.2006

[22] Arquitectura Android, [Online] Available:

https://sites.google.com/site/swcuc3m/home/android/generalidades/2-2-arquitectura-de-android

[Accessed: 11-September-2014]

[23] Manifest.permission, Android Developers, [Online] Available:

http://developer.android.com/reference/android/Manifest.permission.html [Accessed: 11-September-

2014]

[24] Permisos en Android, [Online] Available: http://androideity.com/2011/09/13/permisos-en-android/

[Accessed: 11-September-2014]

[25] Jelly Bean al fin es la versión Android más usada, Xataka móvil, [Online], Available:

http://www.xatakamovil.com/sistemas-operativos/jelly-bean-al-fin-es-la-version-android-mas-usada

[Accessed: 11-September-2014]

10

[26] Introducing Android 4.0, Android, [Online] Available: http://www.android.com/about/ice-cream-

andwich/ [Accessed: 11-September-2014]

[27] Google Chrome, chrome.google.com

[28] Firefox, https://www.mozilla.org/es-ES/firefox/new/

[29] Internet Explorer, http://windows.microsoft.com/es-xl/internet-explorer/download-ie

[30] W3C. Simple Object Access Protocol. [Online] Available: http://www.w3.org/TR/soap/

[31] Google App Engine. [Online] Available: https://developers.google.com/appengine/

[32] W3C. Extensible Markup Language. [Online] Available: http://www.w3.org/XML/

[33] Estadística de práctica deportiva y ejercicio físico, Boletín de Prensa 14/14, Aguascalientes AGS, 23

de Enero de 2014, [Online] Available:

http://www.inegi.org.mx/inegi/contenidos/espanol/prensa/boletines/boletin/comunicados/especiales/

2014/enero/comunica2.pdf [Accessed: 11-September-2014]

[34] NetBeans, https://netbeans.org/

1.5 Visión Global del Documento

El presente documento tiene como objetivo contextualizar y detallar la especificación de los

requerimientos obtenidos para el desarrollo del sistema MV LIFE Gym Mobile. Igualmente, se brinda una

descripción a cada una de las funcionalidades contenidas en el sistema, tal como lo es la perspectiva del

producto, interfaces generales, operaciones, adaptación, restricciones y demás herramientas que

permiten la funcionalidad del sistema y el desarrollo de los requerimientos y servicios.

2. DESCRIPCIÓN GLOBAL La presente sección muestra una descripción detallada de las diferentes herramientas utilizadas para el

desarrollo de la aplicación y los cuales ayudan en la especificación de requerimientos, restricciones del

sistema, operaciones, servicios, etc.

2.1 Perspectiva del Producto

El producto estará conformado por una plataforma web, un servidor y una plataforma móvil. MV LIFE

Gym Mobile generará rutinas de ejercicios personalizadas para usuario de gimnasio, partiendo de sus

características físicas y restricciones médicas. Incluirá reproducción de música personalizada. En esta

sección se detallarán las diferentes interfaces del sistema, así como el proceso de interacción con el

usuario, restricciones y requerimientos.

2.1.1 Interfaces con el Sistema

El sistema tiene una arquitectura orientada a servicios [21], con el fin de poder ser reutilizado y articulado

con otros sistemas, para ser adaptados a los servicios de gimnasios y sistemas asociados.

11

La comunicación con el dispositivo android, se manejarán los permisos que se pueden utilizar sobre estos

dispositivos. Esto se hace a través del framework de aplicaciones del dispositivo [22] y se tendrán en

cuenta los permisos de seguridad de android [23] [24].

PostgreSQL [20]: Sistema de gestión de base de datos utilizado normalmente para aplicaciones web o

móviles. Este sistema será donde se llevará toda la información tanto de los usuarios de gimnasio, como

de los entrenadores desde su plataforma web. Igualmente, se llevará persistencia de las rutinas, ejercicios,

listas de reproducción de música e información de códigos QR [14] de máquinas y equipamiento en

general.

Servidor de correo: El servidor de correo se utilizará para cuando un usuario, sea de gimnasio o entrenador

se registre en el sistema. Además se enviará notificaciones al usuario de las rutinas creadas por la

aplicación o el entrenador asociado y de recordatorios de entrenamiento.

2.1.2 Interfaces con el Usuario

Las interfaces con los usuarios se definen según la plataforma donde se encuentren utilizando la

aplicación.

Usuarios web: Los entrenadores y médicos del gimnasio utilizarán esta plataforma, donde se les

permitirá registrar su cuenta utilizando su nombre, email y contraseña. Con ello puede abrir su

sesión, en la cual podrá verificar las rutinas generadas por la aplicación para los usuarios

asociados. Puede aceptarla, modificar ejercicios o rechazarla. Igualmente, puede ingresar a la

base de datos nuevos ejercicios, especificando la información del mismo, agregando imágenes o

video y descripción del mismo. Al igual que el usuario de gimnasio, puede solicitar la generación

de rutinas propias o para un usuario específico.

Usuarios móviles: Tendrán una interacción con la aplicación móvil diseñada para android. MV

LIFE Gym Mobile tendrá varias interfaces gráficas de interacción donde podrá registrarse, iniciar

sesión, crear rutina personalizada, consultar y modificar su perfil, consultar registro de

entrenamiento, consultar sus listas de reproducción de música, consultar los ejercicios, generar

rutinas y listas de reproducción de música. Además, ver videos, descripción de ejercicios y detalles

de las rutinas, etc.

2.1.3 Interfaces con el Hardware

Usuarios móviles:

- Sistema de localización GPS [15]: Es utilizado para poder reconocer la posición actual del

usuario, permitiendo generar rutinas según su ubicación.

- Pantalla Touch Screen: Permite al usuario la interacción con el dispositivo móvil.

Usuarios Web:

- Mouse: Se usa para la navegación en las opciones y la plataforma web.

12

- Pantalla: Principal componente de interacción con el entrenador, permite dar la información

de la plataforma gráficamente.

- Teclado: Principal elemento de interacción del entrenador con la plataforma. Se utiliza para

ingresar los diferentes datos que son requeridos.

2.1.4 Interfaces con el Software

Para el funcionamiento del sistema se tiene las siguientes características de software:

Usuario móvil:

Sistema operativo Android como mínimo 4.0x (Ice Cream Sandwich). [26]

Se decide tomar este sistema operativo Android, pues la gran mayoría de los dispositivos móviles actuales

utilizan sistemas desde esta versión o posteriores, llegando así a la mayor cantidad de usuarios posible.

[25]

Usuario Web:

Para el uso de la plataforma web, se accederá a través de cualquier sistema operativo que tenga acceso a

los siguientes exploradores:

- Google Chrome [28]

- Firefox [29]

- Internet Explorer [30]

2.1.5 Interfaces de Comunicación El dispositivo móvil se comunica con el servicio web [6] a través del protocolo de aplicación SOAP, [30] el cual es un protocolo estándar de invocación de servicios remotos, basado en el protocolo estándar HTTP [6] para la transmisión de mensajes codificados en XML [32]. La principal característica de los servicios web es la independencia de plataforma, por esta razón cualquier dispositivo o sistema externo con acceso a internet podrá invocar el servicio web que se ejecuta en Google App Engine [31].

2.1.6 Restricciones de Memoria

Usuario Móvil:

Dispositivo Móvil Android:

Almacenamiento:

o Mínimo 2 Mb de almacenamiento interno del dispositivo. Puede extenderse a mínimo 1

GB de memoria externa.

Procesamiento:

o Mínimo 128 RAM.

Usuario Web: Mínimo 128 Mb de memoria RAM

13

2.1.7 Operaciones

Para la operación de cada una de las plataformas, se debe tener en cuenta el tipo de interacción que el

usuario de gimnasio o entrenador vaya a realizar. Con ello, tenemos la siguiente clasificación:

Usuario Móvil:

• Modo Usuario: Modo de uso general de los usuarios de gimnasio, donde se puede

registrar, iniciar sesión, modificar perfil, generar rutinas de ejercicios, consultar ejercicios

y descripción de cada uno de ellos, escanear códigos QR [14] y generar listas de

reproducción de música.

• Modo Rutinas: Modo donde se detallan las rutinas de ejercicios, ya sean generadas por la

aplicación por grupo muscular, objetivo o restricción médica. Se pueden consultar videos,

descripción de ejercicios, detalle de músculos entrenador, etc.

• Modo Música: Modo donde el usuario puede generar listas de reproducción de música

general o personalizada, según su tipo de entrenamiento y preferencias en canciones.

Usuario Web:

• Modo entrenador o médico: Modo de uso específico para los entrenadores y médicos del

gimnasio, en donde pueden registrarse como tal, crear rutinas de ejercicios, ingresar

nuevos ejercicios, verificar rutinas generadas y consultar registro y evolución del

entrenamiento de un usuario de gimnasio específico.

• Modo Rutinas Entrenador: Modo donde el entrenador puede detallar las rutinas

generadas por la aplicación y hacer las modificaciones que considere necesarias.

Igualmente, puede ingresar nuevos ejercicios al sistema.

2.1.8 Requisitos de Adaptación del Sitio

Hay dos escenarios en los cuales el sistema funcionará. Uno de ellos se encuentra en los dispositivos móviles Android. Para hacer uso del sistema, es necesario acceder a la tienda de aplicaciones Google Play [18] para descargar la aplicación y contar con buena conexión a internet, ya sea Wi-Fi o datos móviles para hacer uso de todas las funciones de la aplicación. Este escenario está destinado para los usuarios de gimnasio. El otro escenario es el de la plataforma web, en donde es necesario un explorador web estándar con una conexión a internet óptima. Este está destinado para los entrenadores y médicos del gimnasio, que llevarán registro, control y evolución de sus pacientes (usuarios de gimnasio).

2.2 Funciones del Producto

A continuación se encuentran las funciones más importantes de MV LIFE Gym Mobile. Las funcionalidades

completas y detalladas se encuentran especificadas en el documento de especificación de casos de uso

[Ver Anexo CasosdeUso_MV LIFE Gym Mobile]:

14

Usuario Móvil:

Manejo de sesión de usuario: registro, consulta y modificación de perfil, características físicas y

restricciones médicas.

Consulta rutinas de ejercicio y lista de ejercicios.

Generar rutinas de ejercicios a partir de un grupo muscular, su objetivo o sus restricciones

médicas. Igualmente generar rutina por ubicación o con códigos QR.

Consulta de listas de reproducción de música y listado de canciones.

Consultar su registro de entrenamiento y evolución física.

Usuario Web:

Manejo de sesión de usuario: registro de entrenador, consulta y modificación de su perfil.

Consulta de rutinas generadas por la aplicación para sus usuarios asociados. Modificación y

adecuación de las mismas.

Creación de rutinas de ejercicios e ingreso de nuevos ejercicios en el sistema.

2.3 Características del Usuario

A continuación se describen los tipos de usuario que utilizará MV LIFE Gym Mobile para su entrenamiento

diario y recuperación física, además del entrenador y médico asesor en dichos procesos:

Usuario Móvil:

Tabla 1 - Características de Usuario Móvil

Características del usuario Usuario de Gimnasio

Descripción

El usuario de gimnasio, incluye a los hombres y mujeres entre los 14 y 60 años que sean usuarios frecuentes de gimnasio y/o que

realicen actividad física regularmente. Deben tener acceso a dispositivos móviles o

computador.

Actividades Registro, inicio de sesión, Consultar rutinas, ejercicios, listas de reproducción de música,

escanear código QR.

Experiencia

Tener un breve conocimiento de manejo de dispositivos móviles, acceso a la tienda de

aplicaciones Google Play y utilización de lector QR y GPS.

Frecuencia de Uso Frecuente

Usuario Web:

Tabla 2. Características de Usuario Web

Características del usuario Entrenador o Médico

15

Descripción

Entrenador o médico de gimnasio. Incluye hombres y mujeres entre 23 y 60 años.

Profesionales o especializados en las ciencias del deporte y tratamiento de lesiones.

Actividades

Registro, inicio de sesión, creación de rutinas, ingreso de nuevos ejercicios al sistema, verificación de rutinas generadas por la

aplicación móvil.

Experiencia Tener conocimiento en el manejo de

computadores y navegadores de internet.

Frecuencia de Uso Frecuente

2.4 Restricciones

Las restricciones sobre los diferentes aspectos de desarrollo del proyecto y que directamente influyen en

el proceso de implementación son:

Tabla 3. Restricciones

Tipo de Restricción Restricciones

Requisitos de lenguaje El sistema va a estar desarrollado en el idioma español

principalmente, ya que va a ser lanzado en la ciudad de Bogotá.

Cliente El producto debe ser entregado en las fechas especificadas.

El producto debe contar con las funciones especificadas inicialmente.

Interfaz de usuario

Se espera que la interfaz sea consistente y fácil de usar para los usuarios, que sea amigable y no presente errores de ningún tipo.

Lenguaje de Programación

La plataforma móvil y la plataforma web serán desarrolladas en NetBeans IDE y Android Studio [8], a través de lenguaje de programación JAVA.

Legales

El software empleado para el desarrollo de este proyecto será en su mayoría de software libre.

Todo el contenido del proyecto será de propiedad del estudiante Víctor Hugo Vela Pinzón

Persistencia Toda la información será persistida en el sistema de

almacenamiento MySql.

Sistema operativo

El sistema operativo para la plataforma móvil Android 4.0x o posterior.

El sistema operativo para la plataforma web será Windows 7 o Windows 8

16

3. PLAN DE MANEJO DE REQUERIMIENTOS Este Plan de Manejo de Requerimientos describe los procesos realizados para la captura, clasificación,

control, priorización y trazabilidad de los requerimientos funcionales y no funcionales del sistema.

3.1 Levantamiento de Requerimientos

En las siguientes secciones del presente plan se detallará el proceso de levantamiento de requerimientos

realizado en las instalaciones de la Sede Chapinero del CMD Bodytech, teniendo en cuenta los

implementos deportivos disponibles en éste lugar.

3.1.1 Requerimientos Funcionales

Para la captura de los requerimientos funcionales del sistema MV LIFE Gym Mobile, se realizaron 3

reuniones dentro de las instalaciones de la Sede Chapinero del CMD Bodytech. Igualmente, se hicieron

varias visitas y revisiones a los equipos, máquinas y demás implementos deportivos disponibles en este

gimnasio.

En las reuniones estuvieron presentes: Oscar Alfredo Bahamón, Coordinador de Sede Chapinero – CMD

Bodytech y Víctor Hugo Vela Pinzón, estudiante de Ingeniería de Sistemas.

En cada una de las reuniones se definieron las funcionalidades más relevantes a desarrollar en el

prototipo, las lesiones a tratar y los implementos deportivos (máquinas y equipamiento) que serán

incluidos en el mismo. De igual manera, se realizó la definición de las rutinas de ejercicios para usuarios

nivel básico (Acondicionamiento), intermedio (Fortalecimiento, Tonificación) y avanzado (Hipertrofia,

Fortalecimiento).

3.1.2 Requerimientos No Funcionales

Los requerimientos no funcionales se tomaron a partir de las observaciones hechas durante las reuniones,

se discutieron durante las reuniones y se tomaron en cuenta partiendo de las funcionalidades que el

sistema debe tener para su confiabilidad, disponibilidad y demás criterios no funcionales que se deben

tomar en cuenta para el desarrollo de la aplicación.

3.1.3 Verificación y Validación de Requerimientos

Se hizo un estudio inicial de las funcionalidades que podría tener la aplicación móvil, partiendo de las

necesidades del contexto de trabajo y del alcance esperado de la misma. Teniendo como base esto, se

realizó el levantamiento de requerimientos, por medio del proceso descrito anteriormente en este mismo

documento. De allí el estudiante Víctor Hugo Vela Pinzón, realizó una primera versión de los

requerimientos funcionales y no funcionales que tendría la aplicación.

En 2 reuniones hechas con la directora del trabajo de grado, la Ing. Luisa Barrera, se hicieron revisiones

de requerimientos, descartando los requerimientos redundantes y especificando con mayor detalle y

claridad los requerimientos definitivos. En cada uno de ellos se incluyó su descripción y verificación, la

cual se realiza durante el desarrollo, la ejecución y prueba de funcionalidad de la aplicación.

17

3.2 Tipos de Requerimientos

A continuación encontramos los tipos de requerimientos que se encuentran en la aplicación:

Tabla 4 - Clasificación de los Requerimientos

CLASIFICACION DE LOS REQUERIMIENTOS

REQUERIMIENTOS FUNCIONALES

Sesión de usuario

CRUD Perfil

Consultas de datos

Cuenta administrador

Servicios MV LIFE Gym Mobile

REQUERIMIENTOS NO FUNCIONALES

Rendimiento

Disponibilidad

Seguridad

Portabilidad

Escalabilidad

Modificabilidad

Extensibilidad

3.3 Atributos de los Requerimientos

Para la especificación de los requerimientos funcionales, se utilizó la siguiente información:

ID Req: Identificador único de los requerimientos funcionales (Ejemplo: RF-1).

Fecha de Creación: Especifica la fecha en la cual fue creado o modificado el requerimiento.

Tipo Usuario: Representa el o los usuarios que tienen relación con el requerimiento funcional

definido.

ID Caso de Uso: Representa el caso de uso asociado a cada requerimiento funcional.

Nombre: Representa una breve explicación del requerimiento.

Estado: Es una descripción del estado actual del requerimiento el cual puede ser: Especificado,

Diseñado, Implementado o Verificado, los cuales serán detallados más adelante.

Prioridad: Es la importancia que tiene la elaboración de dado requerimiento para el sistema y

para los stakeholders, medida en alta, media o baja.

Descripción: Es una explicación detallada sobre el requerimiento que se debe elaborar.

Verificación: Representa la forma en la cual se puede verificar el correcto funcionamiento del

requerimientos y como se verá durante el uso de la aplicación.

Versión: Numero asociado al control de versiones de los requerimientos.

Para los requerimientos no funcionales, su información es:

ID Req: Identificador único de los requerimientos funcionales (Ejemplo: RNF-1).

Tipo: Representa el tipo de no funcionalidad o atributo de calidad a evaluar con el requerimiento.

Fecha de Creación: Especifica la fecha en la cual fue creado o modificado el requerimiento.

18

Nombre: Representa una breve explicación del requerimiento.

Estado: Es una descripción del estado actual del requerimiento el cual puede ser: Especificado,

Diseñado, Implementado o Verificado, los cuales serán detallados más adelante.

Prioridad: Es la importancia que tiene la elaboración de dado requerimiento para el sistema y

para los stakeholders, medida en alta, media o baja.

Descripción: Es una explicación detallada so bre el requerimiento que se debe elaborar.

Verificación: Representa la forma en la cual se puede verificar el correcto funcionamiento del

requerimientos y como se verá durante el uso de la aplicación.

Versión: Numero asociado al control de versiones de los requerimientos.

3.4 Mecanismo de Control de Estado de los Requerimientos

Para llevar un control del estado de los requerimientos funcionales y no funcionales del sistema, el cual

permita tener una perspectiva del avance del proyecto y control sobre el proceso, se definieron 4

categorías como se muestran a continuación:

Tabla 5 - Control de Estado de Requerimientos

ESTADO DESCRIPCIÓN

Especificado Requerimiento especificado por los stakeholders.

Diseñado Requerimiento en una etapa de diseño, sin implementación

Implementado Requerimiento implementado, pero no se ha probado aún.

Verificado Requerimiento implementado y probado satisfactoriamente.

3.5 Mecanismo de priorización de los requerimientos

La priorización de requerimientos funcionales y no funcionales del sistema, fue determinada durante las

reuniones de levantamiento de requerimientos y con los criterios de categorización de requerimientos

definida por los estándares seguidos y el estudiante Víctor Hugo Vela Pinzón.

Los criterios que se tuvieron en cuenta para determinar la prioridad de los requerimientos funcionales

fueron:

Importancia dentro de la funcionalidad de la aplicación.

Impacto en el desarrollo del prototipo.

Esfuerzo de implementación.

Los criterios que se tuvieron en cuenta para determinar la prioridad de los requerimientos no funcionales

fueron:

Importancia dentro de la funcionalidad de la aplicación.

Riesgo para la arquitectura.

De esta manera se determinó que cada requerimiento se debía clasificar dentro de las siguientes

prioridades:

19

Tabla 6 - Priorización de Requerimientos

PRIORIDAD DESCRIPCIÓN

Alta Requerimiento indispensable para uno o más stakeholders. Debe incluirse en versiones tempranas del producto para no afectar el desarrollo general del prototipo.

Media No es indispensable para el desarrollo general del proyecto, pero brinda funcionalidades importantes y puede afectar la satisfacción de algún stakeholder.

Baja No es indispensable su desarrollo. No genera mayor impacto en el desarrollo del prototipo y no afecta a los stakeholder.

3.6 Trazabilidad

Para el control de la trazabilidad durante el análisis, el diseño, la implementación y las pruebas del

proyecto, se decide utilizar las siguientes plantillas:

3.6.1 Requerimientos Funcionales

Tabla 7 - Trazabilidad Requerimientos Funcionales

REQUERIMIENTO CASO(S) DE USO ASOCIADO(S)

COMPONENTE(S) ARQUITECTURAL(ES)

ASOCIADO(S)

CASO(S) DE PRUEBA ASOCIADO(S)

3.6.2 Requerimientos No Funcionales

Tabla 8 - Trazabilidad Requerimientos No Funcionales

4. REQUERIMIENTOS ESPECIFICOS

4.1 Requerimientos Funcionales

Se especifican y detallan en el documento de especificación de requerimientos adjunto.

REQUERIMIENTO ELEMENTO(S) DE DISEÑO ASOCIADO(S) ESCENARIO(S) DE CALIDAD

20

4.2 Requerimientos No Funcionales

Se especifican y detallan en el documento de especificación de requerimientos adjunto.

5. ANÁLISIS DEL SISTEMA - MODELO DE DOMINIO A continuación se detallará el sistema MV LIFE Gym Mobile, por medio de la representación de sus

componentes y relaciones que lo conforman. Se muestra el flujo de negocio, resaltando los servicios que

ofrece y los recursos necesarios para satisfacerlos.

5.1 Modelo de Dominio

El Modelo de Dominio del sistema MV LIFE Gym Mobile se detalla en el ANEXO 1 – MODELO DEL MUNDO

MV LIFE GYM MOBILE (Ver Ilustración 1).

5.2 Documentación Modelo de Dominio

A continuación se presenta una breve descripción de los componentes incluidos en el diagrama del mundo

y que será importante tener en cuenta para comprender el funcionamiento del sistema:

MV LIFE Gym Mobile: Es el sistema base del proyecto. Es el encargado de proveer los servicios

personalizados a los usuarios de gimnasio con base en el conocimiento del mismo, sus características,

gustos y preferencias representados por un Perfil Usuario (Ver Modelo Perfil Usuario MV). Además, es el

encargado de la interacción entre los diferentes servicios con el fin de articularlos y así enriquecer cada

uno y proveerle al cliente una mejor solución. El sistema ofrece 3 servicios a los usuarios de gimnasio y

entrenadores. Igualmente, se divide en 3 modelos, teniendo en cuenta el contexto de entrenamiento, el

gimnasio y el usuario final.

Finalmente, el sistema tiene 2 tipos de usuario inicialmente, los cuales se definen en TipoUsuario y se

dividen en:

UsuarioGym: es el usuario de gimnasio regular y/o usuario de la aplicación móvil para

ejercicios, que se registra e ingresa al sistema y tiene acceso a los servicios principales del

mismo.

UsuarioEntrenador/Médico: es el profesional del ejercicio o profesional de la salud que tiene

acceso a la plataforma web para verificación de rutinas, creación de rutinas y ejercicios,

registro e ingreso al sistema y seguimiento de lesiones y restricciones médicas.

Servicio: Detalla los servicios que ofrece MV LIFE Gym Mobile, los cuales son:

Modulo Entrenador: Plataforma Web encargada de proporcionar al usuario Entrenador

acceso a las funcionalidades dentro del sistema, de las cuales puede hacer uso, como lo son:

Registro, Verificación de Rutinas Generadas, Seguimiento a usuarios asociados, Creación de

Rutinas (crea RUTINA) y Creación de ejercicios. Éste módulo lo usan PROFESIONAL SALUD y

PROFESIONAL EJERCICIO. Tiene los siguientes atributos:

Tabla 9 - Atributos Módulo Entrenador

Nombre Descripción

nombreEntrenador Nombre del entrenador dentro del sistema

21

contraseñaEntrenador Clave de ingreso e identificación del entrenador en el sistema

verificacionEntrenador Casilla de verificación de las rutinas asociadas de sus usuarios por parte del

entrenador

En el módulo entrenador se puede verificar:

Tabla 10 - Atributos Rutinas Generadas por la Aplicación

Rutina GeneradaXApp

Nombre Descripción

nombreRutina Nombre de la rutina generada por la aplicación y que verifica el entrenador

Tabla 11 - Atributos Seguimiento por Usuario

SeguimientoXUsuario

Nombre Descripción

usuarioAsociado Identificador del usuario asociado al entrenador y al cual se le hará el

seguimiento a su evolución física y entrenamientos

RUTINA: Servicio que genera la rutina para el usuario de gimnasio, partiendo de sus

características físicas (rutinas generales asociadas a un grupo muscular), de su objetivo físico

y de sus restricciones médicas. Igualmente, este servicio lo puede realizar el entrenador desde

su plataforma web y puede generarse a partir de la identificación de elementos (máquinas)

del gimnasio a través de código QR [14] o de su ubicación y elementos deportivos disponibles

(Ver ModeloPerfilRutina_MVLIFE).

Lista Reproducción Música: Servicio de reproducción de música en el sistema. Permite

conectarse al reproductor del dispositivo o a aplicaciones de reproducción de música, con las

cuales el usuario puede crear y reproducir a partir de su tipo de entrenamiento y permitiendo

adaptarse al mismo, teniendo en cuenta las preferencias del usuario (Ver

ModeloMusica_MVLIFE).

Tabla 12 - Atributos Tipo Entrenamiento

TipoEntrenamiento

Nombre Descripción

TipoEntrene Nombre del tipo de entrenamiento asociado a las rutinas y ejercicios que

realiza el usuario, con la música asociada al mismo.

Modelo: El sistema MV LIFE Gym Mobile está compuesto por 3 modelos, los cuales permiten identificar

las características que ayudan a obtener la información, procesarla y realizar los servicios que ofrece el

sistema. Los modelos son:

Perfil Gimnasio: Modelo donde se representan los componentes incluidos dentro de las

instalaciones y demás elementos de un gimnasio. El perfil de Gimnasio tiene: instalaciones,

22

Horarios, Servicios y Personal (puede ser personal del gimnasio, profesional de la salud o

profesional del ejercicio) (Ver ModeloPerfilGimnasio_MVLIFE). También incluye:

Tabla 13 - Atributos Equipamiento

Equipamiento

Nombre Descripción

tipoEquipamiento Nombre del tipo de equipamiento que se encuentra disponible en el

gimnasio. Puede ser máquina o equipamiento para ejercicio específico.

codigoQR Código QR identificador de la máquina del gimnasio. Este ofrece información

detallada de la máquina y el (los) ejercicio(s) que se pueden realizar en él.

Perfil Contexto: Modelo donde se representa el lugar de entrenamiento del usuario, diferente

a las instalaciones del gimnasio. Este perfil tiene en cuenta si el usuario se encuentra en su

casa u otra ubicación y en la cual desea realizar una rutina de ejercicios. Se tiene en cuenta:

Tabla 14 - Atributos Lugar Entrenamiento

Lugar Entrenamiento

Nombre Descripción

ubicacion Ubicación del usuario y en donde desea realizar un entrenamiento.

Perfil Usuario: El modelo más importante dentro del sistema, junto con el servicio RUTINA,

con el cual está asociado. En este modelo se entiende como Usuario de Gimnasio a la persona

que asiste regularmente a las instalaciones de entrenamiento más usadas para tal fin [33] y/o

personas que pueden presentar restricciones médicas y requieran un tratamiento especial

para las mismas. Teniendo en cuenta esto, este perfil permite generar mayor conocimiento

de los usuarios y/o pacientes del gimnasio y obtiene la información de los mismos, partiendo

de sus características físicas, Objetivos, Preferencias y Restricciones Médicas (Ver

ModeloPerfilUsuario_MVLIFE).

23

ANEXO 1

Ilustración 1 - Modelo del Mundo MV LIFE Gym Mobile