Un documento de requisitos de 500 páginas contiene cientos de obligaciones verificables. Convertirlas en pruebas estructuradas y trazables es mecánico, tedioso y le toma semanas a un ingeniero senior. Construimos una plataforma que hace la transcripción y deja el criterio a sus ingenieros — con revisión humana antes de tocar su herramienta ALM.
Escala desplegada
El problema
Toda organización de verificación con la que hemos trabajado tiene las mismas tres. La mayoría de las herramientas atiende una y finge que las otras dos no existen.
GAP 01
Los requisitos viven en PDFs, archivos Word y hojas de cálculo. Los pruebas deben vivir en una herramienta estructurada. El puente entre ambos es un humano transcribiendo una especificación, obligación por obligación, durante semanas — y equivocándose bajo presión de plazos.
GAP 02
Sus repositorios definen el comportamiento real del sistema — fuentes en C y C++, artefactos de diseño basado en modelos, componentes RTOS, definiciones de interfaz y arneses — sin cobertura correspondiente. Los ingenieros rastrean la estructura del código a mano, y nadie puede decir qué porcentaje del comportamiento implementado está verificado.
GAP 03
Miles de casos existentes usan estructura inconsistente, carecen de enriquecimiento de señales, omiten precondiciones y no tienen trazabilidad a requisitos. Modernizarlos a mano es aritméticamente imposible, así que la deuda se acumula y cada auditoría la vuelve a sacar a la luz.
Arquitectura
La base de conocimiento se construye analizando su código real en entidades de señal y fragmentos de código. Cada ruta de generación se fundamenta en ella, por eso la salida referencia cosas que existen y no cosas que un modelo recuerda.
Cada caja arriba es un subsistema empaquetado por separado con su propio almacén, telemetría e interruptor. Desactivar cualquiera deja la tubería central sin cambio alguno.
Subsistemas
Cada subsistema está aislado y es tolerante a fallos: una falla devuelve vacío en lugar de derribar a otro. Eso hace realista un despliegue por etapas en vez de una migración de todo o nada.
| Subsistema | Qué hace | Por defecto |
|---|---|---|
| Tubería de Requisitos | Lee documentos de especificación, extrae requisitos verificables, empareja señales, genera casos en lenguaje natural y ejecutables, y envía los aprobados a su herramienta ALM. | Central |
| Generador de Cobertura | Ingiere repositorios de software embebido — C/C++, diseño basado en modelos, componentes RTOS — desde control de versiones o sistema de archivos, normaliza artefactos en fragmentos y genera pruebas unitarias y de integración ejecutables por componente con iteración guiada por cobertura. | Activo |
| Monitor de Fusiones | Monitorea PRs fusionados en repositorios vigilados, evalúa la relevancia conductual de cada uno, reconstruye la intención verificable desde el diff y pasa por un panel de alcance antes de despachar. | Opcional |
| Modernizador de Suites | Lee casos heredados de suites existentes, los adapta a una estructura estándar con enriquecimiento de señales, muestra un diff por campo con pasos editables y escribe las actualizaciones aprobadas en sitio. | Opcional |
| Consulta Conversacional | Preguntas en lenguaje natural sobre señales, requisitos y código con tres planos de citación, filtrado por repositorio, contexto multi-turno y un crítico de fundamentación que rechaza respuestas sin respaldo. | Opcional |
| Memoria Documental | Memoria semántica persistente sobre prosa de requisitos y artefactos de código. Alimenta a los demás subsistemas con contexto citado y consultable para que compartan una sola vista del corpus. | Activo |
| Escáner de Cobertura | Escaneo proactivo de señales y funciones sin cobertura en cada combinación de configuración, con triaje asistido opcional para priorizar lo que realmente importa. | Opcional |
| Redacción de Requisitos | Redacta requisitos formales tipo "shall" a partir de prosa de ingeniería, con validación de fundamentación contra la base de conocimiento. | Aislado |
Lo innegociable
Esta es la restricción que hace adoptable el sistema en una organización de verificación regulada. Generar es rápido y barato; una prueba incorrecta escrito en silencio en un plan de pruebas no lo es. Por eso cada artefacto generado se detiene en una cola de revisión.
Aprobar, editar o rechazar — cada caso, individualmente o en lote, con el requisito fuente al lado.
Diffs por campo en actualizaciones heredadas — ve exactamente qué cambia en un caso existente antes de escribir, nunca un reemplazo total.
Trazabilidad escrita al generar — cada caso lleva el identificador del requisito y las señales que lo produjeron, así una auditoría se responde sola.
Un crítico de fundamentación actúa primero — la salida que referencia una señal ausente del índice se rechaza antes de llegar al revisor.
SOURCE REQUIREMENT
SRS-0912 · §4.2.1
"El controlador deberá deshabilitar la etapa de salida cuando la bandera de validez de entrada permanezca desactivada por más de 250 ms."
MATCHED SIGNALS · re-ranked
GENERATED CASE
pre device in run mode, output stage enabled
step deassert SensorInput_Valid
step hold for 300 ms
exp OutputEnable_Cmd deasserted within 250 ms
Quién lo usa
Dejan de transcribir especificaciones. Revisan casos generados junto al requisito fuente y dedican el tiempo recuperado a los casos límite que el documento nunca enunció.
Generan cobertura directamente desde modelos de comportamiento, definiciones de interfaz y bancos de prueba, con trazabilidad opcional a requisitos en cada caso generado.
Llenan un plan de pruebas en una tarde en lugar de un trimestre, o ejecutan una modernización sobre una suite heredada intocable durante años.
Preguntan qué hace una señal, en qué configuraciones aparece o cómo interactúan dos componentes — y reciben una respuesta con citas a señales, documentos y código.
Redactan requisitos formales desde prosa de ingeniería con validación de fundamentación, y luego ejecutan un escaneo de cobertura para ver qué queda sin probar.
Responden la pregunta que antes nadie podía: ¿qué fracción del comportamiento implementado está verificada y dónde está exactamente la brecha?
No se requiere normalización previa. Apunta la tubería al corpus que ya tiene.
Especificaciones estructuradas
Identificadores formales de requisito y encabezados de sección, como los producen las herramientas de gestión de requisitos.
Especificaciones narrativas
Prosa con lenguaje "shall", "must" y "should", sin identificadores formales — extraída, clasificada y con identificadores trazables asignados automáticamente.
FAQ
Solo después de aprobación humana. Cada caso generado entra en una cola de revisión donde un ingeniero aprueba, edita o rechaza. Las actualizaciones heredadas muestran además un diff por campo contra el caso existente antes de escribir. Consideramos que una escritura desatendida en un plan de pruebas es un defecto, no una función.
La generación se fundamenta en un índice construido desde su código, no en la memoria del modelo. Los requisitos se emparejan con entidades de señal reales con una pasada de re-clasificación, y un crítico de fundamentación rechaza cualquier salida que referencie algo ausente del índice antes de llegar al revisor. El modelo elige entre cosas que existen; no aporta el vocabulario.
No — elimina la transcripción y deja el criterio. La habilidad escasa en verificación es saber qué caso límite omitió la especificación, no teclear precondiciones en un formulario. Los equipos que lo adoptan reasignan ingenieros senior de la captura de datos al análisis de cobertura y la resolución de brechas.
No. La mayoría de los proyectos empieza con uno. Cada subsistema es un paquete separado con su propio almacén, telemetría e interruptor, y todos son tolerantes a fallos — una falla devuelve vacío en lugar de derribar a otro. Desactivar uno deja la tubería central sin cambios, que es justo la propiedad que hace defendible un despliegue por etapas ante un comité de cambios.
A través de su propio gateway de IA interno. Todos los subsistemas comparten un transporte único que apunta al endpoint de inferencia que su organización ya aprobó, de modo que el acceso al modelo sigue su política existente en lugar de introducir una nueva ruta de proveedor. El modelo de embeddings corre residente y localmente, por eso agregar un subsistema no cuesta un despliegue de modelo nuevo.
En una sesión técnica llevaremos su documento real por la ruta de extracción y le mostraremos cómo se ven las señales emparejadas y los casos generados con sus propias convenciones — no con un corpus de demostración enlatado.
Escrito sobre esto
Guía
Conectar un Sistema Agéntico a Azure DevOps
Herramientas divididas por consecuencia y no por endpoint, una credencial que el sandbox nunca ve, y las dos operaciones —disparos de pipeline y aprobaciones caducadas— que rompen una integración ingenua.
Verificación
Trazabilidad de Requisitos Sin la Hoja de Cálculo
La matriz de trazabilidad es exacta el día que se escribe y errónea en un sprint. Generar el vínculo al momento de crear el caso es lo que la hace sobrevivir.
Verificación
La Cobertura de Líneas No Es Cobertura de Verificación
La mayoría de las organizaciones reporta cobertura de líneas con dos decimales y no puede decir para qué comportamiento implementado nadie escribió una prueba. Son cifras distintas.
Verificación
Cómo Saldar la Deuda de Pruebas Heredadas Sin un Año-Ingeniero
Las verificaciones de una suite de hace una década suelen estar bien. Lo que falta es todo lo que las rodea — y adaptarlo es abordable de una forma en que reescribir no lo es.