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 los procesos y necesidades de tu empresa en una definición funcional que el equipo pueda desarrollar y comprobar.
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
Partir de tareas y situaciones reales.
Recogemos cómo se trabaja mediante entrevistas, ejemplos de documentos y recorridos de uso. Identificamos quién inicia cada tarea, qué información necesita, qué resultado espera y quién continúa después.
Las excepciones forman parte de los requisitos: un dato incompleto, una reserva cancelada, un cambio de responsable o una operación duplicada pueden modificar el flujo. Documentarlas pronto ayuda a evitar interpretaciones distintas durante el desarrollo.
Requisitos funcionales y condiciones de funcionamiento.
Describimos acciones, estados, permisos, datos e integraciones. Cada requisito se relaciona con una necesidad y con el usuario que lo utiliza. Definimos también qué información es obligatoria y qué reglas deben mantenerse entre operaciones.
Las condiciones de funcionamiento se concretan según el proyecto: concurrencia prevista, tiempos de respuesta que deban comprobarse, dispositivos, disponibilidad o recuperación. Se expresan como criterios que puedan validarse, con un contexto y una forma de medirlos.
Un alcance que permita comparar presupuestos.
Organizamos las funciones por prioridad y explicitamos las dependencias. Diferenciamos la primera entrega de las ampliaciones previstas para que las propuestas de distintos equipos respondan a una base común.
Los bocetos de flujo o pantallas pueden ayudar a discutir el comportamiento. Su profundidad se acuerda con la empresa: en esta etapa se aclaran estructura y acciones; el diseño visual detallado puede desarrollarse después.
Aceptar el trabajo y gestionar los cambios.
Cada función relevante necesita un criterio de aceptación: qué situación se prepara, qué acción se realiza y qué resultado se espera. Esto conecta el documento inicial con las pruebas y la revisión de entregas.
Cuando aparece una necesidad nueva, se analiza su efecto en alcance, datos, calendario e integraciones. Mantener versiones y decisiones evita que el documento deje de representar lo que realmente se ha acordado construir.
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. |
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.
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
ERP para organizar la gestión de eventos audiovisuales y el trabajo interno de la empresa.
Conocer Eleka →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.
¿Es lo mismo que diseñar las pantallas?
La definición funcional concreta tareas, datos y comportamiento. Puede incluir esquemas para aclararlos; el diseño visual trabaja después la presentación y la interacción con mayor detalle.
¿Sirve si desarrolla otra empresa?
Sí. Los entregables se plantean para que el equipo responsable pueda comprender el alcance, hacer preguntas y contrastar las entregas.
¿Y si los requisitos cambian?
Acordamos cómo registrar, valorar y aprobar cambios. La prioridad es mantener trazabilidad entre la necesidad, la decisión y su impacto en el proyecto.
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.