Los requerimientos funcionales describen las funciones, servicios y comportamientos que el sistema debe ofrecer. Indican qué debe hacer el software ante determinadas entradas, acciones de usuarios, reglas de negocio o eventos.
Son una parte central de la especificación porque permiten entender las capacidades principales del producto. Por ejemplo, registrar un cliente, emitir una factura, consultar stock, enviar una notificación o generar un reporte son funciones posibles de un sistema.
En este tema estudiaremos qué son los requerimientos funcionales, cómo reconocerlos, cómo redactarlos y qué errores conviene evitar.
Un requerimiento funcional puede definirse de esta manera:
Los requerimientos funcionales suelen responder preguntas como:
Estos son ejemplos de requerimientos funcionales:
En todos los casos se describe una capacidad o comportamiento observable del sistema.
Los requerimientos funcionales pueden describir distintos tipos de comportamiento.
| Tipo de comportamiento | Descripción | Ejemplo |
|---|---|---|
| Registro de datos | El sistema guarda información ingresada o recibida. | Registrar un reclamo con cliente, motivo y descripción. |
| Consulta | El sistema muestra información según ciertos criterios. | Consultar pedidos por cliente, fecha o estado. |
| Modificación | El sistema permite cambiar información existente. | Actualizar el domicilio de un cliente. |
| Cálculo | El sistema obtiene un resultado a partir de datos y reglas. | Calcular intereses por pago fuera de término. |
| Validación | El sistema verifica condiciones antes de aceptar una operación. | Impedir una venta si no hay stock suficiente. |
| Notificación | El sistema informa un evento a una persona o sistema. | Enviar correo cuando se confirme una inscripción. |
| Integración | El sistema intercambia información con otro sistema. | Enviar datos de facturación al sistema contable. |
Los requerimientos funcionales indican qué debe hacer el sistema. Los no funcionales indican con qué calidad, bajo qué condiciones o con qué restricciones debe hacerlo.
| Requerimiento funcional | Requerimiento no funcional relacionado |
|---|---|
| El sistema debe permitir buscar clientes por documento. | La búsqueda debe responder en menos de 2 segundos bajo carga normal. |
| El sistema debe permitir registrar una venta. | Solo usuarios autorizados pueden registrar ventas. |
| El sistema debe generar un reporte mensual. | El reporte debe poder generarse en formato PDF y estar disponible durante 5 años. |
Ambos tipos son necesarios. Una función puede existir, pero ser inútil si no cumple condiciones mínimas de rendimiento, seguridad o usabilidad.
Muchos requerimientos funcionales se expresan desde la interacción de un usuario o actor con el sistema. Un actor puede ser una persona, otro sistema o un dispositivo externo.
Ejemplos:
Identificar quién realiza cada función ayuda a definir permisos, flujos y responsabilidades.
Una forma práctica de analizar un requerimiento funcional es identificar entradas, procesamiento y salidas.
| Elemento | Pregunta | Ejemplo en una venta |
|---|---|---|
| Entrada | ¿Qué datos recibe el sistema? | Cliente, productos, cantidades, forma de pago. |
| Procesamiento | ¿Qué reglas o acciones aplica? | Validar stock, calcular descuentos e impuestos. |
| Salida | ¿Qué resultado produce? | Venta registrada, comprobante generado y stock actualizado. |
Este análisis ayuda a completar requerimientos que inicialmente están demasiado vagos.
Muchas funciones dependen de reglas de negocio. Si la regla no se expresa, el requerimiento queda incompleto.
Por ejemplo, "registrar inscripción" parece simple, pero puede depender de reglas como:
Las reglas pueden documentarse junto al requerimiento o en una sección específica de reglas de negocio, pero deben estar visibles.
Un requerimiento funcional puede escribirse con distinto nivel de detalle. El nivel adecuado depende del proyecto, el riesgo, la criticidad y el grado de conocimiento compartido.
| Nivel | Ejemplo | Problema o utilidad |
|---|---|---|
| Muy general | El sistema debe gestionar clientes. | Es ambiguo; no indica operaciones ni datos. |
| Intermedio | El sistema debe permitir registrar, consultar y modificar clientes. | Indica funciones principales, pero faltan datos y reglas. |
| Más preciso | El sistema debe permitir registrar clientes con nombre, documento, correo y teléfono, validando que el documento no exista previamente. | Es más verificable y útil para desarrollo y pruebas. |
El objetivo no es escribir textos largos sin necesidad, sino aportar la información suficiente para evitar interpretaciones incorrectas.
Una forma simple de redactar requerimientos funcionales es usar una estructura como esta:
Ejemplos:
La redacción debe ser clara, directa y verificable.
No todas las funciones tienen la misma importancia. Algunas son esenciales para que el sistema cumpla su propósito; otras son auxiliares, administrativas o convenientes.
Por ejemplo, en un sistema de reclamos:
Distinguir importancia ayuda a priorizar entregas y a definir versiones.
Muchas funciones dependen del rol del usuario. No basta con decir que "el sistema debe permitir modificar pedidos"; también hay que indicar quién puede hacerlo y bajo qué condiciones.
Ejemplos:
Los permisos pueden documentarse como requerimientos funcionales, reglas de negocio o una matriz de roles y acciones.
Cuando un sistema intercambia información con otro, esa integración también puede expresarse como requerimiento funcional.
Ejemplos:
En integraciones conviene aclarar datos intercambiados, frecuencia, errores posibles y responsabilidades de cada sistema.
Para un sistema de biblioteca, algunos requerimientos funcionales podrían ser:
Estos requerimientos describen acciones observables que el sistema debe realizar.
Un requerimiento funcional se vuelve más claro cuando se acompaña con criterios de aceptación. Los criterios indican condiciones que deben cumplirse para considerar que la función está correctamente implementada.
Ejemplo:
Los criterios de aceptación ayudan a desarrollo, pruebas y validación con usuarios.
Al redactar requerimientos funcionales, suelen aparecer errores como:
Estos errores vuelven difícil diseñar, estimar, probar y validar el sistema.
Algunas buenas prácticas para requerimientos funcionales son:
Los requerimientos funcionales describen las capacidades concretas que el sistema debe ofrecer. Son esenciales para comprender qué operaciones, datos, reglas e interacciones formarán parte del producto.
Redactarlos bien permite que usuarios, analistas, desarrolladores y testers compartan una misma interpretación del comportamiento esperado.
En el próximo tema estudiaremos los requerimientos no funcionales y los atributos de calidad, que explican cómo debe comportarse el sistema en términos de seguridad, rendimiento, usabilidad, disponibilidad y otras cualidades importantes.