Audita los requisitos del producto para detectar ambigüedad y decisiones ausentes

Autor: AILesson9 min de preparaciónProbado con:ChatGPTRevisado el: 2026-08-28

Respuesta rápida

Detecta expresiones que permiten implementaciones incompatibles y revela la persona responsable y las pruebas necesarias para decidir. Proporciona: Documento de requisitos, Contexto del producto y del sistema, Alcance y gobernanza de la revisión. Resultado esperado: Una auditoría de requisitos con ubicaciones de ambigüedades, decisiones ausentes, conflictos, riesgos, preguntas aclaratorias y estado de preparación.

1

Añade tu contexto

Tu texto permanece en este navegador. AILesson Prompts no lo envía a un modelo ni a un servidor.

2

Tu prompt

Los campos sin rellenar permanecen visibles como marcadores de posición, para que puedas copiar y editar el prompt

Audita los requisitos exactos del producto para detectar ambigüedades, conflictos y decisiones ausentes.

PRD, historias, criterios, diagramas, términos, enlaces, versiones, comentarios y registro de decisiones:
[requirements]

Usuarios, flujos de trabajo, comportamiento actual, plataformas, estados, funciones, datos, integraciones, restricciones, riesgos y políticas:
[context]

Versión, equipos, responsables, revisiones, gravedad, preparación, entornos y alcance de reescritura:
[review]

Conserva fragmentos exactos y sus ubicaciones. Señala los adjetivos y adverbios subjetivos, los sustantivos y actores sin definir, los cuantificadores vagos, los valores predeterminados ocultos, la voz pasiva que oculta la responsabilidad, los pronombres con varios referentes, los términos usados de forma incoherente, las declaraciones de soluciones sin una necesidad, los ejemplos confundidos con reglas exhaustivas y palabras como fácil, rápido, intuitivo, fluido, flexible, seguro, admitir, en tiempo real, normalmente, adecuado y etcétera. Para cada problema, enumera al menos dos implementaciones sustancialmente diferentes que permita la redacción, la consecuencia para el usuario o el sistema, la gravedad, el requisito afectado, la persona responsable de decidir si se ha proporcionado, las pruebas necesarias y una pregunta aclaratoria neutral. Audita también los límites del alcance, las condiciones previas, los desencadenantes, los estados y las transiciones, los permisos, el origen y el ciclo de vida de los datos, el comportamiento ante estados vacíos, errores, carga, desconexión y reintentos, la concurrencia y la idempotencia, la localización, la accesibilidad, la privacidad, la seguridad, la analítica, el rendimiento, la compatibilidad, la migración, la reversión, las dependencias y los criterios de aceptación. Identifica contradicciones entre artefactos y decisiones ausentes del registro. No inventes respuestas ni reescribas como hechos opciones aún sin resolver. Termina distinguiendo las carencias bloqueantes de las no bloqueantes, con una cola de decisiones ordenada por dependencia y riesgo, y con el estado de preparación para la implementación y las pruebas.
Probar en Playground
Privado de forma predeterminadaLa preparación del prompt se realiza localmente en tu navegador. Evita introducir información confidencial en cualquier servicio de IA, a menos que tu organización lo permita.

De la entrada al resultado

Un ejemplo completo

Mira cómo un contexto concreto convierte esta receta en un resultado que puedes usar

Entrada real

Documento de requisitos
PRD v0.7 sección 2: ‘Haz que la responsabilidad de aceptación sea fácil de ver para todos los usuarios. Los solicitantes deberían poder asignar rápidamente a la persona adecuada. El sistema debería notificárselo debidamente y actualizarse en tiempo real. Admite casos sin asignar, etc.’ Historia AC-4: ‘Dado un traspaso Ready, cuando el owner selecciona un accepter, el cambio se guarda’. El diagrama D2 muestra al requester seleccionando al accepter; el comentario C18 dice que el coordinator puede editarlo. Registro de decisiones: solo prototipo web; sin notificaciones en esta versión; únicamente miembros activos del espacio de trabajo; texto exacto pendiente. Otra historia dice que el estado pasa a Assigned cuando existe un accepter, pero el modelo de estados actual solo contiene Draft, Active, Ready y Accepted.
Contexto del producto y del sistema
Funciones: el requester crea; el owner realiza el trabajo; el accepter autoriza la aceptación; el coordinator administra el espacio de trabajo. Aprobado: el requester o el coordinator pueden establecer un accepter opcional; el owner solo puede verlo. El registro de auditoría guarda el actor, el valor anterior y el nuevo y la hora. Se usan los identificadores de miembros existentes; no cambia la conservación. Solo web. La accesibilidad exige teclado, etiqueta programática y estado que no dependa del color. Revisión de privacidad completada. Los nombres de analítica y el objetivo de rendimiento están pendientes.
Alcance y gobernanza de la revisión
Versión del prototipo para pruebas de usabilidad. Producto es responsable de las decisiones sobre el flujo de trabajo, Diseño del texto, Ingeniería de los estados y el comportamiento ante errores, Accesibilidad revisa la interacción e Investigación es responsable del guion de prueba. Gravedad de los bloqueos: B impide la implementación o las pruebas; M permite construir, pero entraña riesgo de incoherencia; L es editorial. Para estar listo no debe haber carencias B, los criterios deben ser comprobables, el diseño debe estar revisado, el prototipo debe funcionar y deben superarse las comprobaciones unitarias y de accesibilidad. Solo diagnostica; no reescribas los requisitos definitivos.

Ejemplo de salida

Preparación: no está listo; quedan seis decisiones bloqueantes y varias carencias de gravedad media.

