DEV2BIT · CONSULTORÍA TECNOLÓGICA
Análisis de requisitos de software y definición funcional
Necesitas presupuestar o construir una aplicación y cada persona imagina algo distinto. Convertimos procesos, reglas y situaciones reales de trabajo en una definición funcional que negocio y desarrollo puedan revisar juntos.
El objetivo no es dibujar pantallas cuanto antes. Es aclarar qué tiene que ocurrir, quién puede hacerlo, qué información necesita, qué excepciones existen y cómo sabremos que el resultado cumple lo acordado.
LA DECISIÓN QUE VAMOS A RESOLVER
¿Qué tiene que hacer exactamente el sistema?
Usuarios, procesos, reglas y criterios de aceptación reunidos en una especificación compartida.
- 01Escuchar a los usuarios
- 02Modelar el proceso
- 03Definir reglas y límites
- 04Acordar la aceptación
Necesidad → Evidencia → Decisión → Siguiente paso
01 / DE LA NECESIDAD AL REQUISITO
«Necesitamos gestionar expedientes» todavía no define qué construir
Las empresas expresan objetivos válidos: controlar mejor las reparaciones, automatizar presupuestos o evitar datos duplicados. Pero cada uno deja abiertas decisiones que dos personas pueden interpretar de forma distinta.
Transformamos la necesidad en comportamientos discutibles. Si el objetivo es evitar facturar un expediente incompleto, el requisito puede indicar que el sistema impida generar la factura mientras falten determinados datos. Después hay que acordar cuáles son, quién puede completarlos y qué excepciones existen.
Esta definición no busca burocratizar el proyecto: evita que las interpretaciones diferentes lleguen al código o aparezcan al comparar presupuestos.
RESULTADO PARA TU PROYECTO
Una definición que el equipo puede desarrollar
Transformamos ideas, reuniones y excepciones en un alcance que negocio y desarrollo puedan revisar juntos.
Tareas y usuarios
Descripción de quién hace qué, con qué datos y en qué orden.
Reglas visibles
Casos habituales y excepcionales que suelen generar cambios tardíos si no se acuerdan.
Base de decisión
Requisitos priorizados para estimar, diseñar pantallas y validar entregas.
Ejemplo: gestionar un expediente de reparación.
EJEMPLO ORIENTATIVO DE TRABAJO
“Gestionar expedientes” se concreta en registrar el aviso, relacionarlo con la compañía, asignar trabajos, adjuntar documentación y revisar su estado. Cada paso necesita permisos y condiciones claras; por ejemplo, qué información debe existir antes de facturar.
En un sistema como Renovatio, la operativa de expedientes, trabajos, contactos y facturación muestra por qué una petición amplia necesita descomponerse en recorridos y condiciones. El ejemplo anterior simplifica ese tipo de trabajo; no afirma que la regla ilustrativa sea la lógica exacta del ERP.
Experiencia que da contexto a las decisiones.
Renovatio
Desarrollo de un ERP que relaciona expedientes, trabajos, contactos y facturación con la operativa de reparaciones y siniestros.
Conocer Renovatio →
Eleka
La planificación de eventos audiovisuales relaciona fechas, responsables, equipos y vehículos. Sirve para mostrar que los requisitos describen decisiones y recursos, además de altas y consultas de datos.
Conocer Eleka →EL RECORRIDO
Tu proyecto, paso a paso
Entendemos el proceso
Usuarios, tareas, información y problemas actuales.
Identificamos reglas
Condiciones y excepciones que cambian el recorrido.
Definimos requisitos
Comportamientos, datos y permisos funcionales.
Delimitamos el alcance
Prioridades, dependencias y fases.
Definimos aceptación
Resultados observables para validar funciones relevantes.
Revisamos con las partes
Negocio y equipo técnico comparten la definición.
02 / PROCESOS Y ACTORES
Primero recorremos cómo se realiza realmente el trabajo
Entrevistas, documentos y ejemplos permiten reconstruir una operación: quién la inicia, qué información recibe, qué decisión toma, qué modifica, quién continúa y qué resultado necesita. El procedimiento escrito puede omitir excepciones y comprobaciones informales que el equipo aplica todos los días.
Identificamos roles desde el punto de vista funcional. Administración puede necesitar corregir datos económicos, un técnico registrar un trabajo y un cliente consultar el estado. Aquí acordamos quién debería poder hacer qué; la autenticación y la autorización técnica se diseñan después.
Estados
Definimos cómo se entra en un estado, quién puede cambiarlo, qué datos exige, si puede revertirse y qué operaciones permite. La lista «abierto → revisión → cerrado» no explica por sí sola qué ocurre si un expediente debe reabrirse.
Información
Identificamos qué datos entran, cuáles produce cada operación, cuáles son obligatorios y cuáles proceden de otro sistema. Todavía no diseñamos toda la base de datos.
Reglas
Una regla como «un expediente cerrado no puede modificarse» pertenece al proceso, no al botón de una pantalla. Expresarla aparte permite mantenerla aunque cambie la interfaz.
Excepciones
Priorizamos las que ya suceden o cambiarían de forma importante el resultado: cancelaciones, duplicados, datos ausentes o una integración que no responde. No intentamos imaginar situaciones infinitas.
03 / COMPORTAMIENTO Y CONDICIONES
Qué debe hacer el sistema y en qué circunstancias son preguntas distintas
Un requisito funcional puede decir que una persona consulta sus pedidos. Una condición de funcionamiento aclara desde qué dispositivos, con qué disponibilidad o bajo qué carga debe poder hacerlo, cuando esos aspectos importan de verdad al proyecto.
Preferimos expresar una condición que pueda comprobarse: un recorrido en los navegadores acordados o un tiempo de respuesta bajo un escenario definido. «Debe ser rápido» o «debe ser compatible» dejan demasiadas interpretaciones abiertas.
Si estas condiciones determinan la organización técnica, la siguiente decisión pertenece a la arquitectura de software. El análisis de requisitos define qué necesita cumplirse; no escoge el stack ni diseña toda la infraestructura.
04 / ACEPTACIÓN
Un requisito necesita un resultado observable para saber si se ha cumplido
Un criterio de aceptación describe una situación, una acción y el resultado que negocio y desarrollo podrán contrastar. No obliga a una plantilla fija ni decide cómo se programará la función.
Un expediente cerrado.
Una persona sin permiso intenta modificarlo.
El sistema rechaza la operación y el expediente queda sin cambios.
Criterio de aceptación
Define qué resultado debe observarse.
Prueba o comprobación
Define cómo verificar que ocurre: una prueba de regla, API, interfaz, integración o revisión funcional, según el riesgo.
Esta página no decide automáticamente el nivel ni la automatización de cada prueba. Deja claro el comportamiento esperado para que el desarrollo pueda comprobarlo y conservarlo.
La guía de testing de software explica cómo convertir ese comportamiento esperado en comprobaciones útiles durante la implementación y los cambios posteriores.
La guía de ingeniería de software sitúa este trabajo dentro del ciclo completo: el requisito define el comportamiento, las pruebas aportan evidencia y la entrega organiza cuándo y cómo se publica el cambio.
05 / TRAZABILIDAD
Seguir una necesidad hasta aquello que finalmente comprobamos
Si una regla cambia meses después, necesitamos saber por qué existía, qué otras funciones dependen de ella y qué escenarios podrían verse afectados. La profundidad de esa relación se ajusta al tamaño y la criticidad del proyecto; no hace falta una matriz enorme para cada encargo.
Ejemplo orientativo de análisis; no reproduce una regla específica del proyecto Renovatio.
06 / ALCANCE Y CAMBIOS
Definir lo que no entra también forma parte del proyecto
Distinguimos lo imprescindible en la primera entrega, las ampliaciones previstas, lo opcional y lo que queda fuera. Así distintos proveedores pueden valorar una base comparable y una expectativa no discutida no aparece como obligación al final.
Prioridad
Ordenamos funciones por valor, dependencia y riesgo, sin convertir la lista en una promesa de desarrollar todo a la vez.
Cambios
Cuando aparece una necesidad nueva, revisamos qué requisitos, datos, aceptación, coste y calendario afecta. Cambiar no es un fracaso; lo importante es saber qué decisión está vigente.
Los requisitos también pueden servir para comparar una selección de software y ERP. No implican automáticamente construir una solución a medida.
RESULTADO DEL TRABAJO
Entregables para tomar la siguiente decisión.
| Entregable | Qué contiene | Para qué sirve |
|---|---|---|
| Mapa de procesos y roles | Recorridos, actores, entradas, salidas y excepciones. | Compartir cómo debe funcionar la aplicación. |
| Especificación funcional | Funciones, datos, permisos y reglas de negocio. | Preparar el desarrollo y comparar propuestas. |
| Criterios de aceptación | Escenarios verificables y prioridades de entrega. | Revisar si el resultado cumple lo acordado. |
| Condiciones de funcionamiento | Rendimiento, compatibilidad, disponibilidad u otras cuando sean relevantes. | Identificar restricciones verificables. |
| Priorización | Primera fase, ampliaciones y dependencias. | Preparar presupuesto y planificación. |
| Decisiones y cambios | Supuestos, aclaraciones y modificaciones relevantes. | Conservar la trazabilidad del acuerdo. |
Los entregables concretos se ajustan al objetivo y tamaño del encargo. Deben ayudar a decidir, desarrollar y comprobar, no producir volumen documental sin utilidad.
Cómo concretamos alcance, dedicación y presupuesto.
Antes de empezar acordamos la decisión que debe resolver el encargo, los entregables, las personas que participarán y la información disponible. La propuesta concreta las reuniones, revisiones y comprobaciones incluidas.
El coste y el plazo dependen del número de procesos o sistemas, de su documentación y del grado de incertidumbre. Si una conclusión exige una prueba adicional, se plantea su alcance antes de realizarla. Recibirás las conclusiones junto con sus supuestos y los siguientes pasos recomendados.
Preguntas antes de empezar.
¿Qué diferencia hay entre una necesidad y un requisito?
La necesidad expresa un objetivo o problema. El requisito concreta qué comportamiento debe proporcionar el sistema para responder a ella.
¿Un requisito tiene que describir una pantalla?
No. También puede describir reglas, datos, permisos, estados o condiciones independientes de la interfaz.
¿Qué es un criterio de aceptación?
Una condición observable que permite comprobar si un requisito se ha cumplido en una situación determinada.
¿Un criterio de aceptación es un test?
No. El criterio define qué resultado se espera; el test o la revisión decide cómo comprobarlo.
¿Definís también las excepciones?
Sí, cuando son relevantes. Un recorrido puede funcionar en el caso normal y fallar con cancelaciones, duplicados o datos ausentes.
¿Definís condiciones de funcionamiento?
Cuando importan al proyecto concretamos rendimiento, compatibilidad, disponibilidad u otras condiciones de forma verificable.
¿El análisis decide qué tecnología usar?
No necesariamente. Primero define qué necesita el sistema; arquitectura y desarrollo toman después las decisiones técnicas.
¿Necesito una fase separada antes de cualquier desarrollo?
No. En proyectos pequeños los requisitos pueden concretarse dentro del desarrollo. La fase específica ayuda cuando hay varios procesos, personas, integraciones o incertidumbres.
¿Sirve para solicitar varios presupuestos?
Sí. Una definición compartida ayuda a que los proveedores valoren aproximadamente el mismo alcance.
¿Sirve si después desarrolla otra empresa?
Sí. Los entregables se plantean para que otro equipo pueda comprender el alcance y contrastar las entregas.
¿Qué ocurre si cambian los requisitos?
Se analiza su efecto en alcance, dependencias, datos, coste y criterios de aceptación, y se registra la decisión vigente.
¿Necesitáis hablar con los usuarios?
Cuando conocen pasos no documentados, entrevistarlos puede aportar información esencial para definir el comportamiento.
¿Hacéis prototipos?
Podemos usar diagramas o bocetos funcionales para aclarar recorridos; eso no equivale al diseño visual final.
¿El resultado es un documento enorme?
No por defecto. La documentación se ajusta al proyecto y debe servir para decidir, desarrollar y comprobar.
Continúa según lo que necesite tu proyecto.
CONCRETEMOS LA DECISIÓN
Cuéntanos qué necesitas resolver.
Describe cómo trabajáis ahora, qué está frenando el proyecto y qué decisión tienes pendiente. Acordaremos la información necesaria y el alcance de la consultoría.