DDR Genérico Definición de Requisitos del Cliente Proyecto Flujos de Pagos Motor de Pagos

Transcripción

1 DDR Genérico Definición de Requisitos del Cliente Proyecto Flujos de Pagos Motor de Pagos Ingeniería de Software Bancario, S.L. Todos los derechos reservados.

2 Índice 1. INTRODUCCIÓN PROPÓSITO Y AUDIENCIA NORMAS DE CUMPLIMENTACIÓN VOCABULARIO COMÚN Y ACRÓNIMOS REFERENCIAS DESCRIPCIÓN DE LA FUNCIONALIDAD OBJETIVOS Y BENEFICIOS DESCRIPCIÓN ALCANCE ÁMBITO DE IMPLANTACIÓN ÁREAS, USUARIOS Y PROCESOS DE NEGOCIO AFECTADOS CANALES AFECTADOS INTEGRACIÓN Y UBICACIÓN PREVISTAS PARA LA NUEVA APLICACIÓN ENTORNO, ÁMBITO, ALCANCE Y PAÍS RELACIÓN DE PORTALES DESDE LOS QUE SERÁ ACCESIBLE LA APLICACIÓN SITUACIÓN ACTUAL REQUERIMIENTOS FUNCIONALES DESCRIPCIÓN DE FUNCIONALIDADES IMPACTO EN OPERACIÓN BANCARIA REQUERIMIENTOS FUNCIONALES NO INCLUIDOS REQUERIMIENTOS NO FUNCIONALES ANÁLISIS DE USUARIOS DEL SISTEMA VOLUMETRÍA... 11

3 5.3. SEGURIDAD GESTIÓN DE USUARIOS REQUISITOS DE SEGURIDAD USABILIDAD RENDIMIENTO DISPONIBILIDAD ACCESIBILIDAD MOTIVO SOPORTE ACCESIBILIDAD NIVEL DE CONFORMIDAD QUE DEBE CUMPLIR EL SISTEMA MOTIVO NO NECESIDAD ACCESIBILIDAD EN APLICACIÓN CONSERVACIÓN DE LA INFORMACIÓN TRAZABILIDAD DE LA OPERATIVA REQUERIMIENTOS NO FUNCIONALES NO INCLUIDOS CATÁLOGO DE REQUISITOS REVISIÓN FIRMA... 16

4 Control de Ediciones Versión Fecha Modificación Autor V1.0 26/05/2006 Creación Metodología V1.1 03/11/2006 Actualización de nuevos apartados Metodología V1.2 15/04/2010 Actualización de nuevos apartados Metodología V1.3 28/07/2010 Actualización con apartado de requerimientos no contemplados en la petición Metodología

5 1. Introducción 1.1. Propósito y audiencia El propósito del presente documento es dejar claramente definidos los requerimientos funcionales para Santander Chile, que están relacionados a la implementación del Proyecto RTO Historificación y Respaldo de tablas que contienen información requerida para los procesos contables. Se necesita respaldar información de tablas que contienen la información necesaria para generar archivos o interfaces para los sistemas contables, en este caso, la información a respaldar, es la de los pagos liquidados por AGP, con la cual se genera un archivo de movimientos contables el cual es cargado es enviado a final del día por FTP, para que lo tome el Batch Contable Normas de cumplimentación La plantilla general DDR debe cumplimentarse en su totalidad. Como norma general se tendrán en cuenta los siguientes puntos que aplicarán a todo el documento: - No debe eliminarse ningún apartado. En caso de no ser necesaria la información requerida en un apartado de la plantilla, se indicará con un comentario No aplica en el mismo con el objetivo de evitar malentendidos. - Cualquier texto en cursiva y acotado por corchetes (por ejemplo: [Texto de ejemplo]) debe ser borrado en la versión final del documento cumplimentado. - El texto que se introduce en cada apartado y en cada tabla existente en el DDR debe tener el formato adecuado (tipo de letra Arial, de 10 puntos de tamaño, normal y de color negro) Vocabulario común y acrónimos Término AGP Definición Administración y Gestión de Pagos también conocido como Motor de Pagos

