Requisitos del Software Aplicativo Móvil SISTEMAS INTELIGENTES EN RED S.A.S.

Transcripción

1 Requisitos del Software Aplicativo Móvil SISTEMAS INTELIGENTES EN RED S.A.S.

2 Desarrollo de Aplicativo Móvil 2 Índice 1. INTRODUCCIÓN OBJETIVO MÓDULO MENSAJERÍA Actores Requisitos Funcionales Requisitos No Funcionales (Calidad) REQUISITOS MÓDULO REPORTE Actores Requisitos Funcionales Requisitos No Funcionales (Calidad) GLOSARIO... 10

3 Desarrollo de Aplicativo Móvil 3 1. INTRODUCCIÓN En el año 2011, XM Gestión Inteligente De Sistemas De Tiempo Real, comenzó con la operación El centro de control de tránsito de Medellín. Dentro de sus objetivos del 2015, se encuentra la elaboración de un aplicativo móvil que potencie las capacidades de su gestión. 2. OBJETIVO Implementar un aplicativo móvil, incluyendo el diseño y ejecución. 3. MÓDULO MENSAJERÍA Alcance: El objetivo es recibir información desde una central para la toma de decisiones Actores Receptor: El receptor es el usuario que descarga e instala la aplicación en su dispositivo móvil, es el cliente de la información. Emisor: El emisor es el encargado de administrar los mensajes para el receptor pueda informarse. Administrador: El administrador es el encargado de verificar que los procesos se estén llevando correctamente y tendrá todos los permisos para el manejo de la aplicación. Sistema: Es el encargado de hacer los cálculos necesarios para que la aplicación logre lo planeado Requisitos Funcionales Receptor RF_001 El receptor deberá aceptar los términos de uso de la aplicación la primera vez que abra la aplicación. Es con el fin de recolectar información y se acepten los términos de uno de la aplicación. Id del teléfono. Que sea práctico con los parámetros de registro Número de celular, habilitar GPS, acceso a datos. Se podrá

4 Desarrollo de Aplicativo Móvil 4 registrar con sus datos de perfil de otras cuentas como por ejemplo Facebook o Google. RF_002 RF_003 El receptor deberá poder leer el mensaje en la pantalla. El receptor deberá poder iniciar y cerrar su sesión. RF_004 El receptor deberá poder reportar si el mensaje es erróneo e indicar justificación opcional. Con el fin de que la aplicación sea más eficiente gracias a la interacción de los usuarios. RF_005 El receptor deberá poder consultar los mensajes activos con su respectiva dirección. RF_006 RF_007 RF_008 RF_009 usuarios. El receptor deberá poder consultar sus mensajes recibidos. El receptor deberá poder calificar el mensaje, como positivo o negativo. El receptor deberá poder escribir un comentario del mensaje. El receptor deberá poder consultar las calificaciones recibidas por otros RF_010 El receptor deberá poder consultar los comentarios y calificaciones de otros grupos usuarios sobre el mensaje. RF_011 El receptor deberá poder compartir el mensaje en sus redes sociales u otras aplicaciones de su dispositivo móvil. RF_012 El receptor deberá poder escuchar el mensaje. RF_013 El receptor deberá poder leer la cantidad de usuarios que han recibido el mensaje, y la cantidad que lo ha calificado como positivo o negativo. RF_014 El receptor deberá poder leer la fecha y hora y hace cuantos minutos fue publicado. Emisor RF_015 El Emisor deberá poder gestionar (Crear, Modificar, Eliminar) un mensaje. RF_016 El Emisor deberá poder crear un mensaje seleccionando de una lista de mensajes predefinidos. RF_017 El Emisor deberá poder crear un mensaje escribiendo su contenido. RF_018 El Emisor deberá poder seleccionar un mensaje de una lista predefinida. RF_019 El Emisor deberá poder seleccionar o adjuntar una imagen. RF_020 El Emisor deberá poder editar manualmente una sección en un mapa. RF_021 El Emisor podrá interactuar con un sistema geográfico para la gestión de mensajes.

