CCAR-P · Comunicación con stakeholders y ciclo de vida
Discovery y requisitos que chocan, a quién sumar, qué escribir y quién decide
El documento de requisitos salió de tres talleres con la sponsor y sus dos gerentes, y se firma la semana que viene. En la última recorrida, una persona de atención comenta que muchos clientes usan el chat con lector de pantalla y que legal nunca opinó sobre cuánto tiempo se guardan las conversaciones. Esos dos detalles cambian la arquitectura, y aparecieron por casualidad.
Un discovery que empieza por el proceso
El relevamiento (discovery) no empieza por la tecnología ni por el modelo. Empieza por:
- El proceso actual: volúmenes, excepciones, puntos de decisión, dónde se va el tiempo. Observado con la gente que lo hace, no solo descrito por quien lo patrocina.
- La métrica: qué número tiene que mejorar y cuál es su línea de base (baseline) hoy. Sin eso no hay forma de saber si la solución sirvió.
- Los interesados (stakeholders) que pueden frenar o cambiar el diseño: seguridad, legal, cumplimiento, el equipo que va a operar el sistema y los usuarios reales. Si solo hablaste con el sponsor, el relevamiento está incompleto.
Requisitos no funcionales: escribirlos y validarlos
Los requisitos no funcionales (non-functional requirements) son los que más cambian una arquitectura con LLM y los que más se olvidan:
| Requisito | Qué puede cambiar |
|---|---|
| Retención y residencia de datos | dónde se despliega, qué se loguea, qué proveedor o región |
| Accesibilidad | formato de salida, interacción, pruebas con usuarios reales |
| Latencia por flujo | modelo, streaming, procesamiento asíncrono o por lotes |
| Revisión humana obligatoria | flujo de aprobación, colas, capacidad del equipo |
| Auditoría | qué se guarda de cada decisión y por cuánto tiempo |
Van escritos explícitamente, con un criterio verificable, y se validan con quien corresponde. No se dejan para “pedidos de cambio después del lanzamiento” ni se confían a la configuración por defecto de un proveedor.
Cuando dos requisitos chocan
Legal exige que una persona revise cada respuesta antes de enviarla. Operaciones exige respuesta en minutos porque se están yendo clientes. Así escritos, no se pueden cumplir los dos. Son requisitos en conflicto (conflicting requirements), y el arquitecto no los resuelve eligiendo en silencio:
- Hacé explícito el conflicto: ponelo por escrito, sin tomar partido.
- Cuantificalo: qué parte del volumen es rutinaria y qué parte tiene riesgo real, cuánto demora la revisión, cuánto cuesta cada opción.
- Proponé alternativas con una recomendación: por ejemplo, respuesta inmediata para lo rutinario y revisión para cláusulas especiales y disputas.
- Llevalo al dueño de la decisión (decision owner): quien tiene autoridad sobre ambos objetivos, no el que grita más fuerte.
- Registrá lo decidido como requisito, con el porqué.
Comunicá todo en el idioma del negocio: costo por transacción, tiempo de respuesta, impacto de los errores, medidos con datos propios.
Las trampas típicas
- Firmar los requisitos como estaban y anotar los huecos como cambios futuros.
- Pedirle solo a la sponsor que confirme puntos que son de legal o de seguridad.
- Elegir uno de los dos requisitos porque “el riesgo legal pesa más” o “el negocio es lo que importa”.
- Postergar la decisión hasta tener el sistema construido.
- Mandar una nota técnica llena de siglas y dejar que el negocio “decida solo”.
En el examen
Si un requisito importante aparece tarde y por un actor que no estaba en el relevamiento, la respuesta suele combinar sumar a los interesados que faltaban y escribir el requisito de forma explícita y verificable. Si dos interesados piden cosas incompatibles, buscá la opción que cuantifica el conflicto, propone un diseño intermedio y lo lleva a quien tiene la autoridad. Descartá las que deciden por su cuenta o lo patean para después.
Pregunta rápida
Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.
A regional water utility is designing a Claude assistant to answer billing questions in its web chat. The head of customer service sponsors the project, and the requirements document came out of three workshops with her and her two managers. It is ready to be signed next week.
During a final walkthrough, a frontline agent mentions that many older customers use the chat through a screen reader, and that the regulator requires chat transcripts to be kept for seven years and stored in the country. Neither point appears in the document. The information security team has not been contacted, and the contact-centre operations team that will run the assistant day to day was never invited.
The build is planned for a team of four over two quarters, on top of the existing customer API.
Which TWO actions should the architect take before closing the requirements? (Select two.)
Elegí todas las que correspondan.