Banco:
consignaciones y
retiros
Valentina Prado Marín – Carlos Mario Garaicoa
Alejandro Forero Cardona – Carlos Arturo Minota López
Índice
01 Requisitos Funcionales
02 Requisitos de Calidad
03 Restricciones
04 Arquitectura de Software
05 Diagramas
01
Requisitos funcionales
Requisitos funcionales
R1. El usuario podrá autenticarse en el sistema con usuario y
contraseña, con esto será identificado por la aplicación.
R2. El sistema enviará un correo electrónico a la dirección
diligenciada por el usuario para verificar que se trata de una
dirección real al momento de registrarse en la aplicación.
R3. Al momento de hacer una consignación el sistema verificará
tanto el saldo disponible como el valor que va a consignar a la
cuenta destino, si el monto a consignar es mayor al que tiene
disponible la transacción no se puede realizar, el sistema debe
mostrar el mensaje "No tiene suficiente saldo disponible".
Requisitos funcionales
R4. El sistema validará al momento de realizar una consignación
que la cuenta destino exista, de lo contrario debe mostrar el
mensaje "No se ha encontrado la cuenta destino"
R5. El sistema calculará y actualizará cual es el saldo disponible
después de realizar una consignación, ya sea hacía otra cuenta,
dinero que ingrese a esta, o un retiro.
R6. El sistema enviará un correo al usuario al momento de
realizar un retiro con el detalle del monto, dónde y la hora que se
realizó el retiro.
R7. El sistema enviará un correo al usuario al momento de que se
le consigne a la cuenta
Requisitos funcionales
R7. El sistema enviará un correo al usuario al momento de que se
le consigne a su cuenta con el detalle de, quién, monto y ahora
que se realiza la consignación.
R8. El sistema tendrá un límite máximo de consignaciones y
retiros, esto está sujeto a las políticas del banco.
R9. El sistema deberá encriptar todas las consignaciones y retiros
para proteger los datos de los clientes.
R10. El sistema contará con un historial de transacciones
realizadas, ya sean consignaciones o retiros, tendrán alto detalle
para realizar registro y auditoría.
Requisitos funcionales
R11. El sistema tendrá un monto límite estándar para realizar
consignaciones o retiros el cual podrá ser editado por el usuario,
esto está sujeto a las políticas del banco.
02
Requisitos de calidad
Requisitos de calidad
1.PRECISION Y CONFIABILIDAD
● El sistema debe ser preciso y confiable al registrar y
procesar las transacciones.
● Los saldos de cuentas deben reflejar con exactitud las
transacciones realizadas.
2.SEGURIDAD
● Implementar medidas de seguridad robustas para proteger
los datos y las cuentas de los clientes contra accesos no
autorizados o actividades fraudulentas.
Requisitos de calidad
3.VELOCIDAD Y EFICIENCIA
● El sistema debe procesar rápidamente las transacciones de
consignaciones y retiros.
● Tiempos de respuesta mínimos y sin retrasos significativos.
4.DISPONIBILIDAD
● El sistema debe estar disponible constantemente para que
los clientes realicen transacciones en cualquier momento.
● Minimizar el tiempo de inactividad y asegurar alta
disponibilidad del sistema.
Requisitos de calidad
5.FACILIDAD DE USO
● Interfaz intuitiva y proceso de consignaciones y retiros
sencillo para los clientes.
● Minimizar errores y mejorar la experiencia del usuario.
6.CUMPLIENTO NORMATIVO
● Cumplir con las regulaciones y requisitos legales aplicables
a las transacciones financieras.
● Protección de datos y privacidad de los clientes.
04
Arquitectura de
Software
Arquitectura a Utilizar Multi-tier
(a) Capa de Presentación
• Esta capa se encarga de la interfaz de usuario, donde los clientes interactúan con el sistema para realizar
consignaciones y retiros.
• Puede incluir componentes como interfaces web, aplicaciones móviles y cajeros automáticos.
(b) Capa de Seguridad
• La seguridad es un aspecto crítico en un sistema bancario. Esta capa se encarga de implementar medidas
de seguridad para proteger los datos y prevenir fraudes.
• Puede incluir componentes como autenticación de usuarios, cifrado de datos, monitoreo de actividad
sospechosa y cumplimiento de estándar
Arquitectura a Utilizar Multi-tier
(c) Capa Lógica
• Aquí se encuentra la lógica de negocio del sistema bancario, que maneja las reglas y los procesos
relacionados con las consignaciones y retiros.
• Puede incluir componentes como gestión de cuentas, verificación de saldos, validación de transacciones
y cálculo de comisiones.
(d) Capa de Integración
• En un sistema bancario, es común tener integraciones con sistemas externos, como redes de pago,
proveedores de servicios financieros y sistemas de verificación de identidad.
• Esta capa se encarga de facilitar las interacciones y comunicaciones con esos sistemas externos.
Arquitectura a Utilizar Multi-tier
(e) Capa de Acceso a Datos
• Esta capa se ocupa de acceder y gestionar los
datos relacionados con las cuentas bancarias,
transacciones y otros detalles relevantes.
• Puede incluir componentes como gestores de
bases de datos, servicios de almacenamiento y
APIs para interactuar con sistemas externos,
como redes de pago.
Patrones a Utilizar
(a) Patrón Repository
● Este patrón proporciona una capa de abstracción entre la capa de acceso a datos y la capa de lógica de negocio.
● Permite gestionar las operaciones de lectura y escritura en la base de datos a través de métodos bien definidos en
lugar de acceder directamente a la base de datos.
● Facilita el intercambio de tecnologías de almacenamiento de datos sin afectar la lógica de negocio.
(b) Patrón Service
• Este patrón se utiliza para encapsular la lógica de negocio compleja y exponerla como servicios reutilizables.
• Permite una mayor modularidad y desacoplamiento al separar la lógica de negocio de la capa de presentación.
• Facilita la reutilización de la lógica empresarial en diferentes partes del sistema.
05
Diagramas
Diagrama de Entidad – Relación
Diagrama de componentes
Gracias
¿Alguna pregunta?
CRÉDITOS: Esta plantilla para presentaciones es una creación de
Slidesgo, e incluye iconos de Flaticon, infografías e imágenes de
Freepik y contenido de Eliana Delacour
Por favor, conserva esta diapositiva para atribuirnos