En un proyecto de software no alcanza con saber qué funciones debe tener el sistema. También es necesario definir cómo debe comportarse respecto de calidad, seguridad, rendimiento, usabilidad, disponibilidad, mantenimiento y otras condiciones importantes.
Por eso se suele distinguir entre requerimientos funcionales y requerimientos no funcionales. Los primeros describen funciones o comportamientos específicos del sistema. Los segundos describen cualidades, restricciones o condiciones que afectan la forma en que esas funciones deben cumplirse.
Comprender esta diferencia ayuda a especificar mejor el sistema y a evitar que aspectos críticos de calidad queden implícitos.
Un requerimiento funcional describe una acción, servicio o comportamiento que el sistema debe ofrecer. Responde principalmente a la pregunta: ¿qué debe hacer el sistema?
Ejemplos de requerimientos funcionales:
Un requerimiento no funcional describe una característica de calidad, una restricción o una condición bajo la cual el sistema debe operar. Responde a preguntas como: ¿qué tan rápido?, ¿qué tan seguro?, ¿qué tan disponible?, ¿qué tan fácil de usar?, ¿bajo qué condiciones?
Ejemplos de requerimientos no funcionales:
Estos requerimientos pueden no describir una función nueva, pero condicionan fuertemente el diseño, la arquitectura, las pruebas y la operación.
| Aspecto | Requerimiento funcional | Requerimiento no funcional |
|---|---|---|
| Pregunta principal | ¿Qué debe hacer el sistema? | ¿Cómo debe hacerlo o bajo qué condiciones? |
| Enfoque | Funciones, acciones, reglas y servicios. | Calidad, restricciones, rendimiento, seguridad, operación. |
| Ejemplo | El usuario puede cancelar una reserva. | La cancelación debe registrarse en auditoría. |
| Validación | Probar que la función existe y se comporta correctamente. | Medir o verificar que se cumple una condición de calidad. |
| Impacto | Afecta funcionalidades específicas. | Puede afectar todo el sistema o varias funcionalidades. |
Muchas reglas de negocio se expresan dentro de requerimientos funcionales. Una regla de negocio describe una política, condición o restricción propia del dominio del problema.
Ejemplos:
Estas reglas forman parte del comportamiento funcional del sistema porque determinan qué acciones se permiten, se rechazan o se calculan.
Los requerimientos no funcionales suelen estar relacionados con atributos de calidad. Estos atributos describen propiedades importantes del producto.
| Atributo | Qué evalúa | Ejemplo de requerimiento |
|---|---|---|
| Rendimiento | Tiempo de respuesta, capacidad y uso de recursos. | El listado de pedidos debe cargar en menos de tres segundos para hasta 5.000 registros. |
| Seguridad | Protección de datos, accesos y operaciones. | Solo usuarios con rol administrador pueden eliminar productos. |
| Usabilidad | Facilidad de aprendizaje y uso. | Un usuario nuevo debe poder completar una reserva sin capacitación previa. |
| Disponibilidad | Tiempo en que el sistema está operativo. | El sistema debe estar disponible el 99% del tiempo durante horario comercial. |
| Mantenibilidad | Facilidad para corregir, adaptar y mejorar. | Las reglas de descuento deben poder modificarse sin cambiar la interfaz de usuario. |
| Compatibilidad | Funcionamiento en entornos definidos. | La aplicación debe funcionar en las dos últimas versiones de Chrome, Edge y Firefox. |
| Accesibilidad | Uso por personas con distintas capacidades. | Los formularios deben poder completarse usando teclado. |
Los requerimientos no funcionales pueden tener gran impacto en la arquitectura. Una misma funcionalidad puede requerir soluciones técnicas muy distintas según las condiciones de calidad exigidas.
Por ejemplo, "consultar saldo de una cuenta" parece una función simple. Pero si debe responder a millones de usuarios, estar disponible todo el día, registrar auditoría, proteger datos sensibles y recuperarse rápidamente ante fallas, la arquitectura será mucho más exigente.
Algunas decisiones afectadas por requerimientos no funcionales son:
Tanto los requerimientos funcionales como los no funcionales deben poder verificarse. Un requerimiento ambiguo genera discusiones porque no queda claro cuándo está cumplido.
| Requerimiento débil | Problema | Versión más verificable |
|---|---|---|
| El sistema debe ser rápido. | No define qué significa rápido. | El sistema debe mostrar resultados de búsqueda en menos de dos segundos para el 95% de las consultas. |
| La aplicación debe ser segura. | Seguridad es demasiado general. | Después de cinco intentos fallidos de inicio de sesión, la cuenta debe bloquearse durante quince minutos. |
| La interfaz debe ser fácil. | No indica para quién ni cómo medirlo. | Un usuario nuevo debe completar el registro con los campos obligatorios en menos de tres minutos durante una prueba de usabilidad. |
| El sistema debe estar siempre disponible. | "Siempre" puede ser irreal o impreciso. | El sistema debe estar disponible el 99,5% del tiempo mensual, excluyendo mantenimiento programado. |
En la práctica, una funcionalidad puede tener condiciones no funcionales asociadas. No siempre conviene separarlas artificialmente si se entienden mejor juntas.
Ejemplo:
La primera parte describe una función: consultar pedidos. La segunda parte define una condición de rendimiento. Ambas son importantes para que la funcionalidad sea aceptable.
Para un sistema de reservas, algunos requerimientos funcionales podrían ser:
Y algunos requerimientos no funcionales podrían ser:
En una tienda en línea, los requerimientos funcionales describen acciones comerciales:
Los requerimientos no funcionales indican condiciones críticas:
Los requerimientos funcionales y no funcionales deben priorizarse. Muchas veces se priorizan funciones visibles y se dejan para después aspectos de calidad. Esto puede ser riesgoso.
Por ejemplo, una aplicación bancaria no puede dejar la seguridad para el final. Una plataforma de venta masiva no puede ignorar rendimiento. Un sistema médico no puede tratar la trazabilidad como detalle menor.
Al priorizar conviene considerar:
Los criterios de aceptación ayudan a verificar si un requerimiento está cumplido. Para requerimientos funcionales, suelen describir escenarios, entradas, acciones y resultados esperados. Para requerimientos no funcionales, suelen incluir métricas, condiciones de prueba o límites verificables.
| Requerimiento | Criterio de aceptación |
|---|---|
| El usuario debe poder cancelar una reserva. | Dada una reserva activa, cuando el usuario presiona cancelar y confirma, la reserva queda con estado cancelada y el horario vuelve a estar disponible. |
| La búsqueda debe responder rápidamente. | Con 10.000 productos cargados, el 95% de las búsquedas debe responder en menos de dos segundos. |
| Las acciones administrativas deben auditarse. | Cada alta, baja o modificación debe registrar usuario, fecha, hora, entidad afectada y operación realizada. |
Al trabajar con requerimientos funcionales y no funcionales suelen aparecer errores como:
Una forma de registrar requerimientos diferenciando su tipo es la siguiente:
| Identificador | Código o nombre corto. |
|---|---|
| Tipo | Funcional o no funcional. |
| Descripción | Qué debe cumplir el sistema. |
| Justificación | Necesidad, actor o riesgo que lo motiva. |
| Prioridad | Alta, media, baja u otra escala acordada. |
| Criterio de aceptación | Condición observable para considerarlo cumplido. |
| Impacto | Funcionalidades, arquitectura, pruebas u operación afectadas. |
Distinguir entre requerimientos funcionales y no funcionales permite describir mejor un sistema. Las funcionalidades indican qué debe hacer; los atributos de calidad y restricciones indican cómo debe comportarse, con qué límites y bajo qué condiciones.
Para quien comienza, la idea principal es esta: un sistema no es correcto solo porque tiene funciones; también debe cumplir condiciones de calidad que lo hagan útil, seguro, eficiente, usable y mantenible.
En el próximo tema veremos historias de usuario, casos de uso y criterios de aceptación, tres herramientas habituales para expresar necesidades, interacciones y condiciones de validación.