5 Desarrollo de Aplicativo Móvil 5 RF_022 El Emisor deberá poder consultar los mensajes enviados, recibidos confirmados y reportados como erróneos por los receptores. RF_023 El Emisor deberá poder consultar una lista con todos los paneles virtuales activos. RF_024 El Emisor deberá poder reenviar el mensaje a una red social definida por el administrador. Administrador RF_025 El administrador deberá poder editar un algoritmo de cálculo de redes de influencia tipo grafo en un mapa georreferenciado. RF_026 El administrador deberá poder gestionar (Crear, Modificar, Eliminar) una red georeferenciada tipo grafo. RF_027 El administrador deberá poder consultar cuantos mensajes fueron enviados (de Emisor a Receptor) y cuántos de ellos fueron recibidos (de Receptor a Emisor). RF_028 El administrador deberá poder administrar los usuarios, roles, permisos, contraseñas. RF_029 El administrador deberá poder administrar el sistema desde una base de datos mínimo SQL. Sistema RF_030 La interfaz del Receptor deberá poder ofrecer la opción de confirmar la recepción del mensaje. RF_031 La interfaz del Emisor deberá ser un mapa interactivo georreferenciado. RF_032 La interfaz del Emisor deberá permitirle posicionar un mensaje sobre una red geográfica tipo grafo. RF_033 Para el registro del Receptor se deberá poder desplegar un formulario con campos obligatorios como: número de celular y aceptación de términos y condiciones para el registro. RF_034 El sistema debe poder calcular automáticamente una red de influencia dados unos parámetros en un grafo. RF_035 El sistema debe permitir que la aplicación quede en modo running in background (Ver Glosario. Glosario Running in background). RF_036 El sistema debe poder preguntar al momento de abrir la aplicación si desea encender el GPS. Si no lo desea no podrá hacer uso de la aplicación.

6 Desarrollo de Aplicativo Móvil 6 RF_037 El sistema debe poder recibir todos los mensajes publicados por el Emisor y seleccionar cuál mensaje enviar al Receptor dependiendo de un análisis geográfico parametrizable. Estos mensajes se repetirán cada cierto periodo de tiempo a los usuarios situados en la ruta de influencia y que no hayan confirmado la recepción del mensaje. RF_038 El sistema debe poder reportar los mensajes enviados (de Emisor a Receptor) y los confirmados como recibidos (de Receptor a emisor). RF_039 El sistema debe poder reproducir el mensaje de texto en voz humana sin opción de ser desactivado. RF_040 RF_041 actores. El sistema de voz debe ser en idioma español estándar. El sistema deberá generar los informes solicitados por cada uno de los RF_042 El sistema debe tener un archivo.log que indique las acciones del sistema para identificar causas de problemas y que queden almacenadas en la base de datos. RF_043 La interfaz del Emisor debe revisar la ortografía de los mensajes antes de su publicación, alertar al Emisor sobre los errores ortográficos y sugerir la palabra bien escrita, en los casos que la palabra no la contenga el diccionario, esta podrá ser agregada por el Emisor. RF_044 El sistema enviará el mensaje a una red social definida tipo grafo. RF_045 El sistema debe tener un módulo para interactuar con otro software a través de un sistema estándar de conectividad entre software. RF_046 El sistema debe contar con esquema de administración de roles y permisos por tipos de usuario. RF_047 La aplicación móvil deberá registrar de forma centralizada los datos del Receptor, ya sea por evento o tiempo. RF_048 El sistema deberá notificar al Emisor cuando un mensaje sobrepase el tiempo promedio establecido Requisitos No Funcionales (Calidad) Los requisitos no funcionales de este módulo son los mismos que los del módulo de gestión de solicitudes.

