4.1 Objetivos, RN, NFR y frontera de alcance

Al terminar esta lección

• Clasificar una frase del cliente como objetivo, requerimiento funcional, regla de negocio, restricción, requisito no funcional o mecanismo heredado del proceso actual.
• Reescribir un requerimiento vago como un enunciado refutable, con condición, respuesta y efectos observables.
• Convertir un adjetivo ("rápido", "seguro") en un NFR con estímulo, entorno, respuesta y medida.
• Trazar una frontera IN, OUT y BLOCKED donde cada decisión nombra su razón, lo que falta y quién lo resuelve.
• Verificar la trazabilidad de un requerimiento hasta su evidencia de origen y hasta la prueba que lo defendería.

4. Convertir evidencia en requerimientos sin copiar el proceso actual

Comprender el negocio no obliga a digitalizarlo tal como está. En los módulos anteriores acumulaste episodios, reglas candidatas y desconocidos sobre Nexo B2B. Ahora tenés que decidir qué problema va a resolver el software, qué decisiones siguen siendo humanas y qué restricciones no son negociables.

El riesgo de este paso es doble. Si copiás el proceso, construís una versión digital del desorden: el pedido que hoy se reescribe tres veces pasa a reescribirse tres veces en una pantalla. Si te saltás la evidencia, construís lo que alguien pidió con más énfasis. En los dos casos el requerimiento no tiene un problema detrás, y eso se nota recién cuando el equipo de desarrollo hace preguntas que nadie puede contestar.

Esta lección te da el vocabulario y los criterios para evitarlo. La lección 4.2 los aplica al caso Nexo con artefactos completos y la 4.3 te hace producir los tuyos.

4.1 Cinco cosas que suelen mezclarse y conviene separar

Una frase de un cliente casi nunca es una sola cosa. "Que el sistema controle el crédito" contiene un objetivo, una regla, un comportamiento, una cualidad y una restricción, todo junto. Si no las separás, cada una se escribe, se prueba y se cambia a un ritmo distinto, y las vas a tener que pelear en un solo renglón.

Para cada una de las cinco tenés que poder responder: qué problema resuelve separarla, cómo se define de forma operativa, cómo se ve en Nexo, qué antipatrón aparece y cómo se verifica.

Objetivo de negocio

Problema que resuelve. Sin objetivo no hay manera de decidir si un requerimiento vale la pena ni de saber si el proyecto funcionó. Los features compiten entre sí por tiempo, y el único árbitro es lo que la empresa quiere mejorar.

Definición operativa. Un resultado que la empresa puede observar, medido sobre algo que ya existe. Se escribe como cambio en una magnitud ("bajar", "evitar", "reducir") y nombra qué se mide, no qué se construye.

En Nexo. Reducir el tiempo entre que llega un pedido y que alguien sabe si puede confirmarse (confirmado, pendiente de autorización o rechazado con motivo). La línea base sale de episodios reales: el pedido 48231, que llegó por audio con 12 productos, tardó de 08:47 a 09:51 en quedar resuelto, con siete minutos de identificación, cinco de autorización y trece de quiebre de stock. En este módulo, "confirmado" como estado significa CONFIRMADO_COMERCIAL (el pedido pasó crédito); la colisión con el "confirmado" de depósito se cierra en el modelo de estados.

Antipatrón. "Tener un portal." Es una solución, no un resultado. Tampoco sirve "mejorar la experiencia": no dice cuánto, medido dónde.

Cómo se verifica. Podés escribir cómo lo medirías hoy, antes de construir nada. Si no existe una forma de medir la línea base, todavía no tenés un objetivo: tenés un deseo.

Requerimiento funcional (RF)

Problema que resuelve. Traduce el objetivo en algo que alguien pueda construir y alguien pueda refutar.

Definición operativa. Un comportamiento que el sistema ofrece en una condición dada, con una respuesta y efectos observables. Contribuye a un objetivo y se apoya en reglas, pero no es la regla.

En Nexo. "Al confirmar un pedido, el sistema evalúa la exposición de crédito del cliente y devuelve aprobado, requiere autorización o rechazado, según las reglas vigentes."

Antipatrón. Convertir un paso del proceso actual en un RF: "imprimir el pedido para llevarlo a depósito" se vuelve RF-17 Imprimir pedido. Lo que importa es el propósito (que depósito reciba y priorice pedidos confirmados), no el papel.

Cómo se verifica. Podés imaginar un caso que lo contradiga. Si no se te ocurre ninguno, el enunciado es demasiado vago.

