Qué es un requisito de software

Introducción

En el desarrollo de software, todo comienza con una idea. Pero convertir esa idea en un producto útil, usable y valioso requiere algo más: requisitos bien definidos. Pero antes debemos responder a la pregunta ¿qué es un requisito?

Los requisitos actúan como el contrato implícito entre los interesados del negocio y el equipo de desarrollo. Son la base que permite planificar, construir, probar y validar que el producto cumple su propósito.

En este artículo aprenderás:

• Qué es un requisito de software y cómo se diferencia de otros artefactos
• Cómo redactar requisitos de calidad evitando ambigüedades
• Cómo clasificar los requisitos según su naturaleza y nivel
• Qué métodos existen para priorizarlos estratégicamente

Todo con ejemplos prácticos inspirados en el desarrollo de una aplicación de gestión de tareas basada en GTD (Getting Things Done), nuestro caso de estudio continuo.

¿Qué es un requisito de software?

Definición formal y práctica

En palabras de Klaus Pohl:

“Un requisito es una propiedad que debe tener un sistema para cumplir con una necesidad documentada de una parte interesada o una restricción impuesta por factores externos.”

Este concepto, desarrollado en Requirements Engineering: Fundamentals, Principles and Techniques, destaca que los requisitos son tanto necesidades como limitaciones. Es decir:

Un requisito de software = especificación de lo que el sistema debe hacer + restricciones sobre cómo debe hacerlo.

Por ejemplo:

“La aplicación debe permitir crear una nueva tarea introduciendo un título y pulsando Enter. La tarea creada debe estar visible solo para el usuario que la creó.”

• Especificación: crear tarea introduciendo un título y pulsando Enter
• Restricción: solo el usuario que la creó puede verla

Requisitos vs. Deseos vs. Soluciones

En ingeniería de requisitos es esencial no confundir:

• Requisitos: necesidades reales que el sistema debe satisfacer
• Deseos: ideas de usuarios que pueden o no tener valor real
• Soluciones: decisiones técnicas sobre cómo implementar un requisito

Uno de los retos es distinguir entre lo que los usuarios piden y lo que realmente necesitan. Aquí entran en juego técnicas de elicitación y validación, que trataremos en otro artículo.

Cómo redactar requisitos de calidad

Redactar un buen requisito no es solo escribir lo que el sistema debe hacer: es definirlo de forma clara, sin ambigüedad, medible y entendible para todos los involucrados.

Criterios de calidad (según IEEE 29148)

El estándar IEEE 29148 (sucesor del IEEE 830) establece las propiedades que debe cumplir cada requisito:

1. Correcto – refleja una necesidad del sistema
2. No ambiguo – solo tiene una interpretación posible
3. Completo – cubre todas las condiciones relevantes
4. Consistente – no entra en conflicto con otros requisitos
5. Verificable – puede probarse si se ha cumplido
6. Comprensible – legible por humanos y sin jerga innecesaria
7. Modificable – estructurado para poder cambiarlo sin romper el documento
8. Trazable – se puede seguir su origen y destino (por ejemplo, a pruebas o código)

Errores comunes y su mejora

Veamos ejemplos reales de requisitos mal definidos y cómo transformarlos en versiones de calidad.

❌ Ejemplo 1: Ambigüedad

“El sistema debe ser rápido.”

Esta frase es subjetiva. ¿Qué significa “rápido”? ¿Para quién? ¿Cuánto?

✅ Redacción mejorada:

“El sistema debe responder a las peticiones de creación de tareas en menos de 300 ms bajo una carga de 50 usuarios simultáneos.”

❌ Ejemplo 2: Indeterminación funcional

“La aplicación debe permitir ordenar las tareas.”

¿Ordenarlas cómo? ¿Por qué criterio? ¿Quién lo decide?

✅ Redacción mejorada:

“El usuario debe poder ordenar sus tareas por fecha de vencimiento, prioridad y fecha de creación, en orden ascendente o descendente, desde la vista de lista de tareas.”

❌ Ejemplo 3: Subjetividad

“La aplicación debe ser fácil de usar.”

¿Para quién? ¿Cómo lo medimos?

✅ Redacción mejorada:

“El 85% de los usuarios nuevos debe completar el proceso de creación de una tarea en menos de 2 minutos sin asistencia externa.”

Buenas prácticas generales

