Binary-Rain
Informe de Verificación de Documento
Versión 1.3
Historia de revisiones
Fecha Versión Descripción Autor
01/09/2012 1.0 Creación del documento Matias Banchero
01/09/2012 1.1 Revisión de calidad Camilo Servetti
04/09/2012 1.2 Modificación del documento Matias Banchero
Contenido
1. IDENTIFICACIÓN DEL DOCUMENTO A SER VERIFICADO ... 3
2. OBJETIVO DE LA VERIFICACIÓN ... 3
2.1. ASPECTOS DEL DOCUMENTO A SER VERIFICADOS ... 3
2.2. VERIFICACIÓN DE ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE PARA EL SISTEMA VERSIÓN 1.3 ... 3
3. ERRORES ENCONTRADOS ... 3
3.1. ERRORES DE DOCUMENTACIÓN ... 3
3.2. FALTAN REFINAR Y DEFINIR PUNTOS EN ÍTEMS DE PERSPECTIVA DEL PRODUCTO ... 4
3.3. FALTAN REFINAR Y DEFINIR REQUERIMIENTOS ... 4
1.
Identificación del Documento a ser verificado
Documento verificado: Especificación de Requerimientos de Software para el Sistema Versión 1.5
Área a la que corresponde el documento: Requerimientos
Responsable de su realización: Paul Green, Maru Cristiani, German Lagrega, Angie Lecot, Santiago Dudok, Gabriel Artus.
2.
Objetivo de la verificación
El objetivo de esta verificación es comprobar que se han corregido los errores encontrados previamente y que la versión actual del documento está acorde a los requerimientos especificados por el cliente y que no falte ninguno.
Se verifica que el documento sea entendible ante la visión del cliente.
Se busca asegurar la completitud y el mínimo rango de ambigüedad en los requerimientos.
2.1. Aspectos del documento a ser verificados
• Formato:
Se verificará que se sigue el formato especificado en las plantillas dadas en el curso.
• Completitud:
Se verificará que todos los requerimientos que salieron de las reuniones y negociaciones con el cliente estén en el documento, que no haya carencias en las especificaciones de los requisitos.
• Correctitud:
Todos los requerimientos en el documento deben corresponderse con datos recabados en las reuniones de requerimientos y es consistente con otros documentos.
• Entendibilidad:
Se verificará que el documento sea entendible y que no se presenten ambigüedades en los requerimientos.
2.2. Verificación de Especificación de Requerimientos de Software para el
Sistema Versión 1.3
Se realizaron las correcciones de ortografía correspondientes.
3.
Errores encontrados
3.1. Errores de documentación
Descripción: Los requerimientos funcionales y no funcionales no están numerados.
Ubicación: Punto 3. Requerimientos (3.1 Requerimientos Funcionales, 3.2
Nivel de gravedad: Critico
Sugerencia de corrección: Numerar los requerimientos.
3.2. Faltan refinar y definir puntos en ítems de Perspectiva del Producto
Descripción: Ambigüedades y falta de información en las Perspectivas del
producto.
Ubicación: 1. Perspectiva del Producto (1.1 Interfaces de Usuario, 1.2
Interfaces con hardware, 1.3 Interfaces con software, 1.4 Interfaces de Comunicación, 1.5 Restricciones de Memoria, 2.1 Restricciones Tecnológicas)
Nivel de gravedad: Critico Sugerencia de corrección:
1.2 Interfaces con hardware:
• Definir marca y modelo de dispositivos móviles y tablets que se van a usar en las pruebas.
1.3 Interfaces con software:
• Definir versiones de Android en las cuales se asegurará que el sistema funcione. Si es desde Android 2.2 ¿Hasta que versión? Esto debería quedar formalmente documentado.
1.4 Interfaces de comunicación:
• Agregar lo definido por el cliente del uso de browsers para los formularios. (Internet Explorer y Google Chrome)
• Se deben definir versiones para los browsers.
• Agregar lo definido con el cliente. ¿Qué servidor de correo se utilizará para el envío de mails?
• Agregar lo definido con el cliente referido al envío de SMS. Desde cuales compañías puede mandar? ¿Que compañías pueden recibir los SMS’s?
1.5 Restricciones de memoria
• Definir máxima capacidad de almacenamiento del dispositivo móvil. 2.1 Restricciones tecnológicas:
• Se debería agregar como lenguaje de programación para implementar
Java
Falta agregar las restricciones respecto a las dimensiones de la pantalla
3.3. Faltan refinar y definir Requerimientos
Descripción: Ausencias y carencias de información en requerimientos
funcionales.
Ubicación: 3. Requerimientos específicos (3.1 Requerimientos
Funcionales, 3.2 Requerimientos No Funcionales) Nivel de gravedad: Critico
Sugerencia de corrección: Referencias:
RqX – Requerimiento textual del documento SugX – Sugerencia
REQUERIMIENTOS FUNCIONALES
Relativo a los usuarios:
Rq1) El sistema debe permitir el registro de usuarios (se identificará por una cuenta de correo electrónico de gmail). Cuando un usuario se da de alta en el sistema, dará lugar a la creación de una nueva empresa, dentro de la cual tendrá el rol de administrador.
Sug1.1) Debería agregarse poder modificar usuario y dar de baja un usuario (Esta especificado en Modo Offline pero quizás debería ir aquí).
Sug1.2) Dice que un usuario es administrador de una empresa. ¿Un
empleado es usuario? ¿El empleado también crea una empresa cuando da de alta su usuario?
Rq4) El administrador debe poder agregar empleados a su empresa.
Sug4) Se debería definir si el administrador puede quitar empleados y dar la posibilidad de listar los empleados.
Rq5) El administrador brinda los permisos para que los empleados puedan: o Debe poder asignar permisos a empleados para que puedan
traspasar tareas.
o Debe poder asignar permisos a empleados para que puedan crear/modificar tareas.
o Puede asignar permisos a usuarios para crear, modificar y eliminar contactos de la agenda de contactos de la empresa. o Puede asignar permisos a empleados para poder consultar el
calendario de todos los empleados de la empresa.
Sug5) La redacción no queda del todo clara, se propone exponer el punto de la siguiente forma.
El administrador puede otorgarles a sus empleados los siguientes permisos: a) Traspasar tareas
b) Crear/modificar tareas
c) Crear/Modificar/Borrar Contactos
d) Consultar el calendario de todos los empleados de la empresa Sug_extra01) Detallar todos los atributos para el alta de usuario o por lo menos debe estar contemplado en el caso de uso.
Manejo de Tareas:
Rq2) Los datos correspondientes a las tareas, ya sea insumos (tipo o cantidad) o resumen de lo que se realizó se registrará como texto sin formato, permitiendo una mayor flexibilidad de la aplicación.
Sug2) Se debería especificar cuales son los datos correspondientes a las tareas.
Rq4) Los estados de las tareas no obedecerán un flujo predeterminado, para permitir que el usuario establezca manualmente el mismo.
Sug4) Se debe establecer si un flujo posible sería comenzar la tarea en finalizada. O si un flujo posible para una tarea podría ser:
Finalizada->Comenzada->Pendiente. De no ser posible, es deberían definir flujos posibles.
Rq6) Se debe permitir el traspaso de tareas entre usuarios de una misma empresa. Una vez asignada la tarea la misma no podrá ser rechazada.
Sug6.1) Definir como se le comunica el traspaso de una tarea a un usuario, las vías de comunicación. (Mail, notificación de Android, SMS)
Sug6.2) ¿Debería haber una notificación por parte del destinatario al remitente para asegurarle que el mensaje le llegó?
Manejo de Clientes:
Rq3) Debemos brindar la posibilidad al usuario de importar clientes desde la agenda de su dispositivo.
Sug3) Se debería especificar si se deben importar todos los contactos a la
vez o si se pueden elegir.
Sug_extra01) Definir si habrá una función para Alta de contactos. Sug_extra02) Definir los atributos que se guardan del contacto (deben contenerse por lo menos en casos de uso).
Sug_extra03) Definir si habrá función para modificación y baja de contactos.
Notificaciones a los clientes:
Rq2) Una vez que la tarea se encuentre en estado “en curso” el sistema
deberá enviar un recordatorio de la visita al cliente 24 horas antes de la misma. Adicionalmente proveerá la opción de cancelar este recordatorio o modificar el tiempo de anterioridad de envío.
Sug2) Definir si esto se hace estando el usuario offline.
Rq3) El usuario debe tener la posibilidad de notificarle a un cliente que va a llegar tarde o cancelar un trabajo mediante envío de email o SMS.
Sug3) Definir tiempo de antelación con que se manda el mensaje. Vías de envío (SMS, mail)
Rq5) Al momento de culminar el trabajo se debe enviar un resumen con el detalle de la tarea realizada, donde se incluyan los insumos, horas trabajadas y costo total.
Sug5.1) Definir a quien se le envía el detalle.
Rq6) Debe enviarse al cliente una encuesta de satisfacción una semana luego de culminada la tarea. También ofrecerá la posibilidad al usuario de cancelar este envío o cambiarle el periodo en el cual se debe enviar. Al enviar la encuesta se debe dar la posibilidad de que el cliente pueda solicitar una nueva visita, debido a una insatisfacción con el trabajo realizado por parte del usuario. El nivel de satisfacción del cliente se evaluará en una escala del 1 al 5, y se asociarán emoticones que representen dicha escala.
Sug6) Definir cual será la vía para la comunicación (Mail, SMS)
Modo Offline:
Rq4) Debe mantenerse sincronizada la información local con la contenida en el servidor.
Sug4) Definir en que momento se deben sincronizar. Rq5) Se debe realizar persistencia local.
Sug5) Se podría especificar un poco más. Parece no quedar totalmente entendible al cliente.
REQUERIMIENTOS NO FUNCIONALES
Completar con los nuevos datos recabados tras la corrección de la perspectiva del producto.
