Binary Rain
Especificación de Requerimientos de Software para el Sistema
Versión 4.4
Historia de revisiones
Fecha Versión Descripción Autor
17/08/2012 1.0 Creación del documento.
Requerimientos relevados en la primera reunión.
Martín Poli
18/08/2012 1.1 Revisión y corrección SQA Mercedes Marzoa 23/08/2012 2.0 Actualización del documento. Martín Poli 24/08/2012 2.1 Detalle de algunos
requerimientos.
Martín Poli
25/08/2012 2.2 Revisión y corrección SQA Mercedes Marzoa 29/08/2012 3.0 Completar funcionalidades Jimena Díaz
30/08/2012 3.1 Revisión SQA Mercedes Marzoa
01/09/2012 3.2 Revisión Verificación Florencia Clerici 03/09/2012 3.3 Agrego funcionalidades Emiliano Schiavone 06/09/2012 4.0 Agregar requerimientos que
faltaban, agrupar por categorías y numerarlos.
Santiago Sánchez
07/09/2012 4.1 Correcciones que envió el
cliente. Santiago Sánchez
12/09/2012 4.2 Revisión de req. funcionales según casos de uso.
Santiago Sánchez
14/09/2012 4.3 Corrección según la reunión
con el cliente del 12/09. Santiago Sánchez
15/09/2012 4.3 Revisión SQA Mercedes Marzoa
15/09/2012 4.4 Corrección luego de revisión
SQA Santiago Sánchez
16/09/2012 4.4 Revisión SQA Mercedes Marzoa
Responsables: Grupo de Analistas del proyecto.
Contenido
1.1. INTRODUCCIÓN ... 4
1. Introducción ... 4
1.1.PROPÓSITO ... 4
1.2.ALCANCE ... 4
1.3.DEFINICIONES, SIGLAS Y ABREVIATURAS. ... 4
1.4.REFERENCIAS ... 4
1.5.VISIÓN GENERAL ... 4
2.2. DESCRIPCIÓN GENERAL ... 4
2. Descripción general ... 4
2.1.PERSPECTIVA DEL PRODUCTO ... 5
2.1.1. Interfaces de usuario ... 5
2.1.2. Interfaces con hardware ... 5
2.1.3. Interfaces con software ... 5
2.1.4. Interfaces de comunicación ... 5
2.1.5. Restricciones de memoria ... 5
2.1.6. Requerimientos de adecuación al entorno... 5
2.2.FUNCIONES DEL PRODUCTO ... 6
2.3.CARACTERÍSTICAS DE LOS USUARIOS ... 6
2.4.RESTRICCIONES DE DISEÑO ... 6
2.5.SUPUESTOS Y DEPENDENCIAS ... 6
3.3. REQUERIMIENTOS ... 7
3. Requerimientos ... 7
3.1.REQUERIMIENTOS FUNCIONALES ... 7
Clientes ... 7
RF1 – Agenda de clientes: ... 7
RF2 – Alta, baja y modificación de clientes: ... 7
RF3 - Ver detalle de cliente:... 7
Servicios ... 7
RF4 - Crear servicio: ... 7
RF5 - Finalizar servicio: ... 8
RF6 – Ver detalle de servicio: ... 8
RF7 – Ver presupuestos: ... 8
RF8 - Encuesta de evaluación del servicio realizado: ... 8
RF9 - Consultar Historial de servicios: ... 8
Visitas y Tareas ... 8
RF10 - Alta y modificación de tipos de tareas: ... 8
RF11 - Ver tipos de tareas: ... 8
RF12 – Agregar y eliminar tareas: ... 9
RF13 - Agendar visita: ... 9
RF14 - Finalizar visita: ... 9
RF15 - Ver detalle de tarea: ... 9
RF16 - Ver visitas agendadas: ... 9
RF17 - Consultar historial por cliente: ... 9
RF18 - Filtrar historial: ... 9
RF19 - Delegar visita: ... 10
Empresa ... 10
RF20 - Registrar empresa: ... 10
RF21 - Modificar configuración: ... 10
RF22 – Alta, baja y modificación de empleados: ... 10
RF23 – Colegas: ... 10
RF24 - Notificar hora de llegada: ... 10
RF25 – Inicio y cierre de sesión: ... 10
3.2.REQUERIMIENTOS NO FUNCIONALES ... 11
4.4. REQUERIMIENTOS DE DOCUMENTACIÓN ... 11
4. Requerimientos de documentación ... 11
4.1.MANUAL DE USUARIO ... 11
4.2.AYUDA EN LÍNEA ... 11
4.3.GUÍAS DE INSTALACIÓN, CONFIGURACIÓN Y ARCHIVO LÉAME. ... 11
4.4.ETIQUETADO Y EMPAQUETADO ... 11
1. Introducción
En este documento se busca especificar los requerimientos solicitados por el cliente en la presentación del proyecto y reuniones posteriores.
1.1. Propósito
Se busca definir los requerimientos del sistema a desarrollar con el objetivo de colaborar en etapas posteriores, así como ayudar a obtener un mejor diseño y construcción del sistema a desarrollar.
También se busca poder validar estos requerimientos en futuras reuniones con el cliente.
1.2. Alcance
La idea es desarrollar un prototipo de un sistema para tabletas y smart phones que permita a micro y pequeños proveedores de servicios mejorar la gestión de su negocio a través de la automatización de tareas diarias reiterativas.
Para los micro proveedores se tendrá en cuenta la existencia de un administrador que podrá agregar empleados a su empresa y elegir qué permisos darles.
El diseño de la interfaz de Usuario tiene que considerar el proyecto global pensado por el cliente, es decir, aunque la lógica de una funcionalidad no esté implementada por estar pensada para una versión futura, en el diseño se tendrá que tener en cuenta. A modo de ejemplo, en la versión comercial se pretende el uso de Banking System, si bien en esta etapa no se pretende dar funcionalidades que contemplen este mecanismo, en el diseño de la aplicación el botón debería estar presente aunque la funcionalidad va a estar deshabilitada.
1.3. Definiciones, siglas y abreviaturas.
Customer Relationship Management (CRM)
Natural User Interface (NUI)
MUM es el modelo de proceso utilizado en el proyecto de ingeniería de software.
Alta, baja y Modificación (ABM)
1.4. Referencias
Glosario
Acta de Reunión de Requerimientos
Pautas para interfaz de Usuario
1.5. Visión general
En los próximos puntos se da una descripción general de los requerimientos que se fueron relevando hasta el momento en las sucesivas reuniones mantenidas con el cliente, incluyendo las principales características funcionales y no funcionales del sistema Binary Rain.
2. Descripción general
El cliente quiere desarrollar un prototipo del sistema propuesto que le permita realizar pruebas de campo y validar los conceptos tecnológicos y de negocios
utilizados con respecto a la utilidad para el usuario final en el desempeño de sus tareas.
De este modo se podrá obtener en detalle los puntos positivos, negativos y a mejorar del sistema en el impacto en la tarea desarrollada por los usuarios finales.
2.1. Perspectiva del producto
2.1.1. Interfaces de usuario
La interfaz de Usuario tiene que ser desarrollada utilizando técnicas NUI, aprovechando la experiencia de usuario estudiada por la empresa.
Se busca conseguir un diseño intuitivo, ágil y fácil de usar. Dado que los usuarios finales pueden no estar familiarizados con este tipo de tecnologías, lo que se busca es no genera un rechazo hacia ellas.
En principio la interfaz de Usuario va a estar enfocada en dispositivos móviles.
Se realizará una validación del diseño con un grupo de usuarios finales elegidos en principio por el cliente. Este grupo va a estar conformado por 5 posibles usuarios, el cliente nos ofreció la posibilidad de estar presente en la prueba y ayudar en la evaluación. La prueba se realiza en base a los bocetos creados para el diseño, lo que se busca principalmente es validar que el diseño sea intuitivo.
Un requerimiento que nos planteó el cliente es que la aplicación no cuente con scroll horizontal ya que no es intuitivo para el tipo de usuario final.
2.1.2. Interfaces con hardware
La aplicación móvil podrá correr en dispositivos móviles y tabletas con tecnología Android. Para todo el manejo de repositorio e intercambio de información se usa el servicio cloud (Google App Engine).
2.1.3. Interfaces con software
Los dispositivos móviles y tabletas deben contar con tecnología Android para poder usar la aplicación desarrollada. El cliente nos proporcionará los dispositivos para realizar pruebas en la empresa y así poder probar el producto final en el ambiente deseado y evitar que sea en un simulador.
2.1.4. Interfaces de comunicación
El software va a estar modelado en base a una comunicación entre los clientes de software para las plataformas mencionadas y un servicio cloud (Google App Engine) que funcionará como centro de intercambio de información y repositorio.
Se tendrá en cuenta que el funcionamiento de la aplicación está pensado para ser utilizado con conexión a Internet. En caso de no contar con conexión se le permitirá al usuario usar ciertas funcionalidades de la aplicación que no necesiten mantener una conexión para ser realizadas, y cuando se consiga nuevamente estar conectado se sincronizará. Deberá poder ver sus contactos y calendario, y modificar sus contactos y tareas.
2.1.5. Restricciones de memoria
En principio se cuenta con las limitaciones de memoria que las tabletas y smart phones posean.
2.1.6. Requerimientos de adecuación al entorno
El cliente estará acotado por las limitaciones del sistema Android.
2.2. Funciones del producto
El sistema deberá brindar las siguientes funcionalidades:
Inicio de sesión para usuarios registrados.
Registro de empresas, administradores y empleados.
Brindar las funcionalidades de ABM para empleados.
Crear y finalizar servicios.
Crear tipos de tareas con un nombre, descripción y precio asociado.
Agregar tareas a los servicios y agendarlas.
Crear y modificar presupuestos para los servicios.
Brindar las funcionalidades de ABM para clientes.
Importar contactos de la agenda del dispositivo.
Agenda de contactos en la aplicación. Se podrán ver los contactos del usuario (clientes y colegas) y hacer búsquedas en la agenda de la empresa.
Brindar un historial de los servicios y tareas realizadas a cada cliente.
Brindar la posibilidad al usuario de notificar al cliente la hora de llegada a una cita, y avisar en caso de llegar tarde.
Brindar un calendario donde se pueden agendar tareas y ver las tareas previamente agendadas.
Manejo de permisos y configuraciones de funcionalidades.
Enviar un resumen después de cada visita con el detalle de lo que se hizo, los insumos utilizados y la fecha de la siguiente visita.
Enviar una encuesta vía correo electrónico para determinar el grado de satisfacción del cliente con el servicio brindado. Dicha encuesta se enviará una semana después de haber terminado el trabajo.
Información de los insumos que se necesitan para realizar cada una de las tareas.
Brindarle al usuario la posibilidad de revisar las tareas que tiene que realizar en cada cita acordada.
2.3. Características de los usuarios
El sistema esta enfocado a usuarios finales que no necesariamente están vinculados con las tecnologías o con el uso de dispositivos móviles. Por eso se prioriza aplicar la técnica de NUI.
El cliente sugirió enfocarse en un diseño para hombres de 30 a 54 años dado que este es el genero que predomina en las tareas de carpintería, electricidad, sanitaria, etc.
2.4. Restricciones de diseño
Proceso de desarrollo: MUM.
Lenguaje de programación: Java y SDK de Android.
Entorno de desarrollo: Eclipse.
Servicio cloud: Google App Engine.
Versión de Android 2.2 en adelante.
2.5. Supuestos y dependencias
El supuesto principal de la aplicación es que para su completo desempeño debe contar con conexión a Internet. Además se asume una alta disponibilidad y conectividad por parte del servicio de cloud computing de Google (App Engine).
Cabe destacar que dicho servicio tiene un límite diario sobre los recursos que se brindan de forma gratuita, como ser: ancho de banda consumido, volumen de datos y acceso a los mismos, cantidad de mails, etc. Una vez superados esos límites, Google empieza a cobrar por la utilización de sus recursos. Se pueden encontrar más detalles sobre los precios del servicio en el sitio de la plataforma cloud de Google: http://cloud.google.com/pricing/
3. Requerimientos
3.1. Requerimientos Funcionales
Nota: Para cada requerimiento funcional se especifica el caso de uso asociado, los cuales se encuentran en el documento Modelo de Casos de Uso (RQMODG6). Allí se puede ver con mayor detalle la descripción y el flujo de cada caso de uso del sistema.
Además la aplicación deberá contar con un sistema de roles y permisos, de manera de poder controlar los usuarios que pueden acceder a cada funcionalidad. Remitirse al Modelo de Casos de Uso para consultar los roles que se definen y la correspondencia entre los mismos y los casos de uso.
Clientes
RF1 – Agenda de clientes:
Un usuario con los permisos adecuados podrá ver los clientes de su agenda e importar contactos desde la agenda del dispositivo móvil en el que se esta corriendo la aplicación, y desde la agenda de la empresa.
Un usuario con permisos restringidos sólo podrá ver la información de los clientes para los cuales tiene visitas agendadas en el momento.
Casos de Uso: Ver Clientes, Importar Contactos e Importar Clientes
RF2 – Alta, baja y modificación de clientes:
Se podrán dar de alta nuevos clientes en la agenda del usuario, modificar los datos o eliminarlos. En el caso de eliminar un cliente, el mismo no se elimina de la lista de contactos de la empresa. Los datos de un cliente son los siguientes: nombre completo, teléfono, mail, RUT y dirección.
Casos de Uso: Alta Cliente, Modificar Cliente, Eliminar Cliente
RF3 - Ver detalle de cliente:
Ver toda la información relativa a un cliente de la empresa: sus datos personales, registro de servicios realizados y promedio de calificación.
Caso de Uso: Ver Detalle de Cliente
Servicios
RF4 - Crear servicio:
Se crea un nuevo servicio en el sistema asociado a un técnico y al cliente solicitante. Para esto el usuario ingresa una descripción del servicio, selecciona el cliente (o lo registra en caso de ser un cliente nuevo) y agrega una a una las tareas a realizar, pudiendo modificar opcionalmente el costo asociado a cada una de ellas y agendarlas. El sistema muestra el presupuesto total del servicio, a lo que el usuario puede indicar si el mismo fue validado por el cliente. Si no lo fue, se le
envía por mail el formulario con el presupuesto para que pueda aceptarlo o rechazarlo.
Caso de Uso: Crear servicio
RF5 - Finalizar servicio:
Se podrá dar por finalizado un servicio y se enviará automáticamente un mail al cliente con las tareas que se realizaron, el costo de cada una y el costo total. En caso de cancelación por parte del cliente se le detallará el monto a cobrar por lo que se realizó del servicio hasta el momento, y si el mismo corre por cuenta de la empresa o no.
Caso de Uso: Finalizar servicio
RF6 – Ver detalle de servicio:
Se podrán ver los datos de un servicio, como el cliente, la fecha y las tareas.
Caso de Uso: Ver detalle de servicio
RF7 – Ver presupuestos:
Se podrá ver la lista de presupuestos del sistema, ordenada según el estado de cada presupuesto respecto de la aprobación del cliente:
validados, rechazados y pendientes de aprobación. Además se podrá consultar la información detallada de cada uno, modificarlos y validarlos.
Casos de Uso: Ver presupuestos y Ver detalle de presupuesto
RF8 - Encuesta de evaluación del servicio realizado:
Se enviará al cliente una encuesta para evaluar el servicio realizado una semana después de haberlo terminado. Esto se hará de forma automática vía mail.
Caso de Uso: Encuesta de evaluación del servicio realizado
RF9 - Consultar Historial de servicios:
Se podrán consultar los servicios realizados a los clientes, ordenados en tres pestañas: Activos, Pendientes y Finalizados.
Caso de Uso: Consultar Historial de Servicios
Visitas y Tareas
RF10 - Alta y modificación de tipos de tareas:
El usuario podrá dar de alta y modificar tipos de tareas, ingresando para cada una el nombre de la tarea, el costo, una descripción, los insumos y el tiempo estimado que lleva realizarla.
Casos de Uso: Alta tipo de tarea, Modificar un tipo de tarea
RF11 - Ver tipos de tareas:
Se podrá consultar la lista de los tipos de tareas definidos en la empresa y ver el detalle de cada una.
Caso de Uso: Ver tipos de tareas, Ver detalle de tipo de tarea
RF12 – Agregar y eliminar tareas:
Se podrán crear nuevas tareas dentro de un servicio, así como eliminarlas.
Casos de Uso: Agregar tarea a servicio, Eliminar una tarea
RF13 - Agendar visita:
Una visita representa una jornada de trabajo en el cliente, en la que se realizan un conjunto de tareas. Un usuario con los permisos adecuados podrá agendar visitas tanto en su calendario como en el de los demás, eligiendo el día, la hora y las tareas que se van a realizar. Además podrá modificar la fecha y hora para una visita previamente agendada.
Dicho usuario sería típicamente el administrador de la empresa.
Casos de Uso: Agendar tarea, Reagendar tarea
RF14 - Finalizar visita:
Se podrán ingresar las tareas que se realizaron en una visita una vez terminada, así como los insumos utilizados y un texto con comentarios.
Se le enviará por mail al cliente un resumen de la misma.
RF15 - Ver detalle de tarea:
Se podrá consultar la información de una tarea en particular.
Caso de Uso: Ver Detalle de Tarea
RF16 - Ver visitas agendadas:
El usuario puede consultar las tareas que tiene agendadas. Para eso se le muestra el calendario del mes actual, donde puede elegir un día, y para ese día se le muestran las visitas agendadas, ordenadas por horario. Además desde el menú principal se tendrá un acceso directo a las visitas agendadas del día. Si cuenta con los permisos adecuados también podrá consultar el calendario de otros empleados de la empresa.
Casos de Uso: Ver tareas agendadas, Ver cantidad de tareas del día
RF17 - Consultar historial por cliente:
El usuario podrá consultar el historial de servicios por cliente. El historial le mostrará los servicios que se realizaron a un determinado cliente, mostrando para cada uno la fecha, el nombre y la calificación otorgada por el cliente. Por defecto se mostrarán los últimos 5 servicios, y dicha cantidad podrá ser configurada por el administrador.
Caso de Uso: Consultar Historial por Cliente
RF18 - Filtrar historial:
Se podrá filtrar el historial de tareas por cliente o servicio. Para el filtro el usuario ingresará un rango de fechas en la cual desea aplicar el filtro.
Caso de Uso: Filtrar Historial
RF19 - Delegar visita:
Un usuario con los permisos adecuados podrá delegar una visita a otro usuario de la misma empresa.
Se enviará una notificación al usuario al que se le delegará la visita, avisándole que se le solicita realizar la misma.
Caso de Uso: Delegar tarea
Empresa
RF20 - Registrar empresa:
Se podrá registrar una empresa en la aplicación. Deberá ingresar el nombre de la empresa, el RUT (opcional), el nombre, mail y contraseña del administrador.
Caso de Uso: Registrar empresa
RF21 - Modificar configuración:
Se podrán configurar los permisos que tiene cada rol, los cuales serán aplicados a los usuarios con dichos roles. Se podrá también editar la encuesta de evaluación de servicio, los datos de la empresa y la cantidad de items que se muestran en el historial por cliente.
Caso de Uso: Modificar Configuración
RF22 – Alta, baja y modificación de empleados:
El administrador de la empresa podrá dar de alta nuevos empleados de la empresa, modificarlos y eliminarlos. Los datos de un empleado son los siguientes: nombre completo, mail, contraseña, confirmación de la misma, teléfono, cédula de identidad y rol. Al eliminar un empleado se lo marca como eliminado, pero no se eliminan físicamente los registros del sistema.
Casos de Uso: Registrar empleado, Modificar empleado y Baja de empleado
RF23 – Colegas:
El usuario podrá consultar la agenda de colegas y ver el detalle de los mismos: nombre, apellido, mail y teléfono.
Casos de Uso: Ver Agenda de Colegas y Ver Detalle de Colegas
RF24 - Notificar hora de llegada:
El técnico podrá notificar a un cliente vía SMS el horario de llegada a una visita agendada, pudiendo comunicarle si llegará tarde. También se le enviará la notificación al administrador.
Caso de Uso: Notificar hora de llegada
RF25 – Inicio y cierre de sesión:
El usuario podrá identificarse para iniciar sesión en la aplicación. Para esto deberá ingresar su identificador (mail o cédula de identidad) y contraseña. El sistema deberá validar los datos ingresados.
Además podrá indicar si desea que el sistema inicie sesión automáticamente cada vez que abre la aplicación, y al cerrarla.
Casos de Uso: Iniciar Sesión y Cerrar Sesión
3.2. Requerimientos No Funcionales
El código debe estar en ingles, y se deben comentar las clases y los métodos más complejos, para lograr un código legible para futuras modificaciones.
Debe funcionar en dispositivos con sistema operativo Android en su versión 2.2 o superior.
Interfaz de Usuario:
◦ Intuitiva y fácil de usar.
◦ Soporte de varias resoluciones de pantalla.
◦ Resolución mínima: 320x240.
◦ Respetar los estándares de diseño de Android.
◦ Tamaños medianos o grandes para los componentes de la interfaz:
botones, campos de texto, etc.
◦ En el documento Pautas para la Interfaz de Usuario (RQPIUG6) se describen en detalle los requerimientos para la interfaz.
Para la validación del diseño se realizará una evaluación con 5 usuarios finales, utilizando los bocetos de la interfaz de usuario en papel.
4. Requerimientos de documentación
La aplicación deberá brindarle al usuario una ayuda del manejo del funcionamiento de las principales funcionalidades. Este puede ser por medio de videos demostrativos o guías, incluidas en la aplicación.
4.1. Manual de Usuario
No es necesario realizar un manual, alcanza con que la aplicación tenga una guía para ayudar al usuario a adaptarse a ella.
4.2. Ayuda en línea
En principio no se cuenta con ayuda en línea.
4.3. Guías de instalación, configuración y archivo Léame.
Dadas las características de la aplicación no es necesario una guía de instalación o configuración.
4.4. Etiquetado y empaquetado No han sido definidos.
