Módulo 5: Stakeholders y atributos de calidad

3. El escenario de atributo de calidad: volver medible lo vago

Siguiente →

Descripción

Al terminar esta lección vas a saber cerrar la brecha entre un atributo priorizado y algo que un equipo puede de verdad construir y verificar —porque hay una brecha, y es donde mueren la mitad de los requisitos de calidad—. En la lección 2 saliste con un ranking: scalability primero, luego security, availability, performance, cost. Pero "scalability alta" no es un requisito. Es un adjetivo pegado a un atributo. No le dice al equipo cuánto escalar, ante qué estímulo, en qué condiciones, ni cómo sabremos si lo logramos. Es tan vago como "quiero una casa cómoda": ¿cómoda para quién, en qué clima, con qué presupuesto? La herramienta que cierra esa brecha se llama quality attribute scenario —escenario de atributo de calidad— y viene de Bass, Clements y Kazman. Es una plantilla de seis partes que convierte un atributo vago en una frase concreta y testeable: source (quién o qué genera el estímulo), stimulus (qué pasa), artifact (qué parte del sistema recibe el estímulo), environment (en qué condiciones), response (qué debe hacer el sistema) y —la más importante— response measure (con qué número se mide que lo hizo). Con las seis partes, "alta disponibilidad" se vuelve: "cuando el gateway de pagos externo (source) deja de responder (stimulus), el servicio de checkout (artifact), durante el pico de Black Friday (environment), reintenta y encola el cobro sin perder el pedido (response), completando el 99.95% de los pedidos con menos de 5 segundos de latencia extra (response measure)". Eso sí se puede diseñar. Eso sí se puede probar.

Esto importa porque la sexta parte —el response measure— es la línea que separa un requisito de un deseo, y casi nadie la respeta. Un atributo sin medida no se puede diseñar (¿cuánta redundancia hace falta para "alta disponibilidad"? nadie sabe, porque "alta" no es un número), no se puede probar (¿pasó la prueba de disponibilidad? nadie puede decirlo, porque no hay umbral), y no se puede defender (¿cumplimos lo que el negocio pidió? imposible saberlo). Un atributo con medida se vuelve un contrato: "99.95% de los pedidos, menos de 5 segundos" es algo que se diseña para cumplir, se prueba contra un número, y se defiende con evidencia. La regla de esta lección es dura y vale para todo el oficio: si un requisito de calidad no tiene una medida, no es un requisito —es un deseo disfrazado—, y tratarlo como requisito es construir sobre arena. Vas a ejecutar una validación que toma tres scenarios de Mercado y separa los que están listos para diseñar de los que todavía son deseos por falta de esa medida.

Conexión con el módulo: esta lección toma el ranking de la lección 2 y lo hace utilizable. Priorizar los atributos (lección 2) responde qué optimizar y en qué orden; volver cada atributo un scenario medible responde cuánto y cómo lo verificaremos. Sin este paso, el ranking es una lista de buenas intenciones que ningún equipo puede ejecutar. Con este paso, cada atributo priorizado se vuelve uno o varios scenarios concretos que el equipo diseña y prueba. Las lecciones que siguen se apoyan en esto: la 4 pregunta cuáles de estos scenarios son architecturally-significant (moldean la estructura) y cuáles no; la 5 descubre scenarios implícitos que nadie escribió; y la 6 usa el response measure como el número que se traduce al idioma del negocio ("99.95% de disponibilidad" se vuelve "X dólares de venta protegida"). La frontera se mantiene: aquí aprendes a escribir el scenario que hace medible un atributo; cómo se decide el nivel exacto de la medida cuando compite con otro atributo —99.95% contra 99.99%— es el método de architecture-decisions.

El contratista que necesita un número, no un adjetivo

