Requerimientos Ususario BUZZ

DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS DE USUARIO

Nombre del proyecto: Buzz

Organización: TRANSIT UC

Fecha: 20-06-2013

Versión: 1.3

Pontificia Universidad católica de Chile

Escuela de Ingeniería

Departamento de Ciencia de la Computación

Tabla de contenidosi. Historia del Documento........................................2

ii. Equipo de Desarrollo.........................................3ii. Contraparte del Proyecto.....................................3

1. Introducción..................................................41.1 Propósito del Sistema.......................................4

1.2 Alcance del Proyecto........................................41.3 Contexto....................................................5

1.4 Definiciones, Acrónimos y Abreviaturas.....................62. Descripción general...........................................7

2.1 Características de los usuarios.............................72.2 Perspectivas del producto según los usuarios / clientes.....8

2.3 Ambiente operacional de la solución.........................82.4 Descripción del modelo......................................9

2.4.1 Procesos de negocio.....................................92.4.2 Modelos de casos de uso.................................9

2.5 Requisitos del sistema.....................................162.5.1 Requisitos funcionales.................................16

2.5.2 Requisitos no funcionales..............................252.6 Matriz de trazado de casos de usos vs requisitos funcionales...............................................................33

i. Historia del Documento

Versión

Fecha Autor(es) Razón del Cambio

0.1 12/04/2013

Sergio Molina Primer borrador.

0.2 17/04/2013

Sergio Molina Avance Introducción.

0.3 21/04/2013

Sergio Molina Descripción General.

0.4 23/04/2013

Sergio Molina Requisitos Funcionales y nofuncionales.

0.5 24/04/2013

Sergio Molina Diagramas UML y Proceso denegocio para incluir.

0.6 30/04/2013

Sergio Molina Ajustes en Introducción yDescripción debido a reunión concliente 30/04/2013.

0.7 01/05/2013

Sergio Molina Matriz de trazado CU y RF.

0.75 01/05/2013

ConstanzaGómez

Actualización tablas datosequipo y contraparte

0.8 01/05/2013

Juan JaimeDíaz

Ambiente Operacional añadido adocumento.

1.0 01/05/2013

Sergio Molina Revisión y corrección deerrores.

1.1 02/05/2013

ConstanzaGómez

Revisión y corrección deerrores.

1.2 21/05/2013

AlexValenzuela

Revisión y corrección deerrores.

1.3 30/05/2013

Sergio Molina Actualización RequisitosFuncionales y Matriz de trazado.

ii. Equipo de Desarrollo

Nombres yApellidos

Rol Contacto

Alex Valenzuela Administrador delProyecto

[email protected](56 9) 8838-5581

Nicolás Lioi Analista [email protected](56 9) 9220-0832

Sergio Molina Analista/Tester [email protected](56 9) 7648-1571

Constanza Gómez Diseñador/Implementador [email protected](56 9) 8232-6179

Juan Pablo Hurtado Diseñador [email protected](56 9) 8229-1560

Juan Jaime Díaz Implementador [email protected]

mailto:[email protected]






(56 9) 8571-6038Cristóbal Lama Implementador [email protected]

(56 9) 8888-8125Diego Moncada Implementador/Tester [email protected]

(56 9) 9693-0734Luis Hernán Paul Implementador [email protected]

(56 9) 7398-1015

ii. Contraparte del Proyecto

Nombres yApellidos

Rol Contacto

Juan Carlos Muñoz Director [email protected]

Felipe Delgado Director [email protected]

Ricardo Giesen Director [email protected]

Pedro Lizana CEO [email protected](56 9) 8136-6211

Felipe Balbontin CTO [email protected]

Tomás Arriagada CFO [email protected](56 9)8464-3639

1. Introducción

El proyecto consiste en desarrollar una aplicación Androidpara la organización TransitUC. La función principal de laaplicación consiste en entregar al usuario la posibilidad devisualizar los buses del Transantiago en su ubicación actual en unmapa. Además, contiene herramientas adicionales como los tiempos










estimados de los recorridos en cualquier paradero, la opción deconsultar rutas, ver el saldo de la tarjeta Bip! y añadirparaderos o rutas a favoritos, entre otras.

En este documento se detallan los casos de uso, los requisitosfuncionales analizados de la solicitud del cliente y losrequisitos no funcionales detectados por el equipo.

1.1 Propósito del Sistema

Buzz es una aplicación que funciona bajo el sistema operativoAndroid capaz de proporcionar al usuario habitual del Transantiago(usuario pasajero) información del sistema en “tiempo real”. Estainformación la posición de los buses en un mapa, la estimación detiempos de llegada a un paradero, consultas de rutas y saldo Bip!.La aplicación desplegará datos de los paraderos así como tambiénlos recorridos que pasan por ellos.

