Binary-Rain Informe de Verificación de Documento Versión 1.3. Historia de revisiones

Transcripción

1 Binary-Rain Infrme de Verificación de Dcument Versión 1.3 Histria de revisines Fecha Versión Descripción Autr 01/09/ Creación del dcument Matias Bancher 01/09/ Revisión de calidad Camil Servetti 04/09/ Mdificación del dcument Matias Bancher 05/09/ Revisión de calidad Camil Servetti Infrme de Verificación de Dcument Página 1 de 7

2 Cntenid 1. IDENTIFICACIÓN DEL DOCUMENTO A SER VERIFICADO OBJETIVO DE LA VERIFICACIÓN ASPECTOS DEL DOCUMENTO A SER VERIFICADOS VERIFICACIÓN DE ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE PARA EL SISTEMA VERSIÓN ERRORES ENCONTRADOS ERRORES DE DOCUMENTACIÓN FALTAN REFINAR Y DEFINIR PUNTOS EN ÍTEMS DE PERSPECTIVA DEL PRODUCTO FALTAN REFINAR Y DEFINIR REQUERIMIENTOS... 4 REQUERIMIENTOS FUNCIONALES... 5 Infrme de Verificación de Dcument Página 2 de 7

3 1. Identificación del Dcument a ser verificad Dcument verificad: Especificación de Requerimients de Sftware para el Sistema Versión 1.5 Área a la que crrespnde el dcument: Requerimients Respnsable de su realización: Paul Green, Maru Cristiani, German Lagrega, Angie Lect, Santiag Dudk, Gabriel Artus. 2. Objetiv de la verificación El bjetiv de esta verificación es cmprbar que se han crregid ls errres encntrads previamente y que la versión actual del dcument está acrde a ls requerimients especificads pr el cliente y que n falte ningun. Se verifica que el dcument sea entendible ante la visión del cliente. Se busca asegurar la cmpletitud y el mínim rang de ambigüedad en ls requerimients Aspects del dcument a ser verificads Frmat: Se verificará que se sigue el frmat especificad en las plantillas dadas en el curs. Cmpletitud: Se verificará que tds ls requerimients que saliern de las reunines y negciacines cn el cliente estén en el dcument, que n haya carencias en las especificacines de ls requisits. Crrectitud: Tds ls requerimients en el dcument deben crrespnderse cn dats recabads en las reunines de requerimients y es cnsistente cn trs dcuments. Entendibilidad: Se verificará que el dcument sea entendible y que n se presenten ambigüedades en ls requerimients Verificación de Especificación de Requerimients de Sftware para el Sistema Versión 1.3 Se realizarn las crreccines de rtgrafía crrespndientes. 3. Errres encntrads 3.1. Errres de dcumentación Descripción: Ls requerimients funcinales y n funcinales n están numerads. Ubicación: Punt 3. Requerimients (3.1 Requerimients Funcinales, 3.2 Requerimients N Funcinales) Infrme de Verificación de Dcument Página 3 de 7

4 Nivel de gravedad: Critic Sugerencia de crrección: Numerar ls requerimients Faltan refinar y definir punts en ítems de Perspectiva del Prduct Descripción: Ambigüedades y falta de infrmación en las Perspectivas del prduct. Ubicación: 1. Perspectiva del Prduct (1.1 Interfaces de Usuari, 1.2 Interfaces cn hardware, 1.3 Interfaces cn sftware, 1.4 Interfaces de Cmunicación, 1.5 Restriccines de Memria, 2.1 Restriccines Tecnlógicas) Nivel de gravedad: Critic Sugerencia de crrección: 1.2 Interfaces cn hardware: Definir marca y mdel de dispsitivs móviles y tablets que se van a usar en las pruebas. 1.3 Interfaces cn sftware: Definir versines de Andrid en las cuales se asegurará que el sistema funcine. Si es desde Andrid 2.2 Hasta que versión? Est debería quedar frmalmente dcumentad. 1.4 Interfaces de cmunicación: Agregar l definid pr el cliente del us de brwsers para ls frmularis. (Internet Explrer y Ggle Chrme) Se deben definir versines para ls brwsers. Agregar l definid cn el cliente. Qué servidr de crre se utilizará para el enví de mails? Agregar l definid cn el cliente referid al enví de SMS. Desde cuales cmpañías puede mandar? Que cmpañías pueden recibir ls SMS s? 1.5 Restriccines de memria Definir máxima capacidad de almacenamient del dispsitiv móvil. 2.1 Restriccines tecnlógicas: Se debería agregar cm lenguaje de prgramación para implementar Java Falta agregar las restriccines respect a las dimensines de la pantalla 3.3. Faltan refinar y definir Requerimients Descripción: Ausencias y carencias de infrmación en requerimients funcinales. Ubicación: 3. Requerimients específics (3.1 Requerimients Funcinales, 3.2 Requerimients N Funcinales) Nivel de gravedad: Critic Sugerencia de crrección: Referencias: RqX Requerimient textual del dcument SugX Sugerencia Infrme de Verificación de Dcument Página 4 de 7