Piénsalo con quien construye la casa, no con quien la diseña. El arquitecto le pasa los planos al contratista —el que de verdad va a levantar las paredes— con una nota que dice: "la casa debe ser fresca en verano". El contratista la lee y no puede hacer nada con ella. ¿Fresca cómo? ¿Con aire acondicionado, con aislamiento en el techo, con ventanas al norte, con muros gruesos? ¿Fresca en un verano de Monterrey a 42 grados o en uno de Bogotá a 22? ¿Cuánto es "fresca" —24 grados adentro cuando afuera hay 40, o le basta con 30? El adjetivo "fresca" es un deseo legítimo, pero el contratista no construye deseos: construye especificaciones. Así que devuelve la nota con una pregunta: "dame un número". Y el arquitecto reescribe: "cuando la temperatura exterior llegue a 40 °C (environment), en las habitaciones del segundo piso (artifact), el sistema pasivo de la casa (response: aislamiento + ventilación cruzada, sin aire acondicionado) debe mantener el interior por debajo de 26 °C (response measure)". Ahora el contratista sabe qué construir, y —clave— cuando termine, alguien puede medir con un termómetro si la casa cumple. "Fresca" no se puede medir con un termómetro; "por debajo de 26 °C con 40 afuera" sí.

Esa es exactamente la diferencia entre un atributo de calidad y un quality attribute scenario. "Alta disponibilidad", "buen rendimiento", "seguro" son los adjetivos que el negocio y el arquitecto usan para hablar —son útiles para priorizar (lección 2)—, pero ningún equipo construye un adjetivo. El equipo necesita el número: no "disponible" sino "99.95% de los pedidos completados"; no "rápido" sino "el checkout responde en menos de 2 segundos para el percentil 95"; no "seguro" sino "el 100% de los accesos a datos de otro vendedor se bloquean y se registran". El scenario de seis partes es la nota reescrita del arquitecto: toma el adjetivo del negocio y le agrega las cinco cosas que faltan para que sea construible y —sobre todo— verificable con un termómetro. Sin el número al final, le estás pidiendo al equipo que construya "fresca en verano", y cada quien va a entender una cosa distinta.

Ejemplo trabajado: validar que un scenario sea medible

Vamos a tomar tres scenarios de Mercado, cada uno con sus seis partes (o casi), y ejecutar una validación que verifique dos cosas: que estén completos (tengan las seis partes) y que sean medibles (tengan un response measure real, no vacío). El tercer scenario tiene una trampa deliberada —le falta la medida— para que veas cómo el validador lo atrapa. La estructura es un diccionario por scenario; la validación cuenta las partes presentes y revisa si hay medida.

# Un atributo vago ("queremos alta disponibilidad") no se puede probar ni
# disenar. El SCENARIO de 6 partes (Bass/Clements/Kazman) lo vuelve concreto y
# medible. Validamos cuales scenarios estan completos y tienen una medida.

# Cada scenario: source, stimulus, artifact, environment, response, response_measure.
scenarios = [
    {
        "attribute": "availability",
        "source": "el gateway de pagos externo",
        "stimulus": "deja de responder",
        "artifact": "el servicio de checkout",
        "environment": "pico de Black Friday",
        "response": "reintenta y encola el cobro sin perder el pedido",
        "response_measure": "99.95% de pedidos completados, < 5 s de latencia extra",
    },
    {
        "attribute": "security",
        "source": "un vendedor externo autenticado",
        "stimulus": "pide datos de OTRO vendedor via API",
        "artifact": "el API gateway multi-tenant",
        "environment": "operacion normal",
        "response": "rechaza y registra el intento",
        "response_measure": "100% de accesos cross-tenant bloqueados y auditados",
    },
    {
        "attribute": "scalability",
        "source": "el equipo de marketing",
        "stimulus": "lanza una campana que 10x el trafico",
        "artifact": "el catalogo",
        "environment": "produccion",
        "response": "el sistema escala sin caerse",
        "response_measure": "",   # <-- vago: no hay medida, no se puede probar
    },
]

required = ["source", "stimulus", "artifact", "environment", "response", "response_measure"]