El sistema también debe mostrar todos los paraderos delTransantiago y los de los puntos de recarga Bip!!. Otro propósitodel sistema es sugerir rutas e indicar con una alerta el arribo alpróximo paradero de bajada. Lo que se busca con este proyecto esrealizar una aplicación distinta a las existentes, otorgandomejores tiempos de estimación con respecto a lo que entrega elgobierno y mejorando la experiencia de usuario.

1.2 Alcance del Proyecto.

Actualmente el cliente cuenta con los datos del GPS de doslíneas del Transantiago, por tanto el proyecto apunta a que lasestimaciones de los tiempos de llegada de los busescorrespondientes a esas líneas sean mejores que los proporcionadospor el gobierno, así como también la visualización de los buses enel mapa sea un hecho concreto y confiable en cuanto a la calidadde su posición. La aplicación debiese mostrar las rutas que deseanser visualizadas por el usuario, los buses en ella y los tiemposestimados de los buses para llegar a su siguiente paradero.También debe ser capaz de alertar con antelación al usuario con

respecto a su llegada a su paradero destino. Además, el usuariopodrá visualizar su saldo Bip!. Por último, tendrá la capacidad deguardar paraderos, rutas y búsquedas recientes aparte de poderagregar aquellos objetos a una lista de favoritos.

1.2 Contexto

El Transantiago fue implementado a fines de 2006 y fue un grancambio al sistema de transporte público, ya que los recorridos yla forma de pago cambiaron totalmente. Esto motivó a que serealizaran cambios de manera constante, con tal de mejorar elsistema. Hoy en día todos los buses cuentan con sistema de GPS loque permite controlar su recorrido, sin embargo la frecuencia deactualización es bastante baja, por lo que todavía ocurrenfenómenos no deseados, como por ejemplo, el de “tren” (en quemuchos buses del mismo recorrido se juntan).

Se detectó que si se hace esperar un minuto a un bus que está apunto de alcanzar a su sucesor, se elimina el indeseado efecto de“tren”. Gracias a la implementación de un nuevo sistema de GPS(con frecuencia de actualización más rápida) de dos líneas delTransantiago y algoritmos proporcionados por el cliente, selogran estimar mejores tiempos de llegada por bus.

Se desarrollará el proyecto en la ciudad de Santiago de Chile,se sabe que solo por mensajería de texto se realizan sobre 160.000consultas diarias al servidor de Transantiago para conocer lostiempos de llegada de los buses al paradero.

El cliente se compromete a tener una API que nos permitiráobtener los datos necesarios para localizar un bus, paradero opunto Bip!. Por tanto, se desarrollará un servidor que secomunique con esta API y almacene temporalmente los datos másreciente que sean útiles para realizar los cálculos pertinentes.

Algunos de los datos serán descargados directamente delgobierno, por ejemplo, la información de los tiempos estimados queno pueda proporcionar el cliente, o las coordenadas de losparadores. Claramente algunos datos tendrán una frecuencia deactualización distinta (segundos para la ubicación de los buses,mensual para la actualización de la ubicación paraderos, o cambiosen los recorridos)

1.3 Definiciones, Acrónimos y Abreviaturas.

Android: es un sistema operativo basado en Linux, diseñadoprincipalmente para móviles con pantalla táctil como teléfonosinteligentes o tabletas inicialmente desarrollados por Android,Inc.

API: Aplicación o servicio (servicio web en algunos casos), cuyafinalidad es la recibir la consulta de un dato y entregar lainformación solicitada.

Gbno: Gobierno, se refiere al actual gobierno de la RepúblicaNacional de Chile. En el proyecto se recurre a los datos públicosque ofrece el gobierno con respecto al Transantiago.

GPS: Global Positioning System, es un sistema global de navegaciónpor satélite, que permite determinar en todo el mundo la posiciónde un objeto, una persona o un vehículo con una precisión hasta decentímetros (si se utiliza GPS diferencial), aunque lo habitualson unos pocos metros de precisión.

Paradero: Lugar físico en el cual el usuario del Transantiago debetomar el bus. En el sistema de Transantiago los buses solo sedetienen en los paraderos correspondientes a su recorrido.

Punto Recarga Bip!: Estación, lugar físico que ofrece el servicionecesario para recargar la tarjeta Bip!, de modo de aumentar elsaldo.

Recorrido: Se refiere a una línea de buses del Transantiago, porejemplo, el recorrido 210 que va desde Estación Central a PuenteAlto.