Regla de negocio (RN)

Problema que resuelve. Saca de las cabezas y de los audios las condiciones que gobiernan una decisión, para que no se redescubran en cada conversación ni dependan de quién atienda.

Definición operativa. Una condición que gobierna una decisión de negocio, exista o no software. Tiene una frontera concreta y un estado de validación.

En Nexo. RN-01: un cliente ESTÁNDAR no puede confirmar si saldoDeudor más totalPedido supera limiteCredito; igual al límite está permitido y un centavo más bloquea. Existe aunque Nexo no tenga sistema: Laura, de administración, ya la aplica a mano mirando el PDF de saldos y la planilla de cheques. Está confirmada (la confirma Laura, que tiene la autoridad de crédito), aunque qué entra exactamente en saldoDeudor, es decir, la definición de exposición, sigue abierto (U-01).

Antipatrón. Dejar la regla dentro del RF ("bloquear pedidos que exceden el límite"). Cuando la política cambie, hay que reescribir la intención del caso de uso. Peor: escribir la regla con precisión que nadie confirmó. RN-02 (tolerancia de los clientes PLATINO) está BLOCKED porque nadie sabe todavía cuánto es "poco"; escribir un porcentaje inventado la convierte en mentira con aspecto de regla.

Cómo se verifica. Una regla tiene fuente (quién la dice), frontera (ejemplo en el borde) y estado (confirmada, a validar, BLOCKED). Si le falta alguna, no está lista para respaldar un RF.

Restricción

Problema que resuelve. Evita diseñar contra un límite que el equipo no puede mover y gastar tiempo discutiendo cosas decididas.

Definición operativa. Un límite impuesto por el entorno, la regulación, el presupuesto, la tecnología existente o un contrato. No se negocia dentro del proyecto; se acepta y se diseña alrededor.

En Nexo. Durante la primera etapa el ERP legacy sigue siendo el maestro de productos, clientes y listas base; el proveedor fiscal es externo; el equipo es chico. Nada de eso se prueba con un test de aceptación: condiciona qué alternativas son viables.

Antipatrón. Presentar una preferencia como restricción ("tiene que ser en la nube porque sí") o una restricción como si fuera un RF ("el sistema debe usar el ERP").

Cómo se verifica. Preguntá quién puede levantarla y cuánto costaría. Si nadie del proyecto puede levantarla, es restricción; si alguien puede, es decisión pendiente.

Requisito no funcional (NFR)

Problema que resuelve. Captura cómo puede fallar el negocio aunque cada función exista: concurrencia, lentitud, falta de trazabilidad, acceso indebido, falla de un tercero. Estas propiedades suelen forzar la arquitectura mucho más que cualquier pantalla.

Definición operativa. Una cualidad verificable del comportamiento, escrita como escenario con medida. Aplica al sistema entero o a un caso de uso concreto.

En Nexo. NFR-02: toda autorización de sobregiro conserva actor, instante, regla aplicada, pedido y motivo durante el período acordado.

Antipatrón. Un adjetivo ("rápido", "seguro", "escalable"). No guía el diseño ni la prueba.

Cómo se verifica. Tiene estímulo, entorno, respuesta y medida. Con eso podés escribir una prueba o definir una observación.

La distinción evita errores muy comunes: convertir "hoy imprimimos una hoja" en un requisito funcional o escribir "ser rápido" como NFR. El primero es un accidente del proceso actual y el segundo no se puede verificar. El software tiene que preservar intención y restricciones, no rituales.

Primera interacción: ¿qué es cada frase?

4.2 La frontera IN / OUT / BLOCKED

Antes de enumerar features, escribí la frontera. Es la decisión que más trabajo ahorra y la que más se posterga.

• IN: el proyecto se compromete a resolverlo ahora.
• OUT: deliberadamente no entra en este release.
• BLOCKED: podría entrar, pero falta evidencia o una decisión externa.

BLOCKED no es una forma elegante de decir "algún día". Tiene que decir exactamente qué falta y quién puede resolverlo; si no, es un OUT disfrazado o un IN con una trampa adentro.

Cómo se decide

Cada candidato recorre las mismas preguntas. La frontera sale de responderlas con evidencia, no de una votación.

La frontera inicial de Nexo

La tabla siguiente es la frontera de partida del primer slice. Fijate que cada fila tiene una razón concreta y que el único BLOCKED nombra qué le falta.