print(f"{'atributo':<13}{'partes':>8}{'medible?':>10}   veredicto")
ready = 0
for sc in scenarios:
    present = sum(1 for p in required if sc.get(p))
    measurable = bool(sc.get("response_measure"))
    ok = present == len(required) and measurable
    ready += ok
    verdict = "listo para disenar" if ok else "VAGO: falta la medida"
    print(f"{sc['attribute']:<13}{present:>5}/6{('si' if measurable else 'NO'):>10}   {verdict}")

print()
print(f"{ready}/{len(scenarios)} scenarios estan listos para disenar y probar.")
print("El que no tiene 'response_measure' no es un requisito: es un deseo.")

Qué esperar. Al correrlo:

atributo       partes  medible?   veredicto
availability     6/6        si   listo para disenar
security         6/6        si   listo para disenar
scalability      5/6        NO   VAGO: falta la medida

2/3 scenarios estan listos para disenar y probar.
El que no tiene 'response_measure' no es un requisito: es un deseo.

Detente en el tercer renglón, porque es toda la lección. El scenario de scalability tiene cinco de las seis partes —source (marketing), stimulus (campaña que 10x el tráfico), artifact (catálogo), environment (producción), response (escala sin caerse)— y aun así el validador lo marca como VAGO. ¿Por qué? Porque le falta la única parte que lo vuelve un requisito: el response measure. "El sistema escala sin caerse" suena a un requisito, pero no lo es: no dice cuánto tráfico ("10x el tráfico" no es un número absoluto —¿10x de qué base?—), no dice qué significa "sin caerse" (¿cero errores? ¿menos del 1% de errores? ¿latencia bajo qué umbral?), y por lo tanto nadie puede probar si se cumplió. Imagina la campaña de marketing corriendo y el equipo preguntándose "¿pasamos?": sin un número, la respuesta es una discusión de opiniones, no una medición. El validador atrapó exactamente lo que el ojo humano deja pasar: un scenario que parece completo porque tiene cinco partes redactadas, pero que es un deseo porque le falta la sexta.

Compara con el scenario de availability, que sí pasó. Tiene las seis partes, y la sexta es un número de verdad: "99.95% de pedidos completados, menos de 5 segundos de latencia extra". Con eso, el equipo sabe qué construir (redundancia y reintentos suficientes para no perder más del 0.05% de los pedidos), sabe cómo probarlo (simular la caída del gateway en un pico y medir cuántos pedidos se completan y con cuánta latencia), y el negocio sabe qué recibió (una garantía cuantificada, no una promesa vaga). Lo mismo el de security: "100% de accesos cross-tenant bloqueados y auditados" es un número —el 100%— con el que se puede diseñar (aislamiento estricto) y probar (intentar mil accesos cruzados y verificar que los mil se bloquearon y quedaron registrados). La diferencia entre los dos que pasaron y el que falló no es la redacción ni el esfuerzo: es que uno terminó en un número y el otro en un adjetivo.

Fíjate en algo sutil que el validador enseña sobre el oficio. Los tres scenarios están bien escritos —los tres identifican la fuente, el estímulo, el artefacto, el entorno—. El de scalability no es descuidado; alguien lo pensó. Y sin embargo es inútil como requisito. Eso te dice que la parte fácil de un scenario es todo menos la medida, y la parte difícil —la que de verdad importa— es la medida. Es fácil escribir "el sistema escala sin caerse"; es difícil comprometerse a "soporta 10,000 requests por segundo con menos del 0.1% de errores y latencia p95 bajo 300 ms". Lo difícil es difícil por una buena razón: el número obliga a decidir —a comprometerse con un umbral concreto que se puede cumplir o incumplir—. El adjetivo evita la decisión; el número la fuerza. Por eso tanta gente se queda en el adjetivo: es cómodo. El validador no deja: sin número, VAGO.