Ruta: Es una colección de direcciones y significa un camino con unorigen y un destino, la ruta puede estar compuesta por hitos queson transbordos a otro recorrido o estación de metro delTransantiago.

Saldo Bip!: Corresponde al valor almacenado en la tarjeta Bip!,que es el instrumento de pago de pasaje en el Transantiago.

SmarthPhone: Teléfono Inteligente, en este caso se refiere a undispositivo de comunicación móvil inteligente que posee sistemaoperativo Android.

Transantiago: es un sistema de transporte urbano que opera en elárea metropolitana de la ciudad de Santiago, cAPItal de Chile.

Usuario (Usuario pasajero): Es el usuario final de la aplicación,por consiguiente es el pasajero que utiliza el sistema públicoTransantiago.

2. Descripción general

Los usuarios serán pasajeros frecuentes del Transantiago.Estos tienen la necesidad de saber la posición física en que seencuentra el bus que deben tomar, para así planificar su llegadaal paradero. Los principales requerimientos serán visualizar losbuses en el mapa, conocer los tiempos de llegada de un bus a unparadero, visualizar los paraderos en el mapa, agregar susconsultas frecuentes a favoritos y consultar rutas, entre otros.Todo esto lo harán por medio de la pantalla táctil de susmarthphone por lo que la interfaz debe ser intuitiva y fácil deusar. También se le debe dar el feedback necesario de la carga dedatos y su respectiva actualización, los tiempos de operacióndeben ser lo suficientemente ágiles para que el usuario noconsidere que se encuentre frente a una aplicación lenta.

2.1 Características de los usuarios

Tipo deUsuario

Descripción Cantidad UsuariosContactablesActua

lFuturo

UsuarioPasajero

Persona que semoviliza en elTransantiago deforma frecuente.

10 40.000

Por definir.

Administrador

Persona que seencarga de asegurarque la aplicaciónse mantenga en unfuncionamientoestable, suactualización ymantenibilidad.

6 2 Por definir

2.2 Perspectivas del producto según los usuarios /clientes

El usuario espera una aplicación similar a las existentes hoyen día, como por ejemplo, “¿cuánto falta?”, “itransantiago” o“paraderos Transantiago”, entre otras. La diferencia está en queBuzz podrá mostrar en el mapa la posición actual de los buses.

El cliente también espera que debe ser una aplicación simple,usable y tenga la principal ventaja de mostrar la información entiempo real y poder planificar con ella. También alertar lallegada al paradero y por último mostrar la carga de demanda porbus.

2.3 Ambiente operacional de la solución

La aplicación que actúa de puente entre la API del cliente ynuestra aplicación móvil se encuentra alojada temporalmente en laplataforma de aplicaciones en la nube Heroku, pero luego serátrasladada a Amazon. Esta actúa a su vez como API, respondiendo alas funcionalidades de la aplicación.

Por el momento, el plan de la cuenta que almacena laaplicación es el básico, el cual no tiene costo. Por ello, tieneuna serie de limitaciones: - Las tablas de las bases de datos tiene un límite de 10.000filas por tabla. - Al no tener una tarjeta de crédito asociada, no se nospermite el acceso a las tareas programadas (cron jobs). - 20 conexiones máximo a la base de datos.

El servidor nos ofrece una base de datos PostgreSQL básica(Heroku no comparte información de sus servidores más allá deinformar que utiliza el sistema operativo Ubuntu, al cual migraronrecientemente) que, como ya fue comentado, tiene un límite defilas para tablas.

Al actuar como API, no tiene requerimientos particulares conrespecto al cliente (además de una conexión a internet y algúnsistema para poder trabajar con JSON), puesto que siempre respondecon un objeto JSON el cual contiene los datos requeridos.

2.4 Descripción del modelo

2.4.1 Procesos de negocio

Mostrar Buses en el mapa: El proceso de negocio básicamenteconsiste en los requerimientos del cliente. En el siguiente modelose expone el proceso principal que consiste en mostrar los busesen el mapa, pero no se detallan procesos secundarios como laconsulta al saldo. Bip! o los objetos agregados a favoritos.

2.4.2 Modelo de casos de uso

A continuación se presenta el diagrama UML de casos de usoque describe la interacción del Usuario con la aplicación móvil.Se utilizó la relación de <<extend>> para describir el caso de usode Buscar Paradero, ya que los casos de uso de Buscar por código,

Buscar por dirección y Buscar por puntos de interés son unaextensión de la búsqueda y utilizan los mismos mecanismos base.

2.4.2.1 Descripción de los Casos de Uso

