Requirements to Architecture

Interpretar necesidades antes de escoger una solución

Requirements to Architecture es, en el Atlas, la práctica de aclarar y contextualizar necesidades de stakeholders para identificar su significancia arquitectónica, formular drivers y restricciones útiles y examinar implicaciones de diseño. Construye una justificación entre el problema y las decisiones, sin prometer que cada requisito tenga una única arquitectura correcta.

Forma parte del trabajo de design-process, pero no lo agota. Interpretar «necesitamos entregas independientes» todavía no produce una propuesta evaluada. El proceso más amplio explora candidatos, contrasta consecuencias y revisa el diseño con evidencia. software-architecture mantiene la atención en estructuras y compromisos relevantes.

Una petición puede mezclar necesidad, solución sugerida y creencia: «usemos Kafka para escalar». Antes de aceptarla o rechazarla, averiguar qué resultado falta, bajo qué carga y por qué se cree que esa tecnología lo resolvería. La separación conserva tanto la intención comercial como el espacio de elección.

Del objetivo comercial a una preocupación del sistema

Reducir tiempo de entrega, entrar a un mercado, servir clientes empresariales o disminuir costo son objetivos. Necesitan interpretación para identificar capacidades y propiedades que el sistema debe ofrecer. Reducir lead time puede requerir compatibilidad y fronteras de entrega; también puede depender de aprobaciones ajenas al software.

Clements y Bass relacionan metas comerciales con requisitos de calidad derivados que necesitan elaboración y validación con quienes sostienen esas metas. SEI, Relating Business Goals to Architecturally Significant Requirements, 2010. No se usa esa relación como una traducción automática de objetivo a producto tecnológico.

architectural-drivers conserva selección y prioridad; architectural-significance permite investigar consecuencias estructurales y compromisos costosos. Un requisito importante para negocio puede tener una implementación localizada. Otro aparentemente pequeño puede abrir acceso a datos privados o fijar un contrato que muchos consumidores usarán durante años.

Separar sin inventar una taxonomía rígida

Funcionalidad expresa comportamientos necesarios, como aceptar una orden o procesar una devolución. Puede ser arquitectónicamente significativa: operación offline, procesamiento continuo o un workflow entre varias responsabilidades no son detalles irrelevantes. Tampoco toda función necesita reorganizar el sistema; el contexto decide.

Los requisitos de quality-attributes-overview permiten examinar condiciones y respuestas deseadas de esas capacidades; constraints identifica límites reales de elección. Estas lecturas no redefinen aquí atributos particulares ni convierten NFR en una bolsa homogénea. Cuando una fuente use non-functional requirements, conviene precisar si habla de calidad, restricciones u otras obligaciones.

ADD utiliza funcionalidad, requisitos de calidad y restricciones como entradas. Su reporte 2.0 advierte que algunos casos admiten más de una clasificación y que reunir la información importa más que una separación perfecta. ADD 2.0, sección 3.1. No se adopta una taxonomía universal ni se colapsan silenciosamente ASRs, drivers y cualquier requisito.

Distinguir lo exigido, lo supuesto y lo desconocido

«Esperamos 5.000 usuarios concurrentes» puede ser una assumption si no está validado ni comprometido. Registrar origen, confianza y efecto permite revisarla; no equivale automáticamente a un requisito de capacidad. La misma cifra, acordada como condición contractual de una respuesta, tiene otro papel.

«Usamos PostgreSQL hoy» describe estado actual; «preferimos .NET» expresa una preferencia; «el contrato exige Oracle» puede ser una constraint. Habilidades disponibles y equipo de operación son contexto que puede limitar opciones, pero necesitan evidencia y autoridad antes de declararse inmutables.

Un unknown es una pregunta pendiente: concurrencia efectiva, límite del proveedor o número de consumidores. Riesgo aparece cuando esa incertidumbre amenaza un resultado relevante. No hay que disfrazarla de certeza para completar un diagrama. Una medición o consulta puede ser el siguiente trabajo necesario antes de elegir una frontera difícil de revertir.

Refinar frases que todavía no discriminan alternativas

«Checkout debe ser rápido» necesita aclarar inicio y fin de la observación, carga, estado del entorno, respuesta y tolerancia. quality-attribute-scenarios desarrolla el modelo de escenarios; aquí se utiliza para producir una entrada que permita decidir, sin repetir su anatomía.