Un matiz honesto. El validador de este ejemplo revisa que la medida exista (que el campo no esté vacío), no que sea buena. Un scenario podría poner un response measure que es un número pero un número inútil —"escala razonablemente rápido"— y este validador lo dejaría pasar porque el campo no está vacío. La validación mecánica atrapa el error más común (falta la medida) pero no juzga la calidad de la medida; eso lo hace el criterio humano. Una buena medida es específica (un percentil, un porcentaje, un umbral de tiempo), acotada a una condición (bajo qué carga, en qué entorno) y verificable (existe una forma de medirla). "Menos de 5 segundos para el 99.95% de los pedidos durante Black Friday" cumple los tres. "Rápido" no cumple ninguno. El validador es tu primera línea de defensa; tu juicio es la segunda.

Profundización: por qué seis partes, y de dónde salen las que faltan

Vale la pena entender por qué son seis partes y no menos, porque cada una tapa un agujero por el que se escapa la vaguedad.

Source y stimulus responden "¿ante qué?". Un atributo no es incondicional: un sistema no es "disponible" en abstracto, es disponible ante ciertas fallas. Decir "cuando el gateway externo (source) deja de responder (stimulus)" acota el requisito a un evento concreto. Sin esto, "alta disponibilidad" tendría que cubrir todas las fallas imaginables —incluido un meteorito—, lo cual es imposible y por lo tanto inútil. El source y el stimulus vuelven el requisito finito: no "resiste todo", sino "resiste esta falla específica".

Artifact y environment responden "¿dónde y en qué condiciones?". El mismo estímulo importa distinto según qué parte lo reciba y cuándo. Que el gateway falle importa muchísimo en el checkout durante Black Friday (artifact + environment) y casi nada en un reporte interno un martes a las 3am. Acotar el artefacto y el entorno concentra el requisito donde de verdad duele, y evita el error de exigir el mismo nivel de calidad en todas partes —que es la receta del sobre-costo (lección 7)—. El environment, además, es donde suele esconderse el requisito más caro: "en operación normal" es fácil; "durante el pico de Black Friday con el triple de tráfico" es donde la arquitectura se decide.

Response y response measure responden "¿qué debe pasar, y cuánto?". El response describe la conducta deseada ("reintenta y encola sin perder el pedido"); el response measure la cuantifica ("99.95%, menos de 5 segundos"). Ya vimos que la medida es la parte que hace o rompe el scenario. Pero fíjate en la pareja: el response sin la medida es un adjetivo ("escala sin caerse"), y la medida sin el response es un número sin conducta ("99.95%" ¿de qué?). Se necesitan las dos: la conducta le da sentido al número, el número le da precisión a la conducta.

Ahora, la pregunta práctica: ¿de dónde salen las partes que el stakeholder no da? Porque el VP nunca dice "source: gateway externo, environment: Black Friday". El VP dice "no nos podemos caer en Black Friday". Las otras cinco partes las completa el arquitecto, y ahí está buena parte del oficio. El "Black Friday" (environment) lo sacó el arquitecto de conocer el negocio (sabe que ese día concentra la facturación). El "gateway externo que deja de responder" (source + stimulus) lo sacó de conocer el sistema (sabe que el gateway es un punto de falla típico en picos). El "99.95% con menos de 5 segundos" (measure) lo negoció con el negocio traduciendo el costo de cada nivel (lección 6). Escribir un buen scenario es un acto de traducción y de conocimiento: el stakeholder aporta el atributo y el entorno crítico; el arquitecto aporta la estructura de las seis partes y, sobre todo, propone la medida que luego se acuerda. El scenario es el artefacto donde el deseo del negocio y el conocimiento del arquitecto se encuentran y se vuelven un contrato verificable.

Y una nota sobre la frontera. Este scenario dice "99.95% de disponibilidad". ¿Por qué 99.95% y no 99.9% o 99.99%? Esa es una decisión con un trade-off enorme —cada noveno extra cuesta muchísimo más (lección 6)— y decidir el nivel exacto cuando la disponibilidad compite con el costo es el método de architecture-decisions. Aquí tu trabajo es estructurar el scenario para que tenga una medida; cuál medida elegir, cuando esa elección enfrenta a dos atributos, es la decisión que documentas en un ADR con su matriz. El scenario es el molde; el número que va en el molde, cuando hay conflicto, lo decide el método de la otra guía. Lo que esta lección te da es la disciplina de exigir que haya un número, y la estructura para ponerlo en su lugar.