6 1.4. Referencias Referencia Documento 2. Descripción de la Funcionalidad 2.1. Objetivos y beneficios La finalidad del documento es detallar los distintos requerimientos funcionales y técnicos necesarios para el proceso de respaldo de información para la generación de archivos para contabilidad en AGP Descripción Dentro de los procesos de carga de información contable al sistema ASICLISER, existen dos tipos de alimentación a éste, una de ellas es la generación de un archivo Excel en forma automática realizada por el aplicativo de Recaudaciones, el archivo generado está con el formato que necesita en aplicativo de contabilidad para que sea cargado automáticamente. El otro proceso para generar información al sistema contable, es manual, esto es, de los distintos informes o cuadraturas que realiza el aplicativo de Recaudaciones, la gente de Santander GRC, toma información de éstos y manualmente genera los archivos para que luego sean cargados en ASICLISER Alcance Ámbito de implantación El proyecto de historificación y respaldo de información no tendrá impacto en el aplicativo de Recaudaciones Santander GRC, debido a que el proyecto implica sólo el respaldo de información y no realiza cambios a los aplicativos mencionados Áreas, Usuarios y Procesos de Negocio afectados. Como no hay cambios funcionales, no se ven afectadas las áreas de negocio..

7 2.4. Canales afectados Canal Afectado (S/N) Internet Particulares Internet Empresas Intranet Web pública Oficina Contact Center Movilidad Autoservicio_Cajeros Medidadores_Agentes Otros (Identificar) Santander GRC 2.5. Integración y Ubicación Previstas para la nueva Aplicación Entorno, Ámbito, Alcance y País. Recaudaciones: Plataforma Medias, SQL Server, Chile Relación de Portales desde los que será accesible la Aplicación. No tiene relación con portales.

8 3. Situación Actual Actualmente, el aplicativo de Recaudaciones de Santander GRC genera un archivo de forma automática, el cual es cargado directamente al aplicativo contable ASICLISER, este archivo se genera después de realizado el cierre diario de todas las cajas a nivel país de Santander GRC, entonces el archivo contiene la información de los movimientos de pagos del día contable. Junto con esto, existe otro proceso manual para generar para generar información al sistema contable, esto es, de los distintos informes o cuadraturas que genera el aplicativo de Recaudaciones, la gente de Santander GRC, toma información de éstos y manualmente la ingresa a una planilla Excel, para que luego sean cargados en ASICLISER. En relación a los respaldos, sólo están considerados respaldos operativos por parte de Produban. 4. Requerimientos Funcionales 4.1. Descripción de funcionalidades El aplicativo de Recaudaciones de Santander GRC, tiene la funcionalidad de generar en forma automática el archivo Excel que es cargado por el aplicativo contable ASICLISER Descripción de las tablas Las tablas que intervienen en el proceso de Generación del archivo para contabilidad tanto para el proceso automático como manual, y que deben ser respaldadas como objetivo de este proyecto, son las siguientes: TABLA DESCRIPCIÓN CYRPAGOATP Contiene el consolidado de los pagos, tanto en efectivo, cheque, mixto y TC. CYRPAGOEFECTIVO Contiene pagos de cuentas pagadas en efectivo. CYRPAGOCHEQUE Contiene pagos de cuentas pagadas con documento. CYRPAGOMIXTO Contiene pagos realizados en efectivo y cheque. CYRPAGOTARJETA Contiene los pagos realizados con Tarjeta de crédito (POS).