Nombre Abrir AplicaciónIdentificador CU1001Actores Usuarios

Sinopsis Este caso de uso comienza cuando el usuario abre laaplicación, mostrando el menú principal, que eneste caso es el mapa con una barra de opciones enla parte superior.

Restricciones En caso de que sea la primera vez que el usuarioejecuta la aplicación, ésta abrirá una interfaz quepermitirá ingresar la información de la tarjetaBip! del usuario.

Nombre Ver Buses en el MapaIdentificador CU1002Actores AplicaciónSinopsis Este caso de uso comienza cuando el usuario

solicita la información sobre una micro de un respectivo paradero, o cuando buscael recorrido mediante el buscador. Ver posición de los Buses: Se despliega un mapa con los

buses de un recorrido específico con los datosque responde el servidor.

Restricciones Sólo se deben mostrar los 2 buses más cercanos alusuario en caso de que haya hecho la consulta desdeun paradero.En caso de que el usuario haya hecho la consultamediante el buscador, se deben mostrar todos losbuses que se encuentren en el zoom del mapa quetiene el usuario.

Nombre Actualizar Posición de Buses en el MapaIdentificador CU1003Actores Usuarios y AplicaciónSinopsis Este caso de uso se aplica cuando el usuario se

encuentra en la sección del mapa que contiene laposición de los buses de un recorrido. Actualizar Posiciones: Se vuelve a consultar la

posición de los buses y se actualizan en elmapa. Esta actualización es gatillada por laaplicación misma cada 3 segundos.

Mostrar tiempo transcurrido desde la última actualización.Restricciones Debe existir conexión a internet para hacer

efectiva la actualización.

Nombre Buscar ParaderosIdentificador CU1004Actores UsuariosSinopsis Este caso de uso comienza después de que el usuario

abre la aplicación y escoge la opción Paraderos enel menú principal. Seleccionar Paradero: Se despliega un mapa con los

paraderos en un radio cercano, con los datos queresponde el servidor con respecto a la ubicaciónactual, el usuario puede seleccionar cualquierapara ver el detalle.

Buscar por código: En el menú se puede seleccionaresta opción, en la cual se debe ingresar uncódigo de paradero válido.

Buscar por Dirección: En el menú se puede seleccionaresta opción, en la cual el usuario debe ingresaruna dirección de destino válida.

Buscar por punto de interés: En el menú se puedeseleccionar esta opción, en la cual se debeingresar el nombre de un punto de interés. Estepunto será encontrado mediante la conexión a unaAPI especial para eso.

Hacer consulta: Tras seleccionar algún paradero enel mapa o consultar por código, se envían losdatos de consulta al servidor, el cual respondecon los datos de los tiempos estimados de cadarecorrido del respectivo paradero.

Restricciones El código a ser ingresado debe ser válido, de locontrario se debe alertar. Es posible tener el GPSdesactivado para realizar esta opción. Se debetener el GPS encendido para obtener los paraderosmás cercanos.

Nombre Consultar Micro

Identificador CU1005Actores UsuariosSinopsis Este caso de uso comienza una vez que el usuario

busca un recorrido en el buscador, o después deseleccionar un recorrido en el detalle de algúnparadero. Los escenarios del caso son lossiguientes: Ingresar recorrido: El usuario ingresa el número del

recorrido a buscar en la aplicación. Consultar datos: Al hacer la consulta se envía el

código del recorrido al servido, el cual retornala posición de las micros, y el tiempo estimadoa los paraderos más cercanos de donde se realizóla consulta.

Mostrar recorridos: Se muestran las micros en el mapaprincipal, junto con el tiempo de llegada a losparaderos más cercanos y la ruta respectiva.

Restricciones El recorrido consultado debe tener formato correctoy debe ser válido.El GPS no es necesario para este caso.

Nombre Marcar recorrido o paradero como favoritoIdentificador CU1007Actores UsuariosSinopsis Este caso de uso comienza una vez que el usuario se

encuentra en la interfaz que le permite establecerun recorrido o elegir un paradero en especial.Escenarios: Paraderos: La aplicación, luego de seleccionar la

opción “Paraderos” y haber seleccionado uno enparticular en la interfaz correspondiente, semostrará el botón que permitirá guardar dichaelección en una lista especial “favoritos”, paratener acceso rápido posteriormente.

Recorrido: Al igual que en el caso anterior, luegode haber utilizado el buscador para encontrar unrecorrido (ej: 216) y haber seleccionado un busen el mapa, se mostrará el botón que permitirá

guardar dicho recorrido en una lista especial“favoritos”, para tener acceso rápidoposteriormente. Se marcarán todos los buses deese recorrido como favoritos.