Errores comunes

Confundir un scenario bien redactado con uno medible (de falsa completitud). Qué pasa: el arquitecto escribe un scenario con cinco partes hermosas —source, stimulus, artifact, environment, response, todo detallado— y como se ve completo, lo da por bueno, aunque el response measure sea "el sistema responde bien". El equipo lo implementa, y a la hora de probar nadie puede decir si pasó. Por qué pasa: cinco partes redactadas dan una sensación de rigor que engaña; el ojo ve trabajo y asume completitud. Cómo detectarlo: tapa con la mano las cinco primeras partes y lee solo el response measure; si no es un número contra el que puedas correr una prueba, el scenario es vago por más bonito que sea el resto. Cómo corregirlo: trata el response measure como obligatorio y como lo primero que revisas —el validador de esta lección lo hace mecánicamente—; sin medida, el scenario vuelve al remitente.

Poner una medida que no es verificable (de número decorativo). Qué pasa: el scenario dice "response measure: el sistema escala razonablemente", o "responde en tiempo aceptable", y como hay palabras en el campo, parece medible. Pero "razonablemente" y "aceptable" no son números: no hay forma de correr una prueba que dé sí o no. Por qué pasa: la presión de llenar el campo lleva a poner algo, y un adjetivo con forma de medida es más fácil que un umbral real que obliga a comprometerse. Cómo detectarlo: pregúntate "¿qué prueba correría, y qué valor la haría pasar o fallar?"; si no puedes nombrar la prueba y el umbral, la medida es decorativa. Cómo corregirlo: exige que toda medida sea un número con unidad y una condición —percentil, porcentaje, milisegundos, bajo qué carga—; "p95 bajo 300 ms con 10,000 req/s" es verificable, "rápido" no.

Exigir el mismo nivel en todos los entornos (de environment ignorado). Qué pasa: el arquitecto escribe scenarios sin acotar el environment, así que "99.99% de disponibilidad" aplica por igual al checkout en Black Friday y al panel de administración interno un domingo. Termina diseñando (y pagando) una disponibilidad extrema en partes que no la necesitan. Por qué pasa: omitir el environment se siente más simple ("que todo sea muy disponible"), pero es la puerta al sobre-costo. Cómo detectarlo: si tus scenarios no distinguen entornos ni artefactos —si el nivel exigido es el mismo en todos lados—, no estás acotando el requisito donde duele. Cómo corregirlo: usa las partes artifact y environment para concentrar cada nivel de calidad donde el negocio lo necesita; el checkout en Black Friday merece 99.95%, el reporte interno merece 99% y está bien —esa diferenciación es justo lo que evita prometer todo al máximo (lección 7)—.

Ejercicios

Ejercicio 1 — Completa el scenario. El VP de Mercado dice: "la búsqueda de productos tiene que ser rápida, si no la gente se va". Conviértelo en un quality attribute scenario de seis partes. Inventa razonablemente las partes que el VP no dio (source, artifact, environment) y —sobre todo— propón un response measure verificable.

Ver solución

Un scenario razonable (las partes inventadas están basadas en conocer el negocio y el sistema):

  • attribute: performance
  • source: un comprador
  • stimulus: escribe un término de búsqueda y pide resultados
  • artifact: el servicio de búsqueda del catálogo
  • environment: hora pico de tráfico normal (no Black Friday)
  • response: devuelve los resultados relevantes ordenados
  • response measure: el percentil 95 de las búsquedas responde en menos de 400 ms; el percentil 99, en menos de 800 ms