• Evita términos subjetivos: «fácil», «mejor», «rápido», «óptimo»
• Usa unidades medibles siempre que sea posible
• Redacta en voz activa: El sistema hará…, El usuario podrá…
• Utiliza identificadores únicos para cada requisito
• Relaciona los requisitos con sus fuentes (entrevistas, objetivos de negocio, estudios)

Cómo clasificar los requisitos

Clasificar los requisitos ayuda a organizarlos, priorizarlos y mantener trazabilidad. A continuación te explico los principales criterios.

Por nivel

1. Requisitos de Negocio
   • Responden al “por qué” del sistema
   • Reflejan metas y objetivos estratégicos
2. Requisitos de Usuario
   • Responden al “qué” debe permitir hacer el sistema
   • Describen interacciones desde el punto de vista del usuario final
3. Requisitos del Sistema
   • Responden al “cómo” se implementan los anteriores
   • Incluyen detalles técnicos, APIs, rendimiento, seguridad, etc.

Estos tres niveles están interrelacionados: un cambio en el nivel de negocio puede repercutir en todos los demás. Según Axel van Lamsweerde, esta jerarquía permite trazar los objetivos estratégicos hasta las implementaciones técnicas mediante el modelado orientado a objetivos (Goal-Oriented Requirements Engineering).

Por tipo

• Funcionales (RF): acciones o comportamientos específicos del sistema
• No funcionales (RNF): propiedades del sistema como seguridad, rendimiento, escalabilidad
• Restricciones: requisitos impuestos por contexto (plataformas, normativas, presupuesto)
• Requisitos de dominio: reglas específicas del sector (por ejemplo, una tarea no puede tener subtareas en GTD)

No todos los requisitos son funcionales, y los no funcionales suelen olvidarse… hasta que fallan.

Cómo priorizar requisitos

En cualquier proyecto real los recursos son limitados. No todo se puede implementar al mismo tiempo. Priorizar es decidir qué requisitos aportan más valor con menos coste o riesgo.

Aquí introducimos dos métodos prácticos: MoSCoW y KANO.

Método MoSCoW

Usado frecuentemente en desarrollo ágil, divide los requisitos en cuatro categorías para clasificarlos por prioridad:

• Must have (M) – Imprescindibles. El sistema no puede funcionar sin ellos.
• Should have (S) – Importantes pero no críticos para la entrega inicial.
• Could have (C) – Deseables, si el tiempo y presupuesto lo permiten.
• Won’t have (W) – No se harán ahora, pero se consideran para el futuro.

Ejemplo aplicado:

En nuestra app GTD, permitir crear tareas (Must have) es más prioritario que personalizar colores (Could have).

Modelo de KANO

Este modelo clasifica los requisitos según su impacto en la satisfacción del usuario:

• Básicos: Su ausencia molesta, pero su presencia no genera entusiasmo.
• Lineales: A más cumplimiento, más satisfacción.
• Delicia: El usuario no los espera, pero los valora mucho si están.
• Indiferentes / Reversos: No aportan valor o incluso pueden ser negativos.

Ejemplo aplicado:

Poder ver tareas completadas (básico), recibir estadísticas de cumplimiento semanal (lineal), usar comandos por voz para añadir tareas (delicia).

Este enfoque ayuda a diseñar productos no solo funcionales, sino memorables.

Conclusión

Saber qué es un requisito de software no se limita a poder definirlo: implica comprender cómo se redacta, se clasifica, se verifica y se gestiona. Los requisitos son la brújula del equipo, el lenguaje común entre negocio y tecnología, y la primera defensa contra el caos del desarrollo improvisado.

En este artículo hemos cubierto:

• La definición y estructura de un buen requisito
• Criterios internacionales de calidad como los del IEEE 29148
• Errores comunes y ejemplos de cómo evitarlos
• Clasificaciones por nivel y tipo
• Introducción a métodos de priorización como MoSCoW y KANO

Este contenido sirve como base sólida para abordar en siguientes entregas temas como:

• Cómo escribir requisitos funcionales y no funcionales paso a paso
• Cómo capturar requisitos desde entrevistas y observación
• Técnicas de trazabilidad y herramientas modernas para gestionar requisitos

Siguiendo esta guía, ya tienes los recursos necesarios para crear requisitos de calidad, ¿listo para profesionalizar tu gestión de requisitos? Sigue explorando el blog de Hexagonaly, y aprende a conectar teoría con código y decisiones.