Restricciones En ambos casos tiene que haber un paradero o unaruta seleccionada para contar con la opción deguardar en favoritos

Nombre Ver Búsquedas recientes.Identificador CU1008Actores UsuariosSinopsis Este caso de uso se puede modelar como una

extensión de otros casos de uso, tales como: buscarpunto de carga bip, consultar saldo, buscar rutas,buscar paraderos y buscar micros.El escenario de este caso de uso básicamente esque, al momento en que el usuario se encuentre enuna interfaz en la cual tenga que ingresar algúninput el sistema, automáticamente se mostrarán enla misma interfaz los input que el mismo haingresado en algún momento anterior. Por ejemplo, si el usuario se encuentra en el menúpara consultar saldo y selecciona la opción“ingresar código”, el sistema automáticamente lemostrará como una lista descendiente todos losinput que ha ingresado últimamente en esa parte.

Restricciones Para que aparezcan las búsquedas recientes tienenque haber sido efectuadas. Si el usuario ingresapor primera vez a un módulo no habrá ningún tipo deinformación anterior almacenada.

Nombre Mostrar puntos de recarga Bip!Identificador CU1009

Actores UsuariosSinopsis Este caso de uso muestra en el mapa todos los

puntos de recarga Bip! cuando la opción de “Puntosde recarga Bip!” está seleccionada desde el menú decapas, y desactiva la visualización de los puntosde recarga Bip! en el mapa, cuando la opción de“Puntos de recarga Bip!” es deseleccionada desde elmenú de capas.

Restricciones La información ingresada por el usuario debe serválida y para que se pueda efectuar de maneracorrecta el caso de uso el usuario debe contar conconexión a internet.

Nombre Consultar SaldoIdentificador CU1010Actores UsuariosSinopsis Este caso de uso comienza una vez que el usuario

elige la opción "Consultar Saldo" en la barrasuperior. Los escenarios del caso son lossiguientes: Mostrar Saldo: Mostrar en pantalla el valor

obtenido. Ingresar Tarjeta Bip: El usuario ingresa una tarjeta

para ser almacenada en la aplicación y luegopoder consultar saldo

Restricciones En caso de que el usuario no haya ingresado lainformación de su tarjeta Bip! anteriormente, laaplicación le solicitará que ingrese un númeroválido de tarjeta Bip! (del largo adecuado, sólonúmeros y con el formato correcto).

Nombre Consultar RutaIdentificador CU1011Actores UsuarioSinopsis Este caso de uso comienza cuando el usuario

selecciona la opción “Rutas” en el menú principal.El único escenario del caso es el siguiente: Ruta: Se calculan distintas opciones para llegar

al destino ingresado, desde la posición deorigen ingresada. Estas se despliegan en un

menú donde el usuario selecciona la ruta aseguir. Una vez seleccionada una ruta esta sedespliega en el mapa.

Restricciones Se debe ingresar una dirección valida de Santiago,una intersección de dos calles válida o un punto deinterés.

2.5 Requisitos del sistema

2.5.1 Requisitos funcionales

Atributo DescripciónIdentificador RU1001Nombre Mostrar buses en el mapaDescripción Debe ser posible visualizar en un mapa la posición

de los buses que el usuario seleccione junto con surecorrido.

Entradas El código del el recorrido y del paradero de donde se quiere revisar.

Reglas de Negocio

- No debe ser posible mostrar la posición de losbuses ni los recorridos si el dispositivo notiene acceso a internet.

Prioridad AltaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario Pasajero

Iteración 2Caso de Prueba

PR1001

Estado Cumple

Atributo DescripciónIdentificador RU1002Nombre Obtener posición actual GPSDescripción La aplicación debe permitir al usuario obtener su

posición GPS actual, mostrándola en el mapa en pantalla.

Entradas -Reglas de Negocio

- No debe ser posible pedir la posición GPS si elmódulo GPS se encuentra apagado o sin señal.

- No debe ser posible pedir la posición GPS si nohay acceso a internet.


Usuario Pasajero


PR1002

Estado Cumple

Atributo DescripciónIdentificador

RU1003

Nombre Mostrar paraderos cercanos de acuerdo a un punto en el mapa

Descripción Tras seleccionar un punto o ubicación en el mapa, sevisualizan en él los paraderos cercanos a ese punto.

Entradas Coordenadas del punto o ubicación a revisar.Reglas de Negocio

- No deben aparecer paraderos si dentro del radiodel punto a buscar, no existen coordenadas deparaderos.

Prioridad AltaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuario Pasajero

UsuariosIteración 1Caso de Prueba

PR1003

