Los casos raros primero
El recorrido previsto suele estar documentado y concentra menos incertidumbre. El coste aparece en la baja a mitad de curso, el pago devuelto, el permiso revocado y la convocatoria que se anula. Empiezo por esas excepciones.
Aclaro qué debe hacer el sistema antes de que el equipo empiece a construirlo.
Durante el análisis funcional aclaro qué pasa si el alumno se da de baja a mitad de convocatoria, quién puede ver una nota antes de publicarla o cómo responde el sistema si un pago se confirma tres días tarde. Resuelvo esos casos antes de que lleguen al código.
Criterio profesional
Un requisito solo está terminado cuando lleva dentro su propia forma de comprobarse.
Estas cuatro cosas separan un análisis que sirve de un documento que se firma y se archiva.
Estados, no pantallas
Antes de dibujar una interfaz determino en qué estados puede estar cada cosa y qué transición es legítima. Las pantallas suelen cambiar varias veces durante el proyecto; un modelo de estados bien planteado acostumbra a ser más estable, aunque también debe revisarse cuando cambian las reglas.
Cada regla, con responsables definidos
Una regla de negocio sin nadie que responda de ella acaba decidiéndose en el código, por quien la implementa y a la hora que sea. Cada una lleva quién la fija y quién puede cambiarla.
Cobertura, no ejemplos sueltos
Cruzo lo que puede hacer cada perfil con cada estado del sistema. Cada combinación sin definición explícita se clasifica como permitida, prohibida, no aplicable o pendiente.
Dónde se concentra la complejidad
El análisis falta justo cuando más se nota: en la demostración, no en la reunión de arranque.
Cada área entiende una cosa distinta, los requisitos son deseos que no se pueden comprobar y el comportamiento del sistema que se quiere sustituir no está documentado. Todo eso se paga más tarde y con un coste mayor.
El proyecto avanza y cada uno entiende algo distinto
Negocio, docencia y desarrollo hablan de lo mismo con palabras distintas. La discrepancia aparece en la demostración, cuando rehacerlo ya cuesta.
Los requisitos son una lista de deseos
Frases como «el sistema debe ser intuitivo» o «debe gestionar la formación» no se pueden construir ni comprobar. Alguien tiene que convertirlas en decisiones.
El sistema actual no está documentado
Hay que sustituir o integrar algo que lleva años funcionando y cuya lógica solo vive en la cabeza de dos personas y en el propio código.
Se prueba solo lo que se recuerda
Las pruebas cubren lo que a alguien se le ocurrió aquel día. Los fallos aparecen en combinaciones que nadie había enumerado.
Cada cliente pide una excepción
Lo que se acepta como particularidad se convierte en una variante permanente del producto porque nunca se decidió qué era configuración y qué era desarrollo.
Hay que escribir un pliego o valorar una oferta
Sin análisis funcional, un pliego se llena de generalidades y las ofertas no se pueden comparar entre sí.
Qué miro y qué queda por escrito
Qué entrego cuando hago análisis funcional.
Documentos que sirven para construir, para probar y para discutir con un proveedor. No para archivar.
Inventario funcional del sistema
Todo lo que el sistema permite hacer, quién puede hacerlo y desde dónde. Es la base de cualquier decisión posterior sobre alcance, pruebas o sustitución.
- Perfiles y permisos
- Acciones y puntos de entrada
- Configuraciones
- Avisos y notificaciones
- Navegación
Casos de uso y recorridos
Qué hace cada perfil, en qué orden, con qué precondiciones y cuál es el resultado al terminar. Incluye los recorridos que atraviesan a varias personas, que son los que fallan.
- Precondiciones y resultado
- Recorridos entre perfiles
- Casos alternativos
- Excepciones y errores
Modelo de estados y reglas de negocio
En qué estados vive cada entidad, qué transición es legítima y qué regla la gobierna, con la persona que responde de cada regla.
- Estados y transiciones
- Transiciones prohibidas
- Reglas con responsable
- Plazos y caducidades
Matriz de cobertura funcional
El cruce entre lo que puede pasar y lo que está definido y probado. Señala los huecos con nombre y apellidos, para que se decidan en vez de descubrirse en producción.
- Cruce de perfiles y estados
- Huecos identificados
- Prioridad por riesgo
- Base para el plan de pruebas
Especificación para construir
Lo anterior, escrito de forma que el equipo pueda estimarlo y desarrollarlo sin volver a preguntar lo mismo cada semana, y que un tercero pueda verificar.
- Requisitos comprobables
- Criterios de aceptación
- Alcance delimitado
- Trazabilidad hasta la necesidad
Documentación para pliegos y ofertas
Cuando hay que contratar fuera, el mismo análisis sirve para escribir un pliego que se pueda cumplir y para comparar ofertas por lo que resuelven.
- Alcance contratable
- Criterios de comparación
- Obligaciones documentales
- Condiciones de aceptación
Responsabilidades concretas
Respondo de que quede escrito qué debe pasar, incluidos los casos que nadie quiere mirar.
Levanto el proceso real con quien lo ejecuta, delimito el alcance funcional acordado y escribo requisitos que llevan dentro su propia forma de comprobarse. Lo que no se decide aquí queda como riesgo y puede terminar resolviéndose de forma implícita durante la implementación.
Levantar el proceso real
Hablo con quien lo ejecuta cada día y contrasto lo que me cuentan con lo que hace el sistema actual. Casi siempre hay distancia entre las dos cosas, y ahí está lo interesante.
Inventariar todo el alcance funcional
Registro los perfiles, las acciones, los estados, los permisos, las configuraciones, los avisos y los puntos de entrada incluidos en el alcance. Los huecos que aparecen durante el contraste quedan señalados como decisiones pendientes.
Escribir requisitos comprobables
Cada uno dice quién, qué, en qué condiciones y cómo se sabrá que está bien. Si no se puede escribir la comprobación, el requisito todavía no está terminado.
Modelar estados y excepciones
Qué transiciones son legítimas, cuáles están prohibidas y qué ocurre cuando algo se queda a medias. Es donde se concentran los fallos caros.
Construir la matriz de cobertura
Cruzo perfiles con acciones y estados. Cada combinación queda clasificada como permitida, prohibida, no aplicable o pendiente, y las pendientes se asignan a una persona responsable.
Decidir qué se configura y qué se construye
Con el análisis delante se puede separar lo que la plataforma ya resuelve de lo que exige desarrollo propio, y esa separación se defiende con argumentos.
Cómo trabajo
Del proceso real a una especificación que el equipo puede construir y otro puede verificar.
Empiezo por las excepciones, porque el recorrido previsto suele estar mejor documentado. Termino cruzando perfiles, acciones y estados para mostrar las decisiones que aún faltan.
- 01
Priorizar la incertidumbre
Empiezo por las excepciones, los cambios de estado y los cruces entre equipos que todavía no tienen una respuesta compartida.
- 02
Contrastar lo declarado con lo observado
Comparo lo que explican las personas con el comportamiento del sistema, la documentación y los casos reales; las diferencias quedan registradas, no resueltas por intuición.
- 03
Cerrar o asignar cada decisión
Una cuestión termina con una regla aprobada y comprobable o con una decisión pendiente, una persona responsable y una fecha. No desaparece dentro de la especificación.
Experiencia y trabajo propio
He especificado y he construido lo especificado, y eso enseña qué documentos resultan útiles.
Ver trayectoria y perfil- Más de veinte años a los dos lados: recogiendo requisitos y después construyendo lo que se especificó, que es lo que enseña qué especificaciones sirven.
- Método propio para delimitar el inventario funcional, contrastar la superficie relevante del sistema y registrar los huecos pendientes.
- Matrices de cobertura que cruzan perfiles, acciones y estados para localizar lo que todavía no se ha decidido.
- Experiencia en contextos con obligaciones documentales, donde lo que no se especifica al principio puede resultar costoso o imposible de reconstruir con garantías después.
- Trabajo habitual con responsables académicos, de negocio y técnicos, que necesitan que el mismo documento les sirva a los tres.
Trabajo propio relacionado
En mis proyectos propios, el análisis funcional es lo primero que queda documentado.
Las fichas muestran procesos completos con sus estados, sus responsables y sus excepciones. El trabajo hecho para otras organizaciones no aparece por confidencialidad.
Plataforma y operación
Gestión integral de programas formativos
Un proceso que atraviesa captación, admisión, convocatoria e inscripción, modelado con sus estados y responsables.
Ver la ficha de Gestión integral de programas formativos ↗Plataforma y operaciónControl operativo y evidencias de formación
Señales, alertas y responsables definidos antes de construir nada.
Ver la ficha de Control operativo y evidencias de formación ↗Plataforma y operaciónDetección e intervención ante el riesgo de abandono
Qué se considera riesgo, quién interviene y con qué evidencia.
Ver la ficha de Detección e intervención ante el riesgo de abandono ↗Blog
En el blog escribo sobre cómo se especifica algo que después se pueda comprobar.
Analizo por qué fallan las tomas de requisitos, cómo se descubren los casos que nadie contó y qué diferencia hay entre un documento que el equipo usa cada día y uno que se firma y no se vuelve a abrir.
Ir a blog.albertolarah.comHablamos
Si cada área entiende algo distinto del mismo proyecto, hablamos
Suele pasar cuando el requisito escrito no es el problema real. Me interesan esos casos: escríbeme y lo comentamos.