La facturación merece una nota. Parece natural incluirla porque "al final hay que facturar", pero el dolor que motivó el proyecto está antes: la decisión sobre el pedido. Mantenerla OUT no significa ignorarla: el pedido confirmado queda marcado como pendiente de facturación para que la integración posterior tenga de dónde colgarse.

Cada decisión como artefacto

Una tabla en una presentación se olvida. Una frontera que vive en el repositorio se discute, se versiona y se reabre con una condición explícita. Este es el formato que usamos:

1release: nexo-release-1
2objective: "Reducir el tiempo entre recepción de un pedido y una decisión observable."
3items:
4  - id: reserva-concurrente
5    state: IN
6    reason: "Evita prometer dos veces la misma unidad (EV-05)."
7    exit_criteria: "Con una unidad disponible y dos reservas simultáneas, exactamente una confirma."
8    note: "El TTL de la reserva en espera depende de RN-07, que está BLOCKED."
9​
10  - id: reserva-expirable
11    state: BLOCKED
12    missing: "Cuánto tiempo puede esperar una reserva sin autorización firme."
13    needed_from: "Depósito (Sergio) y comercial."
14    resolves_by: "medición en la primera semana de operación del release."
15    meanwhile: "El TTL queda como parámetro; no se fija valor definitivo."
16​
17  - id: recomendaciones-ia
18    state: OUT
19    reason: "Ningún episodio observado muestra que la falta de recomendaciones retrase o rompa un pedido."
20    reopen_when: "Existe una métrica de venta cruzada con línea base y un responsable comercial."

Los tres tienen la misma forma, pero cada estado exige campos distintos. IN pide criterio de salida; BLOCKED pide qué falta, quién y cuándo; OUT pide el motivo y la condición de reapertura. Si un ítem no puede completar sus campos, está en el estado equivocado.

Segunda interacción: ubicá cada tema en la frontera

4.3 Requerimientos que pueden ser refutados

Un buen requerimiento permite imaginar una prueba que lo contradiga. Eso es lo que se llama refutable, y es la propiedad que separa una especificación de un deseo.

"El sistema debe controlar el crédito" no es refutable: ¿qué resultado lo contradiría? "Al intentar confirmar un pedido para un cliente estándar, si saldoDeudor más total supera limiteCredito, el sistema no confirma, no reserva stock y explica que se requiere regularizar saldo" sí lo es. Tiene una condición, una respuesta y efectos observables, incluido un efecto negativo (no reserva). Es una versión inicial: la vía de autorización para ESTÁNDAR se revisa en el módulo 5.

Una plantilla simple que alcanza para la mayoría de los RF:

1Cuando [actor/condición], el sistema [respuesta observable],
2[y deja/no deja] [efecto verificable en datos o estado],
3según [RN/CU de referencia].

Aplicada a RN-01 con su frontera:

1- id: RF-04
2  text: >
3    Al confirmar un pedido de un cliente ESTÁNDAR, si saldoDeudor más totalPedido
4    supera limiteCredito, el sistema no confirma, no reserva stock y devuelve el
5    motivo "crédito".
6  rules: [RN-01]
7  sources: ["minuta de la reunión 1 (Laura, pantalla compartida)"]
8  objective: "decision-observable"
9  refutation:
10    - "saldo + pedido == límite: debe permitir (frontera de RN-01)"
11    - "saldo + pedido == límite + 0,01: debe bloquear y no dejar reservas"

Fijate en el campo refutation. Obligarte a escribir cómo se lo contradiría es la forma más barata de descubrir que el requerimiento no dice lo suficiente. Y esos dos casos de frontera son, tal cual, los futuros tests de RN-01.

Si la respuesta exacta depende de una regla no cerrada, esa dependencia se referencia en lugar de inventarse. Por eso el RF de más arriba cita RN-01 (versión inicial; la vía de autorización para ESTÁNDAR se revisa en el módulo 5), y el equivalente para PLATINO diría "según RN-02 (BLOCKED)" en lugar de poner un porcentaje.

Tercera interacción: encontrá los requerimientos defectuosos

Este fragmento de catálogo tiene cuatro renglones con problemas distintos: un adjetivo, un mecanismo heredado, una regla hardcodeada que contradice una RN y una promesa sin condición medible. Marcalos.

4.4 NFR: de adjetivos a escenarios medibles

Los NFR limitan las alternativas de diseño y pueden aplicar a todo el sistema o a casos de uso concretos. Un NFR útil tiene métrica, contexto y umbral. "Debe ser rápido" no guía el diseño ni la prueba. Esto sí:

