Ganancias:
- Capacidad para distinguir requisitos funcionales y no funcionales y escribir expresiones de requisitos claras y mensurables con el apoyo de inteligencia artificial.
- Capacidad de utilizar inteligencia artificial con indicaciones estructuradas para extraer historias de usuario, criterios de aceptación y límites de alcance de las notas de la entrevista.
- Adquirir el hábito de comprobar los requisitos generados por la IA en busca de ambigüedades, contradicciones y reglas faltantes y confirmarlos con las partes interesadas.
El análisis de requisitos es la tarea de definir de forma completa, clara y verificable lo que debe hacer un sistema. Es una de las etapas donde más valor produce el especialista en MIS; porque un error aquí crece exponencialmente al final del proyecto. Hay dos tipos básicos de análisis de requisitos. El requisito funcional describe el trabajo que debe realizar el sistema: "El sistema debe enviar un correo electrónico al cliente cuando confirma el pedido". El requisito no funcional describe cómo debería ser el sistema: cualidades como rendimiento, seguridad, usabilidad y accesibilidad. "La pantalla del informe debería abrirse en menos de 2 segundos con una carga promedio" es un requisito no funcional.
Un buen requisito tiene tres características: es claro (tiene una interpretación única), es mensurable (tiene un umbral comprobable) y es rastreable (está claro de qué necesidad empresarial proviene). "El sistema debe ser rápido" no cumple con ninguno de estos requisitos; “rápido” es subjetivo, no se puede medir, no se puede probar. En esta etapa, la IA es una poderosa ayuda para redactar requisitos y detectar textos ambiguos; pero sólo el interesado decide qué regla de negocio es real.
Historia de usuario y criterios de aceptación
Un formato común en la redacción de requisitos modernos es la historia del usuario: "Como [rol], para [propósito], quiero [característica]". Ejemplo: "Como representante de ventas, quiero calcular el descuento desde la pantalla del móvil para poder realizar cotizaciones rápidas en el campo". La historia es breve y orientada a los negocios; No impone una solución técnica.
Cada historia debe tener criterios de aceptación: condiciones comprobables que deben cumplirse para que la historia se considere "correcta". Un patrón utilizado con frecuencia es el patrón "Dado/Cuándo/Entonces": "Dado: el cliente está en el segmento VIP. Cuándo: pedidos superiores a 10.000 TL. Luego: el sistema aplica un descuento del 5%". Este patrón elimina la ambigüedad porque conecta claramente la condición y el resultado esperado.
Consejo: Al escribir una historia de usuario para la inteligencia artificial, asegúrese de decir "generar al menos 2 criterios de aceptación en el formato Dado/Cuándo/Entonces para cada historia". Cuando el modelo se ve obligado a producir puntos de referencia, las lagunas ocultas en los requisitos se hacen visibles.
Paso a paso: extracción de requisitos asistida por IA
Paso 1: recopile información sin procesar. Registros de llamadas, correos electrónicos, capturas de pantalla existentes, listas de quejas. Cuanto más información real, menos fabricación.
Paso 2: extrae el primer conjunto de historias. Brinde información sin procesar a la inteligencia artificial y haga que produzca borradores de historias de usuario. Este paso no es una lista completa, sino un primer paso.
Paso 3: agregue criterios de aceptación. Genere criterios Dado/Cuándo/Entonces para cada historia. Una historia para la cual no se pueden producir criterios significa en realidad que no está suficientemente definida.
Paso 4: Escanear en busca de contradicciones y lagunas. Pregúntele a AI "¿existen contradicciones, duplicaciones o situaciones indefinidas entre estos requisitos?" Pregunta y haz que te lo revisen. Filtra el resultado como humano.
Paso 5: Priorice y confirme. Priorice las historias con las partes interesadas en función del valor y la urgencia del negocio. La decisión prioritaria pertenece a la unidad de negocio, no a la IA.
No olvide los requisitos no funcionales
La mayoría de los proyectos tienen dificultades en el campo porque olvidan los no funcionales mientras escriben los requisitos funcionales. Un informe puede funcionar “correctamente”, pero si tarda 45 segundos en abrirse, nadie lo utilizará. La siguiente tabla muestra los tipos de requisitos no funcionales que comúnmente se pasan por alto y ejemplos de escritura medibles.
Género
mala expresión
expresión medible
Rendimiento
"Debe ser rápido"
"Respuesta de consulta < 2 segundos con carga promedio"
accesibilidad
"Todo el mundo debería poder utilizarlo"
"Cumple con WCAG 2.1 AA; navegación completa con teclado"
Seguridad
"Debería ser seguro"
"Los datos personales están cifrados en reposo; el acceso se basa en roles"
disponibilidad
"Debería ser fácil"
"El nuevo usuario completa el pedido en 3 pasos sin formación"
Disponibilidad/continuidad
"No debería chocar"
"Tiempo de actividad mensual ≥ 99,5 %"
Tres minicasos: en cifras
Caso 1: El precio de una necesidad inmensurable. La pantalla, que fue desarrollada en un banco con el requisito de que "la pantalla del informe debería abrirse rápidamente", se abrió en 22 segundos bajo carga de campo. El desarrollador pensó que estaba proporcionando la palabra "rápido" en su entorno (2 segundos). Si el requisito se hubiera escrito como "< 3 segundos en la hora pico, rendimiento real", el problema se habría detectado durante las pruebas. La remodelación costó 3 semanas y un costo adicional mensurable.
Caso 2: Brecha capturada por los criterios de aceptación. Mientras escribía los criterios de aceptación para la historia del "sistema aplica descuento" en un proyecto de comercio electrónico, la parte interesada notó que no se discutía en absoluto lo que sucedería si el descuento entrara en conflicto con el cupón y el descuento VIP. Una única pregunta Dado/Cuándo/Entonces evitó el error de descuento doble antes de la puesta en marcha; Este error provocó graves pérdidas de ingresos en proyectos similares.
Caso 3: regla creada por la IA. En un proyecto de recursos humanos, AI añadió la frase “la solicitud de licencia se aprueba automáticamente dentro de las 24 horas” al borrador de requisitos. En la reunión no se discutió tal aprobación automática; El modelo había inventado una regla que parecía "razonable". Al lado de cada requisito, el experto escribe “fuente: ¿qué entrevista/documento?” Al agregar la columna, eliminó 4 oraciones sin fuente.
Aviso débil / Aviso fuerte
Aviso débil:
Escriba historias de usuarios para este proyecto.
Potente mensaje:
Su función: es un analista de negocios de MIS. Extraiga historias de usuarios de la nota de la entrevista a continuación. Reglas: - Formato: "Como [rol], para [propósito], quiero [característica]". - Escriba AL MENOS 2 criterios de aceptación para cada historia en formato Dado/Cuándo/Entonces. - Agregue una columna "Fuente" al lado de cada historia: ¿de qué oración proviene? - Etiquete [INCIERTO] cualquier regla que no esté clara en la nota; Montaje.- Escriba los requisitos no funcionales medibles (rendimiento, seguridad, accesibilidad) en una sección separada. Nota de la entrevista:[texto]
Un mensaje potente impone el formato de la historia, los criterios de aceptación, la trazabilidad del origen y los requisitos no funcionales, todo al mismo tiempo; Esto facilita el control de la salida.
Cuatro plantillas copiables
1) Aclaración de requisitos:
Revise el requisito a continuación. Marque cada afirmación que sea vaga, inconmensurable o abierta a más de una interpretación y escriba una pregunta aclaratoria para cada una. No inventes la respuesta. Requisito: [texto]
2) Exploración de contradicciones:
En la lista de requisitos a continuación, busque elementos que se contradigan entre sí, sean repetitivos o dejen espacios lógicos. Informe cada hallazgo con números de ítem y una justificación de una oración. Lista: [texto]
3) Generar criterios de aceptación:
Escriba al menos 4 criterios de aceptación para la siguiente historia de usuario en formato Dado/Cuándo/Entonces, incluidos los casos límite y de excepción. También enumere los puntos que aún no están claros. Historia: [texto]
4) Esquema del alcance:
Redacte los elementos "Dentro del alcance" y "Fuera del alcance" como una tabla de dos columnas de acuerdo con los siguientes requisitos. Etiquete [SE REQUIERE CONFIRMACIÓN] para cualquier artículo del que no esté seguro. Requisitos: [texto]
Errores comunes
- Pensar que la solución es una necesidad. "Agregar un menú desplegable" es una solución, no un requisito. El requisito dice "el usuario debe poder seleccionar el país de la lista definida"; El equipo de TI diseña la solución.
- Saltarse los que no funcionan. Simplemente escribir “qué hacer” y olvidar “cómo ser” (velocidad, seguridad, accesibilidad) es el vacío legal más común y costoso.
- Usar adjetivos inconmensurables. Palabras como "rápido, fácil, seguro y fácil de usar" no son válidas sin un umbral.
- Sin darse cuenta de la regla que ha inventado la IA. El modelo puede añadir reglas “razonables” pero no verbales; Pregunta por recursos para cada necesidad.
- Dejando la priorización a la IA. Qué hacer primero es una decisión de valor comercial; La unidad de negocio da esto.
Precaución: la frase más peligrosa en el análisis de requisitos es "todo el mundo ya lo sabe". Las suposiciones tácitas no aparecen en la documentación, nunca aparecen en el código y emergen en el campo. Pregúntele a AI “¿qué se supone pero no está escrito en este requisito?” hace visibles estos supuestos ocultos.
En resumen
El análisis de requisitos define lo que debe hacer el sistema de forma clara, medible y rastreable. Los requisitos funcionales describen el trabajo, los requisitos no funcionales describen las cualidades y estos últimos a menudo se olvidan. La historia de usuario y los criterios de aceptación Dado/Cuándo/Entonces son herramientas poderosas que eliminan la incertidumbre. La inteligencia artificial acelera significativamente la producción de guiones gráficos, criterios de aceptación, detección de conflictos y aclaración de preguntas; Sin embargo, la exactitud de la regla comercial, el alcance y la decisión de prioridad, y la fuente de cada oración son responsabilidad del ser humano. No finalice ningún requisito que no tenga recursos y sea inconmensurable.
Tarea de aplicación
Escriba una solicitud comercial de un párrafo para un “sistema de citas en línea” imaginario (por ejemplo, “Los clientes deberían poder programar citas en línea, el personal debería poder ver los calendarios”). (1) Cree al menos 5 historias de usuarios y 2 criterios de aceptación para cada una con un fuerte mensaje a partir de esta solicitud. (2) Encuentre al menos 2 lagunas ocultas en los criterios producidos por el modelo (por ejemplo, cita doble al mismo tiempo, regla de cancelación). (3) Incluir al menos 3 requisitos no funcionales de forma medible. (4) Identifique al menos 3 elementos como "Fuera de alcance". (5) Marca una regla que el modelo podría haber inventado y escribe cómo la confirmarías.
lista de verificación
- [] Escribí los requisitos funcionales y no funcionales por separado.
- [ ] Cada requisito es claro, medible y comprobable.
- [] Cada historia tiene criterios de aceptación Dado/Cuándo/Entonces.
- [] Puedo rastrear la fuente (conversación/documento) de cada requisito.
- [ ] Marqué las posibles reglas que la IA había inventado y las dejé para confirmación.
- [ ] La priorización la hice junto con la unidad de negocio.