Software Requirement

Specification
S.R.S

Ing. Gabriel H. Fuentes Amorocho

Ing. Juan Pablo Rodríguez Montoya

1
Historial De Cambios

Sección Fecha Versión de la

Sección
2.3 15/02/2016 0.1a
2.6 15/02/2016 0.1a
5 15/02/2016 0.1b
2.1.6 15/02/2016 0.1
3.1 15/02/2016 0.2
4.1 15/02/2016 0.2
2.1.7 15/02/2016 0.2ª
2.2 25/02/2016 0.1a
4.2 25/02/2016 0.1ª
3.3 25/02/2016 0.2
2.4 25/02/2016 0.1a
2.7 25/02/2016 0.2
4.3 25/02/2016 0.3
2.1 25/02/2016 0.1
2.5 25/02/2016 0.4a
1.3 10/03/2016 0.1a
1.4 10/03/2016 0.1a
1.5 10/03/2016 0.1a
6 10/03/2016 0.1
3.2 10/03/2016 0.1a

2
 Prefacio

El proceso de especificación de requerimientos es de vital importancia para el éxito de un proyecto de

software, allí se incluyen todos los procesos fundamentales para la comprensión de la construcción del proyecto
de software. El cual esta descrito de tal manera que los desarrolladores y clientes puedan comprender los
procedimientos realizados a lo largo de la construcción del software.

Este documento muestra los procesos realizados para la especificación de requerimientos de la aplicación la
magia de las palabras. De esta manera se asegura que todas las necesidades del cliente sean cumplidas a
cabalidad y de una manera organizada, además de ilustrar los procesos de trazabilidad que permiten hacer
seguimiento de cualquier elemento del proyecto desde su concepción hasta su implementación, para un mayor
control por parte del equipo de proyecto.

3
Contenido
Historial De Cambios ............................................................................................................................................... 2
Prefacio ................................................................................................................................................................... 3
Lista de figuras......................................................................................................................................................... 5
Lista de tablas .......................................................................................................................................................... 6
1. Introducción ........................................................................................................................................................ 7
1.1 Propósito ...................................................................................................................................................... 7
1.2 Alcance .......................................................................................................................................................... 7
1.3 Definiciones y Acrónimos .............................................................................................................................. 8
1.4 Bibliografía ........................................................................................................................................................ 8
1.5 Apreciación Global ...................................................................................................................................... 10
2. Descripción Global............................................................................................................................................. 11
2.1 Perspectiva del Producto ............................................................................................................................ 11
2.1.1 Interfaces Sistema ............................................................................................................................... 11
2.1.2 Interfaces de usuario ............................................................................................................................ 11
2.1.3 Interfaces de Hardware ........................................................................................................................ 11
2.1.4 Interfaces de Software ......................................................................................................................... 11
2.1.5 Restricciones de Memoria .................................................................................................................... 12
2.1.6 Operaciones ......................................................................................................................................... 12
2.2 Funciones del Producto ............................................................................................................................... 13
2.3 Características del Usuario .......................................................................................................................... 14
2.4 Restricciones ............................................................................................................................................... 15
2.5 Modelo de Dominio..................................................................................................................................... 15
2.6 Suposiciones y Dependencias ..................................................................................................................... 16
2.7 Distribución de Requerimientos.................................................................................................................. 16
3 Requerimientos Específicos ............................................................................................................................... 17
3.1 Requerimientos de Interfaces Externas ...................................................................................................... 17
3.1.1 Interfaces de Software ........................................................................................................................ 17
3.1.2 Interfaces con Usuario ......................................................................................................................... 17
3.1.3 Interfaces de Hardware ........................................................................................................................ 18
3.1.4 Interfaces Software ............................................................................................................................. 18
3.1.5 Interfaz de Comunicación.................................................................................................................... 18
3.2 Características del Producto de Software ................................................................................................... 18
3.2.1 Seguimiento ......................................................................................................................................... 19
3.2.2 Actividades ........................................................................................................................................... 19

4
 3.2.3 Adaptabilidad ....................................................................................................................................... 19
3.3.1 Atributos del Sistemas.......................................................................................................................... 20
3.3.2 Requerimientos de Desempeño .......................................................................................................... 20
3.3.3 Requerimientos de Persistencia .......................................................................................................... 20
3.3.4 Requerimientos de Seguridad ............................................................................................................. 20
3.4 Hardware ..................................................................................................................................................... 21
4 Administración de Requerimientos .................................................................................................................... 21
4.1 Procesos de Administración y Control de Requerimientos durante el desarrollo .................................. 21
4.2 Mecanismos de Priorización y Trazabilidad ................................................................................................ 23
4.2.1 Mecanismos de Priorización................................................................................................................. 23
4.2.1 Mecanismos de Trazabilidad ................................................................................................................ 24
4.3 Construcción del SRS ................................................................................................................................... 24
5 Proceso de Verificación ...................................................................................................................................... 25

Lista de figuras
Ilustración 1 Modelo de Dominio .......................................................................................................................... 16
Ilustración 2 Funcionalidades del Sistema ............................................................................................................ 19
Ilustración 3 Proceso de Administración y Control de Requerimientos ............................................................... 22
Ilustración 4 Proceso de Verificación .................................................................................................................... 26

5
Lista de tablas

Tabla 1 Interfaces de Software.............................................................................................................................. 12

