| Item | Descripción |
Nombre del sistema | AD-CCESS |
Versión | 1.0 |
3.2 REQUISITOS FUNCIONALES.
3.2.1 Ingreso a la aplicación
Elemento | Descripción |
ID del requisito | RF-3.2.1 |
Nombre del requisito | APERTURA DE LA APLICACIÓN |
Descripción | EL SISTEMA DEBE PERMITIR ABRIR POR MEDIO DE LA CABECERA HTTP |
Precondición | DEBE EXISTIR USUARIOS CREADOS PREVIAMENTE POR ADMIN |
Postcondición | SEGÚN ROL REGISTRADO TENDRA HABILITADAS FUNCIONES |
Prioridad | ALTA |
Dependencias | REQUIERE LA FUNCIONALIDAD DE AUTENTICACION DE USUARIOS |
Criterios de aceptación | DE FARICA ESTA CREADO EL ADMINISTRADOR DEL SISTEMA QUE SE ENCARGARA DE CREAR NUEVOS ADMINISTRADORES POR MEDIO DE NOMBRE, EMAIL, ID UNICO Y CONTRASEÑA |
Notas/ Observaciones | SI ES LA PRIMERA VEZ DE USO DEL SOFTWARE NO HAY USUARIOS CREADOS Y VIENE UNA CLAVE POR DEFECTO PARA ADMINISTRADOR DE SISTEMA PARA CAMBIAR CLAVES DE FABRICA Y CREAR NUEVO USUARIO ADMINISTRADOR. USUARIO ADMINISTRADOR DE SISTEMA SOLO PARA SOPORTE E INICIOS DE USO DEL SOFTWARE. |
3.2.2 administración de usuarios
Elemento | Descripción |
ID del requisito | RF-3.2.2 |
Nombre del requisito | INGRESO O SUPRESION DE ROLES |
Descripción | EL SISTEMA DEBE PERMITIR EL INGRESO DE UNO O MAS ROLES Y DE IGUAL MANERA SU SUPRESION |
Precondición | HABER CREADO UN USUARIO ADMINISTRADOR EN EL SOFTWARE |
Postcondición | TENDRA LA OPCION DE ADMINISTRAR USUARIOS, AL INGRESAR A ESTA OPCION SE DESPLEGA UN LISTADO DE LOS USUARIOS, LOS USUARIOS NUEVOS SE ASIGNARÁN A UN ROL ESPECIFICO, EL ADMINISTRADOR GUARDA CAMBIOS Y SE PROCEDE A ALMACENAR LOS NUEVOS CAMBIOS |
Prioridad | ALTA |
Dependencias | DEBE EXISTIR UN USUARIO ADMINISTRADOR |
Criterios de aceptación | · JERARQUIA DE ROLES: ADMINISTRADOR DE USUARIOS, PORTERO / SEGURIDAD, PROPIETARIO-RESIDENTE, VISITANTE, TRABAJADOR. · AL CREAR UN NUEVO USUARIO, SE PODRA ASIGNARLE UN ROL EXISTENTE. · SE PODRA CREAR, MODIFICAR O ELIMINAR UN USUARIO · Datos del usuario: nombre completo, tipo de usuario, cedula, email, clave de acceso
|
Notas/ Observaciones | EL ADMINISTRADOR DEL SISTEMA ES UN ROL DE FABRICA PARA INICIALIZAR EL PRODUCTO Y SE ENCARGARA DE CREAR EL PRIMER USUARIO ADMINISTRADOR. EL USUARIO DEL SISTEMA ES UN USUARIO PARA SOPORTE. |
Elemento | Descripción |
ID del requisito | RF-3.2.3 |
Nombre del requisito | Creación de usuario con rol de administrador |
Descripción | Puede crear nuevos usuarios con cualquier tipo de rol, será encargado de administrar los módulos de AGENDA, PQRS, crear usuario propietario-residente, administrar módulo de difusión de información global. |
Precondición | Recibir entrega de manejo del software por parte del distribuidor y actualizar clave de administrador del sistema para luego crear el usuario administrador |
Postcondición | Ingresa a un menú administrativo que tendrá opciones de creación de usuarios, modulo PQRS, AGENDA, Difusión de mensajes |
Prioridad | Alta |
Dependencias |
|
Criterios de aceptación | Podrán existir varios usuarios administradores y ninguno se podrá eliminar entre si. Solo podrá eliminar el administrador del sistema el rol de administrador de usuarios. Toda modificación quedara documentada en un registro LOG del sistema |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.4 |
Nombre del requisito | Creación de usuario con rol de propietario-residente |
Descripción | Este rol solo puede ser creado por el usuario administrador por el tipo de información sensible y delicada. Acá se crea un usuario por apartamento y tendrá la información de los integrantes de familia, cantidad de vehículos permitidos según normas de la unidad residencial de los cuales se registrará placa, modelo y color de cada vehículo. Se asignará un ID único, se registrará un email, foto y contraseña |
Precondición | Existencia de un usuario administrador que se encargara de la creación de rol propietario-residente |
Postcondición | Usuario en base de datos que tendrá autorización de ingreso a la unidad residencial |
Prioridad | ALTA |
Dependencias | Solo crea este perfil de usuario un rol de administrador que debe estar previamente creado
|
Criterios de aceptación | este usuario tendrá un único ID para identificarse en la plataforma, pero tendrá integrantes familiares con acceso de ingreso a la unidad residencial |
Notas/ Observaciones | El acceso vehicular o peatonal puede ser por medio de tag o tarjetas de proximidad con marcas específicas que se podrán vincular con el software para permitir una automatización del proceso y registro autónomo de la información. Es opcional debido a que se deben adquirir periféricos electrónicos para este fin. |
Elemento | Descripción |
ID del requisito | RF-3.2.5 |
Nombre del requisito | Creación de usuario con el rol de portero/vigilante |
Descripción | Este rol tendrá la posibilidad de crear los usuarios con rol de visitante o trabajador y tendrá acceso a modulo para PQRS que le permitirá comunicarse con administración, tendrá modulo de CORRESPONDENCIA que le permitirá notificar a los propietarios-residentes si llego alguna encomienda |
Precondición | El usuario debe estar autenticado como portero/vigilante El sistema debe estar en funcionamiento y accesible Debe existir un módulo para la gestión de usuarios y roles |
Postcondición | El sistema debe registrar la creación de un nuevo usuario VISITANTE o TRABAJADOR
|
Prioridad | ALTA |
Dependencias | DEBE EXISTIR BASE DE DATOS ORGANIZADA PARA LOS VISITANTES Y TRABAJADORES
|
Criterios de aceptación | EL ROL DEBE CONTERNER INFORMACION: NOMBRE COMPLETO, EMAIL, FOTO, CONTRASEÑA. |
Notas/ Observaciones |
|
3.2.3 creación de registros
Elemento | Descripción |
ID del requisito | RF-3.2.6 |
Nombre del requisito | CREACION DE REGISTRO DE VISITANTE |
Descripción | SE REGISTRA UN VISITANTE Y SE LE PIDE DATOS BASICOS COMO: NOMBRE COMPLETO, CEDULA, SE TOMA FOTO DEL ROSTRO, LUGAR AL QUE SE DIRIJE. |
Precondición | USUARIO PORTERO / VIGILANTE REGISTRA DESDE SU MODULO LA CREACION DEL VISITANTE |
Postcondición | QUEDA EN BASE DE DATOS UN NUEVO REGISTRO DE VISITANTE |
Prioridad | ALTA |
Dependencias | SISTEMA EN FUNCIONAMIENTO |
Criterios de aceptación | EL REGISTRO DEBE CONTERNER INFORMACION: NOMBRE COMPLETO, CEDULA, FOTO DEL ROSTRO, LUGAR AL QUE SE DIRIJE |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.7 |
Nombre del requisito | CREACION DE REGISTRO DE TRABAJADOR |
Descripción | SE REGISTRA UN TRABAJADOR Y SE PIDEN DATOS BASICOS COMO: NOMBRE COMPLETO, CEDULA, SE TOMA FOTO DEL ROSTRO, SE REGISTRA LUGAR EN EL QUE VA A TRABAJAR O LA ACTIVIDAD A REALIZAR, CONTACTO DE EMERGENCIA, EMPRESA DONDE TRABAJA |
Precondición | USUARIO PORTERO / VIGILANTE REGISTRA DESDE SU MODULO LA CREACION DEL TRABAJADOR |
Postcondición | QUEDA EN BASE DE DATOS UN NUEVO REGISTRO DE TRABAJADOR |
Prioridad | ALTA |
Dependencias | SISTEMA EN FUNCIONAMIENTO |
Criterios de aceptación | EL ROL DEBE CONTERNER INFORMACION: NOMBRE COMPLETO, CEDULA, FOTO DEL ROSTRO, LUGAR AL QUE SE DIRIJE, ACTIVIDAD A REALIZAR. |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.8 |
Nombre del requisito | MODIFICAR Y ELIMINAR |
Descripción | EL ADMINISTRADOR TIENE UN MODULO QUE LE PERMITE LISTAR LOS USUARIOS, MODIFICAR Y ELIMINAR USUARIOS, LOS REGISTROS DE VISITANTES Y TRABAJADORES NO SE BORRAN. |
Precondición | EXISTENCIA DE USUARIOS |
Postcondición | modificación de base de datos y registro en archivo LOG del evento ocurrido |
Prioridad | Alta |
Dependencias |
|
Criterios de aceptación | La base de datos se modifica y actualiza con los valores resultantes |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.9 |
Nombre del requisito | Actualización de datos de propietario-residente |
Descripción | Cuando se requiera un cambio en la información de la base de daos del usuario propietario-residente se tendrá que notificar al administrador para hacer la gestión de cambio. |
Precondición | Usuario propietario-residente existente |
Postcondición | Actualización de datos |
Prioridad | Alta |
Dependencias |
|
Criterios de aceptación | Actualización de información en base de datos |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.10 |
Nombre del requisito | Módulo de AGENDA |
Descripción | Esta funcionalidad permite al propietario-residente solicitar reserva de un área común en una determinada fecha y será la administración quien avale si ese día requerido hay disponibilidad del sitio |
Precondición | Usuario propietario-residente crea la solicitud |
Postcondición | En modulo administrativo se revisa la notificación de solicitud y se evalúa si es posible asignar en el día solicitado el espacio del área común requerida. |
Prioridad | Alta |
Dependencias | Que el sitio no esté en mantenimiento o este ocupado. |
Criterios de aceptación | En el modulo AGENDA se visualiza en Interfax un calendario con las fechas disponibles y ocupadas para determinada área común que es posible reservar, desde el modulo de propietarios-residentes se solicita y desde el módulo de administración se avala y se marca la reserva autorizada |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.11 |
Nombre del requisito | Módulo de PQRS |
Descripción | es un módulo en donde se notifica al módulo de administración alguna PQRS y desde el módulo administrativo se hace seguimiento y se cierra el caso. Desde el módulo de portero/vigilante o propietario-residente se crea el caso dirigido a administración. los tipos de solicitudes que se pueden registrar y que competen a la administración (mantenimiento, seguridad, limpieza, etc.). |
Precondición | El modulo de portería/vigilante o propietario-residente inicia el caso de PQRS y desde administración se hace gestión, seguimiento, solución y cierre |
Postcondición | Hilo de conversación para cada caso presentado por cada usuario. |
Prioridad | Alta |
Dependencias | Existencia de alguna novedad que compete a la unidad residencial |
Criterios de aceptación | Se hace el seguimiento de la novedad y quedara almacenado el hilo de la conversación con una bandera de aviso si esta el caso abierto o concluido. El usuario puede adjuntar archivos (fotos, documentos) a la pqrs El sistema asignara automáticamente un numero de caso a cada PQRS Cada caso cerrado tendrá opción de evaluación por parte del creador del caso, usuario portero/vigilante o propietario-residente, la evaluación se hará con iconos de una mano con dedo arriba para indicar satisfecho y una mano con dedo abajo para indicar insatisfecho. Se tendrán métricas de éxito en el modulo de administración.
|
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RF-3.2.13 |
Nombre del requisito | control de acceso de vehículos flexible |
Descripción | Permitir la gestión de vehículos de propietarios y visitantes, incluyendo opciones para el uso compartido de parqueaderos |
Precondición | Debe estar creado un módulo de visitantes, propietario-residentes y trabajadores |
Postcondición | Información almacenada en base de datos |
Prioridad | Alta |
Dependencias | Módulos previamente creados: visitante, trabajador, propietario-residente |
Criterios de aceptación | Según el conjunto residencial se permitirá o no el ingreso de vehículos de visitantes o trabajadores y también se determinará una cantidad de vehículos por propietario previamente registrados |
Notas/ Observaciones |
|
3.3 requisitos no funcionales
Elemento | Descripción |
ID del requisito | RNF-3.3.1 |
Nombre del requisito | CANTIDAD DE INFORMACION ALMACENADA |
Descripción | El sistema debe soportar la información de registros diarios |
Categoría | Usabilidad |
Prioridad | Alta |
Dependencias | Depende de la infraestructura de equipos y medios tecnológicos a utilizar |
Criterios de aceptación | Debe almacenar la información por lo menos un año y permitir hacer backup para almacenamiento en equipos externos. El sistema debe tener en cuenta que información puede ser eliminada y cual debe conservarse |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RNF-3.3.2 |
Nombre del requisito | Base de datos |
Descripción | El sistema debe permitir la manipulación de la información por medio de un motor de base de datos |
Categoría | Usabilidad |
Prioridad | Alta |
Dependencias | Depende de la infraestructura de equipos y medios tecnológicos a utilizar |
Criterios de aceptación | Las consultas que permiten la interacción de los scripts con la base de datos deben permitir interactuar con el motor de base de datos |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RNF-3.3.3 |
Nombre del requisito | DISPONIBILIDAD DEL SISTEMA |
Descripción | El sistema debe ser capaz de operar 24 horas en el día |
Categoría | Usabilidad |
Prioridad | Alta |
Dependencias | Depende de que siempre haya fluido eléctrico y que no haya daños de infraestructura |
Criterios de aceptación | Funcionamiento 24 horas para cualquier usuario que este registrado. |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RNF-3.3.4 |
Nombre del requisito | SEGURIDAD DEL SISTEMA |
Descripción | El sistema debe permitir encriptar las claves de acceso para mayor seguridad |
Categoría | Usabilidad |
Prioridad | Alta |
Dependencias | Un usuario requiere ser validado en el sistema, al momento de su creación el script correspondiente encriptara la clave para almacenarla en la base de datos |
Criterios de aceptación | Clave almacenada y encriptada en base de datos. Un usuario que no este almacenado en la base de datos no se le permitirá acceso |
Notas/ Observaciones |
|
Elemento | Descripción |
ID del requisito | RNF-3.3.5 |
Nombre del requisito | Capacitacion y soporte al usuario |
Descripción | Proveer documentación, capacitación inicial y soporte técnico para que los usuarios puedan utilizar el software de manera efectiva, reduciendo la curva de aprendizaje |
Categoría | Usabilidad |
Prioridad | Alta |
Dependencias | Un usuario requiere ser validado en el sistema, al momento de su creación el script correspondiente encriptara la clave para almacenarla en la base de datos |
Criterios de aceptación | Clave almacenada y encriptada en base de datos. Un usuario que no este almacenado en la base de datos no se le permitirá acceso |
Notas/ Observaciones |
|