Los requerimientos de software, también llamados requisitos, describen lo que un sistema debe hacer, las condiciones que debe cumplir y las restricciones que debe respetar. Son una base fundamental para analizar, diseñar, construir, probar y aceptar una solución.
Un proyecto puede fracasar aunque el código esté bien escrito si los requerimientos fueron mal entendidos. Si el equipo construye algo que no resuelve la necesidad real, el problema no está solamente en la programación, sino en la comprensión inicial del sistema.
En este tema veremos qué son los requerimientos, para qué sirven, de dónde surgen y cómo se trabajan dentro de un proyecto de software.
Un requerimiento es una necesidad, capacidad, condición o restricción que el sistema debe satisfacer. Puede describir una función visible para el usuario, una regla de negocio, una característica de calidad, una integración, una condición legal o una restricción técnica.
Ejemplos de requerimientos:
Los requerimientos sirven como puente entre las necesidades de los interesados y el trabajo técnico del equipo. Ayudan a transformar ideas generales en acuerdos más concretos.
Sirven para:
Sin requerimientos claros, las decisiones se basan en suposiciones. Eso aumenta el riesgo de retrabajo y conflictos.
Es importante distinguir necesidad, requerimiento y solución. Muchas veces un interesado expresa una solución deseada, pero detrás de ella existe una necesidad que conviene entender.
| Concepto | Pregunta que responde | Ejemplo |
|---|---|---|
| Necesidad | ¿Qué problema o resultado se busca? | Los clientes llaman muchas veces para conocer el estado de su pedido. |
| Requerimiento | ¿Qué debe permitir o cumplir el sistema? | El cliente debe poder consultar el estado de su pedido en línea. |
| Solución | ¿Cómo se implementará? | Crear una pantalla de seguimiento con número de pedido y correo electrónico. |
Si el equipo salta directamente a la solución, puede perder alternativas mejores o no resolver el problema real.
Los requerimientos pueden surgir de varias fuentes. No conviene depender de una sola persona o documento.
Trabajar con requerimientos no es solo escribir una lista. Normalmente incluye varias actividades relacionadas.
| Actividad | Propósito | Ejemplo |
|---|---|---|
| Relevamiento | Obtener información de interesados y fuentes disponibles. | Entrevistar usuarios y revisar formularios actuales. |
| Análisis | Ordenar, aclarar, detectar conflictos y comprender reglas. | Separar una regla general de sus excepciones. |
| Especificación | Registrar requerimientos de forma clara y verificable. | Redactar una historia de usuario con criterios de aceptación. |
| Validación | Confirmar que los requerimientos reflejan la necesidad real. | Revisar un prototipo con usuarios referentes. |
| Gestión | Controlar cambios, prioridades, versiones y trazabilidad. | Registrar cuándo se modifica un requisito y por qué. |
El relevamiento consiste en descubrir información necesaria para comprender qué debe cumplir el sistema. Puede realizarse con entrevistas, observación, reuniones, análisis de documentos, encuestas, prototipos o revisión de sistemas existentes.
Al relevar, conviene preguntar:
El relevamiento no debe limitarse a aceptar pedidos textuales. También debe buscar causas, objetivos y contexto.
Después de obtener información, hay que analizarla. El análisis permite detectar ambigüedades, contradicciones, duplicaciones, requisitos incompletos y prioridades poco claras.
Durante el análisis se pueden realizar tareas como:
Un requerimiento mal analizado puede generar una funcionalidad incorrecta aunque esté programada sin errores.
Especificar significa registrar los requerimientos de forma comprensible para quienes deben usarlos: usuarios, clientes, analistas, desarrolladores, testers y responsables del proyecto.
La especificación puede adoptar distintas formas:
No existe un único formato obligatorio para todos los proyectos. Lo importante es que los requerimientos sean claros, útiles y verificables.
Un buen requerimiento debería cumplir varias condiciones:
| Característica | Significado | Ejemplo de mejora |
|---|---|---|
| Claro | Se entiende sin interpretaciones múltiples. | Cambiar "rápido" por "responder en menos de tres segundos". |
| Completo | Incluye información suficiente para construir y probar. | Indicar datos, reglas, excepciones y resultado esperado. |
| Consistente | No contradice otros requerimientos. | Alinear permisos de usuarios con políticas de seguridad. |
| Verificable | Puede comprobarse mediante revisión, prueba o medición. | Definir criterios de aceptación observables. |
| Necesario | Aporta valor o responde a una restricción real. | Evitar funciones pedidas "por si acaso" sin justificación. |
| Trazable | Puede relacionarse con su origen, diseño, pruebas y cambios. | Registrar qué actor lo solicitó y qué caso de prueba lo valida. |
La ambigüedad aparece cuando un requerimiento puede interpretarse de más de una manera. Es uno de los problemas más comunes.
Ejemplos de frases ambiguas:
Estas frases pueden ser un punto de partida, pero necesitan aclaración. Por ejemplo, "rápida" puede transformarse en "la búsqueda debe mostrar resultados en menos de tres segundos para hasta 10.000 registros".
Validar requerimientos significa confirmar que representan correctamente lo que los interesados necesitan. No alcanza con que estén bien escritos; deben ser correctos para el problema real.
Algunas técnicas de validación son:
Validar temprano reduce el riesgo de construir funcionalidades incorrectas.
Los requerimientos pueden cambiar. Esto es normal, especialmente cuando el equipo aprende más sobre el problema o cuando cambia el contexto. Lo importante es gestionar esos cambios de forma ordenada.
Ante un cambio conviene analizar:
Gestionar cambios no significa impedirlos. Significa entender sus consecuencias antes de aceptarlos.
La trazabilidad permite relacionar requerimientos con su origen, diseño, implementación, pruebas y cambios. Ayuda a responder preguntas como: ¿por qué existe esta funcionalidad?, ¿quién la pidió?, ¿qué prueba la valida?, ¿qué se afecta si cambia?
Un ejemplo simple de trazabilidad:
| Requerimiento | Origen | Diseño o módulo | Prueba asociada |
|---|---|---|---|
| El usuario debe poder cancelar una reserva hasta dos horas antes. | Regla definida por administración. | Módulo de reservas. | Caso de prueba: cancelación permitida y cancelación fuera de plazo. |
La trazabilidad es especialmente importante en sistemas grandes, críticos o regulados.
Supongamos que una biblioteca necesita un sistema para gestionar préstamos.
Una necesidad inicial podría ser:
De esa necesidad pueden surgir requerimientos como:
Cada requerimiento puede luego transformarse en diseño, tareas de desarrollo y casos de prueba.
Al trabajar con requerimientos suelen aparecer errores como:
Una plantilla breve puede ayudar a registrar requerimientos con claridad:
| Identificador | Código o nombre corto del requerimiento. |
|---|---|
| Descripción | Qué debe cumplir el sistema. |
| Origen | Actor, documento, norma o proceso que lo justifica. |
| Prioridad | Importancia relativa para el proyecto. |
| Criterios de aceptación | Condiciones observables para considerarlo cumplido. |
| Restricciones o reglas | Condiciones especiales, excepciones o límites. |
| Estado | Propuesto, aprobado, en desarrollo, probado, entregado o descartado. |
Los requerimientos de software son una de las bases más importantes de un proyecto. Permiten comprender qué se necesita construir, por qué, para quién y bajo qué condiciones. Cuando están mal definidos, el equipo corre el riesgo de construir una solución incorrecta aunque el código funcione.
Para quien comienza, la idea principal es esta: un requerimiento claro transforma una necesidad en una condición verificable que guía el diseño, la construcción y las pruebas del sistema.
En el próximo tema veremos la diferencia entre requerimientos funcionales y no funcionales, una distinción fundamental para comprender tanto el comportamiento del sistema como sus atributos de calidad.