Tabla 2 Modos de Operación Usuarios ................................................................................................................. 12
Tabla 3 Periodos de Actividad e Inactividad ......................................................................................................... 13
Tabla 4 Funciones de Producto ............................................................................................................................. 13
Tabla 5 Roles ......................................................................................................................................................... 14
Tabla 6 Funcionalidades/Privilegios ...................................................................................................................... 14
Tabla 7 Descripción de Clases del Modelo de Dominio ........................................................................................ 15

6
1. Introducción

1.1 Propósito

El propósito del documento de SRS para la aplicación la magia de las palabras, es mostrar el proceso
realizado durante el levantamiento y especificación de requerimientos. A causa de esto, se tiene el lineamiento
y procesos para que la creación de software sea exitosa y se pueda realizar sin demoras priorizando los
elementos más importantes y descartando requerimientos fuera del alcance.

El documento está escrito de una manera que sea entendible para toda audiencia. Esto se debe a la naturaleza
del documento en sí; el cual muestra los procesos generales seguidos para el levantamiento de requerimientos
y de ser necesario tiene el nivel de especificación, para poder culminar con éxito la etapa de levantamiento de
requerimientos y creación de prototipo.

1.2 Alcance

El alcance del SRS está igualmente definido en la propuesta de trabajo de grado, no obstante el alcance respecto
al producto está definido a partir de los requerimientos, Anexo UserStories.xlsx, por otro lado en este
documento anexo se explica las funcionalidades de la aplicación la magia de las palabras.

Incluye:

 Juegos (Estipulado en la sección 3.2 Características del Producto de Software)

 Actividades de Seguimiento (Estadísticas sobre actividades realizadas, actividades, puntaje)
 Separación entre Usuario y Tutor

Excluye:

 Pruebas del sistema en niños

 Adaptar Contenido (Visualizar, buscar y agregar frases para las actividades)
 Sistema operativo Android anterior a lo estipulado en la sección 2.1.4 Interfaces de Software

7
 1.3 Definiciones y Acrónimos
1. Trazabilidad: Capacidad para reconstruir el historial de la utilización o la localización de un artículo o
producto mediante una identificación registrada [1]
2. Priorización (de priorizar): Dar prioridad a algo. [2]
3. Interfaz: Conexión física y funcional entre dos aparatos o sistemas independientes. [3]
4. Usuario: En este contexto, cualquier persona que utilice la aplicación La magia de las Palabras.
5. Visualización: Herramienta o método para interpretar los datos alimentados en una computadora y
para generar imágenes de datos multidimensionales complejos. [4]
6. Rendimiento: medida o cuantificación de la velocidad/resultado con que se realiza una tarea o
proceso. [5]
7. Android: Sistema operativo para dispositivos móviles, desarrollado por la compañía Alphabet
(previamente conocida como Google) [6]
8. GB: Gigabyte
9. User Stories: Es una definición de requerimiento de alto nivel, que contiene suficiente información
para que los desarrolladores puedan producir un estimado razonable del esfuerzo para implementarlo
[7].
10. RAM: Random-Access Memory, memoria de acceso aleatorio en inglés. [8]
11. SQLite: Es el sistema de manejo de bases de datos [9]
12. SRS: Software Requirements Specification, especificación de requerimientos de software en inglés.
[10]
13. Smartphone: Es un celular y un computador de mano, el cual ha creado la revolución más de
tecnología desde el internet [11].

1.4 Bibliografía

[1] Universidad Politécnica de Cartagena, «Trazabilidad,» [En línea]. Available:

http://www.upct.es/~gio/trazabilidad.htm. [Último acceso: 18 Abril 2015].
[2] Real Academia de la Lengua, «Priorizar,» [En línea]. Available:
http://lema.rae.es/drae/?val=priorizaci%C3%B3n. [Último acceso: 18 Abril 2015].
[3] Real Academia de la Lengua, «Interfaz,» [En línea]. Available:
http://buscon.rae.es/drae/srv/search?val=interfaz. [Último acceso: 18 Abril 2015].

