🟢 DÍA 33 — TOMA DE REQUISITOS (2/3): FUNCIONALIDAD Y SEGURIDAD

🎯 Objetivo del día:

Definir con precisión qué debe hacer el plugin (requisitos funcionales) y cómo debe comportarse para ser seguro (requisitos de seguridad), como parte del ciclo S-SDLC.
Este análisis permite planificar una arquitectura robusta, escalable y libre de vulnerabilidades desde la fase de diseño.

🛠️ Parte Genérica (válida para todos los alumnos)

⚙️ 1. Requisitos Funcionales

Los requisitos funcionales describen qué debe hacer el plugin. Se deben especificar:

  • Funciones principales y secundarias (mínimo producto viable).
  • Acciones que pueden realizar los usuarios (añadir, ver, modificar, eliminar datos).
  • Roles y permisos necesarios para cada acción.
  • Interacciones con otras partes del sistema WordPress (menus, shortcodes, widgets, REST API…).
  • Comportamiento esperado en casos de error (por ejemplo, qué pasa si un dato obligatorio no se introduce).

📋 Tareas:

  1. Redactar una lista clara de funciones que debe tener la versión 1.0 del plugin.
  2. Definir si el plugin tendrá versión PRO y qué funciones podrían incluirse solo en esa versión.
  3. Especificar qué roles de usuario podrán hacer qué (administrador, editor, suscriptor, etc.).
  4. Si el plugin usará tablas propias, describir cómo se usará cada campo y cómo se relacionará con los usuarios de WordPress.

🔐 2. Requisitos de Seguridad

Aquí se definen las medidas para proteger los datos y el entorno de ejecución del plugin:

  • Validación, sanitización y escape de todos los datos (entradas del usuario, formularios, parámetros).
  • Protección frente a ataques comunes: XSS, CSRF, SQLi, acceso no autorizado.
  • Uso correcto de:
    • current_user_can() para controlar permisos.
    • wp_nonce_field() y check_admin_referer() para proteger formularios.
    • esc_html(), esc_attr(), sanitize_text_field(), etc.
  • Separación de funcionalidades públicas y privadas.
  • Gestión segura de datos almacenados (tablas, opciones, registros temporales).
  • Registro de actividad o logs (opcional, según el proyecto).

📋 Tareas:

  1. Enumerar los puntos donde el plugin recibirá datos externos (formularios, AJAX, REST, URL…).
  2. Indicar qué funciones de sanitización o escape se aplicarán en cada caso.
  3. Establecer una política de roles y permisos seguros.
  4. (Opcional) Pensar en un mecanismo de logs o auditoría mínima si el plugin lo justifica.

👤 Parte específica — Alumno: Pablo Macías

Proyecto: Plugin WordPress «WP Control Horario»

⚙️ Requisitos Funcionales para la versión 1.0:

  • Registro de entrada y salida de jornada por parte de usuarios logueados.
  • Visualización de fichajes propios por parte de cada empleado.
  • Visualización completa por parte del administrador (con filtros por fecha y usuario).
  • Exportación de registros en CSV.
  • Configuración del horario esperado por día y notificación si no se ha fichado.
  • Panel de administración con resumen semanal/mensual.

💼 Funcionalidades potenciales para versión PRO:

  • Firma digital del fichaje.
  • Geolocalización opcional al fichar.
  • Notificaciones por correo o Slack.
  • Dashboard gráfico.
  • Multisite compatible.

🔐 Requisitos de Seguridad para Pablo:

  • Los usuarios solo pueden ver y gestionar sus propios registros.
  • El administrador tiene acceso total.
  • Todos los formularios protegidos con wp_nonce_field() y verificados con check_admin_referer().
  • Todos los datos del formulario se deben sanitizar con funciones como:
    • sanitize_text_field() para textos.
    • sanitize_email() para emails.
    • absint() para IDs.
  • Escapar toda salida con esc_html() o esc_attr().
  • Los datos sensibles como la IP, ubicación o timestamps se deben registrar y almacenar de forma protegida.
  • En caso de fichaje duplicado o incorrecto, el sistema debe responder con un mensaje controlado y registrar el intento.

📄 Entrega esperada (para todos los alumnos)

Un documento con:

  1. Nombre del plugin y objetivo funcional.
  2. Lista de funciones previstas en la versión 1.0 (mínimo viable).
  3. Lista opcional de funciones premium o avanzadas.
  4. Esquema de roles y permisos.
  5. Descripción de cada entrada/salida de datos.
  6. Medidas de seguridad aplicables a cada punto crítico.
  7. (Opcional) Mockups o bosquejo del panel de administración.

💪 Cierre

Hoy pasaste de tener solo una idea a tener un esquema funcional real de lo que tu plugin va a hacer y cómo va a proteger los datos que maneja.
Has pensado como un verdadero DevSecOps: con visión de producto, foco en la seguridad y claridad en los permisos.
Mañana completaremos esta etapa con los requisitos de negocio y el diseño preliminar del plugin. ¡Estás construyendo algo con proyección real! 🚀