9 CYRDETCUOTA Contiene el detalle de todas las cuotas pagadas de una operación. CYRINGRESOSEGRESOSCAJA Contiene información de comprobantes de pago ingresados manualmente por el aplicativo de Recaudaciones, estos se denominan, comprobantes contables. GRC_CuentasResumenCaja Contiene cuentas contables y centros de costo para generar Excel de contabilidad a ASICLISER. GRC_CUENTASFUERA Tabla paramétrica para la generación de Excel a contabilidad a ASICLISER. CYRACCAJA Contiene los movimientos de cierres y aperturas de todas las cajas a nivel país. CYREIRECAUDO Contiene movimientos de pagos de Honorarios, tales como; costas judiciales, honorarios castigo, honorarios pendientes de cobro, etc. CYRCCONTABLES Tabla de parámetros fijos, donde se encuentran las cuentas para realizar la cuadratura de caja. CYRDEFCCONTAB Tabla de parámetros que contiene cuentas contables para realizar cuadratura de caja y resúmenes de caja a nivel administrador. CYRMOVTESORERIA Contiene los movimientos de Ingreso, egreso y depósito por día y sucursal. CYRTESORERIA Contiene información de los arqueos de las cajas, movimiento de dinero para las distintas nominaciones y cheques. CYRAPERTURAT Registro de apertura de Tesorería.

10 Ubicación y volumetría de las tablas Las tablas se encuentran en el servidor SVRCOBRA1, base de datos COBRA, el siguiente es el cuadro con la volumetría de dichas tablas. TABLA N DE REGISTROS PESO CYRPAGOATP KB CYRPAGOEFECTIVO KB CYRPAGOCHEQUE KB CYRPAGOTARJETA KB CYRPAGOMIXTO KB CYRDETCUOTA KB CYRINGRESOSEGRESOSCAJA KB GRC_CuentasResumenCaja 18 8 KB GRC_CUENTASFUERA 1 8 KB CYRACCAJA KB CYREIRECAUDO KB CYRCCONTABLES 30 8 KB CYRDEFCCONTAB 47 8 KB CYRMOVTESORERIA KB CYRTESORERIA KB CYRAPERTURAT 1 8 KB Nota: los valores son al día de hoy (03 de Julio de 2014).

11 4.2. Impacto en Operación Bancaria Con este respaldo de tablas no hay impacto sobre la operativa bancaria Requerimientos Funcionales No Incluidos No existen requerimientos funcionales, todos son de carácter técnico. 5. Requerimientos No Funcionales 5.1. Análisis de Usuarios del Sistema Respaldo de las tablas especificadas en el punto Categoría usuario Descripción y patrones de uso Identifique cómo los distintos tipos de usuarios acceden al sistema y proporcionan objetivos de uso previsto. Por ejemplo: Existen horas pico de acceso al sistema para este tipo de usuario? Cuáles son las horas de acceso habituales? Se distribuyen globalmente los usuarios? Cuál es la duración prevista de la conectividad del usuario? Hay tipos de usuario que realizan gran volumen de transacciones en períodos identificados? 5.2. Volumetría La volumetría para este proyecto se muestra en el punto número

12 Concepto analizado Descripción Número de usuarios por categoría Volumen de Transacciones por tipo de usuario Volumen de Datos Previsiones de crecimiento 5.3. Seguridad No hay requerimientos especiales de seguridad Gestión de usuarios. No hay cambio en la gestión de usuarios Requisitos de Seguridad. No hay cambios en los requisitos de seguridad. AUTENTICACIÓN [Indicar si es necesaria la autenticación del usuario para acceder, el método de autenticación, procedimiento de gestión de la password, ] PERSONALIZACIÓN [Se indicarán los nuevos contenidos generados por la aplicación (opciones de menú / páginas de inicio) y los usuarios que tendrán acceso a cada contenido. La personalización tiene como objetivo proporcionar los contenidos adecuados a cada usuario en función de unas reglas preestablecidas.] Contenido Usuario con acceso al contenido SEGURIDAD OPERATIVA

