3. Ingeniería de Requisitos
El proceso de descubrir y documentar
La Ingeniería de Requisitos NO es adivinar lo que el usuario quiere. Es sentarse, conversar, extraer la verdad y plasmarla en un documento u hoja de ruta para que el equipo de programación sepa exactamente qué contruir.
Regla de Oro: Todo requisito debe ser: Claro, Constante (no contradictorio con otro requisito) y Verificable/Testeable. Si no puedes probarlo cuando el código esté hecho, es un mal requisito.
1. Requisitos Funcionales
Describen el "COMPORTAMIENTO" del sistema. Son el qué debe hacer el software. Sus acciones y flujos.
- ❌ Mal requisito funcional: "La app debe tener login".
- ✅ Buen requisito funcional: "El sistema debe permitir que un usuario registrado inicie sesión utilizando su correo electrónico y su contraseña".
- ✅ "El sistema de ventas debe aplicar un 10% de descuento si la compra del usuario supera los 50.000 Pesos".
- ✅ "El administrador debe poder generar un reporte en PDF o Excel con las ventas mensuales filtradas por rango de fechas".
Típicamente estos se convierten en Historias de Usuario (Scrum) o Casos de Uso (UML).
2. Requisitos No Funcionales (Atributos de Calidad)
Describen la "CUALIDAD" del sistema. Son el cómo de bien (o rápido, o seguro) debe funcionar el software. Limitan al sistema. Sin ellos, el software puede compilar y hacer lo que se pide, pero ser inutilizable en el mundo real.
Se dividen en categorías (URPS+, etc.):
- ⚙️ Rendimiento / Escalabilidad: "El sistema debe responder consultas dentro del catálogo en menos de 2.5 segundos bajo una carga de 1000 usuarios concurrentes".
- 🔐 Seguridad: "Todas las contraseñas de los usuarios deben almacenarse en la base de datos hasheadas utilizando el algoritmo Bcrypt".
- 🎨 Usabilidad: "El flujo de compra principal no debe tener más de 3 pantallas antes de requerir que el usuario pague".
- 💻 Tecnológicos / Portabilidad: "La aplicación debe ser compatible con los navegadores Chrome v90+, Firefox v88+ y Safari 14+".