Un acuerdo ilustrativo podría exigir completar o rechazar explícitamente una solicitud de checkout en un p95 de dos segundos bajo una mezcla y carga definidas. Todavía falta precisar si se observa aceptación durable o autorización de pago terminada, qué errores cuentan y qué ocurre si el proveedor demora. La cifra es un ejemplo, no una medida universal ni un resultado del Atlas.

La medida tampoco debería premiar rechazar rápidamente todo el tráfico: el negocio necesita distinguir resultados válidos, solicitudes rechazadas por reglas comerciales y errores técnicos. Antes de usar ese p95 para elegir una arquitectura, acordar qué población se mide y qué proporción de trabajo útil debe completarse. Esos detalles pueden cambiar cuánto tiempo conviene esperar y qué estado necesita persistirse.

Una función que parecía simple puede revelar otra significancia al refinarla. «Reservar inventario» podría tolerar confirmación posterior o exigir impedir ventas sobre la misma unidad física en un instante determinado. No se infiere esa obligación del nombre de la función; hay que explicitarla antes de elegir coordinación, almacenamiento o comunicación.

«Alta disponibilidad» pide identificar capacidad, fallo, duración y degradación admisible. «Debe escalar» pide workload, baseline, crecimiento, horizonte y respuesta. scaling permite examinar unidades y límites; usuarios registrados, requests por segundo, concurrencia y volumen de datos no son medidas intercambiables.

No toda necesidad cabe en un único número. Acceso autorizado, preservación de autoridad o alcance localizado de un cambio también requieren evidencia. Evitar falsa precisión significa explicar observaciones y límites, sin reemplazar un adjetivo ambiguo por una cifra arbitraria.

Escuchar preocupaciones que no llegan como features

Operación necesita diagnosticar incidentes, recuperar capacidad, desplegar y administrar accesos; soporte necesita comprender qué sucedió a una transacción. operability y deployability vuelven esas preocupaciones entradas de diseño, en lugar de dejarlas para después de implementar el camino feliz.

Rozanski y Woods incluyen entre stakeholders a quienes construyen, prueban, mantienen, operan y financian, además de usuarios. En Commerce también importan partners y quienes revisan pagos. Sus preocupaciones pueden entrar en conflicto y necesitan representación suficiente, no prioridad automática por jerarquía.

Identidad, autorización, protección de información y trust boundaries pueden influir en interfaces y aislamiento. Residencia, retención y auditoría pueden imponer obligaciones. El análisis debe recuperar su interpretación y responsables aplicables; no ofrece asesoramiento legal ni abre aquí un catálogo de arquitectura de seguridad.

Datos, integración, cambio y contexto heredado

data-ownership conduce preguntas sobre autoridad, escrituras, lectores, consistencia e historia. Volumen y patrones de acceso ayudan a evaluar opciones, pero no justifican diseñar tablas antes de aclarar semántica. Una copia para reporting no adquiere autoridad comercial por contener los mismos campos.

interfaces, communication e interoperability permiten estudiar consumidores, proveedores, contratos, latencia y versiones. Un proveedor que solo ofrece SOAP limita ese vínculo, no obliga a que todo Commerce use el mismo protocolo. Si una dependencia falla, preguntar qué resultado sigue siendo aceptable antes de prescribir mecanismos de resiliencia.

modifiability y evolvability incorporan cambios esperados: países comprometidos, medios de pago, tenants o proveedores. modularity permite considerar variación relevante sin construir una abstracción para cada futuro imaginable. En brownfield, legacy-systems y migration-strategy mantienen datos, contratos y transición dentro del alcance; greenfield conserva contexto y obligaciones propias.

Seleccionar drivers y reconocer conflictos

Priorizar requiere explicar importancia, efecto arquitectónico, riesgo y consecuencia de incumplir. Una obligación no negociable delimita candidatos aunque otra mejora sea muy deseada. utility-trees puede ayudar a organizar escenarios en su contexto; no es una tabla obligatoria de puntuación para cada proyecto.