B1 — conflicto de actor. AC-4 dice «el owner selecciona», D2 indica el requester y C18, el coordinator, mientras que el contexto aprobado permite al requester o al coordinator y deja al owner en modo de solo lectura. Estas opciones dan lugar a pruebas de autorización y seguridad incompatibles. Producto debe confirmar la regla aprobada en todos los artefactos; las pruebas son el registro de decisiones y el contexto.

B2 — conflicto de estado. Una historia crea Assigned, pero el modelo de estados aprobado no contiene Assigned. Las implementaciones podrían añadir una nueva transición al flujo de trabajo o mantener Ready con un indicador de campo, lo que afecta a la persistencia, la analítica, la migración y las pruebas. Producto es responsable de decidir: ¿asignar un accepter cambia el estado del flujo de trabajo o solo la presentación del campo?

B3 — contradicción de las notificaciones. «Notificárselo debidamente» permite correo electrónico, notificación push, aviso en la aplicación o ninguna notificación; el registro de decisiones indica que no habrá notificaciones en esta versión. Tampoco define la persona destinataria, el desencadenante, el comportamiento repetido ni la baja. Producto debe eliminar las notificaciones de este límite o excluirlas explícitamente; nadie debe inventar un comportamiento.

B4 — elegibilidad y datos no válidos. «La persona adecuada» podría significar cualquier usuario, un miembro activo, un miembro con una función apta o una persona sugerida. El límite aprobado es un miembro activo del espacio de trabajo, pero los criterios de aceptación no abarcan el envío de una persona inactiva o ajena ni su desactivación simultánea. Producto e Ingeniería deben definir un rechazo y una recuperación observables; Diseño es responsable del texto posterior.

B5 — comportamiento sin asignación. «Admite casos sin asignar, etc.» no define si se permite dejarlo vacío al crearlo, si puede borrarse después, quién puede borrarlo, cómo se muestra ni si puede continuar en Ready. Producto es responsable de estas decisiones; «etc.» no es comprobable.

B6 — guardado, errores y concurrencia. «Se guarda» podría significar una visualización local optimista o la persistencia confirmada en el servidor. Faltan: carga, fallo, reintento, envío repetido, dos personas editando, vista obsoleta, auditoría y reversión. Ingeniería propone opciones; Producto aprueba la regla visible para el usuario.

Carencias medias: «fácil», «rápidamente» y «en tiempo real» carecen de medidas; el texto exacto y los nombres de analítica están explícitamente pendientes; el orden del teclado, la etiqueta programática, el foco después de un error y el indicador que no dependa del color necesitan criterios. «Todos los usuarios» entra en conflicto con los permisos de edición según la función y debería distinguir la visualización de la edición.

Orden de decisión: actor/estado/notificación → ausencia de asignación y elegibilidad → guardado/concurrencia/error → interacción accesible/texto → analítica/rendimiento. La preparación para las pruebas solo llega después de convertir los elementos B en criterios observables.

Por qué funciona

  1. 1

    Los ejemplos de implementaciones contrapuestas hacen concreta la ambigüedad abstracta para quienes deben decidir.

  2. 2

    Ordenar las carencias por dependencias evita que los equipos perfeccionen criterios alrededor de un comportamiento esencial aún sin decidir.

Comprueba el resultado

  • ¿Cada ambigüedad incluye el texto exacto y dos interpretaciones sustancialmente diferentes?

  • ¿Las decisiones ausentes se asignan únicamente a responsables conocidos y nunca se resuelven de forma implícita?

  • ¿La preparación abarca los estados, permisos, datos, fallos, accesibilidad, privacidad, pruebas y reversión?

Úsalo con confianza

Preguntas frecuentes

Respuestas prácticas sobre cuándo usar esta receta, qué debes proporcionar y en qué casos la revisión humana sigue siendo importante

¿Qué debo preparar antes de usar «Audita los requisitos del producto para detectar ambigüedad y decisiones ausentes»?

Para «Audita los requisitos del producto para detectar ambigüedad y decisiones ausentes», prepara el documento de requisitos, el contexto del producto y del sistema y el alcance y la gobernanza de la revisión. Sustituye los marcadores de posición solo con información que puedas verificar. Si se desconoce algún detalle, expresa esa incertidumbre de forma explícita en lugar de pedir al modelo que lo infiera.

¿Cuándo no está listo para usarse el resultado de «Audita los requisitos del producto para detectar ambigüedad y decisiones ausentes»?

El resultado no está listo si todavía no ofrece, a partir de las pruebas proporcionadas, el resultado indicado —una auditoría de requisitos con ubicaciones de ambigüedades, decisiones ausentes, conflictos, riesgos, preguntas aclaratorias y estado de preparación— o si depende de suposiciones sin resolver, aprobaciones pendientes o detalles inventados. Usa las comprobaciones como criterios de autorización: revisa los datos de origen o asigna a una persona identificada y autorizada para revisarlos, en lugar de pulir un resultado sin fundamento.

¿Qué herramientas de IA tienen pruebas registradas para «Audita los requisitos del producto para detectar ambigüedad y decisiones ausentes»?

El registro de pruebas publicado para «Audita los requisitos del producto para detectar ambigüedad y decisiones ausentes» incluye ChatGPT a fecha de 2026-08-28. Esto confirma que se registraron ejecuciones, pero no garantiza la compatibilidad ni resultados idénticos en versiones posteriores del producto. Para otra herramienta o versión, mantén visibles todas las restricciones y repite las comprobaciones del resultado antes de usarlo.

Mantén el trabajo en marcha