2 Tipos de Requerimientos
📊 Clasificación de Requerimientos
Section titled “📊 Clasificación de Requerimientos”Los requerimientos de software se clasifican en dos categorías fundamentales que definen aspectos complementarios del sistema: los requerimientos funcionales que especifican qué debe hacer el sistema, y los requerimientos no funcionales que establecen cómo debe comportarse.
🎯 Taxonomía General
Section titled “🎯 Taxonomía General”⚙️ Requerimientos Funcionales
Section titled “⚙️ Requerimientos Funcionales”Los requerimientos funcionales describen las capacidades, funciones y servicios que el sistema debe proporcionar. Especifican el comportamiento del sistema en términos de entradas, procesamiento y salidas.
📖 Definición Formal
Section titled “📖 Definición Formal”🔍 Características Principales
Section titled “🔍 Características Principales”-
Especificidad de Comportamiento
Definen acciones concretas y observables que el sistema debe ejecutar en respuesta a entradas o eventos específicos.
-
Orientación a Funcionalidad
Se centran en las capacidades del sistema desde la perspectiva del usuario o del negocio.
-
Verificabilidad Directa
Pueden ser probados mediante casos de prueba que validan la presencia o ausencia de la funcionalidad.
-
Independencia de Implementación
Describen QUÉ debe hacer el sistema, no CÓMO debe implementarse técnicamente.
📊 Categorías de Requerimientos Funcionales
Section titled “📊 Categorías de Requerimientos Funcionales”📝 Estructura de un Requerimiento Funcional
Section titled “📝 Estructura de un Requerimiento Funcional”Un requerimiento funcional bien formulado debe incluir:
| Componente | Descripción | Ejemplo |
|---|---|---|
| Identificador | Código único de trazabilidad | RF-001 |
| Nombre | Título descriptivo breve | Login de usuario |
| Descripción | Especificación detallada del comportamiento | El sistema debe permitir a los usuarios autenticarse mediante email y contraseña |
| Precondiciones | Estado requerido antes de ejecutar | Usuario registrado en el sistema |
| Entradas | Datos que recibe la función | Email, contraseña |
| Proceso | Lógica o algoritmo a ejecutar | Validar credenciales contra base de datos |
| Salidas | Resultados esperados | Sesión iniciada o mensaje de error |
| Postcondiciones | Estado del sistema después de ejecutar | Usuario autenticado con sesión activa |
| Prioridad | Importancia relativa | Alta, Media, Baja |
💡 Ejemplos de Requerimientos Funcionales
Section titled “💡 Ejemplos de Requerimientos Funcionales”-
Sistema de E-commerce
RF-001: El sistema debe permitir a los usuarios agregar productos al carrito de compras.
RF-002: El sistema debe calcular automáticamente el total de la compra incluyendo impuestos y costos de envío.
RF-003: El sistema debe procesar pagos mediante tarjeta de crédito, débito y PayPal.
-
Sistema Bancario
RF-010: El sistema debe permitir transferencias entre cuentas del mismo banco en tiempo real.
RF-011: El sistema debe generar un comprobante PDF (Portable Document Format) de cada transacción realizada.
RF-012: El sistema debe bloquear automáticamente una cuenta después de 3 intentos fallidos de login.
-
Sistema de Gestión Académica
RF-020: El sistema debe permitir a los estudiantes inscribirse en cursos disponibles.
RF-021: El sistema debe calcular automáticamente el promedio ponderado de calificaciones.
RF-022: El sistema debe generar reportes de asistencia por estudiante y por curso.
✅ Criterios de Calidad
Section titled “✅ Criterios de Calidad”Un requerimiento funcional de calidad debe ser:
📋 Plantilla de Especificación
Section titled “📋 Plantilla de Especificación”ID: RF-XXXNombre: [Nombre descriptivo de la funcionalidad]Prioridad: [Alta | Media | Baja]Módulo: [Módulo o componente del sistema]
Descripción:El sistema debe [verbo de acción] [objeto] [condiciones/restricciones].
Precondiciones:- [Estado o condición requerida 1]- [Estado o condición requerida 2]
Flujo Principal:1. [Paso 1 del proceso]2. [Paso 2 del proceso]3. [Paso 3 del proceso]
Flujos Alternativos:- [Escenario alternativo 1]- [Escenario alternativo 2]
Criterios de Aceptación:- [Criterio verificable 1]- [Criterio verificable 2]
Dependencias:- [RF-XXX: Requerimiento relacionado]ID: RF-015Nombre: Procesamiento de Pago con TarjetaPrioridad: AltaMódulo: Módulo de Pagos
Descripción:El sistema debe permitir a los usuarios realizar pagos de sus comprasutilizando tarjetas de crédito o débito (Visa, Mastercard, American Express)de forma segura y obtener confirmación inmediata de la transacción.
Precondiciones:- Usuario autenticado en el sistema- Carrito de compras con al menos un producto- Total de compra calculado correctamente- Pasarela de pago disponible
Flujo Principal:1. Usuario selecciona método de pago "Tarjeta de Crédito/Débito"2. Sistema muestra formulario de datos de tarjeta3. Usuario ingresa número de tarjeta, fecha de vencimiento, CVV (Card Verification Value - Valor de Verificación de Tarjeta) y nombre4. Sistema valida formato de datos ingresados5. Sistema envía datos cifrados a pasarela de pago6. Pasarela procesa transacción y retorna resultado7. Sistema registra transacción en base de datos8. Sistema muestra confirmación de pago exitoso al usuario9. Sistema envía email de confirmación con número de orden
Flujos Alternativos:- Si validación de formato falla: mostrar mensaje de error específico- Si pasarela rechaza pago: mostrar razón de rechazo y permitir reintentar- Si hay timeout de pasarela: mostrar mensaje y guardar carrito- Si usuario cancela: retornar a página de carrito sin procesar pago
Criterios de Aceptación:- Transacción completa en menos de 10 segundos- Datos de tarjeta cifrados con TLS 1.3 (Transport Layer Security - Seguridad de Capa de Transporte)- Número de tarjeta enmascarado (mostrar solo últimos 4 dígitos)- Email de confirmación enviado en menos de 1 minuto- Registro de auditoría creado para cada intento de pago
Dependencias:- RF-012: Cálculo de total de compra- RF-008: Autenticación de usuario- RNF-025: Integración con pasarela de pago StripeID: RF-042Nombre: Transferencia entre Cuentas PropiasPrioridad: AltaMódulo: Módulo de Transferencias
Descripción:El sistema debe permitir a los clientes transferir fondos entre sus propiascuentas (ahorro, corriente, inversión) de forma inmediata, con validaciónde saldos y generación de comprobante.
Precondiciones:- Cliente autenticado con token de sesión válido- Cliente posee al menos dos cuentas activas- Cuenta origen tiene saldo disponible suficiente- Sistema de core bancario operativo
Flujo Principal:1. Cliente selecciona opción "Transferir entre mis cuentas"2. Sistema muestra listado de cuentas del cliente con saldos3. Cliente selecciona cuenta origen y cuenta destino4. Cliente ingresa monto a transferir5. Sistema valida que monto sea mayor a $0 y menor o igual al saldo6. Sistema muestra resumen de transferencia para confirmación7. Cliente confirma la operación8. Sistema debita monto de cuenta origen9. Sistema acredita monto en cuenta destino10. Sistema genera número de comprobante único11. Sistema muestra confirmación con detalles de transferencia12. Sistema envía notificación push y email al cliente
Flujos Alternativos:- Si saldo insuficiente: mostrar mensaje y saldo disponible- Si monto excede límite diario: informar límite y permitir ajustar- Si cuenta destino está bloqueada: mostrar mensaje y no permitir- Si cliente cancela: retornar a menú principal sin realizar operación- Si falla débito: revertir transacción y registrar error
Criterios de Aceptación:- Transferencia procesada en tiempo real (< 3 segundos)- Saldos actualizados inmediatamente en ambas cuentas- Comprobante PDF (Portable Document Format) generado y disponible para descarga- Operación registrada en historial de transacciones- Notificaciones enviadas en menos de 30 segundos- Transacción atómica (todo o nada, sin estados intermedios)
Dependencias:- RF-038: Consulta de saldos de cuentas- RF-005: Autenticación de cliente- RF-044: Generación de comprobantes PDF- RNF-018: Disponibilidad del core bancario✨ Requerimientos No Funcionales
Section titled “✨ Requerimientos No Funcionales”Los requerimientos no funcionales especifican criterios de calidad, restricciones y atributos que determinan cómo debe comportarse el sistema. Definen las características cualitativas que afectan la experiencia del usuario y la viabilidad técnica.
📖 Definición Formal
Section titled “📖 Definición Formal”🔍 Características Principales
Section titled “🔍 Características Principales”-
Cualidades del Sistema
Describen atributos de calidad que el sistema debe poseer (rendimiento, seguridad, usabilidad, etc.).
-
Restricciones Globales
Frecuentemente se aplican al sistema completo en lugar de funcionalidades específicas.
-
Impacto en Arquitectura
Influyen significativamente en las decisiones de diseño arquitectónico y tecnológico.
-
Medición Cuantitativa
Deben especificarse con métricas medibles y verificables.
📊 Clasificación según ISO/IEC 25010
Section titled “📊 Clasificación según ISO/IEC 25010”🎯 Categorías Detalladas
Section titled “🎯 Categorías Detalladas”-
⚡ Rendimiento (Performance)
Define la eficiencia del sistema en términos de tiempo y recursos.
Aspectos clave:
- Tiempo de respuesta: Latencia máxima aceptable para operaciones
- Throughput: Número de transacciones por unidad de tiempo
- Utilización de recursos: CPU, memoria, ancho de banda
- Capacidad: Número máximo de usuarios concurrentes
Ejemplo: El sistema debe procesar 1,000 transacciones por segundo con un tiempo de respuesta menor a 2 segundos en el percentil 95.
-
🔒 Seguridad (Security)
Protección contra accesos no autorizados y amenazas.
Aspectos clave:
- Autenticación: Verificación de identidad de usuarios
- Autorización: Control de acceso basado en roles (RBAC - Role-Based Access Control)
- Confidencialidad: Cifrado de datos sensibles
- Integridad: Protección contra modificaciones no autorizadas
- Auditoría: Registro de acciones críticas
Ejemplo: Todos los datos personales deben ser cifrados en tránsito (TLS 1.3 - Transport Layer Security) y en reposo (AES-256 - Advanced Encryption Standard).
-
👥 Usabilidad (Usability)
Facilidad de uso y experiencia del usuario.
Aspectos clave:
- Curva de aprendizaje: Tiempo para dominar funcionalidades básicas
- Eficiencia de uso: Productividad de usuarios experimentados
- Prevención de errores: Diseño que minimiza equivocaciones
- Accesibilidad: Cumplimiento de estándares WCAG (Web Content Accessibility Guidelines - Pautas de Accesibilidad para Contenido Web)
Ejemplo: Un usuario nuevo debe poder completar una transacción básica en menos de 5 minutos sin capacitación previa.
-
✅ Confiabilidad (Reliability)
Capacidad del sistema para funcionar correctamente bajo condiciones específicas.
Aspectos clave:
- Disponibilidad: Porcentaje de tiempo operativo (uptime)
- MTBF (Mean Time Between Failures): Tiempo medio entre fallos
- MTTR (Mean Time To Repair): Tiempo medio de reparación
- Tolerancia a fallos: Capacidad de continuar operando ante fallos parciales
Ejemplo: El sistema debe tener una disponibilidad de 99.9% (máximo 8.76 horas de downtime al año).
-
🔧 Mantenibilidad (Maintainability)
Facilidad para modificar, corregir y mejorar el sistema.
Aspectos clave:
- Modularidad: Componentes independientes y cohesivos
- Reusabilidad: Componentes reutilizables en otros contextos
- Analizabilidad: Facilidad para diagnosticar problemas
- Modificabilidad: Esfuerzo requerido para implementar cambios
Ejemplo: El código debe tener una cobertura de pruebas unitarias mínima del 80% y cumplir con estándares de clean code.
-
🔄 Portabilidad (Portability)
Capacidad de ejecutarse en diferentes entornos.
Aspectos clave:
- Adaptabilidad: Funcionamiento en múltiples plataformas
- Instalabilidad: Facilidad de instalación y configuración
- Reemplazabilidad: Capacidad de sustituir componentes
Ejemplo: El sistema debe ser compatible con navegadores Chrome, Firefox, Safari y Edge en sus últimas 3 versiones.
-
⚙️ Compatibilidad (Compatibility)
Capacidad de coexistir e interoperar con otros sistemas.
Aspectos clave:
- Interoperabilidad: Intercambio de información con sistemas externos
- Coexistencia: Funcionamiento sin conflictos con otros sistemas
Ejemplo: El sistema debe integrarse con APIs REST (Representational State Transfer) y SOAP (Simple Object Access Protocol), soportando formatos JSON (JavaScript Object Notation) y XML (eXtensible Markup Language).
-
📈 Escalabilidad (Scalability)
Capacidad de manejar crecimiento de carga o usuarios.
Aspectos clave:
- Escalabilidad horizontal: Agregar más servidores
- Escalabilidad vertical: Aumentar recursos de servidor existente
- Elasticidad: Ajuste automático de recursos según demanda
Ejemplo: El sistema debe soportar un crecimiento de 50% en usuarios sin degradación de rendimiento.
📊 Tabla Comparativa de Métricas
Section titled “📊 Tabla Comparativa de Métricas”| Categoría | Métrica | Ejemplo de Especificación |
|---|---|---|
| Rendimiento | Tiempo de respuesta | < 2 segundos para 95% de las peticiones |
| Rendimiento | Throughput | 10,000 transacciones/segundo |
| Seguridad | Cifrado | TLS 1.3 (Transport Layer Security) para datos en tránsito |
| Seguridad | Autenticación | MFA (Multi-Factor Authentication - Autenticación Multifactor) obligatorio |
| Seguridad | Tokens | JWT (JSON Web Token) con expiración de 15 minutos |
| Disponibilidad | Uptime | 99.95% (4.38 horas downtime/año) |
| Disponibilidad | RTO (Recovery Time Objective - Tiempo Objetivo de Recuperación) | < 1 hora |
| Usabilidad | Curva aprendizaje | Usuario completa tarea en < 5 minutos |
| Usabilidad | Accesibilidad | WCAG (Web Content Accessibility Guidelines) 2.1 Nivel AA |
| Escalabilidad | Usuarios concurrentes | Soportar 100,000 usuarios simultáneos |
| Mantenibilidad | Cobertura de tests | > 80% de cobertura de código |
💡 Ejemplos de Requerimientos No Funcionales
Section titled “💡 Ejemplos de Requerimientos No Funcionales”RNF-001: RendimientoEl sistema debe cargar la página principal en menos de 1.5 segundosen una conexión de 10 Mbps.
RNF-002: SeguridadTodas las contraseñas deben ser hasheadas usando bcrypt con unfactor de costo mínimo de 12.
RNF-003: DisponibilidadEl sistema debe tener un SLA de 99.9% de disponibilidad durantehorario laboral (8am-8pm).
Nota: SLA = Service Level Agreement (Acuerdo de Nivel de Servicio)
RNF-004: UsabilidadLa aplicación móvil debe cumplir con las guías de diseño MaterialDesign 3.0 de Google.
RNF-005: EscalabilidadEl sistema debe soportar un incremento de 100% en la carga sinrequerir cambios arquitectónicos.
RNF-006: CompatibilidadEl sistema debe ser compatible con iOS 14+ y Android 10+.
RNF-007: MantenibilidadEl código debe seguir los principios SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) y tener documentacióninline en formato JSDoc (JavaScript Documentation).
RNF-008: PortabilidadEl sistema debe ejecutarse en contenedores Docker en cualquierplataforma que soporte Docker Engine 20.10+.⚠️ Errores Comunes
Section titled “⚠️ Errores Comunes”📋 Plantilla de Especificación
Section titled “📋 Plantilla de Especificación”ID: RNF-XXXCategoría: [Rendimiento | Seguridad | Usabilidad | etc.]Prioridad: [Alta | Media | Baja]
Descripción:El sistema debe [característica de calidad] [métrica cuantificable][condiciones de medición].
Métrica:- Indicador: [Qué se mide]- Valor objetivo: [Valor numérico esperado]- Método de medición: [Cómo se verifica]
Restricciones:- [Restricción técnica o de negocio 1]- [Restricción técnica o de negocio 2]
Impacto en Arquitectura:[Descripción de cómo afecta el diseño del sistema]
Criterios de Aceptación:- [Criterio medible 1]- [Criterio medible 2]ID: RNF-008Categoría: RendimientoPrioridad: Alta
Descripción:El sistema debe procesar y responder a las búsquedas de productos en elcatálogo en menos de 1.5 segundos para el 95% de las peticiones, bajocondiciones de carga normal (hasta 5,000 usuarios concurrentes).
Métrica:- Indicador: Tiempo de respuesta de endpoint /api/products/search- Valor objetivo: Percentil 95 < 1.5 segundos- Método de medición: Monitoreo con herramientas APM (Application Performance Monitoring - Monitoreo de Rendimiento de Aplicaciones) como New Relic/Datadogy pruebas de carga con JMeter
Restricciones:- Base de datos con hasta 500,000 productos activos- Catálogo con 50 categorías y 200 atributos de filtrado- Búsqueda debe soportar texto completo y filtros combinados- Infraestructura en AWS (Amazon Web Services) con instancias m5.xlarge- Presupuesto máximo de $2,000/mes para infraestructura
Impacto en Arquitectura:- Implementar caché distribuido con Redis para resultados frecuentes- Utilizar Elasticsearch para búsqueda de texto completo- Índices optimizados en base de datos PostgreSQL- CDN (Content Delivery Network - Red de Distribución de Contenido) para servir imágenes de productos- Load balancer con al menos 3 instancias de aplicación- Implementar paginación con límite de 50 resultados por página
Criterios de Aceptación:- Tiempo de respuesta P95 < 1.5s verificado en producción- Tiempo de respuesta P99 < 3.0s- Throughput mínimo de 500 búsquedas por segundo- Caché con hit rate > 70% para búsquedas populares- Pruebas de carga exitosas con 5,000 usuarios concurrentes- Monitoreo activo con alertas si P95 > 2.0s por 5 minutosID: RNF-023Categoría: SeguridadPrioridad: Crítica
Descripción:El sistema debe proteger todos los datos personales y financieros de losusuarios mediante cifrado en tránsito y en reposo, cumpliendo con estándaresPCI-DSS (Payment Card Industry Data Security Standard) nivel 1 y GDPR (General Data Protection Regulation - Reglamento General de Protección de Datos), con auditoría completa de accesos.
Métrica:- Indicador: Nivel de cumplimiento de estándares de seguridad- Valor objetivo: 100% de cumplimiento PCI-DSS y GDPR- Método de medición: Auditoría trimestral por QSA (Qualified Security Assessor - Evaluador de Seguridad Calificado) certificado yescaneos automáticos semanales con herramientas ASV (Approved Scanning Vendor - Proveedor de Escaneo Aprobado) aprobadas
Restricciones:- Datos de tarjetas nunca almacenados en servidores propios- Logs de auditoría inmutables y retenidos por 7 años- Acceso a datos sensibles solo mediante VPN (Virtual Private Network - Red Privada Virtual) y 2FA (Two-Factor Authentication - Autenticación de Dos Factores)- Cumplimiento obligatorio para operar en UE y procesar pagos- Certificación PCI-DSS requerida antes de go-live
Impacto en Arquitectura:- Implementar TLS 1.3 (Transport Layer Security) para todas las comunicaciones HTTPS (HyperText Transfer Protocol Secure)- Cifrado AES-256 (Advanced Encryption Standard) para datos en reposo en base de datos- Tokenización de datos de tarjetas mediante Stripe/PayPal- Implementar HSM (Hardware Security Module - Módulo de Seguridad de Hardware) para claves criptográficas- Sistema de gestión de secretos con HashiCorp Vault- WAF (Web Application Firewall - Firewall de Aplicaciones Web) con reglas OWASP (Open Web Application Security Project) Top 10- Segregación de red con DMZ (Demilitarized Zone - Zona Desmilitarizada) para servicios públicos- Logs centralizados en SIEM (Security Information and Event Management - Gestión de Información y Eventos de Seguridad)- Implementar RBAC (Role-Based Access Control - Control de Acceso Basado en Roles) granular- Encriptación de backups con claves rotadas mensualmente
Criterios de Aceptación:- Certificación PCI-DSS nivel 1 obtenida y vigente- 100% de endpoints expuestos con HTTPS (HyperText Transfer Protocol Secure) / TLS 1.3- Escaneos de vulnerabilidades sin hallazgos críticos- Auditoría de accesos con registro de todas las operaciones sensibles- Penetration testing anual sin vulnerabilidades de severidad alta- Tiempo de detección de intrusión < 15 minutos- Datos personales cifrados verificados mediante inspección de BD- Políticas de contraseñas: mínimo 12 caracteres, complejidad alta- MFA (Multi-Factor Authentication - Autenticación Multifactor) obligatorio para roles administrativos (100% de adopción)- Rotación de credenciales cada 90 días