7 Desarrollo de Aplicativo Móvil 7 4. REQUISITOS MÓDULO REPORTE 4.1. Actores Receptor: El Receptor es el usuario que descarga e instala la aplicación en su dispositivo móvil y hace uso del módulo de reporte. Administrador: El administrador es el encargado de verificar que los procesos se estén llevando correctamente y tendrá todos los permisos para el manejo de la aplicación. Sistema: Es el encargado de direccionar las peticiones del cliente al sistema y así el proceso de solicitud se lleve de forma correcta Requisitos Funcionales Receptor RF_001 El Receptor debe poder crear una solicitud de servicio por medio de su dispositivo móvil. RF_002 El Receptor debe poder consultar el estado del recurso y el tiempo aproximado atención del servicio. RF_003 El Receptor debe poder cancelar o editar la solicitud de servicio. Administrador RF_004 El administrador podrá administrar la información. Sistema RF_005 El sistema debe poder desplegar un formulario para que el Receptor registre la solicitud. RF_006 El sistema debe poder conocer la ubicación del móvil, el número de celular, por medio del GPS para registrar una solicitud. RF_007 El sistema debe poder mostrar el estado del recurso y tiempo aproximado de llegada al sitio. RF_008 El sistema deberá interactuar de forma automática con un software externo para la gestión de solicitudes. Dicho software cuenta con un sistema de mensajería ActiveMQ, JMS en JAVA, como sistema de intercambio de mensajes y solicitudes.

8 Desarrollo de Aplicativo Móvil 8 RF_009 El sistema deberá permitir que si el Receptor cancela la solicitud de pedido preguntar cuál fue el motivo por el que lo cancelo Requisitos No Funcionales (Calidad) Los siguientes requisitos se aplican tanto para el módulo de gestión de paneles como el módulo de gestión de solicitudes. Rendimiento RNF_001 La aplicación debe poder lograr con éxito una prueba de rendimiento, o prueba de estrés con al menos 100,000 receptores. RNF_002 El sistema deberá ser de rápido rendimiento, máximo 1 segundo de tiempo de espera por cada acción. Disponibilidad RNF_003 La aplicación debe permitir un monitoreo de fallas dado que si se presentan las podrá ver el administrador. RNF_004 En caso de ocurrir fallas la aplicación debe cerrar la sesión a los usuarios activos y que vuelvan a activar la aplicación. RNF_005 La aplicación debe lograr con éxito una prueba de disponibilidad en el servidor para conocer las peticiones que se hacen en cada momento y así saber su correcto funcionamiento. RNF_006 La aplicación debe poder funcionar con el GPS o un servicio de ubicación similar en el móvil. RNF_007 La aplicación solo debe poder funcionar si el móvil dispone de una red de datos o conexión a internet y el cargo será asumido por el Receptor. Accesibilidad RNF_008 El sistema debe poder ser accesible desde el desde las oficinas administrativas de SISTEMAS INTELIGENTES EN RED S.A.S. para el administrador. RNF_009 El administrador debe poder asignar los permisos de los Emisores. RNF_010 Se debe poder operar y administrar la aplicación desde la extranet. Usabilidad RNF_011 El porcentaje de rebote debe ser inferior al 10%. Cantidad de usuarios que ingresas a la aplicación y se salen casi inmediatamente.