El p95 del registro de pedido, con la emisión fiscal fuera del camino, debe ser menor a 800 ms con 30 usuarios concurrentes en la carga acordada.

Usamos 30 usuarios porque Nexo tiene unos treinta usuarios internos (los 25 vendedores más administración y depósito), con los vendedores trabajando en horario pico. Son cifras del caso, no de un contrato real: lo importante es que el escenario nombra su carga, y que quien lo lea sepa contra qué lo va a medir.

Anatomía de un escenario de calidad

Una forma probada de escribir NFR es el escenario de calidad (lo describen, entre otros, Bass, Clements y Kazman en Software Architecture in Practice). Tiene cinco partes:

El último renglón no es un adorno. El 800 es un umbral acordado como punto de partida; el equipo no lo promete hasta medir en el prototipo. Escribir el estado evita que una cifra inicial se convierta en contrato por inercia.

1- id: NFR-01
2  quality: latencia
3  stimulus: "un vendedor confirma un pedido de hasta 50 líneas"
4  environment: "horario pico, 30 usuarios concurrentes, dataset de producción representativo"
5  response: "el sistema devuelve número, estado y totales"
6  measure: "p95 < 800 ms"
7  status: "umbral propuesto; se valida con prototipo"
8  why: "evita que los vendedores vuelvan a WhatsApp por lentitud"
9​
10- id: NFR-02
11  quality: auditoría
12  stimulus: "una persona autoriza un sobregiro"
13  environment: "cualquier momento"
14  response: "se conserva actor, instante, regla aplicada, pedido y motivo"
15  measure: "100% de las autorizaciones con los cinco campos, durante el período acordado"
16  status: "período de retención por acordar con administración"
17  why: "permite explicar decisiones y resolver disputas"

Los cuatro NFR de partida

NFR-04 merece una aclaración: la emisión real de comprobantes es OUT del primer release, así que el escenario se verifica contra un simulador del proveedor (un fake) que falla a pedido. Lo que se protege es el contrato: el pedido ya confirmado permanece válido y la intención de facturar se puede reintentar sin duplicarse.

De dónde salen los NFR

Los NFR no se copian de una lista estándar. Salen de cómo puede fallar este negocio en esta operación:

• Latencia importa distinto si 25 vendedores trabajan de 8 a 18 que si hubiera un portal 24/7. Por eso se mide en horario pico.
• Auditoría aparece porque hay autorizaciones por audio que "no están escritas, más o menos sabemos" quién puede dar. El daño de no tenerla es no poder explicar un sobregiro.
• Seguridad aparece por la cartera de clientes: un vendedor no debería ver ni operar la de otro.
• Recuperación aparece porque hay un tercero (el proveedor fiscal) que va a fallar en algún momento.

Si no podés explicar el daño de incumplir un NFR, probablemente no es prioritario. Y si el adjetivo es lo único que tenés, volvé a preguntar qué demora o qué falla interrumpe el trabajo.

Cuarta interacción: reescribí un adjetivo

4.5 Trazabilidad ligera: cada decisión debe poder volver a su origen

No necesitás una matriz gigantesca para cada proyecto. Sí necesitás poder responder, ante una regla crítica, de dónde salió, qué comportamiento afecta y cómo se prueba. La trazabilidad puede vivir en IDs y enlaces simples. Lo importante es que un cambio no obligue a confiar en la memoria del equipo.

Un ejemplo concreto de cadena para el crédito de un cliente ESTÁNDAR:

Si la cadena se corta, la información se cae:

• Un RF sin evidencia ni regla es un requerimiento huérfano: lo pidió alguien, pero nadie sabe por qué.
• Una RN sin RF que la use es una regla que el sistema no aplica.
• Un RF sin prueba posible es un deseo.

Un linter que revisa lo que se puede revisar

La parte mecánica de la trazabilidad se puede automatizar con muy poco código. Si el catálogo de requerimientos vive en YAML, un script detecta huérfanos, adjetivos y vocabulario de interfaz antes de que alguien lo lea. No reemplaza la revisión humana: ahorra la parte aburrida.