8
[4] Visualizar.info, «Visualización de información,» [En línea]. Available: http://visualizar.info/que-
es/visualizacion-de-informacion/. [Último acceso: 18 Abril 2015].
[5] L. Alegsa, «Definición de rendimiento,» [En línea]. Available:
http://www.alegsa.com.ar/Dic/rendimiento.php#sthash.rd5uQkzS.dpuf. [Último acceso: 18 Abril
2015].
[6] Android, [En línea]. Available: http://source.android.com/.
[7] Agile Modeling, «User stories,» Agile Modeling, [En línea]. Available:
http://www.agilemodeling.com/artifacts/userStory.htm.
[8] Acronym Finder, «What does RAM stand for?,» [En línea]. Available:
http://www.acronymfinder.com/Random_Access-Memory-(RAM).html. [Último acceso: 18
Abril 2015].
[9] SQLite, «SQLite,» [En línea]. Available: https://www.sqlite.org/.
[10 Acronym Finder, «What does SRS stand for?,» [En línea]. Available:
] http://www.acronymfinder.com/Software-Requirements-Specification-(SRS).html. [Último
acceso: 18 Abril 2015].
[11 PC Magazine, «Encyclopedia,» [En línea]. Available:
] http://www.pcmag.com/encyclopedia/term/51537/smartphone.
[12 Android, «Compatibily Definition,» Compatibily Program, [En línea]. Available:
] https://static.googleusercontent.com/media/source.android.com/en//compatibility/5.0/android-
5.0-cdd.pdf.
[13 Universidad de Murcia, «Ingeniería del software,» [En línea]. Available:
] http://www.um.es/docencia/barzana/IAGP/Iagp1.html. [Último acceso: 2015 03 28].
[14 J. P. Quiroga, «Requerimientos funcionales y no funcionales,» [En línea]. Available:
] https://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=principal:csof510
1-requerimientos.pdf. [Último acceso: 18 Abril 2015].
[15 C. González Almirón, «Gestión de los requisitos,» 5 Mayo 2010. [En línea]. Available:
] http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=RM#_Toc260742323. [Último
acceso: 18 Abril 2015].
[16 M. Cohn, «Mountain Goat Software,» [En línea]. Available:
] http://www.mountaingoatsoftware.com/system/asset/file/259/User-Stories-Applied-Mike-
Cohn.pdf. [Último acceso: 11 04 2015].
[17 K. E. Wiegers, Software Requirements: Practical techniques for gathering and managing
] requirement through the product development cycle, 2003.
[18 M. A. G. Vargas, LA TRAZABILIDAD EN EL PROCESO DE REQUERIMIENTOS DE
] SOFTWARE, Heredia Costa Rica: Universidad Nacional,Escuela de Informática., 1999.
[19 J. Doorn, Facilitando la Asignación de Prioridades a los Requerimientos, Departamento de
] Ingeniería e Investigaciones. UNLaM, Argentina.
[20 IEEE, «Tech Whirl L,» Plantilla SRS, [En línea]. Available: http://techwhirl.com/writing-
] software-requirements-specifications/.
[21 IEEE, «IEEE Standars Asociation,» IEEE Recommended Practice for Software Requirements
] Specifications , 2009. [En línea]. Available: http://standards.ieee.org/findstds/standard/830-
1998.html.
[22 J. Castro, «Administracion de Proyectos,» 2010. [En línea]. Available:
] https://code.google.com/p/administracionproyectos2010/. [Último acceso: 11 04 2015].
[23 Google, [En línea]. Available: https://support.google.com/chrome/answer/95346?hl=es-419.
] [Último acceso: 27 Marzo 2015].

9
[24 Mozilla, [En línea]. Available: https://www.mozilla.org/en-US/firefox/36.0.4/system-
] requirements/. [Último acceso: 27 Marzo 2015].
[25 Quiroga, «Requerimientos Funcionales No Funcionales,» Universidad de los Andes, 2015.
]
[26 G. Hadad, «Explicitar Requisitos del Software usando Escenarios,» Departamento de Ingeniería e
] Investigaciones. Tecnológicas, , UNLaM.
[27 D. A. &. M. Marca, structured analysis and design technique, McGraw-Hill, Inc, 1987.
]
[28 Real Academia de la Lengua, [En línea]. Available:
] http://lema.rae.es/drae/?val=perif%C3%A9rico. [Último acceso: 18 Abril 2015].
[29 U. S. Barbara, «Network Devices,» [En línea]. Available:
] http://web.physics.ucsb.edu/~pcs/network/NetworkDevices.htm. [Último acceso: 18 Abril 2015].
[30 Opera, «Opera System Requirements,» [En línea]. Available:
] http://www.opera.com/download/requirements/. [Último acceso: 27 Marzo 2015].
[31 Microsoft, «Requisitos del sistema de Internet Explorer,» [En línea]. Available:
] http://windows.microsoft.com/es-co/internet-explorer/ie-system-requirements#ie=ie-10. [Último
acceso: 27 Marzo 2015].
[32 MySQL, «D.10.4 Limits on Table Column Count and Row Size,» [En línea]. Available:
] http://dev.mysql.com/doc/refman/5.5/en/column-count-limit.html. [Último acceso: 27 Marzo
2015].

1.5 Apreciación Global

El documento SRS los elementos necesarios para realizar una adecuada especificación de requerimientos
para la creación de la aplicación la magia de las palabras y está estructurado de la siguiente manera:

La sección 2 “Descripción global” muestra los factores generales que afectan el producto y los requerimientos
necesarios para la aplicación la magia de las palabras, esto para facilitar al lector entender la descripción de
todo el sistema.

La sección 3 “Especificación de los requerimientos” es donde se pasan de las necesidades del usuario a un
lenguaje técnico enfocado a los desarrolladores, es importante tener en cuenta; que el tipo levantamiento de
requerimientos empleado son los “User Stories”.

La sección 4 “Administración de requerimientos” tendrá los procesos de administración, control, priorización y

trazabilidad de requerimientos empleados. Además el proceso de creación de este documento.

La sección 5 “Proceso de verificación” se muestra el proceso aplicado para verificar y validar los requerimientos
individuales de la aplicación la magia de las palabras.

10
2. Descripción Global

2.1 Perspectiva del Producto

La magia de las palabras es una aplicación que busca apoyar el desarrollo de habilidades lingüísticas en
niños con trastorno del lenguaje expresivo. Esta aplicación permitirá al niño usuario el fortalecer y mejorar sus
habilidades fonéticas, semánticas y sintácticas del idioma español mientras juega. Estas actividades se
desarrollarán a modo que construyan historias, a través de las cuales el niño mejore las habilidades
anteriormente mencionadas. Por otra parte, la aplicación tendrá la capacidad de realizar seguimiento a los logros
del niño a través de reportes y notificaciones; disponibles solo para los familiares del niño.