9 Desarrollo de Aplicativo Móvil 9 RNF_012 La tasa de conversión: El porcentaje de usuarios que permanezcan con la aplicación instalada debe ser superior al 50% del que la instalan. RNF_013 El tiempo de carga de la aplicación debe ser máximo 1 minuto en el 95% de los casos. RNF_014 El usuario no debe sentirse perdido, por lo que la aplicación debe contar con facilidades como el acceso a cada función con dos acciones (ejemplo, dos clics para acceder a cada función), y cada función debe ser accesible desde dos caminos (por ejemplo, ver mensajes activos debe tener mínimo dos botones de acceso en diferentes partes de la aplicación). RNF_015 Los botones deben ser grandes o de fácil lectura, máximo dos botones en el ancho o alto de la pantalla. RNF_016 El sistema deberá permitir que los usuarios se equivoquen y les permita repetir acciones fácilmente. Por ejemplo, al registrar un formulario, si falta alguna palabra, no borrar la palabras diligenciadas con anterioridad. RNF_017 El 80% de los usuarios deberá declararse conforme o muy conforme al preguntarle por la facilidad de uso de la herramienta. RNF_018 El 90% de los usuarios tienen que completar cada operación solamente con la información que proporciona el sistema. RNF_019 El 80% de las tareas de mantenimiento durante el primer año de mantenimiento, se deben a requerimientos de usuarios no previstos, quedando el resto debido a fallos y errores. RNF_020 El sistema deberá contar un asistente de operación o de ayuda que se ejecute automáticamente la primera vez que abra la aplicación, y se pueda volver a abrir nuevamente cuando el usuario lo solicite. RNF_021 El sistema debe poder mostrar al usuario el estado del sistema en operaciones como "descargando", "actualizando", "mensaje enviado", "mensaje recibido". RNF_022 El lenguaje del sistema debe poder ser definido previamente por consulta a los usuarios. (Coincidencia entre el sistema y el mundo real). RNF_023 El sistema debe poder soportar las funciones, deshacer y rehacer. RNF_024 El sistema deberá mostrar para dos funciones que realicen lo mismo, su misma palabra. (Estandarización). RNF_025 El sistema deberá al fallar la aplicación, mostrar la opción al usuario de cerrar o reiniciar. RNF_026 Cuando ocurra un error en el sistema, se deberá mostrar al usuario un mensaje definido y claro del motivo de cierre de la aplicación, no mostrar mensajes como error "024", sino, error "024: el sistema no encuentra conexión a internet". RNF_027 Cada usuario o actor, podrá acceder desde su aplicación a un manual de uso con un ambiente amigable.

10 Desarrollo de Aplicativo Móvil 10 RNF_028 La aplicación debe funcionar para Android, Iphone y Windows phone. RNF_029 La aplicación debe funcionar en las últimas las versiones de Android, Iphone y Windows pone. Dependiendo de los costos. RNF_030 El diseño gráfico de la aplicación debe ser minimalista y agradable para el 80% de los usuarios. Concurrencia RNF_031 El sistema deberá poder soportar mínimamente la cantidad de usuarios de receptores de forma simultánea. Mantenibilidad RNF_032 - Debe incluir manual de mantenimiento y capacitación para mantenimiento. Confiabilidad RNF_033 RNF_034 El sistema debe funcionar correctamente un 99,5% de tiempo. En un mes debe presentar máximo 10 fallas. RNF_035 La capacidad del sistema, sin perder su rendimiento debe ser para 50 Emisores, 5 administradores y 100,000 Receptores operando de forma simultánea. RNF_036 Debe ser escalable para mayor cantidad de Receptores sin perder su rendimiento, el escalamiento debe ser fácilmente, configurable por el administrador, sin pérdida de rendimiento de la aplicación. Seguridad, con el celular y con la aplicación del Emisor servidor. RNF_037 El sistema deberá contar con esquemas de seguridad que garanticen seguridad en los datos. 5. GLOSARIO Ruta de influencia: Son los elementos de una vía que se ven afectadas como: Calzada, sentido y orientación por un solicitud en un punto determinado. Running in background: Es un proceso informático que se ejecuta en segundo plano o "detrás de escena" (es decir, en el fondo del móvil) y sin intervención del usuario. Grafo: Es un conjunto de objetos llamados vértices o nodos unidos por enlaces llamados aristas o arcos, que permiten representar relaciones binarias entre elementos de un conjunto. Típicamente, un grafo se representa gráficamente como un conjunto de puntos (vértices o nodos) unidos por líneas (aristas).