Lo importante es el response measure. "Rápida" (lo que dijo el VP) no se puede probar. "Menos de 400 ms para el p95" sí: se puede correr una prueba de carga que dispare miles de búsquedas y medir el percentil 95 del tiempo de respuesta, y hay un umbral claro que la hace pasar o fallar. Nota tres decisiones de buena medida: usé un percentil (no un promedio, que esconde los casos lentos —el p95 dice "el 95% de la gente vio algo así de rápido o más"), le puse una unidad (milisegundos), y lo acoté a un entorno (hora pico normal; en Black Friday el umbral podría relajarse o requerir otro scenario). También separé p95 y p99 porque "rápido para casi todos" y "nunca demasiado lento" son garantías distintas que vale la pena declarar por separado.

Ejercicio 2 — Atrapa al vago. Un compañero te pasa este scenario para revisión: "Cuando lleguen muchos usuarios (source: usuarios; stimulus: mucho tráfico; artifact: el sistema; environment: producción), el sistema debe manejarlo bien (response) de forma escalable (response measure: escalable)". Sin correr código, señala por qué el validador lo marcaría como VAGO y qué partes, además de la medida, son demasiado imprecisas para servir.

Ver solución

El validador lo marcaría VAGO porque el response measure es "escalable" —una palabra, no un número—: no hay umbral que se pueda probar. "Escalable" es exactamente el adjetivo que el scenario debía eliminar, reaparecido en el campo de la medida. No existe una prueba que dé "sí, es escalable" o "no lo es" contra ese texto.

Pero el problema es más profundo: casi todas las partes son demasiado imprecisas, no solo la medida.

  • source: "usuarios" — ¿cuántos? ¿de dónde? "Muchos usuarios" no es un source acotado. Un buen source diría, por ejemplo, "una campaña de marketing que multiplica por 10 el tráfico base".
  • stimulus: "mucho tráfico" — ¿cuánto es mucho? Sin un número base ("de 1,000 a 10,000 requests por segundo"), no hay estímulo medible.
  • artifact: "el sistema" — demasiado amplio. ¿Todo el sistema, o el catálogo, o el checkout? Escalar el catálogo (lectura, cacheable) es un problema distinto de escalar el checkout (escritura, transaccional). "El sistema" esconde esa diferencia.
  • environment: "producción" — aceptable pero pobre; no dice si es un pico esperado o un evento excepcional.
  • response: "manejarlo bien" — otro adjetivo. ¿"Bien" es sin errores? ¿con latencia bajo cierto umbral? "Bien" no describe una conducta verificable.

La lección: el scenario está lleno de adjetivos vagos ("muchos", "mucho", "bien", "escalable") disfrazados de partes. Un buen scenario reemplaza cada adjetivo por una especificación: "de 1,000 a 10,000 req/s (stimulus) en el catálogo (artifact), mantén el p95 bajo 300 ms y menos del 0.1% de errores (response + measure)". El validador atrapa la medida vacía; tu criterio atrapa el resto.

Ejercicio 3 — De la medida al diseño y a la prueba. Toma el scenario de availability que pasó la validación: "cuando el gateway de pagos externo deja de responder, durante Black Friday, el checkout reintenta y encola el cobro sin perder el pedido, completando el 99.95% de los pedidos con menos de 5 s de latencia extra". Sin entrar en implementación detallada, responde: (a) ¿qué te obliga a diseñar el "99.95% sin perder el pedido"?; (b) ¿cómo probarías que se cumple?; (c) ¿por qué el mismo scenario sin el response measure no te dejaría hacer ni (a) ni (b)?

Ver solución

(a) Qué te obliga a diseñar. El "99.95% sin perder el pedido, aun cuando el gateway externo se cae" te obliga a una arquitectura donde el pedido no depende de que el cobro sea inmediato: hace falta desacoplar aceptar-el-pedido de cobrar-el-pedido. En concreto, algo como encolar el pedido de forma durable en cuanto el cliente confirma (para no perderlo si el gateway falla), y reintentar el cobro de forma asíncrona hasta que el gateway vuelva. El "99.95%" pone la vara: el diseño tiene que tolerar la caída del gateway el tiempo suficiente para no perder más de 5 de cada 10,000 pedidos. Ese número decide cuánta durabilidad y cuántos reintentos hacen falta.

