Inicio › Documentación › Definir y someter a revisión
Definir y someter a revisión
La Definición responde dos preguntas distintas, y Devora las nombra así en la interfaz:
| En la pantalla | Nombre técnico | Qué fija |
|---|---|---|
| Qué debe hacer la solución | Requisitos funcionales | El comportamiento que la solución debe tener |
| Cómo sabremos que está bien | Condiciones de satisfacción | Qué habrá que observar para dar el resultado por bueno |
Antes de empezar
- El Discovery debe estar completo: es el insumo.
- Permiso necesario: preparar la definición es un permiso propio. No incluye revisarla. Esa separación es el punto entero de esta etapa.
Paso 1 · Componer los requisitos funcionales
- Abre la etapa Definición.
- Pulsa Componer requisitos funcionales. Si la acción no está disponible, Devora dice por qué: «Faltan los requisitos funcionales de la definición.»
- Devora produce una propuesta. La interfaz lo declara sin ambigüedad: «Una propuesta de requisitos funcionales; el modelo no puede declararlos confirmados.»
- Revisa y corrige el contenido.
- Pulsa Materializar los requisitos funcionales para registrarlo como artefacto durable.
El artefacto queda con una versión y un hash de contenido: identifica exactamente esa redacción y ninguna otra.
Paso 2 · Someterlo a revisión
Al someter el artefacto, aparece en Decisiones como Revisar definición, con el contexto «Un artefacto de definición fue sometido y espera revisión.»
Quién revisa: una persona distinta de quien lo creó. La plataforma comprueba la separación y rechaza la firma del propio autor. En la etapa lo verás escrito así: «Operador del recorrido propone · Revisor aprueba».
Esta es la regla más consecuente de la Definición. Un artefacto aprobado por su propio autor no tiene segunda mirada, y toda la definición cuelga de él.
El revisor abre Ver la definición, lee el artefacto y lo aprueba o lo devuelve.
Paso 3 · Componer las condiciones de satisfacción
Con los requisitos funcionales aprobados, compón las condiciones. Devora entrega «identificadores estables, cobertura calculada, duplicados y advertencias de verificabilidad».
Lo que no hace la IA, y la propia interfaz lo declara: «Confirmar condiciones y declarar la evidencia esperada son actos humanos.»
Cada condición se traza a su requisito. Al terminar, el artefacto se somete y se revisa igual que los requisitos.
Resultado esperado y cómo comprobarlo
En la etapa Definición verás satisfechos los dos elementos: Qué debe hacer la solución con «Artefacto de requisitos funcionales aprobado y vigente», y Cómo sabremos que está bien con su artefacto aprobado. El Resumen mostrará la etapa con un check en esos dos tramos.
Lo que está bloqueado en el piloto, y por qué
La Definición tiene dos tramos más que hoy no puedes ejecutar:
- Consolidar los requisitos en una línea base. La capacidad está servida pero no certificada.
- Generar una matriz nueva de requisitos no funcionales. El código servido avanzó de versión y la certificación se quedó en la anterior; Devora bloquea la ejecución por esa diferencia exacta.
Lo que sí puedes hacer con los requisitos no funcionales: si ya existe una matriz aprobada, corregirla —añadir o editar filas, enviarla y ratificarla— está abierto. Esa vía no depende de la certificación.
Si la matriz aprobada deja sin evaluar una categoría que tu organización declaró crítica, la etapa de Diseño técnico queda bloqueada con ese motivo escrito, hasta que exista una versión que la resuelva. No es un fallo: es el control funcionando.
Errores frecuentes
| Lo que ves | Qué significa | Qué hacer |
|---|---|---|
| La acción de componer no aparece | Falta el insumo de la etapa anterior | Lee el motivo que Devora muestra junto a la acción |
| No puedes aprobar tu propio artefacto | Separación de autor y revisor | Pide la revisión a quien porte esa autoridad |
| «La arquitectura exige los requisitos funcionales aprobados.» | Intentaste avanzar sin la definición cerrada | Cierra primero los requisitos |
Siguiente