Así mismo se tendrá la capacidad de adaptar contenido, la cual se verá reflejada en la búsqueda y
adicción de frases a la aplicación. Esta modalidad, estará disponible tanto para al familiar como a tutores que
deseen utilizar la aplicación.

2.1.1 Interfaces Sistema

MDP no tendrá ninguna interacción con ningún sistema externo de ninguna entidad o institución,
debido a que esto genera mayores tiempos de aprendizaje de herramientas y por consecuencia: el proyecto.
Además se requerirían de permisos o licencias, que aumentarían el presupuesto para la realización de este
proyecto.

2.1.2 Interfaces de usuario

La interfaz con el usuario consistirá de un conjunto de ventanas con botones, imágenes, listas, campos
de texto, frases, y juegos. Estos serán construidos específicamente para la aplicación.

2.1.3 Interfaces de Hardware

Lo único necesario para poder utilizar la aplicación es poseer un Smartphone.

2.1.4 Interfaces de Software

Para el correcto funcionamiento de la magia de las palabras, la aplicación debe de interactuar con
estos softwares:

11
Tabla 1 Interfaces de Software

Producto de Android 4.2 SQLite

Software
La aplicación será desarrollada a partir de esta Este sistema de gestión de bases de datos
versión del sistema operativo Android en soporta la realización de transacciones en
Descripción adelante, dado que es la versión que la gran simultánea, multiusuario.
mayoría de dispositivos móviles en el mercado
actual soportan.
Utilizar una base datos segura que
soporte múltiples consultas que además
Asegurar que la mayor cantidad usuarios provea una rápida respuesta y mantenga
Propósito de
tengan acceso a la plataforma. la consistencia e integridad de la
uso
Alojar la aplicación en un servidor Linux. información.

 SDK 17
 Android 4.2 en adelante
Versión

[6] [9]
Fuente
La aplicación no soportará versiones La velocidad de consultas estará
Comentarios anteriores a la estipulada aquí. restringida a la capacidad de
adicionales procesamiento del dispositivo.

2.1.5 Restricciones de Memoria

Para las restricciones de memoria en la magia de las palabras la capacidad mínima requerida para
ejecutar el SO1 de Android 4.2 es de 512 MB de memoria RAM y 20 MB de memoria para la aplicación dividida
entre memoria cache del dispositivo y la aplicación en sí [12].

2.1.6 Operaciones

2.1.6.1. Modos de operación de usuarios

En la Tabla 2 Modos de Operación Usuarios se pueden observar los modos de usuario que puede utilizar el
programa y operaciones que tienen estos con respecto a las funciones del producto de Software.

Tabla 2 Modos de Operación Usuarios

MODOS DE OPERACIÓN DE USUARIOS

Usuario Función
Usuario Niño entre 5-6 años que utiliza la aplicación para mejorar sus habilidades mientras se divierte
recreando una historia.
 Realiza seguimiento del usuario a través de reportes y notificaciones
Tutor
 Puede agregar frases (contenido).

1
Sistema Operativo

12
  Puede jugar con el usuario para interactuar con él.

2.1.7.2. Periodos de actividad e inactividad

Tabla 3 Periodos de Actividad e Inactividad

PERIODOS DE ACTIVIDAD E INACTIVIDAD

Estado Proceso
Activo La aplicación estará siempre activa, siempre y cuando el dispositivo lo soporte.
El sistema solo estará inactivo cuando el dispositivo se encuentre apagado o cuando el usuario
Inactivo no tenga sesión activa en la aplicación.

2.1.7.3. Procesos de Recuperación

Una vez iniciada la sesión por el usuario, en caso de haber alguna falla; el sistema de recuperación será
mantener habilitada la sesión, esto quiere decir, que dentro de la base de datos interna de la aplicación quedará
guardada la sesión.

2.2 Funciones del Producto

Aquí se puede observar la funcionalidad básica que presenta MDP2 a los usuarios involucrados, se
encuentra detallada en la siguiente Tabla 4 Funciones de ProductoError! Reference source not found. [13].

Tabla 4 Funciones de Producto

Aplicación Móvil

 MDP provee un medio para ayudar a desarrollar habilidades lingüísticas para niños (5-6 años) con
trastorno del lenguaje expresivo.
 Los usuarios pueden desarrollar habilidades fonéticas, semánticas y sintácticas mientras juegan y
elaboran una historia en el proceso.
 Los tutores de los usuarios pueden hacer seguimientos de los logros realizados, junto con la
inclusión de más contenido útil para el usuario.

Interfaz Grafica

 MDP cuenta con una interfaz gráfica ordenada e infantil que permite al usuario identificarse con la
aplicación y ubicarse dentro de la aplicación para encontrar las áreas de interés.

Cuenta Personal

 Cada uno de los usuarios y tutores pueden tener una cuenta personal, donde: los familiares, pueden
hacer seguimiento al usuario, y añadir frases a la aplicación.
 Las cuentas de los tutores están vinculadas al usuario.

2
La Magia de las Palabras

13
 Actividades

 Asociación de imágenes con frases que forman en conjunto una historia.

Seguimiento

 El tutor a través de notificaciones y reportes, puede conocer el progreso del usuario en el tiempo

Para información más detallada sobre la relación del usuario con respecto al Sistema remítase al Anexo “Modelo
Casos de Uso.PNG”, para una explicación detallada sobre cada uno de los casos de uso remítase a “CASOS DE
USO.pdf”. Para mayor información sobre la relación de cada uno de estos casos de uso con los requerimientos
funcionales, no funcionales, de hardware y componentes remítase a “UserStories.xlsx”.