(b) Cómo lo probarías. Simulando el estímulo en un entorno de carga: generas tráfico equivalente a un pico de Black Friday, en medio de la prueba tumbas deliberadamente el gateway de pagos (o su simulación) por un rato, y mides dos cosas: cuántos pedidos se completaron (debe ser ≥ 99.95%) y cuánta latencia extra añadió el reintento/encolado (debe ser < 5 s). Es una prueba de caos/resiliencia con criterios de aprobación claros, precisamente porque tienes números contra los cuales comparar.

(c) Por qué sin la medida no podrías hacer ni (a) ni (b). Sin el "99.95% con menos de 5 s", el scenario diría "el checkout no pierde pedidos cuando el gateway falla" —un deseo—. Para (a), no sabrías cuánta resiliencia diseñar: ¿tolerar 1 segundo de caída o 1 hora? ¿perder cero pedidos (carísimo, quizás imposible) o 0.05%? El número fija el objetivo de diseño. Para (b), no sabrías qué prueba correr ni qué la haría pasar: sin umbral, la prueba de caos daría un resultado ("se completaron el 99.7% de los pedidos") que nadie podría juzgar como éxito o fracaso. La medida es lo que convierte el scenario en un objetivo de diseño y en un criterio de prueba a la vez —es el puente entre el deseo del negocio y algo que un equipo construye y verifica—. Eso es, en una frase, por qué la sexta parte es la que hace o rompe el scenario.

Resumen y siguiente paso

En esta lección aprendiste a cerrar la brecha entre un atributo priorizado y algo construible: el quality attribute scenario de seis partes (source, stimulus, artifact, environment, response, response measure) que convierte un adjetivo vago en una frase testeable. Con el contratista que necesita un número y no un adjetivo viste que "fresca en verano" no se construye pero "por debajo de 26 °C con 40 afuera" sí, y que el termómetro —la medida— es lo que separa un requisito de un deseo. Lo validaste ejecutando: tres scenarios de Mercado, dos listos para diseñar y uno atrapado como VAGO por faltarle el response measure, aunque tuviera las otras cinco partes bien escritas. Entendiste que la parte difícil de un scenario es la medida (porque el número obliga a comprometerse mientras el adjetivo lo evita), que las seis partes tapan cada una un agujero por donde se escapa la vaguedad, y que el arquitecto completa las partes que el stakeholder no da con su conocimiento del negocio y del sistema.

Antes de avanzar deberías poder: tomar un atributo vago del negocio y escribir un scenario de seis partes con un response measure verificable; distinguir una medida real (número, unidad, condición, prueba) de una decorativa (un adjetivo disfrazado); usar artifact y environment para acotar cada nivel de calidad donde el negocio lo necesita; y aplicar la regla dura —si no tiene medida, no es un requisito—.

Lo que sigue es un filtro distinto. Ya sabes priorizar atributos (lección 2) y volverlos scenarios medibles (esta lección). Pero no todos los requisitos que llegan —ni todos los scenarios que podrías escribir— moldean la arquitectura. Algunos son decisiones de estructura de las que cuelga todo el sistema (aislar los datos de cada vendedor); otros son detalles del producto que se cambian en una tarde sin tocar la arquitectura (el color del botón de compra). En la lección 4 vas a aprender a separar la señal del ruido con el concepto de architecturally-significant requirement (ASR): el requisito que moldea la estructura, es caro de cambiar después, y es de alto riesgo. Vas a ejecutar un filtro que toma una lista de requisitos de Mercado y separa los pocos que de verdad importan para la arquitectura de los muchos que importan al producto pero no a la estructura —para que gastes tu energía de arquitecto donde de verdad cuenta—.

Recursos

← Anterior2. De la meta de negocio al atributo de calidadSiguiente →4. Requisitos arquitectónicamente significativos: la señal y el ruido