Skip to content

2 Tipos 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.

Diagrama UML

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.

  1. Especificidad de Comportamiento

    Definen acciones concretas y observables que el sistema debe ejecutar en respuesta a entradas o eventos específicos.

  2. Orientación a Funcionalidad

    Se centran en las capacidades del sistema desde la perspectiva del usuario o del negocio.

  3. Verificabilidad Directa

    Pueden ser probados mediante casos de prueba que validan la presencia o ausencia de la funcionalidad.

  4. 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”
Diagrama UML

📝 Estructura de un Requerimiento Funcional

Section titled “📝 Estructura de un Requerimiento Funcional”

Un requerimiento funcional bien formulado debe incluir:

ComponenteDescripciónEjemplo
IdentificadorCódigo único de trazabilidadRF-001
NombreTítulo descriptivo breveLogin de usuario
DescripciónEspecificación detallada del comportamientoEl sistema debe permitir a los usuarios autenticarse mediante email y contraseña
PrecondicionesEstado requerido antes de ejecutarUsuario registrado en el sistema
EntradasDatos que recibe la funciónEmail, contraseña
ProcesoLógica o algoritmo a ejecutarValidar credenciales contra base de datos
SalidasResultados esperadosSesión iniciada o mensaje de error
PostcondicionesEstado del sistema después de ejecutarUsuario autenticado con sesión activa
PrioridadImportancia relativaAlta, Media, Baja

💡 Ejemplos de Requerimientos Funcionales

Section titled “💡 Ejemplos de Requerimientos Funcionales”
  1. 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.

  2. 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.

  3. 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.

Un requerimiento funcional de calidad debe ser:

Plantilla de Requerimiento Funcional
ID: RF-XXX
Nombre: [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]

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.

  1. Cualidades del Sistema

    Describen atributos de calidad que el sistema debe poseer (rendimiento, seguridad, usabilidad, etc.).

  2. Restricciones Globales

    Frecuentemente se aplican al sistema completo en lugar de funcionalidades específicas.

  3. Impacto en Arquitectura

    Influyen significativamente en las decisiones de diseño arquitectónico y tecnológico.

  4. Medición Cuantitativa

    Deben especificarse con métricas medibles y verificables.

Diagrama UML
  1. ⚡ 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.

  2. 🔒 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).

  3. 👥 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.

  4. ✅ 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).

  5. 🔧 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.

  6. 🔄 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.

  7. ⚙️ 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).

  8. 📈 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.

CategoríaMétricaEjemplo de Especificación
RendimientoTiempo de respuesta< 2 segundos para 95% de las peticiones
RendimientoThroughput10,000 transacciones/segundo
SeguridadCifradoTLS 1.3 (Transport Layer Security) para datos en tránsito
SeguridadAutenticaciónMFA (Multi-Factor Authentication - Autenticación Multifactor) obligatorio
SeguridadTokensJWT (JSON Web Token) con expiración de 15 minutos
DisponibilidadUptime99.95% (4.38 horas downtime/año)
DisponibilidadRTO (Recovery Time Objective - Tiempo Objetivo de Recuperación)< 1 hora
UsabilidadCurva aprendizajeUsuario completa tarea en < 5 minutos
UsabilidadAccesibilidadWCAG (Web Content Accessibility Guidelines) 2.1 Nivel AA
EscalabilidadUsuarios concurrentesSoportar 100,000 usuarios simultáneos
MantenibilidadCobertura de tests> 80% de cobertura de código

💡 Ejemplos de Requerimientos No Funcionales

Section titled “💡 Ejemplos de Requerimientos No Funcionales”
Ejemplos de RNF Específicos
RNF-001: Rendimiento
El sistema debe cargar la página principal en menos de 1.5 segundos
en una conexión de 10 Mbps.
RNF-002: Seguridad
Todas las contraseñas deben ser hasheadas usando bcrypt con un
factor de costo mínimo de 12.
RNF-003: Disponibilidad
El sistema debe tener un SLA de 99.9% de disponibilidad durante
horario laboral (8am-8pm).
Nota: SLA = Service Level Agreement (Acuerdo de Nivel de Servicio)
RNF-004: Usabilidad
La aplicación móvil debe cumplir con las guías de diseño Material
Design 3.0 de Google.
RNF-005: Escalabilidad
El sistema debe soportar un incremento de 100% en la carga sin
requerir cambios arquitectónicos.
RNF-006: Compatibilidad
El sistema debe ser compatible con iOS 14+ y Android 10+.
RNF-007: Mantenibilidad
El código debe seguir los principios SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) y tener documentación
inline en formato JSDoc (JavaScript Documentation).
RNF-008: Portabilidad
El sistema debe ejecutarse en contenedores Docker en cualquier
plataforma que soporte Docker Engine 20.10+.
Plantilla de Requerimiento No Funcional
ID: RNF-XXX
Categorí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]

🔄 Relación entre Requerimientos Funcionales y No Funcionales

Section titled “🔄 Relación entre Requerimientos Funcionales y No Funcionales”
Diagrama UML
🐝