2.3 Características del Usuario

Los usuarios que contendrá la aplicación la magia de las palabras serán: usuario, tutor y el familiar, el cual será
el apoyo para el niño durante su proceso. El podrá hacer seguimiento de las actividades del niño, así como el
poder agregar contenido. Los tutores también tendrán esta última funcionalidad.

En la siguiente tabla se describen los roles:

Tabla 5 Roles

Características
Descripción Experiencia Técnica Frecuencia de Uso
del Usuario

Utilizará la aplicación cada vez

Conocimiento básico que necesite reforzar alguna
el niño que utilizará la
Roles

Niño (Usuario) de uso de habilidad lingüística. O

aplicación
smartphones. también cuando desee jugar(a
diario).
Conocimiento de la Uso tan frecuente como el
Familiar/acudiente/tutor utilidad y variedad de niño para conocer sus logros,
Familiar
relacionado con el niño usos de los así como interactuar con él a
smartphones. través de la aplicación.

Adicionalmente se muestra a continuación la tabla en la cual se relacionan las funcionalidades y privilegios

disponibles para cada rol.

Tabla 6 Funcionalidades/Privilegios

Usuarios
Funcionalidades / Privilegios Niño(usuario) Tutor

CRUD Usuario x x
Jugar x

14
 Ver Seguimientos x
Reportes x
Notificaciones x
Adaptar Contenido x
Buscar Frases x
Agregar Frases x

Para una descripción detallada de los roles se puede ver el anexo “CASOS DE USO.pdf “

2.4 Restricciones
Se trata de los elementos que condicionan el proceso de desarrollo de la aplicación MDP. Se tienen en cuenta
los requerimientos del cliente y las restricciones derivadas de la misma naturaleza del proyecto.

 El medio desde el cual se vaya a entregar tanto prototipo como documentos debe estar libre de todo
tipo de malware.
 No es permitido el uso de generadores de código.
 Las restricciones de software son las mostradas en la Sección 2.1.4 Interfaces de Software
 Las restricciones de memoria son las mostradas en la Sección 2.1.6 Restricciones de memoria.
 Debe poder ser instalado en dispositivos móviles de sistema operativo Android.
 No puede utilizar las bases de datos de la Pontificia Universidad Javeriana para la alimentación de base
datos de la aplicación
 MDP debe contar con persistencia con el fin de almacenar los datos relevantes a la aplicación

2.5 Modelo de Dominio

El modelo de dominio de MDP3 lo constituyen un total de 9 clases, explicadas en la Tabla 7.

Tabla 7 Descripción de Clases del Modelo de Dominio

Modelo de dominio
Clase Descripción
MDP Es la aplicación la magia de las palabras
Usuario (niño, tutor) los personajes que componen la entidad usuario en el sistema
Mapa Es la ventana de la aplicación en la cual se visualiza un conjunto de estaciones que representan
las actividades que con el paso del tiempo el usuario realiza
Estación Unidad de medida utilizada en la aplicación para conocer el estado emocional del usuario
mientras realiza alguna actividad.
Actividad Referente del tipo de juego con el que el usuario interactúa
Frase Componente principal de las actividades, además del componente clave de adaptabilidad de la
aplicación
Tutor este representa a los posibles usuarios que se pueden considerar como el encargado del niño o
también un experto que tenga a un niño en tratamiento

3
La magia de las palabras

15
 Niño Este representa a los usuarios niños, los cuales son quienes usaran la aplicación, más
específicamente la sección de actividades.
Puntaje Este componente representa una puntuación que únicamente presenta el usuario niño en cada
una de las actividades que realice

En la Ilustración 1 se muestra el modelo de dominio que conforma el núcleo de agentes que están
relacionados estrechamente en la aplicación.

Ilustración 1 Modelo de Dominio

2.6 Suposiciones y Dependencias

Las suposiciones se entienden como elementos que se dan por entendido que se cumplen, de otra manera no
se puede cumplir con los objetivos exitosamente con respecto a la utilización de MDP por parte de los Usuarios.
Las dependencias se entienden como elementos de los cuales depende MDP para su ejecución completa y
exitosa.

2.7 Distribución de Requerimientos

Esta sección trabaja como una guía de trazabilidad para el posterior proceso de Ingeniería de Requerimientos
(Ver Sección 4) y así identificar de manera rápida que requerimientos se asocian a cada uno de estos módulos.

16
Lo identificado para esta sección, tiene en cuenta como base lo estipulado en las Secciones 2.1 Perspectiva del
Producto y 2.2 Funciones del Producto.

Para observar el proceso de distribución de requerimientos ver en el Anexo “UserStories.xlsx”. Aquí se pueden
observar las relaciones de cada uno de los casos de uso “CASOS DE USO.pdf” con los requerimientos, así mismo
se puede observar las relaciones que tienen cada uno de estos con los componentes del sistema.

3 Requerimientos Específicos

3.1 Requerimientos de Interfaces Externas

Las siguientes secciones se encuentran estrechamente relacionadas con la Sección 2.1 Perspectiva del
Producto, la explicación de estas, busca simplemente profundizar un poco más en el contenido que debe tenerse
en cuenta a la hora de describir y definir los requerimientos del producto.

3.1.1 Interfaces de Software