13 [Indicar las reglas de seguridad operativa que afectan al sistema. La seguridad operativa proporciona el control necesario para que cada usuario sólo pueda ejecutar aquellas operaciones para las que está autorizado, con unos datos determinados, aplicando unas reglas preestablecidas.] Id. Regla Descripción de la Regla CERTIFICACIÓN OPERATIVA [Indicar si se requiere o no certificación operativa, es decir, si es necesaria la firma o certificación final por parte del usuario de la operación / transacción] Usabilidad [Los requisitos de usabilidad deben ajustarse a la Normativa de Usabilidad vigente en el momento de elaboración del DDR y que aplique para este proyecto Rendimiento [Los requisitos de rendimiento deben ajustarse a la Normativa de Calidad relativa al Rendimiento (Normativa de Rendimiento, Normativa de Rendimiento para Portales, Normativa de Produban).] 5.6. Disponibilidad No aplica Accesibilidad [ESTE APARTADO ES DE OBLIGADO CUMPLIMIENTO, y en caso de que no existan requerimientos de este tipo se ha de indicar de forma explícita. Este apartado debe contener los requisitos de Accesibilidad que debe cumplir el sistema, el nivel de conformidad y el motivo por el que se exige. Para rellenar este apartado aplica la normativa general publicada por Usabilidad, donde los requisitos de Accesibilidad dependen fundamentalmente de si es una web pública o interna. En caso de duda o discrepancia consultar con Arquitectura Técnica] Motivo soporte accesibilidad [Indicar cuales de los siguientes motivos hacen que sea necesario el soporte a la accesibilidad]

14 Ok Motivo Requerido por legislación en el país Requerido por legislación de un ámbito geográfico/político, p.ej, Normativa de la Unión Europea Requerido por normativa del banco destino Otros (Indicar): Nivel de conformidad que debe cumplir el sistema [Indicar si el nivel de conformidad es A, AA, o AAA. Para más información consultar en Motivo no necesidad accesibilidad en aplicación [En caso de no requerir accesibilidad, debe de indicarse la razón por la que no se debe de tener en cuenta en el desarrollo del sistema] 5.8. Conservación de la información [Incluir los requerimientos relativos a la conservación de la información que genera y almacena el sistema. La conservación de la información se refiere tanto a copias de respaldo de la información de los datos almacenados por el sistema como a su histórico. Copia de respaldo: conjunto de información almacenada por el sistema y que se considera lo suficientemente importante como para ser conservada. Histórico de datos: conjunto de información almacenada por el sistema de la que se requiere copias sucesivas a lo largo del tiempo. En ambos casos se detallará tipo de almacenamiento (completo o incremental), la periodicidad y la ubicación.] 5.9. Trazabilidad de la Operativa [Incluir los requerimientos relativos a la trazabilidad de la operativa del sistema: si el sistema requiere monitorización, ficheros de logs, trazas, etc.] Requerimientos No Funcionales No Incluidos [Apartado Opcional - Se describirá de una manera ordenada y estructurada los requerimientos no funcionales del sistema que no están incluidos dentro del alcance del proyecto.]

15 6. Catálogo de Requisitos [Basándonos en la descripción de los requisitos Funcionales y No funcionales elaborar un Catálogo de Requisitos, asignarles un código y detallar cada requisito. El Catálogo de Requisitos se elaborará en un fichero Excel y se incrustará en este apartado.] Catalogo de Requisitos 7. Revisión [La revisión del DDR es un requisito formal por el que se verifica y se valida que los requisitos especificados son coherentes y se detallan a nivel suficiente. En el caso de que el resultado de la revisión sea el rechazo del DDR, es obligatorio rellenar el campo Motivo del rechazo.] Revisión Nombre Función Departamento/Área [Nombre de la persona que revisa] [Role de la persona anterior] [Departamento/Área de la persona anterior] Resultado Revisión [OK/KO] Fecha [Cuándo se realiza la revisión] Motivo Rechazo Nombre [Detalle motivo rechazo] [Nombre de la persona que revisa]

16 8. Firma [El representante del usuario dará su aprobación o rechazo al DDR mediante la firma del documento, una vez comprobado que cumple con sus necesidades. En caso de rechazo deberá indicar el motivo del mismo en el apartado correspondiente.] Firma Nombre Función Departamento/Área [Nombre de la persona que firma] [Role de la persona anterior] [Departamento/Área de la persona anterior] Firma [OK/KO] Fecha [Cuándo se realiza la firma] Motivo Rechazo Nombre [Detalle motivo rechazo si KO] [Nombre de la persona que firma]