[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:es":3,"public-menus:all":38,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:es":205,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:es:1":2050},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","es","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":2049},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1033,"featuredImage":1034,"featuredImageAlt":1035,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1036,"publishedAt":1037,"createdAt":1038,"updatedAt":1039,"seoLocalePaths":1040,"categories":1049,"author":1070,"translations":1075},"482","ADR vs NFR: Las decisiones de arquitectura y la calidad del sistema no son lo mismo","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>Un \u003Cstrong>requisito no funcional (RNF)\u003C\u002Fstrong> describe una cualidad, restricción o condición operativa que se espera que el sistema satisfaga. Un \u003Cstrong>registro de decisión de arquitectura (ADR)\u003C\u002Fstrong> registra una elección arquitectónicamente significativa realizada en respuesta a requisitos, restricciones, riesgos y compensaciones. Están conectados, pero no son intercambiables: un RNF establece qué debe ser verdadero; un ADR explica qué se decidió, por qué y con qué consecuencias.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Respuesta directa\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>RNF = cualidad o restricción requerida del sistema. ADR = decisión de arquitectura registrada.\u003C\u002Fstrong> Un objetivo de latencia, un objetivo de disponibilidad, una regla de aislamiento, una restricción de despliegue o un requisito de mantenibilidad pueden influir en la arquitectura. Un ADR luego registra una elección significativa realizada para abordar uno o más de tales impulsores. El ADR no reemplaza al requisito, y la existencia de un ADR no prueba que el requisito haya sido satisfecho.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Nota sobre terminología y estándares\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">El término \u003Cstrong>RNF\u003C\u002Fstrong> se usa ampliamente pero no está perfectamente estandarizado. Este artículo lo utiliza como abreviatura práctica para requisitos de calidad y restricciones relevantes. Los estándares actuales se verificaron nuevamente el \u003Cstrong>8 de octubre de 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 sigue vigente pero está en revisión; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 son las ediciones publicadas actuales citadas aquí.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Contenido\">\u003Cstrong class=\"editorjs-toc__title\">Contenido\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-5\" class=\"editorjs-toc__link\">¿Cuál es la diferencia entre un RNF y un ADR?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">¿Qué es un RNF en términos arquitectónicos precisos?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">¿Qué es un registro de decisión de arquitectura?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">El ejemplo más simple: requisito de latencia → decisión de arquitectura\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">Los NFR y los ADR suelen tener una relación de muchos a muchos\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">Una elección de tecnología no es automáticamente un requisito\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">Un ADR no es prueba de que se haya satisfecho un NFR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">¿Cuándo se convierte un RNF en arquitectónicamente significativo?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">Un modelo de arquitectura más sólido: requisito → decisión → implementación → validación\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">Evidencia de implementación: cómo separo requisitos y decisiones en SenseFlow\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">Contexto de proyecto empresarial: los requisitos deben preceder a las elecciones de arquitectura\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Modos de fallo comunes cuando se mezclan ADR y NFR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">El marco de decisión ADR–NFR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">Lo que ADR y NFR no son\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Qué cambiaría esta respuesta\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Limitaciones\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">Conclusión\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-74\" class=\"editorjs-toc__link\">Preguntas frecuentes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-76\" class=\"editorjs-toc__link\">Glosario\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Fuentes primarias y evidencia de implementación\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-5\">¿Cuál es la diferencia entre un RNF y un ADR?\u003C\u002Fh2>\n\u003Cp>La distinción más simple es gramatical. Un requisito describe una condición que el sistema debe satisfacer. Un registro de decisión describe una elección que el equipo tomó.\u003C\u002Fp>\n\u003Cp>Por ejemplo, \u003Cstrong>“La API debe devolver el 95% de las solicitudes de lectura en 300 ms bajo la carga de referencia acordada”\u003C\u002Fstrong> es un requisito de calidad. \u003Cstrong>“Usar una caché de lectura para esta carga de trabajo porque la ruta medida solo con base de datos no puede cumplir el objetivo de latencia sin un costo inaceptable”\u003C\u002Fstrong> es una decisión de arquitectura.\u003C\u002Fp>\n\u003Cp>La primera afirmación sigue siendo válida incluso si la implementación cambia. La segunda afirmación puede ser reemplazada posteriormente por otra decisión si la carga de trabajo, la tecnología, el modelo de costos o la evidencia cambian.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">RNF y ADR responden a preguntas diferentes\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">RNF \u002F requisito de calidad\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">ADR \u002F decisión de arquitectura\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Pregunta principal\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What quality, constraint, or operating condition must the system satisfy?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What architecturally significant choice did we make, and why?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Contenido típico\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Measurable target, scope, condition, constraint, acceptance or validation rule\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Context, decision, rationale, alternatives, trade-offs, status and consequences\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Rol en el ciclo de vida\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A requirement to design for and validate\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A historical record of a significant decision\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">¿Qué lo prueba?\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Measurement, test, analysis, inspection, audit or other validation evidence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The record proves what was decided, not that the resulting system meets the requirement\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Cuándo cambia\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">When stakeholder need, operating conditions, policy or quality target changes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">When the decision is replaced, rejected, deprecated, or superseded\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-10\">¿Qué es un RNF en términos arquitectónicos precisos?\u003C\u002Fh2>\n\u003Cp>“Requisito no funcional” es una etiqueta conveniente de la industria, pero puede ocultar varios tipos diferentes de afirmaciones. En el trabajo de arquitectura, la distinción útil es entre \u003Cstrong>comportamiento funcional\u003C\u002Fstrong>, \u003Cstrong>requisitos de calidad\u003C\u002Fstrong> y \u003Cstrong>restricciones\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 25010:2023 proporciona un modelo de calidad de producto con nueve características y subcaracterísticas que se pueden usar al especificar y evaluar la calidad de productos de TIC y software. El trabajo de arquitectura del SEI trata de manera similar los requisitos de atributos de calidad como impulsores principales de la arquitectura de software.\u003C\u002Fp>\n\u003Cp>Un RNF útil, por lo tanto, no es “el sistema debería ser rápido” o “la plataforma debe ser segura”. Esas afirmaciones nombran aspiraciones. Un requisito que impulsa la arquitectura debe hacer que la propiedad esperada sea lo suficientemente verificable como para que las alternativas de diseño y la evidencia posterior puedan evaluarse contra él.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Afirmación débil\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Forma de requisito más útil\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Por qué importa la diferencia\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La API debe ser rápida\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Para la carga de trabajo W, el 95% de la operación X se completa dentro de T milisegundos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Define carga de trabajo, operación, métrica y umbral\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El servicio debe estar disponible\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El servicio S cumple un objetivo de disponibilidad acordado durante la ventana de medición M, excluyendo condiciones de mantenimiento definidas explícitamente\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hace que la disponibilidad sea medible y define el alcance\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Los datos de los inquilinos deben ser seguros\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Una solicitud autenticada para el inquilino A nunca debe recuperar o modificar datos del inquilino B a través de rutas de aplicación compatibles\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Convierte un objetivo de seguridad vago en una propiedad de aislamiento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El sistema debería escalar\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El sistema soporta la carga de trabajo W con concurrencia C mientras cumple los umbrales de latencia y tasa de errores\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conecta la escala con un comportamiento de servicio medible\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Necesitamos PostgreSQL\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">No es un RNF por sí mismo; indique primero las cualidades de persistencia requeridas o la restricción externa\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Una elección tecnológica normalmente es una solución, no el requisito que pretende satisfacer\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Un requisito debe describir la necesidad antes que el mecanismo\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Si “usar Kubernetes”, “usar PostgreSQL”, “usar microservicios” o “usar búsqueda vectorial” aparece como el requisito, pregunte si realmente es una restricción externa o si la solución se escribió antes de que se hiciera explícita la necesidad de calidad subyacente.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-16\">¿Qué es un registro de decisión de arquitectura?\u003C\u002Fh2>\n\u003Cp>Un registro de decisión de arquitectura es un registro compacto de una decisión de arquitectura importante. La formulación original de ADR de Michael Nygard enfatiza el \u003Cstrong>contexto\u003C\u002Fstrong>, la \u003Cstrong>decisión\u003C\u002Fstrong>, su \u003Cstrong>estado\u003C\u002Fstrong> y las \u003Cstrong>consecuencias\u003C\u002Fstrong> resultantes.\u003C\u002Fp>\n\u003Cp>El objeto importante es la decisión, no la plantilla. Diferentes equipos usan diferentes formatos de ADR. Un registro más completo también puede preservar alternativas, criterios de decisión, compensaciones, evidencia, enlaces a requisitos y la fecha o versión desde la cual aplica la decisión.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 es más amplio que la práctica de ADR: especifica requisitos para las descripciones de arquitectura y sus conceptos, mientras que explícitamente no prescribe un proceso, notación, herramienta, formato o medio para registrar una descripción de arquitectura. Por lo tanto, un ADR es una técnica práctica de registro de decisiones, no un formato exigido por ISO 42010.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Campo del ADR\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Qué preserva\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Por qué importa\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexto\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El problema, las fuerzas, los requisitos, los supuestos y el entorno que rodean la elección\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Los lectores futuros pueden reconstruir por qué una elección era necesaria\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisión\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La elección que se volvió autoritativa\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Separa la opción seleccionada de la discusión\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Estado\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Propuesto, aceptado, rechazado, obsoleto, reemplazado u otro estado controlado\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evita que decisiones antiguas permanezcan activas silenciosamente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alternativas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Otras opciones viables consideradas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Muestra que la solución seleccionada no era la única imaginable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Justificación \u002F compensaciones\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Por qué se seleccionó la opción y qué sacrifica\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hace que el razonamiento arquitectónico sea inspeccionable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Consecuencias\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Efectos positivos y negativos esperados, trabajo de seguimiento, riesgos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conecta una elección local con el impacto en el sistema\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Fecha \u002F versión\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cuándo la decisión se volvió válida\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Apoya la trazabilidad histórica y el reemplazo posterior\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-21\">El ejemplo más simple: requisito de latencia → decisión de arquitectura\u003C\u002Fh2>\n\u003Cp>Supongamos que un propietario de producto y un equipo de ingeniería acuerdan que un endpoint de búsqueda debe devolver la primera página de resultados dentro de 400 ms en el percentil 95 bajo una carga de trabajo de referencia definida.\u003C\u002Fp>\n\u003Cp>Ese objetivo no es un ADR. Es un requisito de calidad. El trabajo de arquitectura comienza preguntando qué diseño puede satisfacerlo bajo las demás restricciones del sistema.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Del requisito a la evidencia\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Enunciar el requisito\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definir el objetivo de calidad, la carga de trabajo, el alcance, el umbral y el método de validación.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Identificar la relevancia arquitectónica\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Determinar si el requisito influye materialmente en la estructura, la tecnología, el despliegue, el flujo de datos o el modelo operativo.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Evaluar opciones\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Comparar alternativas como indexación, caché, desnormalización, trabajo asíncrono, particionamiento u otra arquitectura de consulta.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Registrar la decisión\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Capturar la elección de arquitectura seleccionada, la justificación, las alternativas, las compensaciones, el estado y las consecuencias en un ADR.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Implementar\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Convertir la decisión en código, infraestructura, configuración y comportamiento operativo.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Validar\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Medir el sistema real contra el requisito original. El resultado de la prueba valida el NFR; el ADR por sí solo no lo hace.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Dónde se detiene el ejemplo simple\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Los sistemas reales rara vez tienen un solo requisito y una sola decisión. El rendimiento puede compensarse con el costo, la consistencia, la operabilidad, la seguridad, la mantenibilidad, el uso de energía o el riesgo de entrega. Por lo tanto, el modelo útil es un grafo de trazabilidad, no un mapeo uno a uno.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-26\">Los NFR y los ADR suelen tener una relación de muchos a muchos\u003C\u002Fh2>\n\u003Cp>Un requisito de calidad puede impulsar varias decisiones de arquitectura. Un requisito de aislamiento de inquilinos, por ejemplo, puede influir en la propagación de identidad, el alcance de la base de datos, el diseño de trabajos en segundo plano, las claves de caché, el registro de auditoría y las herramientas administrativas.\u003C\u002Fp>\n\u003Cp>Una decisión de arquitectura también puede responder a varios requisitos a la vez. Elegir un límite de procesamiento asíncrono podría mejorar la capacidad de respuesta y el aislamiento de fallos, al tiempo que introduce compensaciones de consistencia, complejidad, observabilidad y operativas.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Por qué la relación no es uno a uno\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Lado del requisito\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Lado de la decisión\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Lado de la validación\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Un NFR → muchos ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A broad quality target can constrain several architectural boundaries\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Several coordinated decisions may be required\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Evidence may need multiple tests or measurements\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Muchos NFR → un ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Several quality and constraint drivers can point at the same design problem\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">One decision may balance several drivers\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Each requirement still needs its own acceptance evidence\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">ADR sin un NFR clásico\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The choice can still be architecturally significant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Validate against the actual driver, not an invented NFR\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Requisito estable, el ADR cambia\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The target can remain unchanged\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A better or necessary implementation choice can supersede the old decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The new architecture must still be checked against the same target\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-30\">Una elección de tecnología no es automáticamente un requisito\u003C\u002Fh2>\n\u003Cp>Un error recurrente de arquitectura es escribir una tecnología preferida en la capa de requisitos y luego tratar el diseño resultante como inevitable.\u003C\u002Fp>\n\u003Cp>«El sistema debe usar PostgreSQL» puede ser una restricción legítima si un contrato, una política de plataforma, un requisito de compatibilidad, una regla de licenciamiento, un estándar organizacional o un límite operativo existente realmente exigen PostgreSQL. Pero si la necesidad real es la consistencia transaccional, las consultas estructuradas, la familiaridad operativa o un objetivo de recuperación específico, el requisito debe enunciar esa necesidad y la selección de tecnología debe registrarse como una decisión.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Declaración\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Clasificación\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Razón\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Todas las lecturas con alcance de inquilino deben aplicar aislamiento de inquilinos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisito \u002F propiedad de seguridad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Describe una propiedad que debe cumplirse\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Usar Row Level Security de PostgreSQL para tablas seleccionadas con alcance de inquilino\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisión de arquitectura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Elige un mecanismo destinado a ayudar a satisfacer la propiedad de aislamiento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El destino de despliegue debe ejecutarse en un entorno aprobado operado en la UE\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Restricción \u002F condición operativa similar a un NFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Restringe dónde puede operar el sistema\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Usar el proveedor X en la región Y\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisión de arquitectura \u002F despliegue a menos que esté impuesto externamente\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Selecciona una solución particular dentro del límite permitido\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latencia de API en el percentil 95 ≤ 300 ms bajo la carga de trabajo W\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisito de calidad\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Define un comportamiento de rendimiento medible\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Introducir una caché para el endpoint X\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisión de arquitectura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Selecciona una táctica destinada a mejorar el comportamiento medido\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-34\">Un ADR no es prueba de que se haya satisfecho un NFR\u003C\u002Fh2>\n\u003Cp>La documentación de decisiones y la validación del sistema responden a preguntas diferentes. Un ADR puede mostrar que se consideraron el rendimiento, la seguridad, la resiliencia o la mantenibilidad. Por sí solo no puede demostrar que el sistema entregado realmente alcanza esas propiedades.\u003C\u002Fp>\n\u003Cp>La prueba debe provenir del método de validación apropiado para el requisito: benchmark, prueba de carga, prueba de fallos, prueba de seguridad, análisis de arquitectura, auditoría, inspección, telemetría operativa, ejercicio de recuperación, estudio de usuarios u otra forma de evidencia.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">No confundas la intención con la evidencia\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ADR:\u003C\u002Fstrong> "Seleccionamos el diseño X porque se espera que satisfaga el requisito R bajo los supuestos A."\u003Cbr>\u003Cstrong>Validación:\u003C\u002Fstrong> "La evidencia medida o analizada E muestra si el sistema implementado realmente satisface R."\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">¿Cuándo se convierte un RNF en arquitectónicamente significativo?\u003C\u002Fh2>\n\u003Cp>No todos los requisitos no funcionales merecen una decisión de arquitectura. El subconjunto importante son los requisitos que moldean materialmente la arquitectura o fuerzan compensaciones en todo el sistema.\u003C\u002Fp>\n\u003Cp>La literatura del SEI utiliza el concepto de \u003Cstrong>requisitos arquitectónicamente significativos\u003C\u002Fstrong> para requisitos con un efecto arquitectónico de gran alcance. Los atributos de calidad como el rendimiento, la fiabilidad, la seguridad y la modificabilidad son fuentes frecuentes de tales impulsores, especialmente cuando conllevan un alto valor empresarial o de misión.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Prueba de significancia arquitectónica\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Preguntar si el requisito cambia la estructura\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">¿Forzarían valores diferentes componentes, límites, rutas de datos o topología de despliegue distintos?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Preguntar si restringe decisiones tecnológicas importantes\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">¿Elimina opciones de implementación que de otro modo serían viables?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Preguntar si crea un comportamiento transversal\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">¿Afecta a muchos componentes, equipos, interfaces o etapas del ciclo de vida?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Preguntar si crea una compensación difícil\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">¿Mejorar esta propiedad afecta materialmente a otra calidad, costo, cronograma, complejidad o riesgo?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Preguntar si el fallo es costoso\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">¿Incumplir el requisito crearía un impacto operativo, de seguridad, regulatorio, financiero o de producto material?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Registrar decisiones solo donde vale la pena preservar el razonamiento\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">No crees ADR para cada elección local de codificación; preserva las decisiones arquitectónicamente significativas y su justificación.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-42\">Un modelo de arquitectura más sólido: requisito → decisión → implementación → validación\u003C\u002Fh2>\n\u003Cp>La conexión más útil entre los RNF y los ADR es la trazabilidad. Un requisito debería poder señalar las decisiones de arquitectura que lo abordan; un ADR debería identificar los impulsores a los que responde; el trabajo de implementación debería realizar la decisión; la validación debería volver al requisito original.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Cadena de trazabilidad de arquitectura\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Necesidad \u002F objetivo de negocio\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Por qué importa la calidad o la restricción.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Requisito \u002F RNF\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Qué debe lograr o respetar el sistema.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Impulsores de arquitectura\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Qué requisitos son lo suficientemente significativos como para dar forma al diseño.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Opciones\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Formas plausibles de abordar el impulsor.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">ADR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">La elección seleccionada, la justificación, las alternativas, las compensaciones y las consecuencias.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Implementación\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Código, modelo de datos, infraestructura, interfaces y mecanismos operativos que realizan la decisión.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Evidencia de validación\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Pruebas, mediciones, análisis o auditorías que demuestran si el requisito original se satisface realmente.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Cambio \u002F sustitución\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Nueva evidencia o requisitos modificados pueden desencadenar un nuevo ADR mientras se preserva el razonamiento histórico.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-45\">Evidencia de implementación: cómo separo requisitos y decisiones en SenseFlow\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Evidencia de implementación \u002F proyecto original\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">La siguiente sección describe la estructura de mi propio proyecto SenseFlow. Es evidencia de implementación para la separación en este artículo, no una afirmación de que cada equipo deba usar el mismo modelo de documentación.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>En SenseFlow, la Fuente de Verdad del proyecto coloca explícitamente los requisitos no funcionales dentro de la estructura de requisitos junto con dependencias, riesgos, supuestos, criterios de aceptación y un método de validación. El modelo de documentación define por separado la integridad de las decisiones para decisiones significativas.\u003C\u002Fp>\n\u003Cp>Para decisiones significativas de SenseFlow, los campos registrados son \u003Cstrong>Decisión, Razón, Alternativas, Compensaciones, Estado y Fecha \u002F Versión\u003C\u002Fstrong>. Las decisiones importantes de arquitectura y producto están destinadas a permanecer históricamente trazables en lugar de ser sobrescritas cuando el proyecto evoluciona.\u003C\u002Fp>\n\u003Cp>SenseFlow también asigna roles operativos diferentes a Confluence y Jira. Confluence es el entorno estructurado de conocimiento y decisiones; Jira gestiona el trabajo de entrega accionable. Las Epics importantes de Jira deberían enlazar de vuelta a la documentación relevante de producto o requisitos. Esto preserva la cadena desde la intención del producto a través de los requisitos y las decisiones hasta la implementación, en lugar de convertir el backlog en la Fuente de Verdad de la arquitectura.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Capa de SenseFlow\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Qué contiene\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Rol en la separación ADR\u002FRNF\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Estructura de producto \u002F requisitos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Objetivo de producto, capacidad, epic, historia de usuario, criterios de aceptación, tareas técnicas; los requisitos pueden incluir RNF y método de validación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preserva qué debe lograrse y cómo se verificará el éxito\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Integridad de decisiones\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisión, razón, alternativas, compensaciones, estado, fecha\u002Fversión\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preserva por qué una elección arquitectónicamente significativa se volvió autoritativa\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confluence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisitos, arquitectura, investigación, registros de decisiones, riesgos, hoja de ruta y fuentes de apoyo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mantiene la Fuente de Verdad conceptual e histórica\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jira\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Iniciativas\u002Fobjetivos, epics, historias, tareas y estado de entrega\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ejecuta el trabajo aprobado sin convertirse en la Fuente de Verdad conceptual\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gestión de cambios\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Estado actual → nueva evidencia → cambio propuesto → impacto → decisión\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permite que las decisiones evolucionen sin borrar el rastro del razonamiento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Trazabilidad de extremo a extremo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Problema → necesidad → valor → objetivo de producto → requisito → implementación → validación\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mantiene la documentación de decisiones conectada al producto real y al ciclo de vida de la evidencia\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Qué demuestra esta implementación\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Un requisito y una decisión pueden vivir cerca sin colapsarse en un solo registro. El requisito sigue siendo el objetivo; la decisión sigue siendo el historial de razonamiento; el trabajo de entrega implementa la decisión; la validación vuelve al objetivo.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-52\">Contexto de proyecto empresarial: los requisitos deben preceder a las elecciones de arquitectura\u003C\u002Fh2>\n\u003Cp>La misma separación es útil en el trabajo de proyectos orientados a la empresa. Las decisiones de arquitectura tomadas antes de que los requisitos, riesgos, restricciones y condiciones de aceptación se comprendan suficientemente pueden convertir las preferencias en falsas necesidades.\u003C\u002Fp>\n\u003Cp>Para Enterprise Aaasaasa 0.1, la lección relevante es metodológica más que una afirmación sobre un ADR particular: los requisitos, la arquitectura, la validación, los hitos, la gestión de riesgos y la aceptación pertenecen a un sistema de entrega conectado. Una elección de arquitectura debe permanecer trazable al requisito o restricción que pretende abordar.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Modos de fallo comunes cuando se mezclan ADR y NFR\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Modo de fallo\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Qué sucede\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Consecuencia\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tecnología disfrazada de requisito\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Se escribe una solución preferida como “debe usar X” sin establecer la necesidad subyacente\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nunca se evalúan alternativas y la arquitectura se fija prematuramente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR oculto solo dentro de un ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La decisión menciona un objetivo de rendimiento\u002Fseguridad que está ausente de la línea base de requisitos\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El objetivo es difícil de validar, priorizar o gestionar de forma independiente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ADR tratado como prueba\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Se asume que una elección documentada significa que el requisito está satisfecho\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La intención arquitectónica reemplaza la medición o la verificación\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR vago\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Palabras como rápido, escalable, seguro o mantenible no tienen un alcance medible\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Diferentes partes interesadas pueden creer que el mismo requisito significa cosas distintas\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sin alternativas registradas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El equipo registra solo la tecnología seleccionada\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Los futuros mantenedores no pueden reconstruir por qué se rechazó otra opción\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sin modelo de sustitución\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Los ADR antiguos se editan o eliminan cuando cambia la arquitectura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El razonamiento histórico desaparece y las decisiones obsoletas pueden quedar ambiguas\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cada detalle de implementación se convierte en un ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El repositorio se llena de registros de bajo valor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Las decisiones arquitectónicas importantes se vuelven difíciles de encontrar\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El backlog se convierte en la fuente de verdad de la arquitectura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Las tareas de Jira se tratan como la única explicación del sistema\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">El estado de entrega sobrevive, pero se pierden la justificación arquitectónica y los impulsores de calidad\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-57\">El marco de decisión ADR–NFR\u003C\u002Fh2>\n\u003Cp>Cuando un equipo se encuentra con una nueva preocupación arquitectónica, la siguiente secuencia ayuda a determinar qué pertenece a los requisitos, qué pertenece a un ADR y qué pertenece a la evidencia.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Prueba de clasificación ADR–NFR\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. ¿Es una propiedad requerida o una restricción externa?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Si es así, escriba o haga referencia al requisito antes de elegir un mecanismo.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. ¿Se puede validar?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Defina el alcance, la condición, la métrica, la regla de aceptación, el método de análisis u otra evidencia necesaria.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. ¿Es arquitectónicamente significativo?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifique si el requisito moldea materialmente la estructura, la tecnología, los datos, el despliegue o las compensaciones transversales.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. ¿Existen alternativas significativas?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Compare tácticas u opciones de arquitectura viables en lugar de saltar directamente a una tecnología preferida.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. ¿Se ha vuelto autoritativa una elección?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Cree o actualice el ADR con contexto, decisión, justificación, alternativas, compensaciones, estado y consecuencias.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. ¿Está implementada la decisión?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Rastree el ADR hasta el diseño, las tareas, el código, la configuración y las operaciones.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. ¿Está satisfecho el requisito?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Recopile evidencia de validación contra el requisito mismo.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. ¿Cambiaron las condiciones?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Vuelva a evaluar el requisito y, cuando sea necesario, sustituya el ADR sin borrar el historial.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-60\">Lo que ADR y NFR no son\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Errores de categoría comunes\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Concepto\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">No es\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Razón\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">NFR \u002F requisito de calidad\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A required quality, constraint or operating condition\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A technology shopping list\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Requirements should preserve the need independently from one implementation when possible\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A record of an architecturally significant decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The complete architecture description\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Architecture also needs views, interfaces, models, responsibilities and other documentation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Evidencia de validación\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Evidence that checks whether a requirement is satisfied\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The ADR itself\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Documented intent is different from measured or analyzed system behavior\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Elemento del backlog\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Actionable delivery work\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A durable substitute for architecture rationale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Task state answers what is being delivered, not necessarily why the architecture exists\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Restricción\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A condition that restricts the solution space\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Always an internally chosen architecture decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Some constraints come from regulation, contracts, existing platforms or organizational boundaries\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-62\">Qué cambiaría esta respuesta\u003C\u002Fh2>\n\u003Cp>La terminología puede evolucionar. ISO\u002FIEC\u002FIEEE 29148:2018 sigue siendo el estándar de ingeniería de requisitos publicado vigente a 8 de octubre de 2026, pero ISO enumera un Proyecto de Norma Internacional destinado a reemplazarlo. Si la nueva edición cambia la terminología relevante o la guía de requisitos, las referencias específicas de la versión en este artículo deberían actualizarse.\u003C\u002Fp>\n\u003Cp>Las plantillas de ADR también pueden evolucionar sin cambiar la distinción central. La plantilla mínima de Michael Nygard, MADR, plantillas específicas de la organización, herramientas de conocimiento arquitectónico o bases de datos de decisiones estructuradas pueden registrar decisiones. La pregunta duradera es si el registro conserva suficiente contexto y justificación para comprender una elección arquitectónicamente significativa.\u003C\u002Fp>\n\u003Cp>La distinción solo colapsaría si una organización eligiera deliberadamente un artefacto combinado que almacene tanto datos de requisitos como de decisiones en un solo documento. Incluso entonces, los roles semánticos siguen siendo diferentes: un campo establece el resultado o la restricción requeridos; otro registra la respuesta elegida.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Limitaciones\u003C\u002Fh2>\n\u003Cp>Este artículo usa \u003Cstrong>NFR\u003C\u002Fstrong> como abreviatura práctica. Algunos métodos de ingeniería prefieren términos como requisito de atributo de calidad, requisito de calidad, calidad del sistema, restricción, objetivo de nivel de servicio o requisito arquitectónicamente significativo. Esos términos no son perfectamente intercambiables, y la terminología del proyecto debe ser explícita.\u003C\u002Fp>\n\u003Cp>No todos los requisitos pueden reducirse a un único umbral numérico. La seguridad, la protección, la mantenibilidad, la interoperabilidad, la usabilidad, la explicabilidad, la portabilidad y la gobernanza pueden requerir combinaciones de escenarios, reglas estructurales, análisis, controles de proceso y evidencia cualitativa. “Medible” debería significar suficientemente verificable para la decisión, no artificialmente numérico.\u003C\u002Fp>\n\u003Cp>No toda decisión de arquitectura necesita un ADR formal. El costo de documentación debe ser proporcional a la importancia arquitectónica, la longevidad, la incertidumbre, la complejidad de las compensaciones y el costo de perder la justificación.\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">Conclusión\u003C\u002Fh2>\n\u003Cp>ADR y NFR pertenecen a capas diferentes del trabajo de arquitectura. \u003Cstrong>El NFR define un objetivo de calidad, una restricción o una condición operativa. El ADR registra una respuesta arquitectónica significativa a uno o más impulsores.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Mantener esas capas separadas hace que la arquitectura sea más fácil de razonar. Los requisitos pueden validarse independientemente de la tecnología. Las decisiones pueden sustituirse sin reescribir el historial. Las alternativas y las compensaciones permanecen visibles. El trabajo de entrega puede rastrearse hasta la intención arquitectónica. La evidencia puede mostrar si el sistema resultante satisface realmente el requisito.\u003C\u002Fp>\n\u003Cp>La cadena más sólida, por lo tanto, no es “NFR → ADR → hecho”. Es \u003Cstrong>necesidad → requisito → impulsores arquitectónicos → opciones → decisión → implementación → validación → cambio\u003C\u002Fstrong>. Esa cadena convierte la documentación de arquitectura de papeleo estático en un registro comprobable de por qué el sistema tiene la forma que tiene.\u003C\u002Fp>\n\u003Ch2 id=\"section-74\">Preguntas frecuentes\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ADR vs NFR\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Es un ADR un requisito no funcional?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Un NFR establece una cualidad, restricción o condición operativa requerida. Un ADR registra una elección arquitectónicamente significativa hecha en respuesta a requisitos, restricciones, riesgos y compensaciones.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Debería cada NFR tener un ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Solo los requisitos que influyen materialmente en la arquitectura necesitan decisiones a nivel de arquitectura que merezca la pena preservar. Un NFR también puede impulsar varios ADR, y un ADR puede responder a varios requisitos.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Puede “usar PostgreSQL” ser un NFR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Solo cuando PostgreSQL se impone genuinamente como una restricción externa. De lo contrario, la necesidad subyacente debería expresarse primero, y seleccionar PostgreSQL normalmente debería tratarse como una decisión de arquitectura.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Demuestra un ADR que se cumple un requisito de rendimiento o seguridad?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Un ADR registra la intención y el razonamiento. El requisito se valida mediante evidencia apropiada, como pruebas, medición, análisis, auditoría o telemetría operativa.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Qué debería contener un ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Como mínimo, un ADR debería dejar claros el contexto y la decisión. Las estructuras comunes también incluyen estado y consecuencias. Los equipos pueden añadir alternativas, justificación, compensaciones, enlaces a requisitos, evidencia, responsables, fechas y relaciones de sustitución.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Qué hace que un NFR sea arquitectónicamente significativo?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Un requisito es arquitectónicamente significativo cuando da forma material a la estructura del sistema, la tecnología, los flujos de datos, el despliegue, el comportamiento transversal o compensaciones de calidad difíciles, especialmente cuando el fallo conlleva un alto impacto empresarial o de misión.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq7\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">¿Debería eliminarse un ADR antiguo cuando cambia la arquitectura?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Normalmente no. Una decisión de reemplazo debería normalmente sustituir el registro antiguo para que el razonamiento histórico siga siendo rastreable.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-76\">Glosario\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Términos centrales de arquitectura\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"nfr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">NFR\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Requisito no funcional: abreviatura práctica para una cualidad, restricción o condición operativa requerida del sistema; la terminología exacta varía según el método y el estándar.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"quality-attribute-requirement\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Requisito de atributo de calidad\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un requisito que describe una propiedad de calidad que se espera que el sistema exhiba bajo condiciones definidas, como rendimiento, disponibilidad, seguridad, fiabilidad o modificabilidad.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"adr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Registro de decisión de arquitectura (ADR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un registro duradero de una decisión arquitectónicamente significativa y suficiente contexto para entender por qué se tomó la elección y qué consecuencias se derivan.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"asr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Requisito arquitectónicamente significativo (ASR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un requisito con un impacto arquitectónico suficientemente amplio como para influir materialmente en el diseño del sistema.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"constraint\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Restricción\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Una condición que restringe el espacio de solución, incluidos límites externos de política, regulación, plataforma, compatibilidad, contractuales u organizativos.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"trade-off\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Compensación\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Una relación de diseño en la que mejorar un objetivo, propiedad o dimensión de coste puede empeorar otra.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"validation\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Validación\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Trabajo que produce evidencia utilizado para determinar si el sistema implementado satisface el requisito declarado bajo las condiciones relevantes.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"superseded-adr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">ADR sustituido\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un registro histórico de decisión que ha sido reemplazado por una decisión autoritativa más reciente, pero que sigue disponible para trazabilidad.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">Fuentes primarias y evidencia de implementación\u003C\u002Fh2>\n\u003Cp>Este artículo separa los estándares actuales de la evidencia de implementación del proyecto. ISO\u002FIEC\u002FIEEE 29148:2018 sigue vigente a 8 de octubre de 2026, pero está marcado para revisión; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 son ediciones publicadas vigentes. SenseFlow es evidencia original del proyecto para el modelo de trazabilidad e integridad de decisiones descrito anteriormente.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 29148:2018 — Ingeniería de requisitos\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Estándar de ingeniería de requisitos publicado vigente. ISO indica que la edición de 2018 fue revisada y confirmada en 2024 y se espera que sea reemplazada por el DIS actualmente en desarrollo.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE DIS 29148 — Ingeniería de requisitos\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Borrador de Norma Internacional actualmente en desarrollo y destinado a reemplazar ISO\u002FIEC\u002FIEEE 29148:2018.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC 25010:2023 — Modelo de calidad del producto\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Modelo de calidad del producto vigente con nueve características de calidad utilizadas para especificar, medir y evaluar la calidad de productos TIC y de software.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 42010:2022 — Descripción de arquitectura\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Estándar de descripción de arquitectura vigente. Especifica conceptos de descripción de arquitectura y requisitos de conformidad sin prescribir un único formato de registro, notación, proceso o herramienta.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Michael Nygard — Documentar decisiones de arquitectura\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Artículo original influyente sobre ADR que describe registros ligeros centrados en contexto, decisión, estado y consecuencias, con decisiones sustituidas conservadas para la comprensión histórica.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Relacionar objetivos de negocio con requisitos arquitectónicamente significativos\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Informe del SEI que explica cómo los requisitos de atributos de calidad y los objetivos de negocio impulsan la arquitectura de software y por qué los requisitos arquitectónicamente significativos necesitan una elicitación explícita.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Definir cualidades no funcionales del sistema\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Resumen del SEI que conecta atributos no funcionales\u002Fde calidad con arquitectura, escenarios, compensaciones y evaluación objetiva del sistema.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Colección del método de diseño guiado por atributos\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Método de diseño de arquitectura basado en requisitos funcionales, requisitos de atributos de calidad y restricciones, con tácticas y patrones arquitectónicos seleccionados para satisfacer escenarios de calidad.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Colección Views and Beyond\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guía de documentación de arquitectura que enfatiza las vistas relevantes y el registro de las decisiones de diseño necesarias como parte del trabajo de arquitectura.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1032},1791476119030,[214,219,226,232,239,243,247,251,255,299,303,307,311,315,343,349,353,357,361,365,401,405,409,413,438,444,448,452,456,497,501,505,509,540,544,548,552,557,561,565,569,592,596,600,629,633,638,642,646,650,682,687,691,695,699,703,743,747,751,780,784,829,833,837,841,845,849,853,857,861,865,869,873,877,881,914,918,950,954,958,968,976,984,992,1000,1008,1016,1024],{"id":215,"data":216,"type":218},"intro",{"text":217},"Un \u003Cstrong>requisito no funcional (RNF)\u003C\u002Fstrong> describe una cualidad, restricción o condición operativa que se espera que el sistema satisfaga. Un \u003Cstrong>registro de decisión de arquitectura (ADR)\u003C\u002Fstrong> registra una elección arquitectónicamente significativa realizada en respuesta a requisitos, restricciones, riesgos y compensaciones. Están conectados, pero no son intercambiables: un RNF establece qué debe ser verdadero; un ADR explica qué se decidió, por qué y con qué consecuencias.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>RNF = cualidad o restricción requerida del sistema. ADR = decisión de arquitectura registrada.\u003C\u002Fstrong> Un objetivo de latencia, un objetivo de disponibilidad, una regla de aislamiento, una restricción de despliegue o un requisito de mantenibilidad pueden influir en la arquitectura. Un ADR luego registra una elección significativa realizada para abordar uno o más de tales impulsores. El ADR no reemplaza al requisito, y la existencia de un ADR no prueba que el requisito haya sido satisfecho.","Respuesta directa","info","callout",{"id":227,"data":228,"type":225},"version-note",{"body":229,"title":230,"variant":231},"El término \u003Cstrong>RNF\u003C\u002Fstrong> se usa ampliamente pero no está perfectamente estandarizado. Este artículo lo utiliza como abreviatura práctica para requisitos de calidad y restricciones relevantes. Los estándares actuales se verificaron nuevamente el \u003Cstrong>8 de octubre de 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 sigue vigente pero está en revisión; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 son las ediciones publicadas actuales citadas aquí.","Nota sobre terminología y estándares","note",{"id":233,"data":234,"type":238},"toc",{"title":235,"maxLevel":236,"minLevel":237},"Contenido",3,2,"tableOfContents",{"id":240,"data":241,"type":42},"h-meaning",{"text":242,"level":237},"¿Cuál es la diferencia entre un RNF y un ADR?",{"id":244,"data":245,"type":218},"p-meaning-1",{"text":246},"La distinción más simple es gramatical. Un requisito describe una condición que el sistema debe satisfacer. Un registro de decisión describe una elección que el equipo tomó.",{"id":248,"data":249,"type":218},"p-meaning-2",{"text":250},"Por ejemplo, \u003Cstrong>“La API debe devolver el 95% de las solicitudes de lectura en 300 ms bajo la carga de referencia acordada”\u003C\u002Fstrong> es un requisito de calidad. \u003Cstrong>“Usar una caché de lectura para esta carga de trabajo porque la ruta medida solo con base de datos no puede cumplir el objetivo de latencia sin un costo inaceptable”\u003C\u002Fstrong> es una decisión de arquitectura.",{"id":252,"data":253,"type":218},"p-meaning-3",{"text":254},"La primera afirmación sigue siendo válida incluso si la implementación cambia. La segunda afirmación puede ser reemplazada posteriormente por otra decisión si la carga de trabajo, la tecnología, el modelo de costos o la evidencia cambian.",{"id":256,"data":257,"type":298},"basic-difference",{"rows":258,"title":289,"layout":290,"columns":291},[259,265,271,277,283],{"id":260,"label":261,"values":262},"question","Pregunta principal",{"adr":263,"nfr":264},"What architecturally significant choice did we make, and why?","What quality, constraint, or operating condition must the system satisfy?",{"id":266,"label":267,"values":268},"content","Contenido típico",{"adr":269,"nfr":270},"Context, decision, rationale, alternatives, trade-offs, status and consequences","Measurable target, scope, condition, constraint, acceptance or validation rule",{"id":272,"label":273,"values":274},"lifecycle","Rol en el ciclo de vida",{"adr":275,"nfr":276},"A historical record of a significant decision","A requirement to design for and validate",{"id":278,"label":279,"values":280},"evidence","¿Qué lo prueba?",{"adr":281,"nfr":282},"The record proves what was decided, not that the resulting system meets the requirement","Measurement, test, analysis, inspection, audit or other validation evidence",{"id":284,"label":285,"values":286},"change","Cuándo cambia",{"adr":287,"nfr":288},"When the decision is replaced, rejected, deprecated, or superseded","When stakeholder need, operating conditions, policy or quality target changes","RNF y ADR responden a preguntas diferentes","table",[292,295],{"id":293,"label":294},"nfr","RNF \u002F requisito de calidad",{"id":296,"label":297},"adr","ADR \u002F decisión de arquitectura","comparison",{"id":300,"data":301,"type":42},"h-nfr",{"text":302,"level":237},"¿Qué es un RNF en términos arquitectónicos precisos?",{"id":304,"data":305,"type":218},"p-nfr-1",{"text":306},"“Requisito no funcional” es una etiqueta conveniente de la industria, pero puede ocultar varios tipos diferentes de afirmaciones. En el trabajo de arquitectura, la distinción útil es entre \u003Cstrong>comportamiento funcional\u003C\u002Fstrong>, \u003Cstrong>requisitos de calidad\u003C\u002Fstrong> y \u003Cstrong>restricciones\u003C\u002Fstrong>.",{"id":308,"data":309,"type":218},"p-nfr-2",{"text":310},"ISO\u002FIEC 25010:2023 proporciona un modelo de calidad de producto con nueve características y subcaracterísticas que se pueden usar al especificar y evaluar la calidad de productos de TIC y software. El trabajo de arquitectura del SEI trata de manera similar los requisitos de atributos de calidad como impulsores principales de la arquitectura de software.",{"id":312,"data":313,"type":218},"p-nfr-3",{"text":314},"Un RNF útil, por lo tanto, no es “el sistema debería ser rápido” o “la plataforma debe ser segura”. Esas afirmaciones nombran aspiraciones. Un requisito que impulsa la arquitectura debe hacer que la propiedad esperada sea lo suficientemente verificable como para que las alternativas de diseño y la evidencia posterior puedan evaluarse contra él.",{"id":316,"data":317,"type":290},"nfr-examples",{"content":318,"stretched":43,"withHeadings":14},[319,323,327,331,335,339],[320,321,322],"Afirmación débil","Forma de requisito más útil","Por qué importa la diferencia",[324,325,326],"La API debe ser rápida","Para la carga de trabajo W, el 95% de la operación X se completa dentro de T milisegundos","Define carga de trabajo, operación, métrica y umbral",[328,329,330],"El servicio debe estar disponible","El servicio S cumple un objetivo de disponibilidad acordado durante la ventana de medición M, excluyendo condiciones de mantenimiento definidas explícitamente","Hace que la disponibilidad sea medible y define el alcance",[332,333,334],"Los datos de los inquilinos deben ser seguros","Una solicitud autenticada para el inquilino A nunca debe recuperar o modificar datos del inquilino B a través de rutas de aplicación compatibles","Convierte un objetivo de seguridad vago en una propiedad de aislamiento",[336,337,338],"El sistema debería escalar","El sistema soporta la carga de trabajo W con concurrencia C mientras cumple los umbrales de latencia y tasa de errores","Conecta la escala con un comportamiento de servicio medible",[340,341,342],"Necesitamos PostgreSQL","No es un RNF por sí mismo; indique primero las cualidades de persistencia requeridas o la restricción externa","Una elección tecnológica normalmente es una solución, no el requisito que pretende satisfacer",{"id":344,"data":345,"type":225},"nfr-rule",{"body":346,"title":347,"variant":348},"Si “usar Kubernetes”, “usar PostgreSQL”, “usar microservicios” o “usar búsqueda vectorial” aparece como el requisito, pregunte si realmente es una restricción externa o si la solución se escribió antes de que se hiciera explícita la necesidad de calidad subyacente.","Un requisito debe describir la necesidad antes que el mecanismo","success",{"id":350,"data":351,"type":42},"h-adr",{"text":352,"level":237},"¿Qué es un registro de decisión de arquitectura?",{"id":354,"data":355,"type":218},"p-adr-1",{"text":356},"Un registro de decisión de arquitectura es un registro compacto de una decisión de arquitectura importante. La formulación original de ADR de Michael Nygard enfatiza el \u003Cstrong>contexto\u003C\u002Fstrong>, la \u003Cstrong>decisión\u003C\u002Fstrong>, su \u003Cstrong>estado\u003C\u002Fstrong> y las \u003Cstrong>consecuencias\u003C\u002Fstrong> resultantes.",{"id":358,"data":359,"type":218},"p-adr-2",{"text":360},"El objeto importante es la decisión, no la plantilla. Diferentes equipos usan diferentes formatos de ADR. Un registro más completo también puede preservar alternativas, criterios de decisión, compensaciones, evidencia, enlaces a requisitos y la fecha o versión desde la cual aplica la decisión.",{"id":362,"data":363,"type":218},"p-adr-3",{"text":364},"ISO\u002FIEC\u002FIEEE 42010:2022 es más amplio que la práctica de ADR: especifica requisitos para las descripciones de arquitectura y sus conceptos, mientras que explícitamente no prescribe un proceso, notación, herramienta, formato o medio para registrar una descripción de arquitectura. Por lo tanto, un ADR es una técnica práctica de registro de decisiones, no un formato exigido por ISO 42010.",{"id":366,"data":367,"type":290},"adr-anatomy",{"content":368,"stretched":43,"withHeadings":14},[369,373,377,381,385,389,393,397],[370,371,372],"Campo del ADR","Qué preserva","Por qué importa",[374,375,376],"Contexto","El problema, las fuerzas, los requisitos, los supuestos y el entorno que rodean la elección","Los lectores futuros pueden reconstruir por qué una elección era necesaria",[378,379,380],"Decisión","La elección que se volvió autoritativa","Separa la opción seleccionada de la discusión",[382,383,384],"Estado","Propuesto, aceptado, rechazado, obsoleto, reemplazado u otro estado controlado","Evita que decisiones antiguas permanezcan activas silenciosamente",[386,387,388],"Alternativas","Otras opciones viables consideradas","Muestra que la solución seleccionada no era la única imaginable",[390,391,392],"Justificación \u002F compensaciones","Por qué se seleccionó la opción y qué sacrifica","Hace que el razonamiento arquitectónico sea inspeccionable",[394,395,396],"Consecuencias","Efectos positivos y negativos esperados, trabajo de seguimiento, riesgos","Conecta una elección local con el impacto en el sistema",[398,399,400],"Fecha \u002F versión","Cuándo la decisión se volvió válida","Apoya la trazabilidad histórica y el reemplazo posterior",{"id":402,"data":403,"type":42},"h-simple-example",{"text":404,"level":237},"El ejemplo más simple: requisito de latencia → decisión de arquitectura",{"id":406,"data":407,"type":218},"p-simple-1",{"text":408},"Supongamos que un propietario de producto y un equipo de ingeniería acuerdan que un endpoint de búsqueda debe devolver la primera página de resultados dentro de 400 ms en el percentil 95 bajo una carga de trabajo de referencia definida.",{"id":410,"data":411,"type":218},"p-simple-2",{"text":412},"Ese objetivo no es un ADR. Es un requisito de calidad. El trabajo de arquitectura comienza preguntando qué diseño puede satisfacerlo bajo las demás restricciones del sistema.",{"id":414,"data":415,"type":437},"simple-flow",{"steps":416,"title":435,"orientation":436},[417,420,423,426,429,432],{"label":418,"description":419},"1. Enunciar el requisito","Definir el objetivo de calidad, la carga de trabajo, el alcance, el umbral y el método de validación.",{"label":421,"description":422},"2. Identificar la relevancia arquitectónica","Determinar si el requisito influye materialmente en la estructura, la tecnología, el despliegue, el flujo de datos o el modelo operativo.",{"label":424,"description":425},"3. Evaluar opciones","Comparar alternativas como indexación, caché, desnormalización, trabajo asíncrono, particionamiento u otra arquitectura de consulta.",{"label":427,"description":428},"4. Registrar la decisión","Capturar la elección de arquitectura seleccionada, la justificación, las alternativas, las compensaciones, el estado y las consecuencias en un ADR.",{"label":430,"description":431},"5. Implementar","Convertir la decisión en código, infraestructura, configuración y comportamiento operativo.",{"label":433,"description":434},"6. Validar","Medir el sistema real contra el requisito original. El resultado de la prueba valida el NFR; el ADR por sí solo no lo hace.","Del requisito a la evidencia","auto","processFlow",{"id":439,"data":440,"type":225},"simple-stop",{"body":441,"title":442,"variant":443},"Los sistemas reales rara vez tienen un solo requisito y una sola decisión. El rendimiento puede compensarse con el costo, la consistencia, la operabilidad, la seguridad, la mantenibilidad, el uso de energía o el riesgo de entrega. Por lo tanto, el modelo útil es un grafo de trazabilidad, no un mapeo uno a uno.","Dónde se detiene el ejemplo simple","warning",{"id":445,"data":446,"type":42},"h-many-many",{"text":447,"level":237},"Los NFR y los ADR suelen tener una relación de muchos a muchos",{"id":449,"data":450,"type":218},"p-many-1",{"text":451},"Un requisito de calidad puede impulsar varias decisiones de arquitectura. Un requisito de aislamiento de inquilinos, por ejemplo, puede influir en la propagación de identidad, el alcance de la base de datos, el diseño de trabajos en segundo plano, las claves de caché, el registro de auditoría y las herramientas administrativas.",{"id":453,"data":454,"type":218},"p-many-2",{"text":455},"Una decisión de arquitectura también puede responder a varios requisitos a la vez. Elegir un límite de procesamiento asíncrono podría mejorar la capacidad de respuesta y el aislamiento de fallos, al tiempo que introduce compensaciones de consistencia, complejidad, observabilidad y operativas.",{"id":457,"data":458,"type":298},"relationship-map",{"rows":459,"title":488,"layout":290,"columns":489},[460,467,474,481],{"id":461,"label":462,"values":463},"one-many","Un NFR → muchos ADR",{"adr":464,"nfr":465,"validation":466},"Several coordinated decisions may be required","A broad quality target can constrain several architectural boundaries","Evidence may need multiple tests or measurements",{"id":468,"label":469,"values":470},"many-one","Muchos NFR → un ADR",{"adr":471,"nfr":472,"validation":473},"One decision may balance several drivers","Several quality and constraint drivers can point at the same design problem","Each requirement still needs its own acceptance evidence",{"id":475,"label":476,"values":477},"non-nfr","ADR sin un NFR clásico",{"adr":478,"nfr":479,"validation":480},"The choice can still be architecturally significant","The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition","Validate against the actual driver, not an invented NFR",{"id":482,"label":483,"values":484},"supersession","Requisito estable, el ADR cambia",{"adr":485,"nfr":486,"validation":487},"A better or necessary implementation choice can supersede the old decision","The target can remain unchanged","The new architecture must still be checked against the same target","Por qué la relación no es uno a uno",[490,492,494],{"id":293,"label":491},"Lado del requisito",{"id":296,"label":493},"Lado de la decisión",{"id":495,"label":496},"validation","Lado de la validación",{"id":498,"data":499,"type":42},"h-technology",{"text":500,"level":237},"Una elección de tecnología no es automáticamente un requisito",{"id":502,"data":503,"type":218},"p-tech-1",{"text":504},"Un error recurrente de arquitectura es escribir una tecnología preferida en la capa de requisitos y luego tratar el diseño resultante como inevitable.",{"id":506,"data":507,"type":218},"p-tech-2",{"text":508},"«El sistema debe usar PostgreSQL» puede ser una restricción legítima si un contrato, una política de plataforma, un requisito de compatibilidad, una regla de licenciamiento, un estándar organizacional o un límite operativo existente realmente exigen PostgreSQL. Pero si la necesidad real es la consistencia transaccional, las consultas estructuradas, la familiaridad operativa o un objetivo de recuperación específico, el requisito debe enunciar esa necesidad y la selección de tecnología debe registrarse como una decisión.",{"id":510,"data":511,"type":290},"tech-table",{"content":512,"stretched":43,"withHeadings":14},[513,517,521,525,529,533,537],[514,515,516],"Declaración","Clasificación","Razón",[518,519,520],"Todas las lecturas con alcance de inquilino deben aplicar aislamiento de inquilinos","Requisito \u002F propiedad de seguridad","Describe una propiedad que debe cumplirse",[522,523,524],"Usar Row Level Security de PostgreSQL para tablas seleccionadas con alcance de inquilino","Decisión de arquitectura","Elige un mecanismo destinado a ayudar a satisfacer la propiedad de aislamiento",[526,527,528],"El destino de despliegue debe ejecutarse en un entorno aprobado operado en la UE","Restricción \u002F condición operativa similar a un NFR","Restringe dónde puede operar el sistema",[530,531,532],"Usar el proveedor X en la región Y","Decisión de arquitectura \u002F despliegue a menos que esté impuesto externamente","Selecciona una solución particular dentro del límite permitido",[534,535,536],"Latencia de API en el percentil 95 ≤ 300 ms bajo la carga de trabajo W","Requisito de calidad","Define un comportamiento de rendimiento medible",[538,523,539],"Introducir una caché para el endpoint X","Selecciona una táctica destinada a mejorar el comportamiento medido",{"id":541,"data":542,"type":42},"h-adr-proof",{"text":543,"level":237},"Un ADR no es prueba de que se haya satisfecho un NFR",{"id":545,"data":546,"type":218},"p-proof-1",{"text":547},"La documentación de decisiones y la validación del sistema responden a preguntas diferentes. Un ADR puede mostrar que se consideraron el rendimiento, la seguridad, la resiliencia o la mantenibilidad. Por sí solo no puede demostrar que el sistema entregado realmente alcanza esas propiedades.",{"id":549,"data":550,"type":218},"p-proof-2",{"text":551},"La prueba debe provenir del método de validación apropiado para el requisito: benchmark, prueba de carga, prueba de fallos, prueba de seguridad, análisis de arquitectura, auditoría, inspección, telemetría operativa, ejercicio de recuperación, estudio de usuarios u otra forma de evidencia.",{"id":553,"data":554,"type":225},"proof-rule",{"body":555,"title":556,"variant":443},"\u003Cstrong>ADR:\u003C\u002Fstrong> \"Seleccionamos el diseño X porque se espera que satisfaga el requisito R bajo los supuestos A.\"\u003Cbr>\u003Cstrong>Validación:\u003C\u002Fstrong> \"La evidencia medida o analizada E muestra si el sistema implementado realmente satisface R.\"","No confundas la intención con la evidencia",{"id":558,"data":559,"type":42},"h-asr",{"text":560,"level":237},"¿Cuándo se convierte un RNF en arquitectónicamente significativo?",{"id":562,"data":563,"type":218},"p-asr-1",{"text":564},"No todos los requisitos no funcionales merecen una decisión de arquitectura. El subconjunto importante son los requisitos que moldean materialmente la arquitectura o fuerzan compensaciones en todo el sistema.",{"id":566,"data":567,"type":218},"p-asr-2",{"text":568},"La literatura del SEI utiliza el concepto de \u003Cstrong>requisitos arquitectónicamente significativos\u003C\u002Fstrong> para requisitos con un efecto arquitectónico de gran alcance. Los atributos de calidad como el rendimiento, la fiabilidad, la seguridad y la modificabilidad son fuentes frecuentes de tales impulsores, especialmente cuando conllevan un alto valor empresarial o de misión.",{"id":570,"data":571,"type":437},"asr-test",{"steps":572,"title":591,"orientation":436},[573,576,579,582,585,588],{"label":574,"description":575},"1. Preguntar si el requisito cambia la estructura","¿Forzarían valores diferentes componentes, límites, rutas de datos o topología de despliegue distintos?",{"label":577,"description":578},"2. Preguntar si restringe decisiones tecnológicas importantes","¿Elimina opciones de implementación que de otro modo serían viables?",{"label":580,"description":581},"3. Preguntar si crea un comportamiento transversal","¿Afecta a muchos componentes, equipos, interfaces o etapas del ciclo de vida?",{"label":583,"description":584},"4. Preguntar si crea una compensación difícil","¿Mejorar esta propiedad afecta materialmente a otra calidad, costo, cronograma, complejidad o riesgo?",{"label":586,"description":587},"5. Preguntar si el fallo es costoso","¿Incumplir el requisito crearía un impacto operativo, de seguridad, regulatorio, financiero o de producto material?",{"label":589,"description":590},"6. Registrar decisiones solo donde vale la pena preservar el razonamiento","No crees ADR para cada elección local de codificación; preserva las decisiones arquitectónicamente significativas y su justificación.","Prueba de significancia arquitectónica",{"id":593,"data":594,"type":42},"h-traceability",{"text":595,"level":237},"Un modelo de arquitectura más sólido: requisito → decisión → implementación → validación",{"id":597,"data":598,"type":218},"p-trace-1",{"text":599},"La conexión más útil entre los RNF y los ADR es la trazabilidad. Un requisito debería poder señalar las decisiones de arquitectura que lo abordan; un ADR debería identificar los impulsores a los que responde; el trabajo de implementación debería realizar la decisión; la validación debería volver al requisito original.",{"id":601,"data":602,"type":437},"trace-flow",{"steps":603,"title":628,"orientation":436},[604,607,610,613,616,619,622,625],{"label":605,"description":606},"Necesidad \u002F objetivo de negocio","Por qué importa la calidad o la restricción.",{"label":608,"description":609},"Requisito \u002F RNF","Qué debe lograr o respetar el sistema.",{"label":611,"description":612},"Impulsores de arquitectura","Qué requisitos son lo suficientemente significativos como para dar forma al diseño.",{"label":614,"description":615},"Opciones","Formas plausibles de abordar el impulsor.",{"label":617,"description":618},"ADR","La elección seleccionada, la justificación, las alternativas, las compensaciones y las consecuencias.",{"label":620,"description":621},"Implementación","Código, modelo de datos, infraestructura, interfaces y mecanismos operativos que realizan la decisión.",{"label":623,"description":624},"Evidencia de validación","Pruebas, mediciones, análisis o auditorías que demuestran si el requisito original se satisface realmente.",{"label":626,"description":627},"Cambio \u002F sustitución","Nueva evidencia o requisitos modificados pueden desencadenar un nuevo ADR mientras se preserva el razonamiento histórico.","Cadena de trazabilidad de arquitectura",{"id":630,"data":631,"type":42},"h-senseflow",{"text":632,"level":237},"Evidencia de implementación: cómo separo requisitos y decisiones en SenseFlow",{"id":634,"data":635,"type":225},"senseflow-evidence",{"body":636,"title":637,"variant":231},"La siguiente sección describe la estructura de mi propio proyecto SenseFlow. Es evidencia de implementación para la separación en este artículo, no una afirmación de que cada equipo deba usar el mismo modelo de documentación.","Evidencia de implementación \u002F proyecto original",{"id":639,"data":640,"type":218},"p-sense-1",{"text":641},"En SenseFlow, la Fuente de Verdad del proyecto coloca explícitamente los requisitos no funcionales dentro de la estructura de requisitos junto con dependencias, riesgos, supuestos, criterios de aceptación y un método de validación. El modelo de documentación define por separado la integridad de las decisiones para decisiones significativas.",{"id":643,"data":644,"type":218},"p-sense-2",{"text":645},"Para decisiones significativas de SenseFlow, los campos registrados son \u003Cstrong>Decisión, Razón, Alternativas, Compensaciones, Estado y Fecha \u002F Versión\u003C\u002Fstrong>. Las decisiones importantes de arquitectura y producto están destinadas a permanecer históricamente trazables en lugar de ser sobrescritas cuando el proyecto evoluciona.",{"id":647,"data":648,"type":218},"p-sense-3",{"text":649},"SenseFlow también asigna roles operativos diferentes a Confluence y Jira. Confluence es el entorno estructurado de conocimiento y decisiones; Jira gestiona el trabajo de entrega accionable. Las Epics importantes de Jira deberían enlazar de vuelta a la documentación relevante de producto o requisitos. Esto preserva la cadena desde la intención del producto a través de los requisitos y las decisiones hasta la implementación, en lugar de convertir el backlog en la Fuente de Verdad de la arquitectura.",{"id":651,"data":652,"type":290},"senseflow-table",{"content":653,"stretched":43,"withHeadings":14},[654,658,662,666,670,674,678],[655,656,657],"Capa de SenseFlow","Qué contiene","Rol en la separación ADR\u002FRNF",[659,660,661],"Estructura de producto \u002F requisitos","Objetivo de producto, capacidad, epic, historia de usuario, criterios de aceptación, tareas técnicas; los requisitos pueden incluir RNF y método de validación","Preserva qué debe lograrse y cómo se verificará el éxito",[663,664,665],"Integridad de decisiones","Decisión, razón, alternativas, compensaciones, estado, fecha\u002Fversión","Preserva por qué una elección arquitectónicamente significativa se volvió autoritativa",[667,668,669],"Confluence","Requisitos, arquitectura, investigación, registros de decisiones, riesgos, hoja de ruta y fuentes de apoyo","Mantiene la Fuente de Verdad conceptual e histórica",[671,672,673],"Jira","Iniciativas\u002Fobjetivos, epics, historias, tareas y estado de entrega","Ejecuta el trabajo aprobado sin convertirse en la Fuente de Verdad conceptual",[675,676,677],"Gestión de cambios","Estado actual → nueva evidencia → cambio propuesto → impacto → decisión","Permite que las decisiones evolucionen sin borrar el rastro del razonamiento",[679,680,681],"Trazabilidad de extremo a extremo","Problema → necesidad → valor → objetivo de producto → requisito → implementación → validación","Mantiene la documentación de decisiones conectada al producto real y al ciclo de vida de la evidencia",{"id":683,"data":684,"type":225},"senseflow-lesson",{"body":685,"title":686,"variant":348},"Un requisito y una decisión pueden vivir cerca sin colapsarse en un solo registro. El requisito sigue siendo el objetivo; la decisión sigue siendo el historial de razonamiento; el trabajo de entrega implementa la decisión; la validación vuelve al objetivo.","Qué demuestra esta implementación",{"id":688,"data":689,"type":42},"h-enterprise",{"text":690,"level":237},"Contexto de proyecto empresarial: los requisitos deben preceder a las elecciones de arquitectura",{"id":692,"data":693,"type":218},"p-enterprise-1",{"text":694},"La misma separación es útil en el trabajo de proyectos orientados a la empresa. Las decisiones de arquitectura tomadas antes de que los requisitos, riesgos, restricciones y condiciones de aceptación se comprendan suficientemente pueden convertir las preferencias en falsas necesidades.",{"id":696,"data":697,"type":218},"p-enterprise-2",{"text":698},"Para Enterprise Aaasaasa 0.1, la lección relevante es metodológica más que una afirmación sobre un ADR particular: los requisitos, la arquitectura, la validación, los hitos, la gestión de riesgos y la aceptación pertenecen a un sistema de entrega conectado. Una elección de arquitectura debe permanecer trazable al requisito o restricción que pretende abordar.",{"id":700,"data":701,"type":42},"h-failures",{"text":702,"level":237},"Modos de fallo comunes cuando se mezclan ADR y NFR",{"id":704,"data":705,"type":290},"failure-table",{"content":706,"stretched":43,"withHeadings":14},[707,711,715,719,723,727,731,735,739],[708,709,710],"Modo de fallo","Qué sucede","Consecuencia",[712,713,714],"Tecnología disfrazada de requisito","Se escribe una solución preferida como “debe usar X” sin establecer la necesidad subyacente","Nunca se evalúan alternativas y la arquitectura se fija prematuramente",[716,717,718],"NFR oculto solo dentro de un ADR","La decisión menciona un objetivo de rendimiento\u002Fseguridad que está ausente de la línea base de requisitos","El objetivo es difícil de validar, priorizar o gestionar de forma independiente",[720,721,722],"ADR tratado como prueba","Se asume que una elección documentada significa que el requisito está satisfecho","La intención arquitectónica reemplaza la medición o la verificación",[724,725,726],"NFR vago","Palabras como rápido, escalable, seguro o mantenible no tienen un alcance medible","Diferentes partes interesadas pueden creer que el mismo requisito significa cosas distintas",[728,729,730],"Sin alternativas registradas","El equipo registra solo la tecnología seleccionada","Los futuros mantenedores no pueden reconstruir por qué se rechazó otra opción",[732,733,734],"Sin modelo de sustitución","Los ADR antiguos se editan o eliminan cuando cambia la arquitectura","El razonamiento histórico desaparece y las decisiones obsoletas pueden quedar ambiguas",[736,737,738],"Cada detalle de implementación se convierte en un ADR","El repositorio se llena de registros de bajo valor","Las decisiones arquitectónicas importantes se vuelven difíciles de encontrar",[740,741,742],"El backlog se convierte en la fuente de verdad de la arquitectura","Las tareas de Jira se tratan como la única explicación del sistema","El estado de entrega sobrevive, pero se pierden la justificación arquitectónica y los impulsores de calidad",{"id":744,"data":745,"type":42},"h-decision-framework",{"text":746,"level":237},"El marco de decisión ADR–NFR",{"id":748,"data":749,"type":218},"p-framework-1",{"text":750},"Cuando un equipo se encuentra con una nueva preocupación arquitectónica, la siguiente secuencia ayuda a determinar qué pertenece a los requisitos, qué pertenece a un ADR y qué pertenece a la evidencia.",{"id":752,"data":753,"type":437},"decision-flow",{"steps":754,"title":779,"orientation":436},[755,758,761,764,767,770,773,776],{"label":756,"description":757},"1. ¿Es una propiedad requerida o una restricción externa?","Si es así, escriba o haga referencia al requisito antes de elegir un mecanismo.",{"label":759,"description":760},"2. ¿Se puede validar?","Defina el alcance, la condición, la métrica, la regla de aceptación, el método de análisis u otra evidencia necesaria.",{"label":762,"description":763},"3. ¿Es arquitectónicamente significativo?","Identifique si el requisito moldea materialmente la estructura, la tecnología, los datos, el despliegue o las compensaciones transversales.",{"label":765,"description":766},"4. ¿Existen alternativas significativas?","Compare tácticas u opciones de arquitectura viables en lugar de saltar directamente a una tecnología preferida.",{"label":768,"description":769},"5. ¿Se ha vuelto autoritativa una elección?","Cree o actualice el ADR con contexto, decisión, justificación, alternativas, compensaciones, estado y consecuencias.",{"label":771,"description":772},"6. ¿Está implementada la decisión?","Rastree el ADR hasta el diseño, las tareas, el código, la configuración y las operaciones.",{"label":774,"description":775},"7. ¿Está satisfecho el requisito?","Recopile evidencia de validación contra el requisito mismo.",{"label":777,"description":778},"8. ¿Cambiaron las condiciones?","Vuelva a evaluar el requisito y, cuando sea necesario, sustituya el ADR sin borrar el historial.","Prueba de clasificación ADR–NFR",{"id":781,"data":782,"type":42},"h-what-not",{"text":783,"level":237},"Lo que ADR y NFR no son",{"id":785,"data":786,"type":298},"not-comparison",{"rows":787,"title":819,"layout":290,"columns":820},[788,794,799,805,812],{"id":293,"label":789,"values":790},"NFR \u002F requisito de calidad",{"not":791,"why":792,"term":793},"A technology shopping list","Requirements should preserve the need independently from one implementation when possible","A required quality, constraint or operating condition",{"id":296,"label":617,"values":795},{"not":796,"why":797,"term":798},"The complete architecture description","Architecture also needs views, interfaces, models, responsibilities and other documentation","A record of an architecturally significant decision",{"id":800,"label":623,"values":801},"test",{"not":802,"why":803,"term":804},"The ADR itself","Documented intent is different from measured or analyzed system behavior","Evidence that checks whether a requirement is satisfied",{"id":806,"label":807,"values":808},"backlog","Elemento del backlog",{"not":809,"why":810,"term":811},"A durable substitute for architecture rationale","Task state answers what is being delivered, not necessarily why the architecture exists","Actionable delivery work",{"id":813,"label":814,"values":815},"constraint","Restricción",{"not":816,"why":817,"term":818},"Always an internally chosen architecture decision","Some constraints come from regulation, contracts, existing platforms or organizational boundaries","A condition that restricts the solution space","Errores de categoría comunes",[821,824,827],{"id":822,"label":823},"term","Concepto",{"id":825,"label":826},"not","No es",{"id":828,"label":516},"why",{"id":830,"data":831,"type":42},"h-change",{"text":832,"level":237},"Qué cambiaría esta respuesta",{"id":834,"data":835,"type":218},"p-change-1",{"text":836},"La terminología puede evolucionar. ISO\u002FIEC\u002FIEEE 29148:2018 sigue siendo el estándar de ingeniería de requisitos publicado vigente a 8 de octubre de 2026, pero ISO enumera un Proyecto de Norma Internacional destinado a reemplazarlo. Si la nueva edición cambia la terminología relevante o la guía de requisitos, las referencias específicas de la versión en este artículo deberían actualizarse.",{"id":838,"data":839,"type":218},"p-change-2",{"text":840},"Las plantillas de ADR también pueden evolucionar sin cambiar la distinción central. La plantilla mínima de Michael Nygard, MADR, plantillas específicas de la organización, herramientas de conocimiento arquitectónico o bases de datos de decisiones estructuradas pueden registrar decisiones. La pregunta duradera es si el registro conserva suficiente contexto y justificación para comprender una elección arquitectónicamente significativa.",{"id":842,"data":843,"type":218},"p-change-3",{"text":844},"La distinción solo colapsaría si una organización eligiera deliberadamente un artefacto combinado que almacene tanto datos de requisitos como de decisiones en un solo documento. Incluso entonces, los roles semánticos siguen siendo diferentes: un campo establece el resultado o la restricción requeridos; otro registra la respuesta elegida.",{"id":846,"data":847,"type":42},"h-limitations",{"text":848,"level":237},"Limitaciones",{"id":850,"data":851,"type":218},"p-limit-1",{"text":852},"Este artículo usa \u003Cstrong>NFR\u003C\u002Fstrong> como abreviatura práctica. Algunos métodos de ingeniería prefieren términos como requisito de atributo de calidad, requisito de calidad, calidad del sistema, restricción, objetivo de nivel de servicio o requisito arquitectónicamente significativo. Esos términos no son perfectamente intercambiables, y la terminología del proyecto debe ser explícita.",{"id":854,"data":855,"type":218},"p-limit-2",{"text":856},"No todos los requisitos pueden reducirse a un único umbral numérico. La seguridad, la protección, la mantenibilidad, la interoperabilidad, la usabilidad, la explicabilidad, la portabilidad y la gobernanza pueden requerir combinaciones de escenarios, reglas estructurales, análisis, controles de proceso y evidencia cualitativa. “Medible” debería significar suficientemente verificable para la decisión, no artificialmente numérico.",{"id":858,"data":859,"type":218},"p-limit-3",{"text":860},"No toda decisión de arquitectura necesita un ADR formal. El costo de documentación debe ser proporcional a la importancia arquitectónica, la longevidad, la incertidumbre, la complejidad de las compensaciones y el costo de perder la justificación.",{"id":862,"data":863,"type":42},"h-conclusion",{"text":864,"level":237},"Conclusión",{"id":866,"data":867,"type":218},"p-conclusion-1",{"text":868},"ADR y NFR pertenecen a capas diferentes del trabajo de arquitectura. \u003Cstrong>El NFR define un objetivo de calidad, una restricción o una condición operativa. El ADR registra una respuesta arquitectónica significativa a uno o más impulsores.\u003C\u002Fstrong>",{"id":870,"data":871,"type":218},"p-conclusion-2",{"text":872},"Mantener esas capas separadas hace que la arquitectura sea más fácil de razonar. Los requisitos pueden validarse independientemente de la tecnología. Las decisiones pueden sustituirse sin reescribir el historial. Las alternativas y las compensaciones permanecen visibles. El trabajo de entrega puede rastrearse hasta la intención arquitectónica. La evidencia puede mostrar si el sistema resultante satisface realmente el requisito.",{"id":874,"data":875,"type":218},"p-conclusion-3",{"text":876},"La cadena más sólida, por lo tanto, no es “NFR → ADR → hecho”. Es \u003Cstrong>necesidad → requisito → impulsores arquitectónicos → opciones → decisión → implementación → validación → cambio\u003C\u002Fstrong>. Esa cadena convierte la documentación de arquitectura de papeleo estático en un registro comprobable de por qué el sistema tiene la forma que tiene.",{"id":878,"data":879,"type":42},"h-faq",{"text":880,"level":237},"Preguntas frecuentes",{"id":882,"data":883,"type":882},"faq",{"items":884,"title":913},[885,889,893,897,901,905,909],{"id":886,"answer":887,"question":888},"faq1","No. Un NFR establece una cualidad, restricción o condición operativa requerida. Un ADR registra una elección arquitectónicamente significativa hecha en respuesta a requisitos, restricciones, riesgos y compensaciones.","¿Es un ADR un requisito no funcional?",{"id":890,"answer":891,"question":892},"faq2","No. Solo los requisitos que influyen materialmente en la arquitectura necesitan decisiones a nivel de arquitectura que merezca la pena preservar. Un NFR también puede impulsar varios ADR, y un ADR puede responder a varios requisitos.","¿Debería cada NFR tener un ADR?",{"id":894,"answer":895,"question":896},"faq3","Solo cuando PostgreSQL se impone genuinamente como una restricción externa. De lo contrario, la necesidad subyacente debería expresarse primero, y seleccionar PostgreSQL normalmente debería tratarse como una decisión de arquitectura.","¿Puede “usar PostgreSQL” ser un NFR?",{"id":898,"answer":899,"question":900},"faq4","No. Un ADR registra la intención y el razonamiento. El requisito se valida mediante evidencia apropiada, como pruebas, medición, análisis, auditoría o telemetría operativa.","¿Demuestra un ADR que se cumple un requisito de rendimiento o seguridad?",{"id":902,"answer":903,"question":904},"faq5","Como mínimo, un ADR debería dejar claros el contexto y la decisión. Las estructuras comunes también incluyen estado y consecuencias. Los equipos pueden añadir alternativas, justificación, compensaciones, enlaces a requisitos, evidencia, responsables, fechas y relaciones de sustitución.","¿Qué debería contener un ADR?",{"id":906,"answer":907,"question":908},"faq6","Un requisito es arquitectónicamente significativo cuando da forma material a la estructura del sistema, la tecnología, los flujos de datos, el despliegue, el comportamiento transversal o compensaciones de calidad difíciles, especialmente cuando el fallo conlleva un alto impacto empresarial o de misión.","¿Qué hace que un NFR sea arquitectónicamente significativo?",{"id":910,"answer":911,"question":912},"faq7","Normalmente no. Una decisión de reemplazo debería normalmente sustituir el registro antiguo para que el razonamiento histórico siga siendo rastreable.","¿Debería eliminarse un ADR antiguo cuando cambia la arquitectura?","ADR vs NFR",{"id":915,"data":916,"type":42},"h-glossary",{"text":917,"level":237},"Glosario",{"id":919,"data":920,"type":919},"glossary",{"title":921,"entries":922},"Términos centrales de arquitectura",[923,926,930,933,937,939,943,946],{"term":924,"anchor":293,"definition":925},"NFR","Requisito no funcional: abreviatura práctica para una cualidad, restricción o condición operativa requerida del sistema; la terminología exacta varía según el método y el estándar.",{"term":927,"anchor":928,"definition":929},"Requisito de atributo de calidad","quality-attribute-requirement","Un requisito que describe una propiedad de calidad que se espera que el sistema exhiba bajo condiciones definidas, como rendimiento, disponibilidad, seguridad, fiabilidad o modificabilidad.",{"term":931,"anchor":296,"definition":932},"Registro de decisión de arquitectura (ADR)","Un registro duradero de una decisión arquitectónicamente significativa y suficiente contexto para entender por qué se tomó la elección y qué consecuencias se derivan.",{"term":934,"anchor":935,"definition":936},"Requisito arquitectónicamente significativo (ASR)","asr","Un requisito con un impacto arquitectónico suficientemente amplio como para influir materialmente en el diseño del sistema.",{"term":814,"anchor":813,"definition":938},"Una condición que restringe el espacio de solución, incluidos límites externos de política, regulación, plataforma, compatibilidad, contractuales u organizativos.",{"term":940,"anchor":941,"definition":942},"Compensación","trade-off","Una relación de diseño en la que mejorar un objetivo, propiedad o dimensión de coste puede empeorar otra.",{"term":944,"anchor":495,"definition":945},"Validación","Trabajo que produce evidencia utilizado para determinar si el sistema implementado satisface el requisito declarado bajo las condiciones relevantes.",{"term":947,"anchor":948,"definition":949},"ADR sustituido","superseded-adr","Un registro histórico de decisión que ha sido reemplazado por una decisión autoritativa más reciente, pero que sigue disponible para trazabilidad.",{"id":951,"data":952,"type":42},"h-sources",{"text":953,"level":237},"Fuentes primarias y evidencia de implementación",{"id":955,"data":956,"type":218},"p-sources-note",{"text":957},"Este artículo separa los estándares actuales de la evidencia de implementación del proyecto. ISO\u002FIEC\u002FIEEE 29148:2018 sigue vigente a 8 de octubre de 2026, pero está marcado para revisión; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 son ediciones publicadas vigentes. SenseFlow es evidencia original del proyecto para el modelo de trazabilidad e integridad de decisiones descrito anteriormente.",{"id":959,"data":960,"type":967},"src-iso-29148",{"link":961,"meta":962},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html",{"image":963,"title":965,"description":966},{"url":964},"","ISO\u002FIEC\u002FIEEE 29148:2018 — Ingeniería de requisitos","Estándar de ingeniería de requisitos publicado vigente. ISO indica que la edición de 2018 fue revisada y confirmada en 2024 y se espera que sea reemplazada por el DIS actualmente en desarrollo.","linkTool",{"id":969,"data":970,"type":967},"src-iso-29148-dis",{"link":971,"meta":972},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html",{"image":973,"title":974,"description":975},{"url":964},"ISO\u002FIEC\u002FIEEE DIS 29148 — Ingeniería de requisitos","Borrador de Norma Internacional actualmente en desarrollo y destinado a reemplazar ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":977,"data":978,"type":967},"src-iso-25010",{"link":979,"meta":980},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html",{"image":981,"title":982,"description":983},{"url":964},"ISO\u002FIEC 25010:2023 — Modelo de calidad del producto","Modelo de calidad del producto vigente con nueve características de calidad utilizadas para especificar, medir y evaluar la calidad de productos TIC y de software.",{"id":985,"data":986,"type":967},"src-iso-42010",{"link":987,"meta":988},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":989,"title":990,"description":991},{"url":964},"ISO\u002FIEC\u002FIEEE 42010:2022 — Descripción de arquitectura","Estándar de descripción de arquitectura vigente. Especifica conceptos de descripción de arquitectura y requisitos de conformidad sin prescribir un único formato de registro, notación, proceso o herramienta.",{"id":993,"data":994,"type":967},"src-nygard",{"link":995,"meta":996},"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions",{"image":997,"title":998,"description":999},{"url":964},"Michael Nygard — Documentar decisiones de arquitectura","Artículo original influyente sobre ADR que describe registros ligeros centrados en contexto, decisión, estado y consecuencias, con decisiones sustituidas conservadas para la comprensión histórica.",{"id":1001,"data":1002,"type":967},"src-sei-asr",{"link":1003,"meta":1004},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F",{"image":1005,"title":1006,"description":1007},{"url":964},"SEI — Relacionar objetivos de negocio con requisitos arquitectónicamente significativos","Informe del SEI que explica cómo los requisitos de atributos de calidad y los objetivos de negocio impulsan la arquitectura de software y por qué los requisitos arquitectónicamente significativos necesitan una elicitación explícita.",{"id":1009,"data":1010,"type":967},"src-sei-nfr",{"link":1011,"meta":1012},"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F",{"image":1013,"title":1014,"description":1015},{"url":964},"SEI — Definir cualidades no funcionales del sistema","Resumen del SEI que conecta atributos no funcionales\u002Fde calidad con arquitectura, escenarios, compensaciones y evaluación objetiva del sistema.",{"id":1017,"data":1018,"type":967},"src-sei-add",{"link":1019,"meta":1020},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F",{"image":1021,"title":1022,"description":1023},{"url":964},"SEI — Colección del método de diseño guiado por atributos","Método de diseño de arquitectura basado en requisitos funcionales, requisitos de atributos de calidad y restricciones, con tácticas y patrones arquitectónicos seleccionados para satisfacer escenarios de calidad.",{"id":1025,"data":1026,"type":967},"src-sei-doc",{"link":1027,"meta":1028},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F",{"image":1029,"title":1030,"description":1031},{"url":964},"SEI — Colección Views and Beyond","Guía de documentación de arquitectura que enfatiza las vistas relevantes y el registro de las decisiones de diseño necesarias como parte del trabajo de arquitectura.","2.31","ADR vs NFR explicado: aprende cómo los requisitos de calidad del sistema impulsan las decisiones de arquitectura, cómo los ADR registran las compensaciones y por qué la validación se mantiene separada.","\u002Fuploads\u002F2026\u002F10\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing-1791475921511-6zgen1.webp","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing-1791475921511-6zgen1","PUBLISHED","2026-10-08T12:11:00.000Z","2026-10-08T16:11:31.560Z","2026-10-08T17:31:47.443Z",{"en":1041,"de":1042,"sr":1043,"es":1044,"fr":1045,"it":1046,"ru":1047,"zh":1048},"\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fde\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fsr\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fes\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Ffr\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fit\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fru\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fzh\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing",[1050,1054,1058,1062,1066],{"id":1051,"name":1052,"slug":1053},72,"Criterios de aceptación","acceptance-criteria",{"id":1055,"name":1056,"slug":1057},67,"KPI y criterios de aceptación","kpis",{"id":1059,"name":1060,"slug":1061},77,"Medición y monitoreo","measurement",{"id":1063,"name":1064,"slug":1065},76,"Presupuestos de rendimiento","budgets",{"id":1067,"name":1068,"slug":1069},68,"Riesgos, controles y evidencias","risks-and-controls",{"id":1071,"login":1072,"email":1073,"displayName":1074},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1076,1719],{"lang":1077,"title":1078,"content":1079,"contentJson":1080,"excerpt":1718},"en","ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing","{\"time\":1791475659420,\"blocks\":[{\"id\":\"intro\",\"data\":{\"text\":\"An \u003Cstrong>non-functional requirement (NFR)\u003C\u002Fstrong> describes a quality, constraint, or operating condition the system is expected to satisfy. An \u003Cstrong>architecture decision record (ADR)\u003C\u002Fstrong> records an architecturally significant choice made in response to requirements, constraints, risks, and trade-offs. They are connected, but they are not interchangeable: an NFR states what must be true; an ADR explains what was decided, why, and with what consequences.\"},\"type\":\"paragraph\"},{\"id\":\"direct\",\"data\":{\"body\":\"\u003Cstrong>NFR = required system quality or constraint. ADR = recorded architecture decision.\u003C\u002Fstrong> A latency target, availability objective, isolation rule, deployment restriction, or maintainability requirement can influence architecture. An ADR then records a significant choice made to address one or more such drivers. The ADR does not replace the requirement, and the existence of an ADR does not prove that the requirement has been satisfied.\",\"title\":\"Direct answer\",\"variant\":\"info\"},\"type\":\"callout\"},{\"id\":\"version-note\",\"data\":{\"body\":\"The term \u003Cstrong>NFR\u003C\u002Fstrong> is widely used but not perfectly standardized. This article uses it as practical shorthand for quality requirements and relevant constraints. Current standards were re-checked on \u003Cstrong>8 October 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 remains current but is under revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are the current published editions cited here.\",\"title\":\"Terminology and standards note\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"toc\",\"data\":{\"title\":\"Contents\",\"maxLevel\":3,\"minLevel\":2},\"type\":\"tableOfContents\"},{\"id\":\"h-meaning\",\"data\":{\"text\":\"What is the difference between an NFR and an ADR?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-meaning-1\",\"data\":{\"text\":\"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-2\",\"data\":{\"text\":\"For example, \u003Cstrong>“The API must return 95% of read requests within 300 ms under the agreed reference load”\u003C\u002Fstrong> is a quality requirement. \u003Cstrong>“Use a read-through cache for this workload because the measured database-only path cannot meet the latency target without unacceptable cost”\u003C\u002Fstrong> is an architecture decision.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-3\",\"data\":{\"text\":\"The first statement remains valid even if the implementation changes. The second statement can later be superseded by another decision if the workload, technology, cost model, or evidence changes.\"},\"type\":\"paragraph\"},{\"id\":\"basic-difference\",\"data\":{\"rows\":[{\"id\":\"question\",\"label\":\"Primary question\",\"values\":{\"adr\":\"What architecturally significant choice did we make, and why?\",\"nfr\":\"What quality, constraint, or operating condition must the system satisfy?\"}},{\"id\":\"content\",\"label\":\"Typical content\",\"values\":{\"adr\":\"Context, decision, rationale, alternatives, trade-offs, status and consequences\",\"nfr\":\"Measurable target, scope, condition, constraint, acceptance or validation rule\"}},{\"id\":\"lifecycle\",\"label\":\"Lifecycle role\",\"values\":{\"adr\":\"A historical record of a significant decision\",\"nfr\":\"A requirement to design for and validate\"}},{\"id\":\"evidence\",\"label\":\"What proves it?\",\"values\":{\"adr\":\"The record proves what was decided, not that the resulting system meets the requirement\",\"nfr\":\"Measurement, test, analysis, inspection, audit or other validation evidence\"}},{\"id\":\"change\",\"label\":\"When it changes\",\"values\":{\"adr\":\"When the decision is replaced, rejected, deprecated, or superseded\",\"nfr\":\"When stakeholder need, operating conditions, policy or quality target changes\"}}],\"title\":\"NFR and ADR answer different questions\",\"layout\":\"table\",\"columns\":[{\"id\":\"nfr\",\"label\":\"NFR \u002F quality requirement\"},{\"id\":\"adr\",\"label\":\"ADR \u002F architecture decision\"}]},\"type\":\"comparison\"},{\"id\":\"h-nfr\",\"data\":{\"text\":\"What is an NFR in precise architectural terms?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-nfr-1\",\"data\":{\"text\":\"“Non-functional requirement” is a convenient industry label, but it can hide several different kinds of statements. In architecture work, the useful distinction is between \u003Cstrong>functional behavior\u003C\u002Fstrong>, \u003Cstrong>quality requirements\u003C\u002Fstrong>, and \u003Cstrong>constraints\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-nfr-2\",\"data\":{\"text\":\"ISO\u002FIEC 25010:2023 provides a product-quality model with nine characteristics and subcharacteristics that can be used when specifying and evaluating ICT and software product quality. SEI architecture work similarly treats quality attribute requirements as major drivers of software architecture.\"},\"type\":\"paragraph\"},{\"id\":\"p-nfr-3\",\"data\":{\"text\":\"A useful NFR is therefore not “the system should be fast” or “the platform must be secure.” Those statements name aspirations. An architecture-driving requirement should make the expected property testable enough that design alternatives and later evidence can be evaluated against it.\"},\"type\":\"paragraph\"},{\"id\":\"nfr-examples\",\"data\":{\"content\":[[\"Weak statement\",\"More useful requirement shape\",\"Why the difference matters\"],[\"The API must be fast\",\"For workload W, 95% of operation X completes within T milliseconds\",\"Defines workload, operation, metric and threshold\"],[\"The service must be available\",\"Service S meets an agreed availability objective over measurement window M, excluding explicitly defined maintenance conditions\",\"Makes availability measurable and defines scope\"],[\"Tenant data must be secure\",\"A request authenticated for tenant A must never retrieve or mutate tenant B data through supported application paths\",\"Turns a vague security goal into an isolation property\"],[\"The system should scale\",\"The system supports workload W at concurrency C while meeting latency and error-rate thresholds\",\"Connects scale to measurable service behavior\"],[\"We need PostgreSQL\",\"Not an NFR by itself; state the required persistence qualities or external constraint first\",\"A technology choice is normally a solution, not the requirement it is meant to satisfy\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"nfr-rule\",\"data\":{\"body\":\"If “use Kubernetes,” “use PostgreSQL,” “use microservices,” or “use vector search” appears as the requirement, ask whether it is truly an external constraint or whether the solution has been written down before the underlying quality need was made explicit.\",\"title\":\"A requirement should describe the need before the mechanism\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-adr\",\"data\":{\"text\":\"What is an Architecture Decision Record?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-adr-1\",\"data\":{\"text\":\"An Architecture Decision Record is a compact record of an important architecture decision. Michael Nygard’s original ADR formulation emphasizes the \u003Cstrong>context\u003C\u002Fstrong>, the \u003Cstrong>decision\u003C\u002Fstrong>, its \u003Cstrong>status\u003C\u002Fstrong>, and the resulting \u003Cstrong>consequences\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-adr-2\",\"data\":{\"text\":\"The important object is the decision, not the template. Different teams use different ADR formats. A richer record can also preserve alternatives, decision criteria, trade-offs, evidence, links to requirements, and the date or version from which the decision applies.\"},\"type\":\"paragraph\"},{\"id\":\"p-adr-3\",\"data\":{\"text\":\"ISO\u002FIEC\u002FIEEE 42010:2022 is broader than ADR practice: it specifies requirements for architecture descriptions and their concepts, while explicitly not prescribing one process, notation, tool, format, or medium for recording an architecture description. An ADR is therefore a practical decision-recording technique, not a format mandated by ISO 42010.\"},\"type\":\"paragraph\"},{\"id\":\"adr-anatomy\",\"data\":{\"content\":[[\"ADR field\",\"What it preserves\",\"Why it matters\"],[\"Context\",\"The problem, forces, requirements, assumptions and environment surrounding the choice\",\"Future readers can reconstruct why a choice was necessary\"],[\"Decision\",\"The choice that became authoritative\",\"Separates the selected option from discussion\"],[\"Status\",\"Proposed, accepted, rejected, deprecated, superseded, or another controlled state\",\"Prevents old decisions from silently remaining active\"],[\"Alternatives\",\"Other viable options considered\",\"Shows that the selected solution was not the only imaginable one\"],[\"Rationale \u002F trade-offs\",\"Why the option was selected and what it gives up\",\"Makes architecture reasoning inspectable\"],[\"Consequences\",\"Expected positive and negative effects, follow-up work, risks\",\"Connects a local choice to system impact\"],[\"Date \u002F version\",\"When the decision became valid\",\"Supports historical traceability and later supersession\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-simple-example\",\"data\":{\"text\":\"The simplest example: latency requirement → architecture decision\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-simple-1\",\"data\":{\"text\":\"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.\"},\"type\":\"paragraph\"},{\"id\":\"p-simple-2\",\"data\":{\"text\":\"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.\"},\"type\":\"paragraph\"},{\"id\":\"simple-flow\",\"data\":{\"steps\":[{\"label\":\"1. State the requirement\",\"description\":\"Define the quality target, workload, scope, threshold and validation method.\"},{\"label\":\"2. Identify architectural significance\",\"description\":\"Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.\"},{\"label\":\"3. Evaluate options\",\"description\":\"Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.\"},{\"label\":\"4. Record the decision\",\"description\":\"Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.\"},{\"label\":\"5. Implement\",\"description\":\"Turn the decision into code, infrastructure, configuration and operational behavior.\"},{\"label\":\"6. Validate\",\"description\":\"Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.\"}],\"title\":\"From requirement to evidence\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"simple-stop\",\"data\":{\"body\":\"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.\",\"title\":\"Where the simple example stops\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-many-many\",\"data\":{\"text\":\"NFRs and ADRs usually have a many-to-many relationship\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-many-1\",\"data\":{\"text\":\"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.\"},\"type\":\"paragraph\"},{\"id\":\"p-many-2\",\"data\":{\"text\":\"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.\"},\"type\":\"paragraph\"},{\"id\":\"relationship-map\",\"data\":{\"rows\":[{\"id\":\"one-many\",\"label\":\"One NFR → many ADRs\",\"values\":{\"adr\":\"Several coordinated decisions may be required\",\"nfr\":\"A broad quality target can constrain several architectural boundaries\",\"validation\":\"Evidence may need multiple tests or measurements\"}},{\"id\":\"many-one\",\"label\":\"Many NFRs → one ADR\",\"values\":{\"adr\":\"One decision may balance several drivers\",\"nfr\":\"Several quality and constraint drivers can point at the same design problem\",\"validation\":\"Each requirement still needs its own acceptance evidence\"}},{\"id\":\"non-nfr\",\"label\":\"ADR without a classic NFR\",\"values\":{\"adr\":\"The choice can still be architecturally significant\",\"nfr\":\"The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition\",\"validation\":\"Validate against the actual driver, not an invented NFR\"}},{\"id\":\"supersession\",\"label\":\"Requirement stable, ADR changes\",\"values\":{\"adr\":\"A better or necessary implementation choice can supersede the old decision\",\"nfr\":\"The target can remain unchanged\",\"validation\":\"The new architecture must still be checked against the same target\"}}],\"title\":\"Why the relationship is not one-to-one\",\"layout\":\"table\",\"columns\":[{\"id\":\"nfr\",\"label\":\"Requirement side\"},{\"id\":\"adr\",\"label\":\"Decision side\"},{\"id\":\"validation\",\"label\":\"Validation side\"}]},\"type\":\"comparison\"},{\"id\":\"h-technology\",\"data\":{\"text\":\"A technology choice is not automatically a requirement\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-tech-1\",\"data\":{\"text\":\"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.\"},\"type\":\"paragraph\"},{\"id\":\"p-tech-2\",\"data\":{\"text\":\"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.\"},\"type\":\"paragraph\"},{\"id\":\"tech-table\",\"data\":{\"content\":[[\"Statement\",\"Classification\",\"Reason\"],[\"All tenant-scoped reads must enforce tenant isolation\",\"Requirement \u002F security property\",\"Describes a property that must hold\"],[\"Use PostgreSQL Row Level Security for selected tenant-scoped tables\",\"Architecture decision\",\"Chooses a mechanism intended to help satisfy the isolation property\"],[\"The deployment target must run in an approved EU-operated environment\",\"Constraint \u002F NFR-like operating condition\",\"Restricts where the system may operate\"],[\"Use provider X in region Y\",\"Architecture \u002F deployment decision unless externally mandated\",\"Selects a particular solution inside the allowed boundary\"],[\"95th-percentile API latency ≤ 300 ms under workload W\",\"Quality requirement\",\"Defines measurable performance behavior\"],[\"Introduce a cache for endpoint X\",\"Architecture decision\",\"Selects a tactic intended to improve the measured behavior\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-adr-proof\",\"data\":{\"text\":\"An ADR is not proof that an NFR has been satisfied\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-proof-1\",\"data\":{\"text\":\"Decision documentation and system validation answer different questions. An ADR can show that performance, security, resilience, or maintainability were considered. It cannot by itself demonstrate that the delivered system actually achieves those properties.\"},\"type\":\"paragraph\"},{\"id\":\"p-proof-2\",\"data\":{\"text\":\"The proof must come from the validation method appropriate to the requirement: benchmark, load test, failure test, security test, architecture analysis, audit, inspection, operational telemetry, recovery exercise, user study, or another form of evidence.\"},\"type\":\"paragraph\"},{\"id\":\"proof-rule\",\"data\":{\"body\":\"\u003Cstrong>ADR:\u003C\u002Fstrong> “We selected design X because it is expected to satisfy requirement R under assumptions A.”\u003Cbr>\u003Cstrong>Validation:\u003C\u002Fstrong> “Measured or analyzed evidence E shows whether the implemented system actually satisfies R.”\",\"title\":\"Do not confuse intent with evidence\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-asr\",\"data\":{\"text\":\"When does an NFR become architecturally significant?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-asr-1\",\"data\":{\"text\":\"Not every non-functional requirement deserves an architecture decision. The important subset is the requirements that materially shape the architecture or force trade-offs across the system.\"},\"type\":\"paragraph\"},{\"id\":\"p-asr-2\",\"data\":{\"text\":\"SEI literature uses the concept of \u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> for requirements with far-reaching architectural effect. Quality attributes such as performance, reliability, security, and modifiability are frequent sources of such drivers, especially when they carry high business or mission value.\"},\"type\":\"paragraph\"},{\"id\":\"asr-test\",\"data\":{\"steps\":[{\"label\":\"1. Ask whether the requirement changes structure\",\"description\":\"Would different values force different components, boundaries, data paths or deployment topology?\"},{\"label\":\"2. Ask whether it constrains major technology choices\",\"description\":\"Does it eliminate otherwise viable implementation options?\"},{\"label\":\"3. Ask whether it creates cross-cutting behavior\",\"description\":\"Does it affect many components, teams, interfaces or lifecycle stages?\"},{\"label\":\"4. Ask whether it creates a difficult trade-off\",\"description\":\"Does improving this property materially affect another quality, cost, schedule, complexity or risk?\"},{\"label\":\"5. Ask whether failure is expensive\",\"description\":\"Would missing the requirement create material operational, security, regulatory, financial or product impact?\"},{\"label\":\"6. Record decisions only where the reasoning is worth preserving\",\"description\":\"Do not create ADRs for every local coding choice; preserve architecturally significant decisions and their rationale.\"}],\"title\":\"Architectural-significance test\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-traceability\",\"data\":{\"text\":\"A stronger architecture model: requirement → decision → implementation → validation\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-trace-1\",\"data\":{\"text\":\"The most useful connection between NFRs and ADRs is traceability. A requirement should be able to point to the architecture decisions that address it; an ADR should identify the drivers it responds to; implementation work should realize the decision; validation should return to the original requirement.\"},\"type\":\"paragraph\"},{\"id\":\"trace-flow\",\"data\":{\"steps\":[{\"label\":\"Need \u002F business goal\",\"description\":\"Why the quality or constraint matters.\"},{\"label\":\"Requirement \u002F NFR\",\"description\":\"What the system must achieve or respect.\"},{\"label\":\"Architecture drivers\",\"description\":\"Which requirements are significant enough to shape the design.\"},{\"label\":\"Options\",\"description\":\"Plausible ways to address the driver.\"},{\"label\":\"ADR\",\"description\":\"The selected choice, rationale, alternatives, trade-offs and consequences.\"},{\"label\":\"Implementation\",\"description\":\"Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.\"},{\"label\":\"Validation evidence\",\"description\":\"Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.\"},{\"label\":\"Change \u002F supersession\",\"description\":\"New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.\"}],\"title\":\"Architecture traceability chain\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-senseflow\",\"data\":{\"text\":\"Implementation evidence: how I separate requirements and decisions in SenseFlow\",\"level\":2},\"type\":\"header\"},{\"id\":\"senseflow-evidence\",\"data\":{\"body\":\"The following section describes my own SenseFlow project structure. It is implementation evidence for the separation in this article, not a claim that every team must use the same documentation model.\",\"title\":\"Original implementation \u002F project evidence\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"p-sense-1\",\"data\":{\"text\":\"In SenseFlow, the project Source of Truth explicitly places non-functional requirements inside the requirements structure together with dependencies, risks, assumptions, acceptance criteria, and a validation method. The documentation model separately defines decision integrity for significant decisions.\"},\"type\":\"paragraph\"},{\"id\":\"p-sense-2\",\"data\":{\"text\":\"For significant SenseFlow decisions, the recorded fields are \u003Cstrong>Decision, Reason, Alternatives, Trade-offs, Status, and Date \u002F Version\u003C\u002Fstrong>. Major architecture and product decisions are intended to remain historically traceable rather than being overwritten when the project evolves.\"},\"type\":\"paragraph\"},{\"id\":\"p-sense-3\",\"data\":{\"text\":\"SenseFlow also assigns different operational roles to Confluence and Jira. Confluence is the structured knowledge and decision environment; Jira manages actionable delivery work. Major Jira Epics should link back to the relevant product or requirements documentation. This preserves the chain from product intent through requirements and decisions into implementation rather than turning the backlog into the architecture Source of Truth.\"},\"type\":\"paragraph\"},{\"id\":\"senseflow-table\",\"data\":{\"content\":[[\"SenseFlow layer\",\"What it contains\",\"Role in ADR\u002FNFR separation\"],[\"Product \u002F requirement structure\",\"Product goal, capability, epic, user story, acceptance criteria, technical tasks; requirements can include NFRs and validation method\",\"Preserves what must be achieved and how success will be checked\"],[\"Decision integrity\",\"Decision, reason, alternatives, trade-offs, status, date\u002Fversion\",\"Preserves why an architecturally significant choice became authoritative\"],[\"Confluence\",\"Requirements, architecture, research, decision records, risks, roadmap and supporting sources\",\"Maintains conceptual and historical Source of Truth\"],[\"Jira\",\"Initiatives\u002Fgoals, epics, stories, tasks and delivery state\",\"Executes approved work without becoming the conceptual Source of Truth\"],[\"Change management\",\"Current state → new evidence → proposed change → impact → decision\",\"Allows decisions to evolve without erasing the reasoning trail\"],[\"End-to-end traceability\",\"Problem → need → value → product goal → requirement → implementation → validation\",\"Keeps decision documentation connected to the actual product and evidence lifecycle\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"senseflow-lesson\",\"data\":{\"body\":\"A requirement and a decision can live close together without being collapsed into one record. The requirement remains the target; the decision remains the reasoning history; delivery work implements the decision; validation returns to the target.\",\"title\":\"What this implementation demonstrates\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-enterprise\",\"data\":{\"text\":\"Enterprise project context: requirements should precede architecture choices\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-enterprise-1\",\"data\":{\"text\":\"The same separation is useful in enterprise-oriented project work. Architecture decisions made before requirements, risks, constraints, and acceptance conditions are sufficiently understood can turn preferences into false necessities.\"},\"type\":\"paragraph\"},{\"id\":\"p-enterprise-2\",\"data\":{\"text\":\"For Enterprise Aaasaasa 0.1, the relevant lesson is methodological rather than a claim about one particular ADR: requirements, architecture, validation, milestones, risk management, and acceptance belong to a connected delivery system. An architecture choice should remain traceable to the requirement or constraint it is intended to address.\"},\"type\":\"paragraph\"},{\"id\":\"h-failures\",\"data\":{\"text\":\"Common failure modes when ADRs and NFRs are mixed\",\"level\":2},\"type\":\"header\"},{\"id\":\"failure-table\",\"data\":{\"content\":[[\"Failure mode\",\"What happens\",\"Consequence\"],[\"Technology disguised as requirement\",\"A preferred solution is written as “must use X” without establishing the underlying need\",\"Alternatives are never evaluated and architecture becomes prematurely fixed\"],[\"NFR hidden only inside an ADR\",\"The decision mentions a performance\u002Fsecurity target that is absent from the requirements baseline\",\"The target is hard to validate, prioritize or manage independently\"],[\"ADR treated as proof\",\"A documented choice is assumed to mean the requirement is satisfied\",\"Architecture intent replaces measurement or verification\"],[\"Vague NFR\",\"Words such as fast, scalable, secure or maintainable have no measurable scope\",\"Different stakeholders can believe the same requirement means different things\"],[\"No alternatives recorded\",\"The team records only the selected technology\",\"Future maintainers cannot reconstruct why another option was rejected\"],[\"No supersession model\",\"Old ADRs are edited or deleted when the architecture changes\",\"Historical reasoning disappears and stale decisions can remain ambiguous\"],[\"Every implementation detail becomes an ADR\",\"The repository fills with low-value records\",\"Important architecture choices become difficult to find\"],[\"Backlog becomes architecture SoT\",\"Jira tasks are treated as the only explanation of the system\",\"Delivery state survives, but architectural rationale and quality drivers are lost\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-decision-framework\",\"data\":{\"text\":\"The ADR–NFR decision framework\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-framework-1\",\"data\":{\"text\":\"When a team encounters a new architecture concern, the following sequence helps determine what belongs in requirements, what belongs in an ADR, and what belongs in evidence.\"},\"type\":\"paragraph\"},{\"id\":\"decision-flow\",\"data\":{\"steps\":[{\"label\":\"1. Is this a required property or external constraint?\",\"description\":\"If yes, write or reference the requirement before choosing a mechanism.\"},{\"label\":\"2. Can it be validated?\",\"description\":\"Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.\"},{\"label\":\"3. Is it architecturally significant?\",\"description\":\"Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.\"},{\"label\":\"4. Are there meaningful alternatives?\",\"description\":\"Compare viable tactics or architecture options rather than jumping directly to a preferred technology.\"},{\"label\":\"5. Has a choice become authoritative?\",\"description\":\"Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.\"},{\"label\":\"6. Is the decision implemented?\",\"description\":\"Trace the ADR into design, tasks, code, configuration and operations.\"},{\"label\":\"7. Is the requirement satisfied?\",\"description\":\"Collect validation evidence against the requirement itself.\"},{\"label\":\"8. Did conditions change?\",\"description\":\"Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.\"}],\"title\":\"ADR–NFR classification test\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-what-not\",\"data\":{\"text\":\"What ADR and NFR are not\",\"level\":2},\"type\":\"header\"},{\"id\":\"not-comparison\",\"data\":{\"rows\":[{\"id\":\"nfr\",\"label\":\"NFR \u002F quality requirement\",\"values\":{\"not\":\"A technology shopping list\",\"why\":\"Requirements should preserve the need independently from one implementation when possible\",\"term\":\"A required quality, constraint or operating condition\"}},{\"id\":\"adr\",\"label\":\"ADR\",\"values\":{\"not\":\"The complete architecture description\",\"why\":\"Architecture also needs views, interfaces, models, responsibilities and other documentation\",\"term\":\"A record of an architecturally significant decision\"}},{\"id\":\"test\",\"label\":\"Validation evidence\",\"values\":{\"not\":\"The ADR itself\",\"why\":\"Documented intent is different from measured or analyzed system behavior\",\"term\":\"Evidence that checks whether a requirement is satisfied\"}},{\"id\":\"backlog\",\"label\":\"Backlog item\",\"values\":{\"not\":\"A durable substitute for architecture rationale\",\"why\":\"Task state answers what is being delivered, not necessarily why the architecture exists\",\"term\":\"Actionable delivery work\"}},{\"id\":\"constraint\",\"label\":\"Constraint\",\"values\":{\"not\":\"Always an internally chosen architecture decision\",\"why\":\"Some constraints come from regulation, contracts, existing platforms or organizational boundaries\",\"term\":\"A condition that restricts the solution space\"}}],\"title\":\"Common category errors\",\"layout\":\"table\",\"columns\":[{\"id\":\"term\",\"label\":\"Concept\"},{\"id\":\"not\",\"label\":\"It is not\"},{\"id\":\"why\",\"label\":\"Reason\"}]},\"type\":\"comparison\"},{\"id\":\"h-change\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-change-1\",\"data\":{\"text\":\"The terminology can evolve. ISO\u002FIEC\u002FIEEE 29148:2018 remains the current published requirements-engineering standard as of 8 October 2026, but ISO lists a Draft International Standard intended to replace it. If the new edition changes relevant terminology or requirements guidance, the version-specific references in this article should be updated.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-2\",\"data\":{\"text\":\"ADR templates can also evolve without changing the central distinction. Michael Nygard’s minimal template, MADR, organization-specific templates, architecture knowledge tools, or structured decision databases can all record decisions. The durable question is whether the record preserves enough context and rationale to understand an architecturally significant choice.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-3\",\"data\":{\"text\":\"The distinction would only collapse if an organization deliberately chose a combined artifact that stores both requirement and decision data in one document. Even then, the semantic roles remain different: one field states the required outcome or constraint; another records the chosen response.\"},\"type\":\"paragraph\"},{\"id\":\"h-limitations\",\"data\":{\"text\":\"Limitations\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-limit-1\",\"data\":{\"text\":\"This article uses \u003Cstrong>NFR\u003C\u002Fstrong> as practical shorthand. Some engineering methods prefer terms such as quality attribute requirement, quality requirement, system quality, constraint, service-level objective, or architecturally significant requirement. Those terms are not perfectly interchangeable, and project terminology should be explicit.\"},\"type\":\"paragraph\"},{\"id\":\"p-limit-2\",\"data\":{\"text\":\"Not every requirement can be reduced to a single numeric threshold. Security, safety, maintainability, interoperability, usability, explainability, portability, and governance can require combinations of scenarios, structural rules, analyses, process controls, and qualitative evidence. “Measurable” should mean verifiable enough for the decision, not artificially numeric.\"},\"type\":\"paragraph\"},{\"id\":\"p-limit-3\",\"data\":{\"text\":\"Not every architecture decision needs a formal ADR. The documentation cost should be proportional to architectural significance, longevity, uncertainty, trade-off complexity, and the cost of losing the rationale.\"},\"type\":\"paragraph\"},{\"id\":\"h-conclusion\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-conclusion-1\",\"data\":{\"text\":\"ADR and NFR belong to different layers of architecture work. \u003Cstrong>The NFR defines a quality target, constraint, or operating condition. The ADR records a significant architectural response to one or more drivers.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-2\",\"data\":{\"text\":\"Keeping those layers separate makes architecture easier to reason about. Requirements can be validated independently of technology. Decisions can be superseded without rewriting history. Alternatives and trade-offs remain visible. Delivery work can be traced back to architectural intent. Evidence can show whether the resulting system actually satisfies the requirement.\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-3\",\"data\":{\"text\":\"The strongest chain is therefore not “NFR → ADR → done.” It is \u003Cstrong>need → requirement → architectural drivers → options → decision → implementation → validation → change\u003C\u002Fstrong>. That chain turns architecture documentation from static paperwork into a testable record of why the system has the shape it has.\"},\"type\":\"paragraph\"},{\"id\":\"h-faq\",\"data\":{\"text\":\"FAQ\",\"level\":2},\"type\":\"header\"},{\"id\":\"faq\",\"data\":{\"items\":[{\"id\":\"faq1\",\"answer\":\"No. An NFR states a required quality, constraint, or operating condition. An ADR records an architecturally significant choice made in response to requirements, constraints, risks and trade-offs.\",\"question\":\"Is an ADR a non-functional requirement?\"},{\"id\":\"faq2\",\"answer\":\"No. Only requirements that materially influence architecture need architecture-level decisions worth preserving. One NFR can also drive several ADRs, and one ADR can respond to several requirements.\",\"question\":\"Should every NFR have an ADR?\"},{\"id\":\"faq3\",\"answer\":\"Only when PostgreSQL is genuinely imposed as an external constraint. Otherwise the underlying need should be expressed first, and selecting PostgreSQL should normally be treated as an architecture decision.\",\"question\":\"Can “use PostgreSQL” be an NFR?\"},{\"id\":\"faq4\",\"answer\":\"No. An ADR records intent and reasoning. The requirement is validated through appropriate evidence such as testing, measurement, analysis, audit or operational telemetry.\",\"question\":\"Does an ADR prove that a performance or security requirement is met?\"},{\"id\":\"faq5\",\"answer\":\"At minimum, an ADR should make the context and decision clear. Common structures also include status and consequences. Teams can add alternatives, rationale, trade-offs, requirement links, evidence, owners, dates and supersession relationships.\",\"question\":\"What should an ADR contain?\"},{\"id\":\"faq6\",\"answer\":\"A requirement is architecturally significant when it materially shapes system structure, technology, data flows, deployment, cross-cutting behavior or difficult quality trade-offs, especially when failure carries high business or mission impact.\",\"question\":\"What makes an NFR architecturally significant?\"},{\"id\":\"faq7\",\"answer\":\"Usually no. A replacement decision should normally supersede the old record so the historical reasoning remains traceable.\",\"question\":\"Should an old ADR be deleted when the architecture changes?\"}],\"title\":\"ADR vs NFR\"},\"type\":\"faq\"},{\"id\":\"h-glossary\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"type\":\"header\"},{\"id\":\"glossary\",\"data\":{\"title\":\"Core architecture terms\",\"entries\":[{\"term\":\"NFR\",\"anchor\":\"nfr\",\"definition\":\"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.\"},{\"term\":\"Quality attribute requirement\",\"anchor\":\"quality-attribute-requirement\",\"definition\":\"A requirement describing a quality property the system is expected to exhibit under defined conditions, such as performance, availability, security, reliability or modifiability.\"},{\"term\":\"Architecture Decision Record (ADR)\",\"anchor\":\"adr\",\"definition\":\"A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.\"},{\"term\":\"Architecturally Significant Requirement (ASR)\",\"anchor\":\"asr\",\"definition\":\"A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.\"},{\"term\":\"Constraint\",\"anchor\":\"constraint\",\"definition\":\"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.\"},{\"term\":\"Trade-off\",\"anchor\":\"trade-off\",\"definition\":\"A design relationship in which improving one objective, property or cost dimension can worsen another.\"},{\"term\":\"Validation\",\"anchor\":\"validation\",\"definition\":\"Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.\"},{\"term\":\"Superseded ADR\",\"anchor\":\"superseded-adr\",\"definition\":\"A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.\"}]},\"type\":\"glossary\"},{\"id\":\"h-sources\",\"data\":{\"text\":\"Primary sources and implementation evidence\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-sources-note\",\"data\":{\"text\":\"This article separates current standards from project implementation evidence. ISO\u002FIEC\u002FIEEE 29148:2018 remains current as of 8 October 2026 but is marked for revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are current published editions. SenseFlow is original project evidence for the traceability and decision-integrity model described above.\"},\"type\":\"paragraph\"},{\"id\":\"src-iso-29148\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering\",\"description\":\"Current published requirements-engineering standard. ISO states that the 2018 edition was reviewed and confirmed in 2024 and is expected to be replaced by the DIS now under development.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-29148-dis\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering\",\"description\":\"Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-25010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 25010:2023 — Product Quality Model\",\"description\":\"Current product-quality model with nine quality characteristics used to specify, measure and evaluate ICT and software product quality.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-42010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current architecture-description standard. It specifies architecture-description concepts and conformance requirements without prescribing one recording format, notation, process or tool.\"}},\"type\":\"linkTool\"},{\"id\":\"src-nygard\",\"data\":{\"link\":\"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Michael Nygard — Documenting Architecture Decisions\",\"description\":\"Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-asr\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Relating Business Goals to Architecturally Significant Requirements\",\"description\":\"SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-nfr\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Defining Non-Functional System Qualities\",\"description\":\"SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-add\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Attribute-Driven Design Method Collection\",\"description\":\"Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-doc\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Views and Beyond Collection\",\"description\":\"Architecture-documentation guidance emphasizing relevant views and the recording of necessary design decisions as part of architecture work.\"}},\"type\":\"linkTool\"}],\"version\":\"2.31.0\"}",{"time":1081,"blocks":1082,"version":1717},1791475659420,[1083,1086,1090,1094,1097,1100,1103,1106,1109,1133,1136,1139,1142,1145,1172,1176,1179,1182,1185,1188,1223,1226,1229,1232,1254,1258,1261,1264,1267,1290,1293,1296,1299,1329,1332,1335,1338,1342,1345,1348,1351,1373,1376,1379,1406,1409,1413,1416,1419,1422,1451,1455,1458,1461,1464,1467,1506,1509,1512,1540,1543,1565,1568,1571,1574,1577,1580,1583,1586,1589,1592,1595,1598,1601,1604,1628,1631,1657,1660,1663,1669,1675,1681,1687,1693,1699,1705,1711],{"id":215,"data":1084,"type":218},{"text":1085},"An \u003Cstrong>non-functional requirement (NFR)\u003C\u002Fstrong> describes a quality, constraint, or operating condition the system is expected to satisfy. An \u003Cstrong>architecture decision record (ADR)\u003C\u002Fstrong> records an architecturally significant choice made in response to requirements, constraints, risks, and trade-offs. They are connected, but they are not interchangeable: an NFR states what must be true; an ADR explains what was decided, why, and with what consequences.",{"id":220,"data":1087,"type":225},{"body":1088,"title":1089,"variant":224},"\u003Cstrong>NFR = required system quality or constraint. ADR = recorded architecture decision.\u003C\u002Fstrong> A latency target, availability objective, isolation rule, deployment restriction, or maintainability requirement can influence architecture. An ADR then records a significant choice made to address one or more such drivers. The ADR does not replace the requirement, and the existence of an ADR does not prove that the requirement has been satisfied.","Direct answer",{"id":227,"data":1091,"type":225},{"body":1092,"title":1093,"variant":231},"The term \u003Cstrong>NFR\u003C\u002Fstrong> is widely used but not perfectly standardized. This article uses it as practical shorthand for quality requirements and relevant constraints. Current standards were re-checked on \u003Cstrong>8 October 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 remains current but is under revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are the current published editions cited here.","Terminology and standards note",{"id":233,"data":1095,"type":238},{"title":1096,"maxLevel":236,"minLevel":237},"Contents",{"id":240,"data":1098,"type":42},{"text":1099,"level":237},"What is the difference between an NFR and an ADR?",{"id":244,"data":1101,"type":218},{"text":1102},"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.",{"id":248,"data":1104,"type":218},{"text":1105},"For example, \u003Cstrong>“The API must return 95% of read requests within 300 ms under the agreed reference load”\u003C\u002Fstrong> is a quality requirement. \u003Cstrong>“Use a read-through cache for this workload because the measured database-only path cannot meet the latency target without unacceptable cost”\u003C\u002Fstrong> is an architecture decision.",{"id":252,"data":1107,"type":218},{"text":1108},"The first statement remains valid even if the implementation changes. The second statement can later be superseded by another decision if the workload, technology, cost model, or evidence changes.",{"id":256,"data":1110,"type":298},{"rows":1111,"title":1127,"layout":290,"columns":1128},[1112,1115,1118,1121,1124],{"id":260,"label":1113,"values":1114},"Primary question",{"adr":263,"nfr":264},{"id":266,"label":1116,"values":1117},"Typical content",{"adr":269,"nfr":270},{"id":272,"label":1119,"values":1120},"Lifecycle role",{"adr":275,"nfr":276},{"id":278,"label":1122,"values":1123},"What proves it?",{"adr":281,"nfr":282},{"id":284,"label":1125,"values":1126},"When it changes",{"adr":287,"nfr":288},"NFR and ADR answer different questions",[1129,1131],{"id":293,"label":1130},"NFR \u002F quality requirement",{"id":296,"label":1132},"ADR \u002F architecture decision",{"id":300,"data":1134,"type":42},{"text":1135,"level":237},"What is an NFR in precise architectural terms?",{"id":304,"data":1137,"type":218},{"text":1138},"“Non-functional requirement” is a convenient industry label, but it can hide several different kinds of statements. In architecture work, the useful distinction is between \u003Cstrong>functional behavior\u003C\u002Fstrong>, \u003Cstrong>quality requirements\u003C\u002Fstrong>, and \u003Cstrong>constraints\u003C\u002Fstrong>.",{"id":308,"data":1140,"type":218},{"text":1141},"ISO\u002FIEC 25010:2023 provides a product-quality model with nine characteristics and subcharacteristics that can be used when specifying and evaluating ICT and software product quality. SEI architecture work similarly treats quality attribute requirements as major drivers of software architecture.",{"id":312,"data":1143,"type":218},{"text":1144},"A useful NFR is therefore not “the system should be fast” or “the platform must be secure.” Those statements name aspirations. An architecture-driving requirement should make the expected property testable enough that design alternatives and later evidence can be evaluated against it.",{"id":316,"data":1146,"type":290},{"content":1147,"stretched":43,"withHeadings":14},[1148,1152,1156,1160,1164,1168],[1149,1150,1151],"Weak statement","More useful requirement shape","Why the difference matters",[1153,1154,1155],"The API must be fast","For workload W, 95% of operation X completes within T milliseconds","Defines workload, operation, metric and threshold",[1157,1158,1159],"The service must be available","Service S meets an agreed availability objective over measurement window M, excluding explicitly defined maintenance conditions","Makes availability measurable and defines scope",[1161,1162,1163],"Tenant data must be secure","A request authenticated for tenant A must never retrieve or mutate tenant B data through supported application paths","Turns a vague security goal into an isolation property",[1165,1166,1167],"The system should scale","The system supports workload W at concurrency C while meeting latency and error-rate thresholds","Connects scale to measurable service behavior",[1169,1170,1171],"We need PostgreSQL","Not an NFR by itself; state the required persistence qualities or external constraint first","A technology choice is normally a solution, not the requirement it is meant to satisfy",{"id":344,"data":1173,"type":225},{"body":1174,"title":1175,"variant":348},"If “use Kubernetes,” “use PostgreSQL,” “use microservices,” or “use vector search” appears as the requirement, ask whether it is truly an external constraint or whether the solution has been written down before the underlying quality need was made explicit.","A requirement should describe the need before the mechanism",{"id":350,"data":1177,"type":42},{"text":1178,"level":237},"What is an Architecture Decision Record?",{"id":354,"data":1180,"type":218},{"text":1181},"An Architecture Decision Record is a compact record of an important architecture decision. Michael Nygard’s original ADR formulation emphasizes the \u003Cstrong>context\u003C\u002Fstrong>, the \u003Cstrong>decision\u003C\u002Fstrong>, its \u003Cstrong>status\u003C\u002Fstrong>, and the resulting \u003Cstrong>consequences\u003C\u002Fstrong>.",{"id":358,"data":1183,"type":218},{"text":1184},"The important object is the decision, not the template. Different teams use different ADR formats. A richer record can also preserve alternatives, decision criteria, trade-offs, evidence, links to requirements, and the date or version from which the decision applies.",{"id":362,"data":1186,"type":218},{"text":1187},"ISO\u002FIEC\u002FIEEE 42010:2022 is broader than ADR practice: it specifies requirements for architecture descriptions and their concepts, while explicitly not prescribing one process, notation, tool, format, or medium for recording an architecture description. An ADR is therefore a practical decision-recording technique, not a format mandated by ISO 42010.",{"id":366,"data":1189,"type":290},{"content":1190,"stretched":43,"withHeadings":14},[1191,1195,1199,1203,1207,1211,1215,1219],[1192,1193,1194],"ADR field","What it preserves","Why it matters",[1196,1197,1198],"Context","The problem, forces, requirements, assumptions and environment surrounding the choice","Future readers can reconstruct why a choice was necessary",[1200,1201,1202],"Decision","The choice that became authoritative","Separates the selected option from discussion",[1204,1205,1206],"Status","Proposed, accepted, rejected, deprecated, superseded, or another controlled state","Prevents old decisions from silently remaining active",[1208,1209,1210],"Alternatives","Other viable options considered","Shows that the selected solution was not the only imaginable one",[1212,1213,1214],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1216,1217,1218],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[1220,1221,1222],"Date \u002F version","When the decision became valid","Supports historical traceability and later supersession",{"id":402,"data":1224,"type":42},{"text":1225,"level":237},"The simplest example: latency requirement → architecture decision",{"id":406,"data":1227,"type":218},{"text":1228},"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.",{"id":410,"data":1230,"type":218},{"text":1231},"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.",{"id":414,"data":1233,"type":437},{"steps":1234,"title":1253,"orientation":436},[1235,1238,1241,1244,1247,1250],{"label":1236,"description":1237},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1239,"description":1240},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1242,"description":1243},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1245,"description":1246},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1248,"description":1249},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1251,"description":1252},"6. Validate","Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.","From requirement to evidence",{"id":439,"data":1255,"type":225},{"body":1256,"title":1257,"variant":443},"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.","Where the simple example stops",{"id":445,"data":1259,"type":42},{"text":1260,"level":237},"NFRs and ADRs usually have a many-to-many relationship",{"id":449,"data":1262,"type":218},{"text":1263},"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.",{"id":453,"data":1265,"type":218},{"text":1266},"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.",{"id":457,"data":1268,"type":298},{"rows":1269,"title":1282,"layout":290,"columns":1283},[1270,1273,1276,1279],{"id":461,"label":1271,"values":1272},"One NFR → many ADRs",{"adr":464,"nfr":465,"validation":466},{"id":468,"label":1274,"values":1275},"Many NFRs → one ADR",{"adr":471,"nfr":472,"validation":473},{"id":475,"label":1277,"values":1278},"ADR without a classic NFR",{"adr":478,"nfr":479,"validation":480},{"id":482,"label":1280,"values":1281},"Requirement stable, ADR changes",{"adr":485,"nfr":486,"validation":487},"Why the relationship is not one-to-one",[1284,1286,1288],{"id":293,"label":1285},"Requirement side",{"id":296,"label":1287},"Decision side",{"id":495,"label":1289},"Validation side",{"id":498,"data":1291,"type":42},{"text":1292,"level":237},"A technology choice is not automatically a requirement",{"id":502,"data":1294,"type":218},{"text":1295},"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.",{"id":506,"data":1297,"type":218},{"text":1298},"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.",{"id":510,"data":1300,"type":290},{"content":1301,"stretched":43,"withHeadings":14},[1302,1306,1310,1314,1318,1322,1326],[1303,1304,1305],"Statement","Classification","Reason",[1307,1308,1309],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1311,1312,1313],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1315,1316,1317],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1319,1320,1321],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1323,1324,1325],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1327,1312,1328],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":541,"data":1330,"type":42},{"text":1331,"level":237},"An ADR is not proof that an NFR has been satisfied",{"id":545,"data":1333,"type":218},{"text":1334},"Decision documentation and system validation answer different questions. An ADR can show that performance, security, resilience, or maintainability were considered. It cannot by itself demonstrate that the delivered system actually achieves those properties.",{"id":549,"data":1336,"type":218},{"text":1337},"The proof must come from the validation method appropriate to the requirement: benchmark, load test, failure test, security test, architecture analysis, audit, inspection, operational telemetry, recovery exercise, user study, or another form of evidence.",{"id":553,"data":1339,"type":225},{"body":1340,"title":1341,"variant":443},"\u003Cstrong>ADR:\u003C\u002Fstrong> “We selected design X because it is expected to satisfy requirement R under assumptions A.”\u003Cbr>\u003Cstrong>Validation:\u003C\u002Fstrong> “Measured or analyzed evidence E shows whether the implemented system actually satisfies R.”","Do not confuse intent with evidence",{"id":558,"data":1343,"type":42},{"text":1344,"level":237},"When does an NFR become architecturally significant?",{"id":562,"data":1346,"type":218},{"text":1347},"Not every non-functional requirement deserves an architecture decision. The important subset is the requirements that materially shape the architecture or force trade-offs across the system.",{"id":566,"data":1349,"type":218},{"text":1350},"SEI literature uses the concept of \u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> for requirements with far-reaching architectural effect. Quality attributes such as performance, reliability, security, and modifiability are frequent sources of such drivers, especially when they carry high business or mission value.",{"id":570,"data":1352,"type":437},{"steps":1353,"title":1372,"orientation":436},[1354,1357,1360,1363,1366,1369],{"label":1355,"description":1356},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1358,"description":1359},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1361,"description":1362},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1364,"description":1365},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1367,"description":1368},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1370,"description":1371},"6. Record decisions only where the reasoning is worth preserving","Do not create ADRs for every local coding choice; preserve architecturally significant decisions and their rationale.","Architectural-significance test",{"id":593,"data":1374,"type":42},{"text":1375,"level":237},"A stronger architecture model: requirement → decision → implementation → validation",{"id":597,"data":1377,"type":218},{"text":1378},"The most useful connection between NFRs and ADRs is traceability. A requirement should be able to point to the architecture decisions that address it; an ADR should identify the drivers it responds to; implementation work should realize the decision; validation should return to the original requirement.",{"id":601,"data":1380,"type":437},{"steps":1381,"title":1405,"orientation":436},[1382,1385,1388,1391,1394,1396,1399,1402],{"label":1383,"description":1384},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1386,"description":1387},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1389,"description":1390},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":1392,"description":1393},"Options","Plausible ways to address the driver.",{"label":617,"description":1395},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1397,"description":1398},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1400,"description":1401},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1403,"description":1404},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":630,"data":1407,"type":42},{"text":1408,"level":237},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":634,"data":1410,"type":225},{"body":1411,"title":1412,"variant":231},"The following section describes my own SenseFlow project structure. It is implementation evidence for the separation in this article, not a claim that every team must use the same documentation model.","Original implementation \u002F project evidence",{"id":639,"data":1414,"type":218},{"text":1415},"In SenseFlow, the project Source of Truth explicitly places non-functional requirements inside the requirements structure together with dependencies, risks, assumptions, acceptance criteria, and a validation method. The documentation model separately defines decision integrity for significant decisions.",{"id":643,"data":1417,"type":218},{"text":1418},"For significant SenseFlow decisions, the recorded fields are \u003Cstrong>Decision, Reason, Alternatives, Trade-offs, Status, and Date \u002F Version\u003C\u002Fstrong>. Major architecture and product decisions are intended to remain historically traceable rather than being overwritten when the project evolves.",{"id":647,"data":1420,"type":218},{"text":1421},"SenseFlow also assigns different operational roles to Confluence and Jira. Confluence is the structured knowledge and decision environment; Jira manages actionable delivery work. Major Jira Epics should link back to the relevant product or requirements documentation. This preserves the chain from product intent through requirements and decisions into implementation rather than turning the backlog into the architecture Source of Truth.",{"id":651,"data":1423,"type":290},{"content":1424,"stretched":43,"withHeadings":14},[1425,1429,1433,1437,1440,1443,1447],[1426,1427,1428],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1430,1431,1432],"Product \u002F requirement structure","Product goal, capability, epic, user story, acceptance criteria, technical tasks; requirements can include NFRs and validation method","Preserves what must be achieved and how success will be checked",[1434,1435,1436],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[667,1438,1439],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[671,1441,1442],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1444,1445,1446],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1448,1449,1450],"End-to-end traceability","Problem → need → value → product goal → requirement → implementation → validation","Keeps decision documentation connected to the actual product and evidence lifecycle",{"id":683,"data":1452,"type":225},{"body":1453,"title":1454,"variant":348},"A requirement and a decision can live close together without being collapsed into one record. The requirement remains the target; the decision remains the reasoning history; delivery work implements the decision; validation returns to the target.","What this implementation demonstrates",{"id":688,"data":1456,"type":42},{"text":1457,"level":237},"Enterprise project context: requirements should precede architecture choices",{"id":692,"data":1459,"type":218},{"text":1460},"The same separation is useful in enterprise-oriented project work. Architecture decisions made before requirements, risks, constraints, and acceptance conditions are sufficiently understood can turn preferences into false necessities.",{"id":696,"data":1462,"type":218},{"text":1463},"For Enterprise Aaasaasa 0.1, the relevant lesson is methodological rather than a claim about one particular ADR: requirements, architecture, validation, milestones, risk management, and acceptance belong to a connected delivery system. An architecture choice should remain traceable to the requirement or constraint it is intended to address.",{"id":700,"data":1465,"type":42},{"text":1466,"level":237},"Common failure modes when ADRs and NFRs are mixed",{"id":704,"data":1468,"type":290},{"content":1469,"stretched":43,"withHeadings":14},[1470,1474,1478,1482,1486,1490,1494,1498,1502],[1471,1472,1473],"Failure mode","What happens","Consequence",[1475,1476,1477],"Technology disguised as requirement","A preferred solution is written as “must use X” without establishing the underlying need","Alternatives are never evaluated and architecture becomes prematurely fixed",[1479,1480,1481],"NFR hidden only inside an ADR","The decision mentions a performance\u002Fsecurity target that is absent from the requirements baseline","The target is hard to validate, prioritize or manage independently",[1483,1484,1485],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1487,1488,1489],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1491,1492,1493],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1495,1496,1497],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1499,1500,1501],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1503,1504,1505],"Backlog becomes architecture SoT","Jira tasks are treated as the only explanation of the system","Delivery state survives, but architectural rationale and quality drivers are lost",{"id":744,"data":1507,"type":42},{"text":1508,"level":237},"The ADR–NFR decision framework",{"id":748,"data":1510,"type":218},{"text":1511},"When a team encounters a new architecture concern, the following sequence helps determine what belongs in requirements, what belongs in an ADR, and what belongs in evidence.",{"id":752,"data":1513,"type":437},{"steps":1514,"title":1539,"orientation":436},[1515,1518,1521,1524,1527,1530,1533,1536],{"label":1516,"description":1517},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1519,"description":1520},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1522,"description":1523},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1525,"description":1526},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1528,"description":1529},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1531,"description":1532},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1534,"description":1535},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1537,"description":1538},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":781,"data":1541,"type":42},{"text":1542,"level":237},"What ADR and NFR are not",{"id":785,"data":1544,"type":298},{"rows":1545,"title":1558,"layout":290,"columns":1559},[1546,1548,1550,1552,1555],{"id":293,"label":1130,"values":1547},{"not":791,"why":792,"term":793},{"id":296,"label":617,"values":1549},{"not":796,"why":797,"term":798},{"id":800,"label":1400,"values":1551},{"not":802,"why":803,"term":804},{"id":806,"label":1553,"values":1554},"Backlog item",{"not":809,"why":810,"term":811},{"id":813,"label":1556,"values":1557},"Constraint",{"not":816,"why":817,"term":818},"Common category errors",[1560,1562,1564],{"id":822,"label":1561},"Concept",{"id":825,"label":1563},"It is not",{"id":828,"label":1305},{"id":830,"data":1566,"type":42},{"text":1567,"level":237},"What would change this answer?",{"id":834,"data":1569,"type":218},{"text":1570},"The terminology can evolve. ISO\u002FIEC\u002FIEEE 29148:2018 remains the current published requirements-engineering standard as of 8 October 2026, but ISO lists a Draft International Standard intended to replace it. If the new edition changes relevant terminology or requirements guidance, the version-specific references in this article should be updated.",{"id":838,"data":1572,"type":218},{"text":1573},"ADR templates can also evolve without changing the central distinction. Michael Nygard’s minimal template, MADR, organization-specific templates, architecture knowledge tools, or structured decision databases can all record decisions. The durable question is whether the record preserves enough context and rationale to understand an architecturally significant choice.",{"id":842,"data":1575,"type":218},{"text":1576},"The distinction would only collapse if an organization deliberately chose a combined artifact that stores both requirement and decision data in one document. Even then, the semantic roles remain different: one field states the required outcome or constraint; another records the chosen response.",{"id":846,"data":1578,"type":42},{"text":1579,"level":237},"Limitations",{"id":850,"data":1581,"type":218},{"text":1582},"This article uses \u003Cstrong>NFR\u003C\u002Fstrong> as practical shorthand. Some engineering methods prefer terms such as quality attribute requirement, quality requirement, system quality, constraint, service-level objective, or architecturally significant requirement. Those terms are not perfectly interchangeable, and project terminology should be explicit.",{"id":854,"data":1584,"type":218},{"text":1585},"Not every requirement can be reduced to a single numeric threshold. Security, safety, maintainability, interoperability, usability, explainability, portability, and governance can require combinations of scenarios, structural rules, analyses, process controls, and qualitative evidence. “Measurable” should mean verifiable enough for the decision, not artificially numeric.",{"id":858,"data":1587,"type":218},{"text":1588},"Not every architecture decision needs a formal ADR. The documentation cost should be proportional to architectural significance, longevity, uncertainty, trade-off complexity, and the cost of losing the rationale.",{"id":862,"data":1590,"type":42},{"text":1591,"level":237},"Conclusion",{"id":866,"data":1593,"type":218},{"text":1594},"ADR and NFR belong to different layers of architecture work. \u003Cstrong>The NFR defines a quality target, constraint, or operating condition. The ADR records a significant architectural response to one or more drivers.\u003C\u002Fstrong>",{"id":870,"data":1596,"type":218},{"text":1597},"Keeping those layers separate makes architecture easier to reason about. Requirements can be validated independently of technology. Decisions can be superseded without rewriting history. Alternatives and trade-offs remain visible. Delivery work can be traced back to architectural intent. Evidence can show whether the resulting system actually satisfies the requirement.",{"id":874,"data":1599,"type":218},{"text":1600},"The strongest chain is therefore not “NFR → ADR → done.” It is \u003Cstrong>need → requirement → architectural drivers → options → decision → implementation → validation → change\u003C\u002Fstrong>. That chain turns architecture documentation from static paperwork into a testable record of why the system has the shape it has.",{"id":878,"data":1602,"type":42},{"text":1603,"level":237},"FAQ",{"id":882,"data":1605,"type":882},{"items":1606,"title":913},[1607,1610,1613,1616,1619,1622,1625],{"id":886,"answer":1608,"question":1609},"No. An NFR states a required quality, constraint, or operating condition. An ADR records an architecturally significant choice made in response to requirements, constraints, risks and trade-offs.","Is an ADR a non-functional requirement?",{"id":890,"answer":1611,"question":1612},"No. Only requirements that materially influence architecture need architecture-level decisions worth preserving. One NFR can also drive several ADRs, and one ADR can respond to several requirements.","Should every NFR have an ADR?",{"id":894,"answer":1614,"question":1615},"Only when PostgreSQL is genuinely imposed as an external constraint. Otherwise the underlying need should be expressed first, and selecting PostgreSQL should normally be treated as an architecture decision.","Can “use PostgreSQL” be an NFR?",{"id":898,"answer":1617,"question":1618},"No. An ADR records intent and reasoning. The requirement is validated through appropriate evidence such as testing, measurement, analysis, audit or operational telemetry.","Does an ADR prove that a performance or security requirement is met?",{"id":902,"answer":1620,"question":1621},"At minimum, an ADR should make the context and decision clear. Common structures also include status and consequences. Teams can add alternatives, rationale, trade-offs, requirement links, evidence, owners, dates and supersession relationships.","What should an ADR contain?",{"id":906,"answer":1623,"question":1624},"A requirement is architecturally significant when it materially shapes system structure, technology, data flows, deployment, cross-cutting behavior or difficult quality trade-offs, especially when failure carries high business or mission impact.","What makes an NFR architecturally significant?",{"id":910,"answer":1626,"question":1627},"Usually no. A replacement decision should normally supersede the old record so the historical reasoning remains traceable.","Should an old ADR be deleted when the architecture changes?",{"id":915,"data":1629,"type":42},{"text":1630,"level":237},"Glossary",{"id":919,"data":1632,"type":919},{"title":1633,"entries":1634},"Core architecture terms",[1635,1637,1640,1643,1646,1648,1651,1654],{"term":924,"anchor":293,"definition":1636},"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1638,"anchor":928,"definition":1639},"Quality attribute requirement","A requirement describing a quality property the system is expected to exhibit under defined conditions, such as performance, availability, security, reliability or modifiability.",{"term":1641,"anchor":296,"definition":1642},"Architecture Decision Record (ADR)","A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.",{"term":1644,"anchor":935,"definition":1645},"Architecturally Significant Requirement (ASR)","A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1556,"anchor":813,"definition":1647},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1649,"anchor":941,"definition":1650},"Trade-off","A design relationship in which improving one objective, property or cost dimension can worsen another.",{"term":1652,"anchor":495,"definition":1653},"Validation","Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.",{"term":1655,"anchor":948,"definition":1656},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":951,"data":1658,"type":42},{"text":1659,"level":237},"Primary sources and implementation evidence",{"id":955,"data":1661,"type":218},{"text":1662},"This article separates current standards from project implementation evidence. ISO\u002FIEC\u002FIEEE 29148:2018 remains current as of 8 October 2026 but is marked for revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are current published editions. SenseFlow is original project evidence for the traceability and decision-integrity model described above.",{"id":959,"data":1664,"type":967},{"link":961,"meta":1665},{"image":1666,"title":1667,"description":1668},{"url":964},"ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering","Current published requirements-engineering standard. ISO states that the 2018 edition was reviewed and confirmed in 2024 and is expected to be replaced by the DIS now under development.",{"id":969,"data":1670,"type":967},{"link":971,"meta":1671},{"image":1672,"title":1673,"description":1674},{"url":964},"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering","Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":977,"data":1676,"type":967},{"link":979,"meta":1677},{"image":1678,"title":1679,"description":1680},{"url":964},"ISO\u002FIEC 25010:2023 — Product Quality Model","Current product-quality model with nine quality characteristics used to specify, measure and evaluate ICT and software product quality.",{"id":985,"data":1682,"type":967},{"link":987,"meta":1683},{"image":1684,"title":1685,"description":1686},{"url":964},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Current architecture-description standard. It specifies architecture-description concepts and conformance requirements without prescribing one recording format, notation, process or tool.",{"id":993,"data":1688,"type":967},{"link":995,"meta":1689},{"image":1690,"title":1691,"description":1692},{"url":964},"Michael Nygard — Documenting Architecture Decisions","Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.",{"id":1001,"data":1694,"type":967},{"link":1003,"meta":1695},{"image":1696,"title":1697,"description":1698},{"url":964},"SEI — Relating Business Goals to Architecturally Significant Requirements","SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.",{"id":1009,"data":1700,"type":967},{"link":1011,"meta":1701},{"image":1702,"title":1703,"description":1704},{"url":964},"SEI — Defining Non-Functional System Qualities","SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.",{"id":1017,"data":1706,"type":967},{"link":1019,"meta":1707},{"image":1708,"title":1709,"description":1710},{"url":964},"SEI — Attribute-Driven Design Method Collection","Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.",{"id":1025,"data":1712,"type":967},{"link":1027,"meta":1713},{"image":1714,"title":1715,"description":1716},{"url":964},"SEI — Views and Beyond Collection","Architecture-documentation guidance emphasizing relevant views and the recording of necessary design decisions as part of architecture work.","2.31.0","ADR vs NFR explained: learn how system quality requirements drive architecture decisions, how ADRs record trade-offs, and why validation stays separate.",{"lang":7,"title":208,"content":210,"contentJson":1720,"excerpt":1033},{"time":212,"blocks":1721,"version":1032},[1722,1724,1726,1728,1730,1732,1734,1736,1738,1754,1756,1758,1760,1762,1771,1773,1775,1777,1779,1781,1792,1794,1796,1798,1807,1809,1811,1813,1815,1830,1832,1834,1836,1846,1848,1850,1852,1854,1856,1858,1860,1869,1871,1873,1884,1886,1888,1890,1892,1894,1904,1906,1908,1910,1912,1914,1926,1928,1930,1941,1943,1960,1962,1964,1966,1968,1970,1972,1974,1976,1978,1980,1982,1984,1986,1996,1998,2009,2011,2013,2017,2021,2025,2029,2033,2037,2041,2045],{"id":215,"data":1723,"type":218},{"text":217},{"id":220,"data":1725,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1727,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1729,"type":238},{"title":235,"maxLevel":236,"minLevel":237},{"id":240,"data":1731,"type":42},{"text":242,"level":237},{"id":244,"data":1733,"type":218},{"text":246},{"id":248,"data":1735,"type":218},{"text":250},{"id":252,"data":1737,"type":218},{"text":254},{"id":256,"data":1739,"type":298},{"rows":1740,"title":289,"layout":290,"columns":1751},[1741,1743,1745,1747,1749],{"id":260,"label":261,"values":1742},{"adr":263,"nfr":264},{"id":266,"label":267,"values":1744},{"adr":269,"nfr":270},{"id":272,"label":273,"values":1746},{"adr":275,"nfr":276},{"id":278,"label":279,"values":1748},{"adr":281,"nfr":282},{"id":284,"label":285,"values":1750},{"adr":287,"nfr":288},[1752,1753],{"id":293,"label":294},{"id":296,"label":297},{"id":300,"data":1755,"type":42},{"text":302,"level":237},{"id":304,"data":1757,"type":218},{"text":306},{"id":308,"data":1759,"type":218},{"text":310},{"id":312,"data":1761,"type":218},{"text":314},{"id":316,"data":1763,"type":290},{"content":1764,"stretched":43,"withHeadings":14},[1765,1766,1767,1768,1769,1770],[320,321,322],[324,325,326],[328,329,330],[332,333,334],[336,337,338],[340,341,342],{"id":344,"data":1772,"type":225},{"body":346,"title":347,"variant":348},{"id":350,"data":1774,"type":42},{"text":352,"level":237},{"id":354,"data":1776,"type":218},{"text":356},{"id":358,"data":1778,"type":218},{"text":360},{"id":362,"data":1780,"type":218},{"text":364},{"id":366,"data":1782,"type":290},{"content":1783,"stretched":43,"withHeadings":14},[1784,1785,1786,1787,1788,1789,1790,1791],[370,371,372],[374,375,376],[378,379,380],[382,383,384],[386,387,388],[390,391,392],[394,395,396],[398,399,400],{"id":402,"data":1793,"type":42},{"text":404,"level":237},{"id":406,"data":1795,"type":218},{"text":408},{"id":410,"data":1797,"type":218},{"text":412},{"id":414,"data":1799,"type":437},{"steps":1800,"title":435,"orientation":436},[1801,1802,1803,1804,1805,1806],{"label":418,"description":419},{"label":421,"description":422},{"label":424,"description":425},{"label":427,"description":428},{"label":430,"description":431},{"label":433,"description":434},{"id":439,"data":1808,"type":225},{"body":441,"title":442,"variant":443},{"id":445,"data":1810,"type":42},{"text":447,"level":237},{"id":449,"data":1812,"type":218},{"text":451},{"id":453,"data":1814,"type":218},{"text":455},{"id":457,"data":1816,"type":298},{"rows":1817,"title":488,"layout":290,"columns":1826},[1818,1820,1822,1824],{"id":461,"label":462,"values":1819},{"adr":464,"nfr":465,"validation":466},{"id":468,"label":469,"values":1821},{"adr":471,"nfr":472,"validation":473},{"id":475,"label":476,"values":1823},{"adr":478,"nfr":479,"validation":480},{"id":482,"label":483,"values":1825},{"adr":485,"nfr":486,"validation":487},[1827,1828,1829],{"id":293,"label":491},{"id":296,"label":493},{"id":495,"label":496},{"id":498,"data":1831,"type":42},{"text":500,"level":237},{"id":502,"data":1833,"type":218},{"text":504},{"id":506,"data":1835,"type":218},{"text":508},{"id":510,"data":1837,"type":290},{"content":1838,"stretched":43,"withHeadings":14},[1839,1840,1841,1842,1843,1844,1845],[514,515,516],[518,519,520],[522,523,524],[526,527,528],[530,531,532],[534,535,536],[538,523,539],{"id":541,"data":1847,"type":42},{"text":543,"level":237},{"id":545,"data":1849,"type":218},{"text":547},{"id":549,"data":1851,"type":218},{"text":551},{"id":553,"data":1853,"type":225},{"body":555,"title":556,"variant":443},{"id":558,"data":1855,"type":42},{"text":560,"level":237},{"id":562,"data":1857,"type":218},{"text":564},{"id":566,"data":1859,"type":218},{"text":568},{"id":570,"data":1861,"type":437},{"steps":1862,"title":591,"orientation":436},[1863,1864,1865,1866,1867,1868],{"label":574,"description":575},{"label":577,"description":578},{"label":580,"description":581},{"label":583,"description":584},{"label":586,"description":587},{"label":589,"description":590},{"id":593,"data":1870,"type":42},{"text":595,"level":237},{"id":597,"data":1872,"type":218},{"text":599},{"id":601,"data":1874,"type":437},{"steps":1875,"title":628,"orientation":436},[1876,1877,1878,1879,1880,1881,1882,1883],{"label":605,"description":606},{"label":608,"description":609},{"label":611,"description":612},{"label":614,"description":615},{"label":617,"description":618},{"label":620,"description":621},{"label":623,"description":624},{"label":626,"description":627},{"id":630,"data":1885,"type":42},{"text":632,"level":237},{"id":634,"data":1887,"type":225},{"body":636,"title":637,"variant":231},{"id":639,"data":1889,"type":218},{"text":641},{"id":643,"data":1891,"type":218},{"text":645},{"id":647,"data":1893,"type":218},{"text":649},{"id":651,"data":1895,"type":290},{"content":1896,"stretched":43,"withHeadings":14},[1897,1898,1899,1900,1901,1902,1903],[655,656,657],[659,660,661],[663,664,665],[667,668,669],[671,672,673],[675,676,677],[679,680,681],{"id":683,"data":1905,"type":225},{"body":685,"title":686,"variant":348},{"id":688,"data":1907,"type":42},{"text":690,"level":237},{"id":692,"data":1909,"type":218},{"text":694},{"id":696,"data":1911,"type":218},{"text":698},{"id":700,"data":1913,"type":42},{"text":702,"level":237},{"id":704,"data":1915,"type":290},{"content":1916,"stretched":43,"withHeadings":14},[1917,1918,1919,1920,1921,1922,1923,1924,1925],[708,709,710],[712,713,714],[716,717,718],[720,721,722],[724,725,726],[728,729,730],[732,733,734],[736,737,738],[740,741,742],{"id":744,"data":1927,"type":42},{"text":746,"level":237},{"id":748,"data":1929,"type":218},{"text":750},{"id":752,"data":1931,"type":437},{"steps":1932,"title":779,"orientation":436},[1933,1934,1935,1936,1937,1938,1939,1940],{"label":756,"description":757},{"label":759,"description":760},{"label":762,"description":763},{"label":765,"description":766},{"label":768,"description":769},{"label":771,"description":772},{"label":774,"description":775},{"label":777,"description":778},{"id":781,"data":1942,"type":42},{"text":783,"level":237},{"id":785,"data":1944,"type":298},{"rows":1945,"title":819,"layout":290,"columns":1956},[1946,1948,1950,1952,1954],{"id":293,"label":789,"values":1947},{"not":791,"why":792,"term":793},{"id":296,"label":617,"values":1949},{"not":796,"why":797,"term":798},{"id":800,"label":623,"values":1951},{"not":802,"why":803,"term":804},{"id":806,"label":807,"values":1953},{"not":809,"why":810,"term":811},{"id":813,"label":814,"values":1955},{"not":816,"why":817,"term":818},[1957,1958,1959],{"id":822,"label":823},{"id":825,"label":826},{"id":828,"label":516},{"id":830,"data":1961,"type":42},{"text":832,"level":237},{"id":834,"data":1963,"type":218},{"text":836},{"id":838,"data":1965,"type":218},{"text":840},{"id":842,"data":1967,"type":218},{"text":844},{"id":846,"data":1969,"type":42},{"text":848,"level":237},{"id":850,"data":1971,"type":218},{"text":852},{"id":854,"data":1973,"type":218},{"text":856},{"id":858,"data":1975,"type":218},{"text":860},{"id":862,"data":1977,"type":42},{"text":864,"level":237},{"id":866,"data":1979,"type":218},{"text":868},{"id":870,"data":1981,"type":218},{"text":872},{"id":874,"data":1983,"type":218},{"text":876},{"id":878,"data":1985,"type":42},{"text":880,"level":237},{"id":882,"data":1987,"type":882},{"items":1988,"title":913},[1989,1990,1991,1992,1993,1994,1995],{"id":886,"answer":887,"question":888},{"id":890,"answer":891,"question":892},{"id":894,"answer":895,"question":896},{"id":898,"answer":899,"question":900},{"id":902,"answer":903,"question":904},{"id":906,"answer":907,"question":908},{"id":910,"answer":911,"question":912},{"id":915,"data":1997,"type":42},{"text":917,"level":237},{"id":919,"data":1999,"type":919},{"title":921,"entries":2000},[2001,2002,2003,2004,2005,2006,2007,2008],{"term":924,"anchor":293,"definition":925},{"term":927,"anchor":928,"definition":929},{"term":931,"anchor":296,"definition":932},{"term":934,"anchor":935,"definition":936},{"term":814,"anchor":813,"definition":938},{"term":940,"anchor":941,"definition":942},{"term":944,"anchor":495,"definition":945},{"term":947,"anchor":948,"definition":949},{"id":951,"data":2010,"type":42},{"text":953,"level":237},{"id":955,"data":2012,"type":218},{"text":957},{"id":959,"data":2014,"type":967},{"link":961,"meta":2015},{"image":2016,"title":965,"description":966},{"url":964},{"id":969,"data":2018,"type":967},{"link":971,"meta":2019},{"image":2020,"title":974,"description":975},{"url":964},{"id":977,"data":2022,"type":967},{"link":979,"meta":2023},{"image":2024,"title":982,"description":983},{"url":964},{"id":985,"data":2026,"type":967},{"link":987,"meta":2027},{"image":2028,"title":990,"description":991},{"url":964},{"id":993,"data":2030,"type":967},{"link":995,"meta":2031},{"image":2032,"title":998,"description":999},{"url":964},{"id":1001,"data":2034,"type":967},{"link":1003,"meta":2035},{"image":2036,"title":1006,"description":1007},{"url":964},{"id":1009,"data":2038,"type":967},{"link":1011,"meta":2039},{"image":2040,"title":1014,"description":1015},{"url":964},{"id":1017,"data":2042,"type":967},{"link":1019,"meta":2043},{"image":2044,"title":1022,"description":1023},{"url":964},{"id":1025,"data":2046,"type":967},{"link":1027,"meta":2047},{"image":2048,"title":1030,"description":1031},{"url":964},"Post erfolgreich abgerufen",{"items":2051,"source":2080,"manualIds":2081,"manualMatchedIds":2082},[2052,2059,2066,2073],{"id":2053,"slug":2054,"title":2055,"excerpt":2056,"featuredImage":2057,"publishedAt":2058},"455","zbt-z8102ax-dual-sim-failover-test","Conmutación por error de doble SIM del ZBT Z8102AX: qué funciona, qué falta y qué necesita un mejor firmware","El ZBT Z8102AX es un router OpenWrt 5G de doble SIM, pero el hardware de doble SIM por sí solo no es lo mismo que una conmutación por error inteligente. El router reconoce la SIM y se conecta correctamente, pero el cambio automático, la recuperación del módem, las decisiones basadas en la señal y una lógica de conmutación por error limpia aún necesitan pruebas más profundas.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":2060,"slug":2061,"title":2062,"excerpt":2063,"featuredImage":2064,"publishedAt":2065},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","Guía Definitiva de Criterios de Aceptación para la Adopción de LLM en Playbooks Empresariales","Domina el arte de definir criterios de aceptación precisos para garantizar una integración exitosa de LLM en tu entorno empresarial. Esta guía integral proporciona marcos accionables, ejemplos y mejores prácticas adaptados para la adopción impulsada por playbooks.","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2067,"slug":2068,"title":2069,"excerpt":2070,"featuredImage":2071,"publishedAt":2072},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Dominando el flujo de trabajo SEO: Estrategias de optimización esenciales para el crecimiento orgánico","Un flujo de trabajo SEO estructurado es crucial para un crecimiento orgánico sostenible. Aprende las diez estrategias fundamentales, desde la investigación de palabras clave y la optimización técnica hasta la calidad del contenido y el análisis de rendimiento.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":2074,"slug":2075,"title":2076,"excerpt":2077,"featuredImage":2078,"publishedAt":2079},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","IA generativa explicada: modelos, recuperación, herramientas y aplicaciones no son lo mismo","La IA generativa es más que un modelo. Aprende cómo los modelos, la recuperación, las herramientas, el contexto, los entornos de ejecución y las aplicaciones encajan en los sistemas de IA en producción.","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z","fallback",[],[]]