Requerimientos necesarios para la ejecución de MDP, estos requerimientos están basados en las
necesidades del usuario para la utilización del software (Recursos, Sistema Operativo, Base de Datos, etc.) para
el pleno desarrollo del producto de Software.

Para Mayor información de los requerimientos software fundamentales, remítase al Anexo “UserStories.xlxs”,
para mayor información sobre las diferentes interfaces necesarias para MDP4 remítase a la “Sección 2.1.4
Interfaces de Software”.

3.1.2 Interfaces con Usuario

Requerimientos de usuario son aquellos que especifican las diferentes necesidades de interacción que
usuario va a tener al momento de entrar en contacto con la aplicación. Así como de todos los requisitos que el
sistema en cuanto a la usabilidad que la aplicación ha de tener.

La interacción entre el usuario y la aplicación se efectuará como comúnmente se ve y realiza con dispositivos
móviles. En otras palabras, se utilizarán diversas ventanas dentro de la aplicación con las vistas de las opciones
que se plantearon en los requerimientos.

4
La magia de las palabras

17
Para mayor información de los requerimientos de usuario con respecto al producto se encuentran en la “Sección
2.1.2 Interfaces con el Usuario”, así mismo los requerimientos asociados a esta sección se encuentran en el
anexo “UserStories.xlxs”.

3.1.3 Interfaces de Hardware

Será necesario que los dispositivos móviles posean las siguientes características:

 Versión 4.2 Sistema Operativo Android

 Memoria Disponible de 30Mb

3.1.4 Interfaces Software

Así como se menciona en la sección 2.1.4 Interfaces de Software, la aplicación debe contar con el
sistema operativo Android 5.0.1 o superior.

3.1.5 Interfaz de Comunicación

Requerimientos de Comunicación son aquellos requerimientos que especifican los principales

protocolos y tipos de comunicación entre el usuario y el sistema, tipo de recursos necesarios para esta
comunicación sea optima, así mismo se incluyen todas aquellas restricciones que estos protocolos incluyen

Las Interfaces de comunicación a utilizar en este producto de software se encuentran en la “Sección 2.1.5
Interfaz de comunicación”, así mismo los requerimientos ligados a estos protocolos de comunicación se
encuentran en el Anexo “UserStories.xlxs”.

3.2 Características del Producto de Software

En esta sección se ilustra las principales funcionalidades que la aplicación MDP5 presentará, así como de
su respectiva explicación de lo abarcado por cada una de las funcionalidades, y que métodos han sido utilizados
para llevar a cabo el proceso de desarrollo y seguimiento de cada funcionalidad a partir de cada requerimiento
y proceso especificados a lo largo de este documento. Basándose dichas funcionalidades en el modelo de
dominio del sistema estipulado en la Sección 2.5 Modelo de Dominio.

5
La magia de las palabras

18
La siguiente imagen representa las principales acciones del sistema que la aplicación presentará:

Ilustración 2 Funcionalidades del Sistema

• Reportes
Seguimiento
• Notificaciones

Actividades • Juegos

• Buscar Frases
Adaptabilidad
• Agregar Frases

Todas las subsecciones de las funcionalidades abarcadas a lo largo de esta sección, se acoplan y complementan
por las secciones donde se realiza la respectiva especificación, trazabilidad, verificación de los requerimientos,
así como la planeación de la construcción de lo planteado a lo largo de este documento, en las secciones: Sección
3. Requerimientos Específicos, Sección 4. Administración de Requerimientos y Sección 5.Proceso de
Verificación.

3.2.1 Seguimiento
Esta funcionalidad se encarga de generar tanto reportes como notificaciones sobre las actividades
realizadas por el usuario. En el anexo “UserStories.xlsx” puede encontrar los requerimientos asociados a esta
funcionalidad, junto con su respectiva descripción y seguimiento de estos.

3.2.2 Actividades
Esta funcionalidad abarca los juegos con los que el usuario va a interactuar. En el anexo
“UserStories.xlsx” puede encontrar los requerimientos asociados a esta funcionalidad, junto con su respectiva
descripción y seguimiento de estos.

3.2.3 Adaptabilidad
Esta funcionalidad permite la búsqueda de las frases existentes en la base de datos, así como de agregar
unas nuevas En el anexo “UserStories.xlsx” puede encontrar los requerimientos asociados a esta funcionalidad.

19
 3.3.1 Atributos del Sistemas
Son aquellos requerimientos que permiten que se garanticen las restricciones de memoria y las
interfaces con hardware y software.

3.3.2 Requerimientos de Desempeño

Características fundamentales que debe tener el sistema como es la respuesta del sistema frente a la
interacción de componentes por unidad de tiempo.

Estos requerimientos son de vital importancia en la ejecución y pruebas del producto de software, dado que
esta velocidad y validez de las operaciones representa la calidad del producto de software respecto a las
necesidades del cliente.

Requerimientos de desempeño son todos aquellos requerimientos los cuales como principal objetivo es el
correcto funcionamiento del producto de software en el momento de ejecución, donde se especifica [14]:

 Describir el desempeño para los escenarios

 Describir el volumen o tiempo de utilización para saber qué tan importante es.
 Especificar el número de usuarios concurrentes
 Especificar el número de operaciones concurrentes
 Tiempos de respuesta
 Restricciones de tiempo para sistemas de tiempo real

Los requerimientos de desempeño fundamentales de la aplicación la magia de las palabras se encuentran en el

Anexo “UserStories.xlsx” donde se pueden ver este tipo de requerimientos.