5 REQUERIMIENTOS FUNCIONALES Relativ a ls usuaris: Rq1) El sistema debe permitir el registr de usuaris (se identificará pr una cuenta de crre electrónic de gmail). Cuand un usuari se da de alta en el sistema, dará lugar a la creación de una nueva empresa, dentr de la cual tendrá el rl de administradr. Sug1.1) Debería agregarse pder mdificar usuari y dar de baja un usuari (Esta especificad en Md Offline per quizás debería ir aquí). Sug1.2) Dice que un usuari es administradr de una empresa. Un emplead es usuari? El emplead también crea una empresa cuand da de alta su usuari? Rq4) El administradr debe pder agregar empleads a su empresa. Sug4) Se debería definir si el administradr puede quitar empleads y dar la psibilidad de listar ls empleads. Rq5) El administradr brinda ls permiss para que ls empleads puedan: Debe pder asignar permiss a empleads para que puedan traspasar tareas. Debe pder asignar permiss a empleads para que puedan crear/mdificar tareas. Puede asignar permiss a usuaris para crear, mdificar y eliminar cntacts de la agenda de cntacts de la empresa. Puede asignar permiss a empleads para pder cnsultar el calendari de tds ls empleads de la empresa. Sug5) La redacción n queda del td clara, se prpne expner el punt de la siguiente frma. El administradr puede trgarles a sus empleads ls siguientes permiss: a) Traspasar tareas b) Crear/mdificar tareas c) Crear/Mdificar/Brrar Cntacts d) Cnsultar el calendari de tds ls empleads de la empresa Sug_extra01) Detallar tds ls atributs para el alta de usuari pr l mens debe estar cntemplad en el cas de us. Manej de Tareas: Rq2) Ls dats crrespndientes a las tareas, ya sea insums (tip cantidad) resumen de l que se realizó se registrará cm text sin frmat, permitiend una mayr flexibilidad de la aplicación. Sug2) Se debería especificar cuales sn ls dats crrespndientes a las tareas. Infrme de Verificación de Dcument Página 5 de 7

6 Rq4) Ls estads de las tareas n bedecerán un fluj predeterminad, para permitir que el usuari establezca manualmente el mism. Sug4) Se debe establecer si un fluj psible sería cmenzar la tarea en finalizada. O si un fluj psible para una tarea pdría ser: Finalizada->Cmenzada->Pendiente. De n ser psible, es deberían definir flujs psibles. Rq6) Se debe permitir el traspas de tareas entre usuaris de una misma empresa. Una vez asignada la tarea la misma n pdrá ser rechazada. Sug6.1) Definir cm se le cmunica el traspas de una tarea a un usuari, las vías de cmunicación. (Mail, ntificación de Andrid, SMS) Sug6.2) Debería haber una ntificación pr parte del destinatari al remitente para asegurarle que el mensaje le llegó? Manej de Clientes: Rq3) Debems brindar la psibilidad al usuari de imprtar clientes desde la agenda de su dispsitiv. Sug3) Se debería especificar si se deben imprtar tds ls cntacts a la vez si se pueden elegir. Sug_extra01) Definir si habrá una función para Alta de cntacts. Sug_extra02) Definir ls atributs que se guardan del cntact (deben cntenerse pr l mens en cass de us). Sug_extra03) Definir si habrá función para mdificación y baja de cntacts. Ntificacines a ls clientes: Rq2) Una vez que la tarea se encuentre en estad en curs el sistema deberá enviar un recrdatri de la visita al cliente 24 hras antes de la misma. Adicinalmente prveerá la pción de cancelar este recrdatri mdificar el tiemp de anteriridad de enví. Sug2) Definir si est se hace estand el usuari ffline. Rq3) El usuari debe tener la psibilidad de ntificarle a un cliente que va a llegar tarde cancelar un trabaj mediante enví de SMS. Sug3) Definir tiemp de antelación cn que se manda el mensaje. Vías de enví (SMS, mail) Rq5) Al mment de culminar el trabaj se debe enviar un resumen cn el detalle de la tarea realizada, dnde se incluyan ls insums, hras trabajadas y cst ttal. Sug5.1) Definir a quien se le envía el detalle. Sug5.2) Definir cual será la vía para la cmunicación (Mail, SMS) Infrme de Verificación de Dcument Página 6 de 7

7 Rq6) Debe enviarse al cliente una encuesta de satisfacción una semana lueg de culminada la tarea. También frecerá la psibilidad al usuari de cancelar este enví cambiarle el perid en el cual se debe enviar. Al enviar la encuesta se debe dar la psibilidad de que el cliente pueda slicitar una nueva visita, debid a una insatisfacción cn el trabaj realizad pr parte del usuari. El nivel de satisfacción del cliente se evaluará en una escala del 1 al 5, y se asciarán emticnes que representen dicha escala. Sug6) Definir cual será la vía para la cmunicación (Mail, SMS) Md Offline: Rq4) Debe mantenerse sincrnizada la infrmación lcal cn la cntenida en el servidr. Sug4) Definir en que mment se deben sincrnizar. Rq5) Se debe realizar persistencia lcal. Sug5) Se pdría especificar un pc más. Parece n quedar ttalmente entendible al cliente. REQUERIMIENTOS NO FUNCIONALES Cmpletar cn ls nuevs dats recabads tras la crrección de la perspectiva del prduct. Infrme de Verificación de Dcument Página 7 de 7