Los requerimientos de software describen lo que un sistema debe hacer, las condiciones que debe cumplir y las restricciones que debe respetar para resolver una necesidad real. Son una parte fundamental de cualquier proyecto porque conectan el problema del usuario con la solución que el equipo construirá.
Antes de diseñar pantallas, elegir tecnologías o escribir código, es necesario entender qué se espera del sistema. Si esa comprensión es incompleta, ambigua o incorrecta, el equipo puede construir un producto técnicamente correcto pero inútil para quienes lo necesitan.
Por eso, trabajar con requerimientos no consiste solo en escribir una lista de funciones. Consiste en descubrir necesidades, aclarar expectativas, registrar acuerdos, analizar restricciones y establecer criterios que permitan verificar si el software cumple su propósito.
Podemos definir un requerimiento de software de la siguiente manera:
Esta definición contiene varias ideas importantes:
En un proyecto es común que usuarios y clientes expresen deseos, ideas, opiniones o soluciones posibles. Algunas de esas expresiones pueden convertirse en requerimientos, pero no todas tienen el mismo valor ni el mismo nivel de precisión.
Por ejemplo, un usuario podría decir: "quiero que el sistema sea rápido". Esa frase expresa una necesidad, pero todavía no es un requerimiento claro. Para convertirla en un requerimiento útil hay que precisar qué significa "rápido", en qué operación, bajo qué condiciones y cómo se medirá.
La diferencia es importante: un deseo puede orientar la conversación, pero un requerimiento debe poder comunicarse, analizarse, implementarse y verificarse.
Los requerimientos cumplen varias funciones dentro de un proyecto de software:
Cuando los requerimientos son claros, el equipo puede tomar mejores decisiones. Cuando son débiles, el proyecto avanza con suposiciones que tarde o temprano generan errores, retrabajo o conflictos.
Para estudiar requerimientos conviene distinguir tres niveles: la necesidad, el requerimiento y la solución.
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Necesidad | ¿Qué problema existe o qué objetivo se quiere alcanzar? | La biblioteca pierde tiempo registrando préstamos en planillas manuales. |
| Requerimiento | ¿Qué debe cumplir el sistema para ayudar a resolver ese problema? | El sistema debe registrar préstamos de libros indicando socio, libro, fecha de retiro y fecha prevista de devolución. |
| Solución | ¿Cómo se implementará ese requerimiento? | Una pantalla web con un formulario, validaciones y almacenamiento en una base de datos. |
Esta separación evita un error frecuente: confundir una solución propuesta con el requerimiento real. A veces un usuario pide una pantalla específica, un botón o una tecnología, pero detrás de ese pedido existe una necesidad que puede resolverse de varias maneras.
Existen distintas formas de clasificar los requerimientos. Una clasificación inicial muy útil distingue entre requerimientos funcionales, no funcionales y restricciones.
| Tipo | Qué describe | Ejemplo |
|---|---|---|
| Funcional | Funciones, servicios o comportamientos que el sistema debe realizar. | El sistema debe permitir registrar un nuevo cliente. |
| No funcional | Cualidades que el sistema debe tener o niveles de calidad esperados. | La consulta de clientes debe responder en menos de 3 segundos. |
| Restricción | Condiciones externas o decisiones que limitan la solución. | El sistema debe funcionar en los navegadores aprobados por la organización. |
Más adelante estudiaremos cada tipo con mayor detalle. Por ahora, lo importante es comprender que un sistema no se define solamente por las funciones que ofrece, sino también por la calidad con que debe ejecutarlas y por las condiciones que debe respetar.
Estos son ejemplos simples de requerimientos expresados con distinto enfoque:
Un buen documento de requerimientos suele combinar todos estos elementos, porque el comportamiento del sistema y sus condiciones de calidad deben analizarse juntos.
Los requerimientos no surgen de una sola persona. Normalmente se construyen a partir del diálogo entre distintos interesados:
La participación de estas personas permite detectar necesidades que no siempre aparecen en una primera conversación. También ayuda a evitar que el sistema se construya desde una mirada demasiado parcial.
Un requerimiento útil debe tener ciertas características mínimas. No siempre se logran perfectamente desde el primer intento, pero sirven como criterio para mejorar la especificación.
Muchos problemas de software comienzan antes de programar. Cuando los requerimientos no están bien trabajados, pueden aparecer situaciones como estas:
La ingeniería de requerimientos no elimina todos los cambios ni toda la incertidumbre, pero reduce el riesgo de construir software basado en suposiciones equivocadas.
Supongamos que una institución educativa quiere un sistema para gestionar inscripciones a cursos. Una frase inicial podría ser: "necesitamos una página para inscribir alumnos". Esa frase es demasiado general.
Al analizarla, podrían aparecer requerimientos como los siguientes:
Este ejemplo muestra que una necesidad simple puede transformarse en varios requerimientos funcionales, no funcionales y restricciones.
Los requerimientos son una base para muchas actividades posteriores del proyecto. A partir de ellos se elaboran modelos, casos de uso, historias de usuario, prototipos, diseños, pruebas y documentación técnica.
Por ejemplo, un requerimiento funcional puede convertirse en un caso de uso, una historia de usuario o un escenario de prueba. Un requerimiento no funcional de seguridad puede influir en la arquitectura, en los permisos, en el almacenamiento de datos y en las pruebas de vulnerabilidad.
Por esta razón, los requerimientos no deben verse como un trámite inicial que se completa una vez y luego se olvida. Deben mantenerse vivos, revisarse cuando cambia el contexto y conectarse con el resto de los artefactos del proyecto.
Los requerimientos de software son el puente entre una necesidad y una solución. Permiten transformar problemas, objetivos y expectativas en condiciones comprensibles que orientan el trabajo del equipo y permiten evaluar el resultado.
Para quien comienza, la idea principal es esta: antes de construir software, debemos entender con claridad qué se necesita, por qué se necesita, quién lo necesita y cómo sabremos que fue cumplido.
En el próximo tema analizaremos con más detalle la importancia de los requerimientos en un proyecto de software y veremos cómo influyen en costos, tiempos, calidad, comunicación y satisfacción del cliente.