Estado Cumple

Atributo DescripciónIdentificador RU1004Nombre Mostrar paraderos cercanos acuerdo a una dirección,

lugar o hito.Descripción El usuario ingresa un texto que contiene una

dirección o el nombre del lugar o hito, la cual se muestra en el mapa junto con los paraderos cercanos.

Entradas Dirección, Lugar o Sitio a buscar, radio de búsqueda.

Reglas de Negocio

- No debe ser posible obtener los datos de lascoordenadas a buscar teniendo los datos móvilesapagados.

- La dirección a buscar debe ser válida.- El lugar o Sitio a ser buscado debe existir en

la lista.- Mientras busca se deben desplegar las 7

búsquedas más recientesPrioridad MediaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario Pasajero


PR1003, PR1004, PR1005

Estado Cumple

Atributo DescripciónIdentificador RU1005Nombre Mostrar Recorridos de un paradero.Descripción El sistema debe ser capaz de mostrar todos

recorridos que pasan por un paradero previamente seleccionado.

Entradas El código del paradero.Reglas de Negocio

En caso de ser un paradero cuyos recorridos sean modificados de acuerdo al día o tramo horario, se mostrarán igual los buses que pasan por ahí pero con el mensaje “fuera de horario de cobertura” o algún mensaje similar.


Usuario Pasajero


PR1006

Estado Cumple

Atributo DescripciónIdentificador RU1006Nombre Tiempo restante para próximo busDescripción El sistema debe mostrar cuánto falta para que pase

un bus de cierto recorrido por un paradero determinado.

Entradas Los datos que se suministran son el paradero y el recorrido del cual se desea la información

Reglas de Negocio

- Se debe seleccionar el código de un paraderoválido

- Se debe seleccionar un recorrido válido, quepase por el paradero indicado.

- El tiempo debe ser estimado con máximo un minutode error

- El tiempo debe ser calculado correctamente conel algoritmo de estimación.

Prioridad AltaFuente Reunión Cliente 13.03.22Estabilidad Estable

Listado de Usuarios

Usuario Pasajero


RP1006

Estado Cumple

Atributo DescripciónIdentificador RU1009Nombre Mostrar rutas posibles para llegar desde un origen

a un destinoDescripción El sistema debe ser capaz de mostrar un recorrido

por una combinación de Bus-Metro desde un punto de origen a un destino

Entradas Se suministra la ubicación geográfica del origenSe suministra la ubicación geográfica del destino

Reglas de Negocio

- Se debe seleccionar un origen geográfico válido- Se debe seleccionar un destino geográfico valido

Prioridad MediaFuente Reunión Cliente 13.03.22Estabilidad No estableListado de Usuarios

Usuario Pasajero


PR1008

Estado Cumple

Atributo DescripciónIdentificador RU1010Nombre Marcar paradero como favoritoDescripción Una vez seleccionado un paradero específico en la

vista, al hacer clic sobre este se le muestra al usuario una estrella junto al nombre del paradero, para agregarlo a una lista especial de fácil acceso.

Entradas Los datos que se suministran son: - El paradero que se desea guardar.

Reglas de Negocio

- Si el paradero ya ha sido agregado a favoritos,la estrella estará activada.

- El paradero seleccionado debe ser válidoPrioridad AltaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario Pasajero


RP1009 – RP1010

Estado Cumple

Atributo DescripciónIdentificador RU1011Nombre Mostrar favoritosDescripción La aplicación debe permitirle al usuario abrir una

ventana donde salga la lista de todos los paraderos, recorridos y rutas guardados y también debe permitir seleccionarlos para desplegarlos en la aplicación.

Entradas -Reglas de Negocio

- Debe por lo menos haber algún paradero guardadoen la lista para que se pueda desplegar ymostrar


Usuario pasajero


PR1013

Estado Cumple

Atributo DescripciónIdentificador RU1012Nombre Marcar recorrido como favoritoDescripción Similar a marcar un paradero como favorito, al

seleccionar un recorrido se muestra una estrella que permite agregar el recorrido a una lista de acceso rápido.

Entradas - Recorrido que se desea guardarReglas de Negocio

- Si el recorrido ya está en la lista defavoritos, la estrella en su nombre estaráactivada.

- El recorrido seleccionado debe ser válido.Prioridad MediaFuente Reunión Cliente 13.03.22Estabilidad No estableListado de Usuarios

Usuario pasajero


PR1026 – PR1027

Estado Cumple

Atributo DescripciónIdentificador RU1013Nombre Mostrar saldo tarjeta Bip!Descripción La aplicación debe permitir al usuario revisar el