3.3.3 Requerimientos de Persistencia

Son aquellos requerimientos que permiten construir el modelo de datos del sistema. Para una aplicación
de videojuegos, normalmente se ponen los requerimientos que definirán las entidades, objetos y la información
que persistirá. [15]

3.3.4 Requerimientos de Seguridad

Son los incluidos en el sistema para asegurar la protección de la información, buen uso del producto y
definir la autenticación o autorización del ingreso del usuario. [14]

20
3.4 Hardware

Para poder ejecutar satisfactoriamente la aplicación la magia de las palabras se deberá contar con un
dispositivo que debe cumplir con las restricciones de memoria vistas en la Sección 2.1.6 “Restricciones de
memoria”.

Para hacer uso de la aplicación, el cliente debe contar una máquina cuyas especificaciones debe cumplir las
siguientes características:

 Procesador Snapdragon 400 a 1.2 GHz

 1 GB en memoria RAM

Estás características obedecen las especificaciones de los dispositivos móviles gama media de Android. Para
este caso específico, corresponden al MotoG 2014.

4 Administración de Requerimientos

4.1 Procesos de Administración y Control de Requerimientos durante el

desarrollo

El proceso general de Administración y Control de requerimientos incluye los procesos de identificación,

especificación, verificación, validación, priorización, análisis y trazabilidad creados para ser usados para obtener
los requerimientos para la aplicación la Magia de las Palabras.

A continuación se muestra el BPMN asociado al proceso general de Administración y Control:

21
Ilustración 3 Proceso de Administración y Control de Requerimientos

El proceso inicia con la identificación de requerimientos los cuales son desarrollados por el Ing. de
Requerimientos, por medio de la metodología de “User Stories” , en donde se identifican requerimientos
basados en los casos de uso realizados como casos funcionales para la aplicación MDP6, los cuales se pueden
ubicar en el anexo “Casos de Uso”. Esta metodología facilita la identificación de los requerimientos, además
facilita el cambio de requerimiento en caso de ser necesario; se identifican las siguientes ventajas [16]:

 El valor de las historias tanto para el cliente como para los usuarios es claro.
 Son negociables entre el usuario y el cliente, esto evita que a futuro sean cambiados los requerimientos.

Debido a esto se creó una plantilla en “UserStories.xlsx” en la cual se relacionan los casos de uso con las “User
Stories” identificadas en esta misma planilla, permite el ingreso de versión, tiempo, estimación de esfuerzo,
criterios para aceptación, complejidad, razones para rechazo de cada “User Story” para que de esta manera se
pueda tener información relevante para las diferentes áreas del equipo y se puedan tomar decisiones sobre
desempeño, calendarización y tiempos necesarios para el desarrollo de cada requerimiento.

Luego de la identificación de requerimientos se debe especificar y clasificar cada “User Story” de modo que
como se mencionó anteriormente se pueda tener mayor información para la toma de decisiones.

6
La Magia de las Palabras

22
El siguiente paso, es la Verificación y Validación de cada “UserStory” a cargo del analista de requerimientos el
cual se basa en una planilla perteneciente al anexo “UserStories.xlsx” / ValVer” el cual se explicara en detalle
en la sección “Sección 5. Proceso de Verificación”.

El proceso se compone de criterios los cuales identificarán si una “User Story” está bien definida y especificada,
de no ser así esta se devuelve al ing. de requerimientos para revisar cual criterio no se cumplió. De ser necesario
se cambia el requerimiento, sino se procede a mejorarlo. De lo contrario si pasa los criterios, estos serán
mostrados al Pedagogo para que cerciore que cumple con lo estipulado en los requerimientos.

Luego de la aceptación se pasa a la priorización proceso que se detalla en la sección “Sección 4.2 Mecanismos
de Priorización y Trazabilidad”.

Una vez realizada la priorización se debe hacer un análisis y revisión de la priorización y de no ser correcta
mejorarla para ser pasada al arquitecto, el cual se encargará del proceso de trazabilidad mostrado en la sección
“Sección 4.2 Mecanismos de Priorización y Trazabilidad”.

4.2 Mecanismos de Priorización y Trazabilidad

4.2.1 Mecanismos de Priorización

Los mecanismos de priorización hechos para la aplicación MDP están basados en 4 aspectos
fundamentales para el proceso e impacto de desarrollo de la aplicación.

Para la priorización de requerimientos se tomaran 4 aspectos fundamentales [17]:

 Beneficio: Beneficio o utilidad que obtiene el producto de Software con la implementación de ese
requerimiento.
 Penalidad: En el caso que este requerimiento no sea implementado que tanto afecta al desarrollo del
producto.
 Costo: Tiempo y costo que implica el desarrollo e implementación de un requerimiento en específico.
 Riesgo: Probabilidad que al ser implantado este riesgo falle en momento de ejecución del programa.

Cada uno de los aspectos anteriores puede ser calificado de 0 a 9, donde 0 es la menor calificación y 9 es la
mayor; en otras palabras cada uno de los requerimientos levantados será calificado de 0 a 9 en cada uno de los
aspectos anteriores. El peso relativo de cada uno de los ítems anteriores es fundamental para la priorización de
los requerimientos, donde el Beneficio tiene un peso relativo de 2 puntos, es decir es el aspecto fundamental
para la implementación de un requerimientos, por otro lado la Penalidad y el Costo Relativo tiene un valor de 1
punto, mientras que por otro lado el Riesgo Relativo tiene un valor de 0.5 [17].