Menor latencia, aislamiento amplio, recursos compartidos y bajo costo pueden tensionarse. quality-attribute-trade-offs permite evaluar combinaciones situadas. No afirmar simplemente que consistencia y disponibilidad siempre se excluyen: hay que describir operaciones, fallos y compromisos. Si dos exigencias son incompatibles bajo una constraint vigente, el resultado puede ser renegociar alcance o admitir explícitamente que aún no hay solución viable.

La selección no elimina requisitos restantes. Distingue qué necesita razonamiento arquitectónico ahora y qué puede delegarse dentro de límites acordados. También registra qué información podría cambiar esa asignación; un requisito local puede volverse sistémico al convertirse en contrato externo.

Commerce: derivar preguntas, no una tecnología inevitable

La siguiente tabla es una síntesis del Atlas. Commerce necesita aceptar órdenes, autorizar pagos, reservar inventario y organizar envíos. Las solicitudes iniciales se aclaran antes de comparar candidatos:

Necesidad inicial	Implicación a investigar
Checkout con respuesta p95 acordada.	Precisar alcance, carga y pago terminado frente a aceptación; examinar communication y execution-model.
Pago autoritativo y auditable.	Declarar autoridad de Payments y evidencia de cambios mediante data-ownership; no deducir database per service.
Releases de integración de Payments independientes de Orders.	Contrastar versiones, dependencias y deployment con deployability; una frontera de módulo sola puede no satisfacer el compromiso.
Shipping no debe bloquear checkout.	Acordar resultado inmediato y finalización; revisar coordination sin imponer EDA o un broker.
Browsing crece mucho más que checkout.	Precisar carga y recurso limitado; comparar scaling y granularity sin exigir servicios separados.
Proveedor SOAP y región obligatoria.	Confirmar alcance y vigencia de constraints; siguen abiertas muchas decisiones internas.

Inventory necesita explicitar cuándo una reserva es válida, qué pasa con stock insuficiente y cómo se trata un pago incierto. Availability pide precisar qué capacidad continúa si el proveedor falla: quizás aceptar una orden pendiente sea válido o quizás no pueda prometerse venta sin autorización. Cambiar ese contrato requiere acuerdo, no un patrón seleccionado por ingeniería unilateralmente.

Después architecture-decision-axes organiza las preguntas y architecture-profiles aporta direcciones candidatas. La misma lista funcional podría admitir un deployment común o varias unidades según drivers aclarados. «Escalabilidad → Kubernetes», «async → Kafka», «mantenibilidad → Microservices» y «cloud → Serverless» omiten el razonamiento que permitiría defender esas decisiones.

high-level-design utiliza esas influencias para elegir qué compromisos representar; deep-dives selecciona preguntas cuya incertidumbre amenaza una decisión. El requisito de stock correcto puede requerir investigar reservas concurrentes, mientras una preferencia de presentación no merece la misma profundidad. La derivación orienta atención sin convertir cada necesidad en otra investigación exhaustiva.

Trazabilidad y evidencia que vuelve sobre la necesidad

Conservar vínculos entre necesidad, driver, decisión, consecuencia y evidencia permite explicar por qué se eligió una alternativa y cuándo revisarla. No exige una matriz formal universal. Un registro breve con supuestos relevantes puede ser más útil que una lista extensa de decisiones sin origen.

La trayectoria necesidad → aclaración → significancia → escenario o restricción → implicaciones → candidato → evidencia es una síntesis revisable del Atlas, no un algoritmo. Un ensayo puede mostrar que el SLA del partner difiere de lo supuesto o que el costo de una separación supera el beneficio. Revisar la interpretación del requisito puede ser tan necesario como cambiar tecnología.

La volatilidad requiere condiciones de revisión, no abstracción ilimitada. Una constraint temporal de compatibilidad puede expirar tras deprecation y sunsetting, abriendo alternativas antes descartadas. design-process integra ese feedback en el ciclo completo; system-design-practice organiza la síntesis sin sustituir los canónicos que fundamentan cada pregunta.

common-pitfalls muestra errores al endurecer preferencias, ocultar supuestos o dar peso arquitectónico a todo requisito. design-exercises permite practicar su aclaración con ambigüedad acotada e información revelada después; cambiar una interpretación con evidencia no equivale a ajustar el problema para justificar una tecnología favorita.