saldo de una tarjeta Bip!. Luego de recibir el número, la aplicación debe obtener los datos y mostrarlos en pantalla.

Entradas Se entrega a la aplicación el número de la tarjeta BIP a consultar.

Reglas de Negocio

- No debe ser posible ingresar un número detarjeta BIP con menos dígitos de los que debetener.

- No debe ser posible ingresar letras en el númerode tarjeta.

- Si no hay conexión a internet, la aplicacióndebe informar de este error.

- Si el servidor de consulta se encuentra caído,la aplicación debe informar de este error.

Prioridad BajaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario pasajero


PR1016

Estado Cumple

Atributo DescripciónIdentificador RU1014Nombre Mostrar puntos de recarga Bip! en un mapaDescripción Debe ser posible visualizar un mapa con los puntos

de recarga Bip! más cercanos en la aplicación.Entradas Coordenadas de la ubicación actual y radio

búsqueda.Reglas de Negocio

- No debe ser posible mostrar la posición actualsi el GPS se encuentra desactivado.

- No debe ser posible mostrar la posición de lospuntos de recarga si el dispositivo no tieneacceso a internet.

- Sólo se podrán visualizar los puntos de recargasi está habilitada esa opción en el menú decapas.

Prioridad MediaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario pasajero

Iteración 2Caso de PR1017

PruebaEstado Cumple

Atributo DescripciónIdentificador RU1015Nombre Abrir la aplicación mostrando un mapa y un menú de

opcionesDescripción El sistema debe ser capaz de iniciar la aplicación,

desplegando inicialmente un mapa con los paraderos y el menú que contiene las opciones pertinentes.

Entradas Locación GPS del usuarioParaderos cercanos al punto inicial.

Reglas de Negocio

- Se debe tener activado el gps.- El celular debe estar conectado a internet.- Aplicación correctamente instalada en el

dispositivo Android.Prioridad MediaFuente Reunión Cliente 13.03.22Estabilidad No estableListado de Usuarios

Usuario pasajero


PR1002 – PR1028

Estado Cumple

Atributo DescripciónIdentificador RU1016Nombre Estimar cuánto demorará bus en llegar a un

paraderoDescripción El sistema debe a todos los buses de una línea en

un mapa, luego se deben mostrar todos los paraderosde la línea, permitiendo seleccionar un paradero. Con esta información se calcula el tiempo estimado de llegada del próximo bus a ese paradero con la información proporcionada por la API del sistema y por el algoritmo de cálculo de tiempo.

Entradas El bus para la cual se quiere sabe el tiempo de

recorridoEl paradero de origen en el que para el busEl paradero de destino en el que para el bus

Reglas de Negocio

- Se debe seleccionar un bus valido- Se debe seleccionar un paradero de origen válido- Se debe seleccionar un paradero de destino

válidoPrioridad MediaFuente Reunión Cliente 13.03.22Estabilidad No estableListado de Usuarios

Usuario pasajero


PR1003 – PR1006

Estado Cumple

Atributo DescripciónIdentificador RU1017Nombre Desplegar lista de búsquedaDescripción El sistema debe mostrar todas las búsquedas pasadas

más recientes, además de los nuevos resultados. Esta búsqueda contempla direcciones, paraderos, lugares y recorridos.

Entradas El texto para realizar la búsqueda.Lista de búsquedas recientes.

Reglas de Negocio

- El texto debe coincidir con alguna porción dealguna búsqueda reciente.

Prioridad MediaFuente Reunión Cliente 13.03.22Estabilidad No estableListado de Usuarios

Usuario pasajero


PR1015

Estado Cumple

2.5.2 Requisitos no funcionales

2.5.2.1 Requisitos de Interfaz

Atributo DescripciónIdentificador RNFD1001Nombre Comunicación efectiva con distintas Api.Descripción La interacción entre el servidor de la aplicación

con la Api del cliente debe realizarse de forma rápida y sin errores, es decir cada consulta no puede tomar más de 5 segundos.


Usuario Pasajero

Iteración 2Estado Cumple

Atributo DescripciónIdentificador RNFD1015Nombre Soporte de idioma en la InterfazDescripción La aplicación debe utilizar archivos de

diccionarios o una solución similar, de modo de poder agregar soporte para nuevos idiomas sin tenerque modificar el código del programa.La interfaz de la aplicación debe presentar el lenguaje español por defecto.


Administrador.

Iteración 2Estado No Cumple

2.5.2.2 Operacionales

Atributo DescripciónIdentificador RNFD1002Nombre Aplicación SimpleDescripción El usuario debe ser capaz de utilizar las