23
Dados los 4 aspectos fundamentales para la priorización de un requerimiento, de pude se puede determinar la
priorización de un requerimiento con la siguiente formula:

𝑉𝑎𝑙𝑜𝑟 %
𝑃𝑟𝑖𝑜𝑟𝑖𝑧𝑎𝑐𝑖𝑜𝑛 =
(% 𝐶𝑜𝑠𝑡𝑜 ∗ 𝑃𝑒𝑠𝑜 𝑑𝑒 𝑐𝑜𝑠𝑡𝑜 + % 𝑅𝑖𝑒𝑠𝑔𝑜 ∗ 𝑃𝑒𝑠𝑜 𝑑𝑒 𝑟𝑖𝑒𝑠𝑔𝑜)

En el Anexo “UserStories.xlsx” se encuentra cada uno de los requerimientos debidamente priorizado.

4.2.1 Mecanismos de Trazabilidad

La Trazabilidad de un requerimiento se entiende como la capacidad de rastrear un requerimiento

horizontalmente y verticalmente desde el levantamiento de este, hasta la implementación y ejecución en el
producto de software, [18].

Trazabilidad vertical es el proceso por el cual se puede conocer un requerimiento desde su levantamiento hasta
su implementación. El proceso realizado para la aplicación MDP desde el levantamiento de sus requerimientos
como User Stories, parte de la premisa que estos derivan directamente de los casos de uso. De esta manera se
puede realizar la trazabilidad con respecto a los casos de uso correspondiente a cada requerimiento para mayor
consistencia. Así mismo se puede observar la relación de estos casos de uso con los componentes del sistema
mismo, esto se puede observar en el Anexo “UserStories.xlsx”

Trazabilidad Horizontal se entiende como la relación directa que tienen los requerimientos entre estos. Aquí se
incluye asociaciones y dependencias, esta especificación de relaciones se desarrolla en una matriz, donde se
relaciona uno a uno. De esta manera se determina directamente como debe ser la implementación de cada uno
de los requerimientos dado las dependencias. Para mayor información observar en el Anexo “UserStories.xlsx”

4.3 Construcción del SRS

Las buenas prácticas de software se enfocan en la existencia de un documento que explica de forma detallada
el proceso de desarrollo de software. Donde se conozcan los procesos adoptados por la pareja de ingenieros
Juan Pablo Montoya y Gabriel Hernando Fuentes durante la construcción de este documento, como base para
el entendimiento del desarrollo de la aplicación La Magia de las Palabras. Procesos tales como: administración
y control del desarrollo de requerimientos, procesos de verificación y validación, entre otros [19].

24
Para tener mejor conocimiento de estos procesos, los cuales sirven de apoyo para la construcción de este
proyecto de ingeniería. Puede observar estos procesos adoptados a lo largo de este documento. Véase 4.1
Procesos de Administración y Control de Requerimientos durante el desarrollo, 4.2 Mecanismos de
Priorización y Trazabilidad, 5 Proceso de Verificación. Por otra parte, la realización de este documento y los
procesos y características del proyecto de tesis, están basados en la plantilla IEEE Std 830-1993 [20].

Plantilla la cual formula contenido y prácticas básicas para la construcción para especificar los requerimientos
de software a ser desarrollados [21].

5 Proceso de Verificación

El proceso de Verificación es integrado en la ilustración de la sección “4.1 Administración y control de

requerimientos” como Verificación y Validación.

Para cada “User Story” se realizará una revisión de criterios a cargo del analista de requerimientos el cual se basa
en una planilla perteneciente al anexo “UserStories.xlsx” / ValVer” el cual tiene los siguientes criterios [22]:

 No ambiguo:
o “¿Los requisitos se pueden leer e interpretar de distinta forma por personas diferentes?” [22].
 Realista:
o “¿Son los requisitos realistas, dada la tecnología que se utilizará para la implementación del
sistema?” [22].
 Comprobable:
o “¿Se pueden comprobar los requisitos? Es decir, ¿los testers pueden diseñar pruebas que
permitan mostrar que el sistema cumple con los requisitos?” [22].
 Combinado:
o “¿La descripción de los requisitos incluye requisitos únicos o pueden ser divididos en varios
requisitos?” [22].
 Necesario:
o “¿Hay requisitos como agregados “cosméticos” para el sistema, los cuales no son realmente
necesarios?” [22].
 Identificado de forma única:
o “¿Los requisitos son plenamente identificables unos de otros?” [22].
 Rastreable:
o “¿Los requisitos pueden seguirse a través de las fases de desarrollo del sistema?” [22]
 Verificable:
o ¿Los requerimientos los puedo probar?
 Comprensible:
o ¿Son claros los requerimientos para las partes interesadas?
 Consistente:
o ¿Los requerimientos están de acorde al alcance y definición de casos de uso?
 Completo:
o ¿Los requerimientos tienen todo lo necesario para empezar el diseño y construcción?

Gracias a estos criterios se podrá saber si una “User Story” está bien definida y especificada, de no ser así esta
se devuelve al rol responsable. El cual se encarga de revisar cual criterio no se cumplió y procede a mejorarlo.

25
De lo contrario si pasa los criterios esto será enviado al Arquitecto quien se encargará de decidir si es aceptada
o no dicha “User Story”.

A continuación se muestra el BPMN del proceso de Verificación:

Ilustración 4 Proceso de Verificación

26