Análisis funcional
Resumen
El análisis funcional convierte una necesidad de negocio en una descripción verificable de lo que un sistema debe hacer. Su producto no es código ni una solución anticipada, sino requisitos, casos de uso, historias, procesos y criterios de aceptación que permiten construir lo correcto y demostrar que satisface la necesidad.
Esta guía cubre requisitos funcionales y no funcionales, elicitación, casos de uso, historias de usuario, modelado de procesos con BPMN, priorización y trazabilidad. También distingue verificación de validación, una confusión frecuente con consecuencias prácticas.
Material educativo independiente. No está afiliado, patrocinado ni respaldado por The Linux Foundation. LFCA es una marca de sus respectivos titulares.
Objetivos de aprendizaje
- Distinguir necesidades, requisitos funcionales y atributos de calidad.
- Identificar actores, casos de uso y escenarios principales y alternativos.
- Redactar historias de usuario con criterios de aceptación verificables.
- Interpretar los elementos básicos de un proceso BPMN.
- Aplicar priorización, trazabilidad y control de cambios.
Prerrequisitos y conexiones
El análisis funcional se apoya en la gestión de proyectos para acordar alcance y cambios, y alimenta la arquitectura con requisitos y restricciones. Una arquitectura sin requisitos claros optimiza supuestos; un requisito sin arquitectura viable se queda en deseo. En un enfoque ágil, el análisis no termina en una fase: se refina de forma continua con el equipo y los interesados.
De la necesidad al requisito
Una necesidad describe un problema u objetivo del negocio. Un requisito es una condición que el sistema debe cumplir para satisfacerla. Entre ambos hay un trabajo de elicitación: entrevistas, talleres, observación del trabajo real, análisis de documentos, encuestas o revisión de sistemas existentes. Preguntar "¿qué necesita lograr?" antes de "¿qué pantalla quiere?" evita diseñar una solución para el problema equivocado.
Los requisitos se suelen clasificar así:
- Funcionales: describen comportamientos o servicios. Por ejemplo, "el cliente puede restablecer su contraseña por correo".
- No funcionales: describen cualidades o restricciones medibles. Por ejemplo, "la búsqueda responde en menos de dos segundos con 500 usuarios concurrentes".
- De negocio o de interesados: expresan objetivos de alto nivel, como reducir el tiempo de atención o cumplir una norma.
- Restricciones: límites impuestos, como presupuesto, legislación o tecnología autorizada.
Un requisito de calidad debe ser, en la medida de lo posible, claro, completo, consistente, viable, verificable y trazable. La norma ISO/IEC/IEEE 29148 recoge criterios de este tipo para la ingeniería de requisitos. "El sistema debe ser rápido" no es verificable; "el 95 % de las búsquedas debe completarse en menos de dos segundos" sí lo es.
Técnicas de elicitación
No existe una técnica única. Las entrevistas permiten profundizar en motivaciones; los talleres reúnen perspectivas y resuelven conflictos; la observación revela trabajo no documentado; el análisis de documentos aporta reglas y restricciones; los prototipos ayudan a descubrir requisitos que el usuario no sabe expresar. Una buena práctica es triangular fuentes: lo que el usuario dice, lo que hace y lo que los datos muestran.
Requisitos no funcionales y atributos de calidad
Los atributos de calidad se describen con un estímulo, un contexto y una respuesta observable. En lugar de afirmar que el sistema "debe ser seguro", conviene indicar qué amenaza se considera, en qué condiciones y cómo se comprobará el resultado. La familia ISO/IEC 25010 organiza estos atributos en adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad, y funciona como lista de verificación, no como plantilla rígida.
| Atributo | Pregunta guía | Métrica de ejemplo |
|---|---|---|
| Rendimiento | ¿Cuánto tarda la operación y con qué carga? | percentil 95 por debajo de 800 ms con 300 peticiones por segundo |
| Disponibilidad | ¿Cuánto tiempo de servicio se compromete? | 99,9 % mensual y recuperación en 30 minutos |
| Escalabilidad | ¿Cómo evoluciona el coste al crecer? | latencia estable hasta 10 000 sesiones simultáneas |
| Seguridad | ¿Quién accede a qué y con qué evidencia? | 100 % de accesos administrativos con segundo factor |
| Usabilidad | ¿Qué esfuerzo exige completar la tarea? | 90 % de personas completa el alta en menos de cinco minutos |
| Mantenibilidad | ¿Cuánto cuesta introducir un cambio? | cobertura de pruebas superior al 80 % en módulos críticos |
| Operabilidad | ¿Cómo se detecta y corrige un fallo? | alerta en menos de dos minutos ante error sostenido |
Los atributos compiten entre sí: reducir la latencia suele encarecer la infraestructura, y elevar la disponibilidad complica los despliegues. Por eso el análisis funcional debe explicitar el compromiso aceptado y el entorno de medición. Una cifra sin condiciones —de carga, de hardware, de red o de tamaño de datos— es difícil de reproducir y, por tanto, de verificar. También conviene acordar quién mide, con qué herramienta y en qué etapa, porque un requisito de calidad sin método de comprobación termina siendo una opinión.
Reglas de negocio y glosario del dominio
Una regla de negocio es una restricción o criterio propio del dominio que existe con independencia del software. "Un descuento no puede superar el 30 % del subtotal" o "una factura solo se anula el mismo día de emisión" son reglas; la pantalla que las aplica es una implementación. Separar ambas cosas permite cambiar la interfaz sin renegociar la política y detectar reglas que hoy viven dispersas en hojas de cálculo.
| Término | Definición acordada | Consecuencia en el sistema |
|---|---|---|
| Cliente activo | Persona con al menos una compra en los últimos doce meses | Habilita promociones y comunicación comercial |
| Solicitud | Petición identificable con estado y responsable | Genera número de seguimiento e historial |
| Periodo de gracia | Ventana posterior al vencimiento sin penalización | Suspende cobros y avisos automáticos |
| Saldo pendiente | Importe reconocido y aún no conciliado | Bloquea el cierre contable del periodo |
El glosario evita que dos equipos usen la misma palabra para conceptos distintos. Cuando un término aparece en un requisito, en una tabla y en una interfaz con significados diferentes, las pruebas acaban midiendo cosas incompatibles. Mantener el glosario junto a los requisitos, con un responsable por término, reduce esa deriva y facilita la incorporación de nuevas personas.
Casos de uso y actores
Un actor es un rol externo que interactúa con el sistema para lograr un objetivo. Puede ser una persona, otro sistema o un servicio. No es una clase interna ni una tabla de base de datos. Un caso de uso describe una interacción completa entre actores y sistema para producir un resultado de valor.
Un caso de uso útil incluye:
- Nombre orientado a un objetivo, como "Registrar una reserva".
- Actores principales y secundarios.
- Precondiciones y postcondiciones.
- Flujo principal.
- Flujos alternativos y de excepción.
El diagrama UML de casos de uso muestra actores, casos y sus asociaciones. No muestra el orden temporal de las llamadas ni la estructura interna del software; para eso existen diagramas de secuencia o de actividad. Confundir el diagrama de casos de uso con un diagrama de flujo es un error común.
Escenarios, flujos y excepciones
Un caso de uso se completa con escenarios concretos. El flujo principal describe el camino que satisface el objetivo en condiciones normales; los flujos alternativos cubren variantes válidas, como elegir otra fecha; los de excepción tratan fallos o situaciones no deseadas, como la pérdida de conexión o un pago rechazado. Documentar solo el camino feliz deja fuera la mayor parte del trabajo real.
| Tipo de flujo | Cuándo aparece | Respuesta esperada | Dónde se registra |
|---|---|---|---|
| Principal | Todo ocurre según lo previsto | Completar el objetivo y confirmar el resultado | Caso de uso y criterios de aceptación |
| Alternativo | Existe una variante legítima | Ofrecer la opción y continuar el objetivo | Caso de uso, como extensión |
| Excepción | Falla una condición necesaria | Informar, conservar datos y permitir reintento | Caso de uso y requisito de error |
| Cancelación | El actor abandona la operación | Liberar recursos y dejar estado consistente | Reglas de estado y pruebas |
Ejemplo abreviado de un caso de uso "Devolver un pedido": el actor principal es el cliente; la precondición es un pedido entregado dentro del plazo; el flujo principal recibe la solicitud, valida el motivo, genera una etiqueta y registra la devolución; un flujo alternativo permite elegir reembolso en saldo; una excepción cubre el pedido ya devuelto; la postcondición deja el pedido en estado "devolución en curso". Este nivel de detalle permite derivar pruebas sin adivinar intenciones.
Las excepciones también son requisitos de calidad: un mensaje de error claro, la conservación de lo introducido y la ausencia de estados a medias son condiciones verificables. Un sistema que solo funciona cuando la red responde y el proveedor externo está disponible no cumple su promesa operativa.
Historias de usuario y criterios de aceptación
Una historia de usuario es una descripción breve de una necesidad desde la perspectiva de un rol. Un formato habitual es:
Como cliente, quiero guardar mi carrito para continuar la compra más tarde, para no perder los productos si cierro la sesión.
La historia no es una especificación completa: es una promesa de conversación. Los criterios de aceptación la vuelven verificable. Un formato extendido es Given/When/Then:
- Dado un cliente autenticado con productos en el carrito,
- cuando cierra la sesión,
- entonces el carrito se conserva y se recupera en el siguiente inicio de sesión.
El acrónimo INVEST recuerda que una buena historia es independiente, negociable, valiosa, estimable, pequeña y testeable. Los criterios de aceptación deben describir resultados observables, no detalles de implementación. "Usa Redis" es una decisión técnica; "el carrito se recupera en menos de un segundo" es un criterio verificable.
Refinamiento y división de historias
Una historia demasiado grande retrasa la retroalimentación y oculta dependencias. Dividirla no consiste en repartir capas técnicas, sino en cortar porciones que aporten valor observable. Algunos patrones útiles:
| Patrón | Pregunta que lo guía | Ejemplo aplicado |
|---|---|---|
| Por paso del flujo | ¿Qué parte se puede entregar primero? | Registrar la devolución antes de automatizar la etiqueta |
| Por regla de negocio | ¿Qué variante es la más frecuente? | Aplicar el descuento estándar antes que el acumulable |
| Por variación de datos | ¿Qué formato o canal llega antes? | Importar CSV antes que la integración en tiempo real |
| Por rol | ¿Quién obtiene valor primero? | Vista del operador antes que el panel del supervisor |
| Por rendimiento | ¿Qué volumen es suficiente al inicio? | Procesar mil registros antes de optimizar el lote |
La definición de preparado indica cuándo una historia puede entrar en una iteración: necesidad comprendida, criterios acordados, dependencias identificadas y diseño suficiente para estimar. La definición de terminado fija qué significa completarla: código revisado, pruebas automatizadas, documentación de usuario y despliegue verificado. Sin estos acuerdos, "terminado" se interpreta de forma distinta en cada equipo.
El refinamiento es continuo y no un evento aislado. Revisar historias pequeñas con quienes las usarán descubre supuestos antes de que se conviertan en retrabajo, y permite ajustar la prioridad con información más reciente. Una historia que nadie puede probar todavía suele necesitar una conversación, no más texto.
Modelado de procesos con BPMN
BPMN (Business Process Model and Notation) representa procesos de negocio. Sus elementos básicos incluyen:
- Eventos: inicio, intermedios y fin.
- Actividades: tareas y subprocesos.
- Compuertas: decisiones y convergencias; una compuerta exclusiva elige un camino.
- Pools y lanes: participantes y responsabilidades.
BPMN describe el flujo del proceso, no la arquitectura del software. Un pool suele representar una organización o participante; un lane, un rol o área dentro de él. Una compuerta exclusiva (XOR) modela una decisión: solo un camino continúa. Una compuerta paralela permite caminos simultáneos.
El modelado ayuda a detectar pasos redundantes, responsables ambiguos y excepciones no tratadas, y a acordar el alcance antes de escribir requisitos detallados.
Modelado de estados
Cuando un objeto recorre un ciclo de vida, un diagrama de estados aclara qué transiciones son legales y quién puede ejecutarlas. Para un pedido, los estados podrían ser borrador, confirmado, preparado, enviado, entregado, cancelado y devuelto. La utilidad está en las guardas: condiciones que deben cumplirse para pasar de un estado a otro.
| Transición | Guarda | Efecto observable |
|---|---|---|
| Borrador a confirmado | Pago autorizado y stock reservado | Se emite el número de pedido |
| Confirmado a preparado | Picking completado | Se notifica al cliente |
| Enviado a entregado | Confirmación del transportista | Se inicia el plazo de devolución |
| Entregado a devuelto | Solicitud dentro del plazo | Se genera la etiqueta inversa |
| Confirmado a cancelado | Antes de preparado | Se libera la reserva de stock |
El modelado revela transiciones imposibles, como devolver un pedido nunca entregado, y decisiones pendientes, como qué ocurre si el pago se autoriza después de la cancelación. Cada transición ilegal que el sistema permite es una fuente de inconsistencias contables o de inventario.
Priorización, trazabilidad y cambio
No todos los requisitos tienen el mismo valor. MoSCoW los clasifica en Must have, Should have, Could have y Won't have para esta entrega. La priorización debe considerar valor, riesgo, dependencias y costo; no solo la urgencia expresada por la persona que más insiste.
Una matriz de trazabilidad relaciona requisitos con casos de uso, diseño, código y pruebas. Su valor práctico aparece cuando un requisito cambia: permite saber qué componentes y pruebas se ven afectados. También ayuda a detectar requisitos huérfanos, es decir, funcionalidades sin justificación, y requisitos sin cobertura de prueba.
El control de cambios evalúa el impacto de una modificación antes de aceptarla. Aceptar cambios verbales sin análisis produce crecimiento no controlado del alcance. Un cambio puede ser válido, pero debe reflejarse en la línea base, el plan y las pruebas.
Verificación y validación
- Verificación: ¿estamos construyendo el producto correctamente? Comprueba que el sistema cumple la especificación, los criterios y las normas acordadas.
- Validación: ¿estamos construyendo el producto correcto? Comprueba que el sistema satisface la necesidad real del usuario en su contexto.
Un equipo puede verificar con éxito cada requisito y, aun así, fallar la validación si los requisitos no representaban la necesidad. Por eso conviene involucrar a usuarios reales en revisiones, prototipos y pruebas de aceptación.
Requisitos de datos
Los datos tienen requisitos propios: origen, calidad, volumen, retención y borrado. Un requisito funcional que consulta clientes supone un dato con identificador único, reglas de duplicados y una política de conservación. Ignorar esa capa produce informes que no cuadran y migraciones que se descubren tarde.
| Aspecto | Pregunta de análisis | Ejemplo verificable |
|---|---|---|
| Origen | ¿Qué sistema es la fuente autorizada? | El maestro de clientes proviene del CRM |
| Calidad | ¿Qué se considera un registro válido? | 99 % con correo sintácticamente válido |
| Volumen | ¿Cuánto crece y a qué ritmo? | 50 000 registros nuevos al mes |
| Retención | ¿Cuánto tiempo debe conservarse? | Siete años para documentos fiscales |
| Borrado | ¿Cómo se atiende una solicitud de supresión? | Eliminación en 30 días, con registro de la acción |
| Linaje | ¿De dónde viene cada campo? | Cada campo del informe tiene sistema de origen |
Conviene acordar también la migración: qué datos se cargan, cómo se transforman y cómo se comprueba que llegaron completos. Un conteo de registros no basta; se necesitan contrastes de importes, claves y fechas. La retención y el borrado se diseñan desde el inicio, porque añadirlos después obliga a reconstruir el historial.
Requisitos de seguridad y privacidad
La seguridad se expresa como comportamiento observable, no como adjetivo. Los casos de abuso describen cómo un atacante intentaría lograr un objetivo indebido: enumerar cuentas, elevar privilegios o exfiltrar datos. Cada caso de abuso se convierte en un control y en una prueba.
| Control | Requisito verificable |
|---|---|
| Autenticación | Los accesos administrativos exigen segundo factor |
| Autorización | Cada consulta valida el rol y el recurso solicitado |
| Registro de auditoría | Toda modificación conserva actor, fecha y valores anteriores |
| Minimización | Solo se recogen campos necesarios para la finalidad declarada |
| Cifrado | Los datos en tránsito usan canales cifrados |
| Bloqueo | Cinco intentos fallidos bloquean la cuenta durante 15 minutos |
| Caducidad | Las sesiones inactivas se cierran tras 30 minutos |
La privacidad se aborda desde el diseño: finalidad declarada, minimización, plazos de conservación y mecanismos para atender derechos de las personas. Regulaciones como el RGPD exigen transparencia y base legal, pero el análisis funcional debe traducirlas a flujos concretos: qué dato se recoge, para qué, durante cuánto tiempo y quién puede consultarlo. Sin esa traducción, la política queda en un documento que el sistema no respeta.
Documentación de requisitos
La documentación no tiene un único formato. Puede ser una especificación formal, un conjunto de historias con criterios o una combinación. Lo relevante es que exista una fuente única, versionada y comprensible para negocio y tecnología. Una estructura habitual de especificación incluye:
| Sección | Contenido | Pregunta que responde |
|---|---|---|
| Propósito y alcance | Contexto, objetivos y límites | ¿Por qué existe el sistema? |
| Interesados | Roles, necesidades y expectativas | ¿A quién afecta? |
| Requisitos funcionales | Comportamientos y reglas | ¿Qué debe hacer? |
| Requisitos no funcionales | Atributos con métricas | ¿Con qué calidad? |
| Interfaces | Entradas, salidas y sistemas externos | ¿Con qué se conecta? |
| Datos | Entidades, ciclo de vida y migración | ¿Qué información gestiona? |
| Restricciones | Normas, tecnología y presupuesto | ¿Qué no se puede elegir? |
| Trazabilidad | Vínculos con diseño y pruebas | ¿Qué cubre cada requisito? |
| Aceptación | Condiciones de satisfacción | ¿Cómo se demuestra? |
En entornos ágiles la especificación vive en el repositorio, junto al código, y se actualiza con cada incremento. Los documentos extensos que nadie mantiene pierden autoridad frente a la conversación diaria; las historias sin contexto tampoco bastan para un sistema regulado. El equilibrio está en documentar lo que reduce riesgo y en eliminar lo que solo decora.
Ejemplos prácticos
Caso 1: reserva de citas. Una clínica necesita reducir las citas perdidas. El requisito funcional puede ser "el paciente puede confirmar o reprogramar una cita desde un enlace"; el no funcional, "la confirmación se registra en menos de tres segundos". El caso de uso "Reprogramar cita" incluye flujo principal, cita inexistente y fecha no disponible. Los criterios de aceptación definen qué se observa al confirmar, y el BPMN muestra recepción, recordatorio, confirmación y escalado.
Caso 2: historia mal escrita. "Como usuario quiero un botón azul para que la app se vea moderna" mezcla una solución visual con una necesidad difusa. Preguntar por el objetivo puede revelar que el problema es encontrar la acción principal. La historia se reformula como "Como usuario nuevo, quiero identificar la acción principal en la primera pantalla, para completar el registro sin ayuda".
Caso 3: cambio de requisito. Negocio pide que el carrito caduque a los 30 días. La matriz de trazabilidad muestra que el requisito afecta al caso de uso, la base de datos, la tarea programada y las pruebas de recuperación. El control de cambios evalúa el impacto antes de modificar la línea base.
Caso 4: portal de trámites. Una administración quiere digitalizar una solicitud que hoy se presenta en papel. Los requisitos incluyen adjuntar documentos, guardar un borrador y recibir acuse. El análisis descubre que el acuse debe llevar sello de tiempo y que ciertos documentos caducan; ambos se convierten en requisitos no funcionales medibles y en reglas de estado. La trazabilidad vincula cada campo del formulario con una norma y con una prueba de validación.
Caso 5: migración de un sistema heredado. Un equipo reemplaza una aplicación antigua. Antes de escribir historias se inventaría qué hace el sistema actual, qué datos conserva y qué informes usa dirección. El riesgo principal no es la interfaz, sino las reglas ocultas en procesos manuales. Un taller con quienes operan el sistema descubre excepciones que ninguna documentación recogía, y esas excepciones se priorizan antes que las mejoras estéticas.
Caso 6: requisito de rendimiento negociado. Marketing pide que la página de ofertas "cargue rápido" durante una campaña. El análisis pregunta por el pico esperado, el dispositivo del usuario y la red disponible. Se acuerda un presupuesto: primer contenido visible en menos de dos segundos con 20 000 visitas simultáneas. El equipo descubre que la imagen principal pesa demasiado y que el requisito afecta al diseño, no solo al servidor. La métrica convierte una queja en una decisión compartida.
Lista de comprobación de una especificación
- ¿Cada requisito tiene un identificador estable y un responsable?
- ¿Los requisitos funcionales describen resultados observables?
- ¿Los atributos de calidad incluyen métrica, carga y entorno?
- ¿Los actores representan roles y no personas ni componentes internos?
- ¿Los casos de uso cubren flujos alternativos, excepciones y cancelación?
- ¿Las historias tienen criterios de aceptación acordados?
- ¿Las reglas de negocio están separadas de su implementación?
- ¿Los requisitos de datos incluyen origen, calidad, retención y borrado?
- ¿Existen casos de abuso y controles verificables?
- ¿La matriz de trazabilidad llega hasta las pruebas?
- ¿El control de cambios define quién aprueba y cómo se actualiza la línea base?
- ¿La documentación está versionada y accesible para negocio y tecnología?
Errores frecuentes
- Saltar a la solución técnica antes de entender la necesidad.
- Escribir requisitos no funcionales sin métricas verificables.
- Confundir actor con componente interno o usuario concreto.
- Aceptar historias sin criterios de aceptación.
- Priorizar por presión política.
- Perder la trazabilidad y descubrir el impacto de un cambio demasiado tarde.
- Confundir verificación con validación.
Puntos clave para el examen
- Requisito funcional: qué hace el sistema; no funcional: cómo debe comportarse.
- Un buen requisito es claro, consistente, viable, verificable y trazable.
- Actor: rol externo; caso de uso: interacción para un objetivo.
- Historia de usuario + criterios de aceptación = necesidad verificable.
- BPMN modela procesos; UML de casos de uso modela actores y objetivos.
- MoSCoW ayuda a priorizar; la trazabilidad mide impacto.
- Verificación: producto correcto según especificación; validación: producto correcto para la necesidad.
Glosario
- Línea base: conjunto de requisitos aprobados que sirve de referencia para medir cambios.
- Requisito huérfano: funcionalidad o requisito sin vínculo con un objetivo o una prueba.
- Criterio de aceptación: condición observable que permite decidir si una historia cumple lo acordado.
- Escenario: recorrido concreto de un caso de uso, con condiciones iniciales y resultado esperado.
- Guarda: condición que debe cumplirse para permitir una transición de estado.
- Caso de abuso: situación en la que alguien busca un resultado indebido y que origina controles de seguridad.
- Refinamiento: conversación continua para aclarar, dividir y estimar trabajo pendiente.
- Trazabilidad bidireccional: capacidad de ir del requisito a la prueba y de la prueba al requisito.
Recursos externos
- ISO/IEC/IEEE 29148, ingeniería de requisitos: https://www.iso.org/standard/72089.html
- OMG UML, especificación: https://www.omg.org/spec/UML/2.5.1/About-UML
- Agile Alliance, historias de usuario: https://www.agilealliance.org/glossary/user-stories/
- OMG BPMN, especificación: https://www.omg.org/spec/BPMN/
- IIBA, BABOK Guide: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Autoevaluación
-
¿Cuál es la diferencia entre un requisito funcional y uno no funcional? El funcional describe un comportamiento o servicio; el no funcional describe una cualidad medible o una restricción, como rendimiento, seguridad o disponibilidad.
-
¿Por qué un actor no es lo mismo que un usuario concreto? Porque el actor representa un rol que interactúa con el sistema. Varias personas pueden desempeñar el mismo rol, y un sistema externo también puede ser actor.
-
¿Qué aportan los criterios de aceptación a una historia de usuario? Convierten la intención en condiciones observables y verificables, reducen ambigüedad y permiten acordar cuándo la historia está terminada.
-
¿Qué diferencia hay entre verificación y validación? La verificación comprueba el cumplimiento de la especificación; la validación comprueba que el producto satisface la necesidad real del usuario.
-
¿Para qué sirve una matriz de trazabilidad? Para relacionar requisitos con diseño, código y pruebas, detectar huecos y evaluar el impacto de cambios y de requisitos sin cobertura.