funcionalidades de la aplicación sin un tutorial o entrenamiento previo.


Usuario Pasajero


Atributo DescripciónIdentificador RNFD1003Nombre Sistema Operativo compatibleDescripción La aplicación debe funcionar desde la versión 2.2

del sistema operativo Android.Prioridad MediaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario Pasajero


2.5.2.3 Recursos (Ambiente Operacional)Atributo DescripciónIdentificador RNFD1004Nombre Servidor RobustoDescripción El servidor debe ser capaz de soportar la carga de

consultas máxima. Este número debe ser estimado en

base a la totalidad de consultas que recibe la API del gobierno (400.000 diarias), estimación pendiente con el Cliente.


Técnicos o administradores encargados de la mantención del servidor


Atributo DescripciónIdentificador RNFD1005Nombre Aplicación LivianaDescripción La aplicación debe pesar menos de 15mb.Prioridad AltaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario Pasajero


2.5.2.4 UsabilidadAtributo DescripciónIdentificador RNFD1006

Nombre Aplicación IntuitivaDescripción La aplicación se debiese entender por sí misma.

Esto significa que debe ser lo suficientemente intuitiva para que el usuario pueda usar la aplicación sin ningún entrenamiento ni explicación.

Prioridad BajaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Usuario pasajero


Atributo DescripciónIdentificador RNFD1007Nombre Campos de texto y botones intuitivos.Descripción Los botones y los campos de texto deben contener

algún tipo de indicación para que el usuario conozca cómo debe rellenarlos o para qué sirven. Por ejemplo, los campos de textos deben tener un texto escrito con color de fuente suave a modo de ejemplo.


Usuario pasajero


2.5.2.5 Mantenibilidad

Atributo DescripciónIdentificador RNFD1008Nombre Aplicación limpiaDescripción La aplicación debe estar libre de bugs y posibles

fallas, el código debe estar debidamente comentado para que sea entendible para cualquier implementador.


Administrador


2.5.2.6 Extensibilidad

Atributo DescripciónIdentificador RNFD1009Nombre ExtensibilidadDescripción El código debe estar documentado, de modo que sea

fácil agregar o quitar nuevas funcionalidades.Prioridad AltaFuente Reunión Cliente 13.03.22Estabilidad EstableListado de Usuarios

Administrador


2.5.2.7 Portabilidad

Atributo DescripciónIdentificador RNFD1010Nombre PortabilidadDescripción La aplicación debe poder ser ejecutada desde

cualquier celular con sistema operativo Android desde la versión 2.2 (Froyo), hasta la más actualizada hasta ahora (versión 4.1), también la API de la aplicación en el servidor debe tener la opción de ser migrada a otro servidor.


Administrador


2.5.2.8 Confiabilidad

Atributo DescripciónIdentificador RNFD1011Nombre Confiabilidad

Descripción Los buses mostrados en el mapa deben tener un errorinferior a los 300 metros con respecto a su ubicación exacta.Los paraderos y el mapa en sí deben corresponder a los datos de la ciudad en que se encuentra el usuario.


No aplica


2.5.2.9 RendimientoAtributo DescripciónIdentificador RNFD1012Nombre RendimientoDescripción La carga de los mapas no debe ser superior a 2

segundos, con una buena conexión.Las consultas a rutas o paraderos no deben ser superiores a 4 segundos.


Técnicos o administradores encargados de la mantención del servidor


2.5.2.10 Documentación

Atributo DescripciónIdentificador RNFD1013Nombre DocumentaciónDescripción Debe existir documentación tanto como de los

requerimientos, pruebas realizadas, su diseño y el manual de operación. Esta documentación debe ser revisada y aprobada por el Tutor.


Cliente


2.5.2.11 Escalabilidad

Atributo DescripciónIdentificador RNFD1014Nombre EscalableDescripción La aplicación debe ser altamente escalable, de

modo de poder ir soportando el aumento gradual de consultas y transacciones (entre todas las aplicaciones existentes para el Transantiago, se realizan un total de 400.000 consultas diarias).

Prioridad MediaFuente Reunión Cliente 13.03.22

Estabilidad EstableListado de Usuarios

Administrador.


2.6 Matriz de trazado de casos de usos vs requisitosfuncionales

RU100

RU100

RU100

RU100

RU100

RU100

RU100

RU101

RU101

RU101

RU101

RU101

RU101

RU101

RU101

CU100 X

1CU1002

X X X

CU1003

X X

CU1004

X X X

CU1005

X X X

CU1007

X X X

CU1008

X

CU1009

X

CU1010

X

CU1011

X X X

Requerimientos Ususario BUZZ

Documents