1import { readFileSync } from "node:fs";
2import { parse } from "yaml";
3​
4type Requirement = {
5  id: string;
6  text: string;
7  rules?: string[];
8  sources?: string[];
9  objective?: string;
10  refutation?: string[];
11};
12​
13const VAGUE =
14  /(?<!\p{L})(rápid[oa]s?|fácil(?:es)?|amigable|intuitiv[oa]|robust[oa]|escalable|flexible|moderno|óptim[oa]|en tiempo real)(?!\p{L})/iu;
15const UI_WORDS = /(?<!\p{L})(botón|pantalla|modal|menú|dropdown|clic|click)(?!\p{L})/iu;
16​
17export function lint(reqs: Requirement[]): string[] {
18  const problems: string[] = [];
19  for (const r of reqs) {
20    if (!r.sources?.length && !r.rules?.length) {
21      problems.push(`${r.id}: huérfano, no cita evidencia ni regla`);
22    }
23    if (!r.objective) problems.push(`${r.id}: no apunta a un objetivo`);
24    const vague = VAGUE.exec(r.text);
25    if (vague) problems.push(`${r.id}: adjetivo no medible ("${vague[1]}")`);
26    const ui = UI_WORDS.exec(r.text);
27    if (ui) problems.push(`${r.id}: vocabulario de interfaz ("${ui[1]}"), ¿es parte del contrato?`);
28    if (!r.refutation?.length) problems.push(`${r.id}: no dice cómo se lo contradiría`);
29  }
30  return problems;
31}
32​
33const file = process.argv[2] ?? "requirements/rf.yaml";
34const problems = lint(parse(readFileSync(file, "utf8")) as Requirement[]);
35problems.forEach((p) => console.error(p));
36process.exit(problems.length ? 1 : 0);

Cuidado con lo que no hace: no sabe si un requerimiento es correcto, solo si es revisable. Un RF puede pasar el linter y estar equivocado. Lo vamos a usar en el taller como primera barrera, antes de la revisión con un compañero o con un agente.

Quinta interacción: ordená la cadena de derivación

Un prompt que funciona razonablemente para la primera revisión:

1Rol: revisor de requerimientos. No agregues requerimientos nuevos.
2​
3Contexto:
4- Objetivo: reducir el tiempo entre recepción de un pedido y una decisión observable.
5- Reglas: RN-01 a RN-07 con su estado (adjuntas). RN-01 confirmada (la definición de
6  exposición sigue abierta, U-01); RN-02 BLOCKED (tolerancia PLATINO sin definir);
7  RN-03, RN-05, RN-06 y RN-07 son invariantes o políticas del sistema futuro derivadas
8  del negocio, no reglas del proceso actual (RN-07 está BLOCKED).
9- Glosario y desconocidos de la entrega E03 (adjuntos).
10- Evidencia: EV-01 a EV-08 (adjunta).
11- Frontera: IN/OUT/BLOCKED (adjunta).
12- Catálogo a revisar: requirements/rf.yaml y requirements/nfr.yaml.
13​
14Tarea: para cada requerimiento devolvé una tabla con:
151. ¿Es refutable? Escribí un caso que lo contradiga o decí por qué no existe.
162. ¿Mezcla política con mecanismo? Citá la frase.
173. ¿Contiene adjetivos sin medida? Citá la palabra.
184. ¿Cita al menos una RN o EV existente? Si inventa un ID, marcalo.
19​
20Restricciones: no propongas números donde la regla esté BLOCKED. Si falta información,
21escribí "falta: ..." en lugar de suponer.

Cómo revisar la salida. Tres controles antes de aceptar nada:

1. Los IDs que menciona existen en tu catálogo (los agentes inventan EV-14 con total confianza).
2. Ningún "caso que lo contradiga" asume una regla que está BLOCKED.
3. Cada observación que aceptás la podés defender con una frase tuya; si no, la descartás aunque suene razonable.

Errores frecuentes

Repaso del vocabulario

Comprobá lo que entendiste

Para llevarte

• Una frase del cliente casi siempre contiene objetivo, regla, función, cualidad y restricción: separalas antes de escribir un renglón.
• Un requerimiento es bueno si podés imaginar una prueba que lo contradiga; escribí el caso que lo refuta al lado del requerimiento.
• Un NFR sin estímulo, entorno, respuesta y medida es un adjetivo. Si el umbral todavía no se midió, marcalo como propuesto.
• BLOCKED es un estado con tres campos: qué falta, quién lo resuelve y cuándo se revisa. Sin eso es un OUT sin motivo.
• Todo RF tiene que poder volver a una evidencia y avanzar hasta una prueba; los huérfanos se justifican o se eliminan.
• Un agente puede revisar tu catálogo, no decidir tu alcance: los IDs que cita se verifican uno por uno.