Quality Attributes Overview

Qué son y por qué importan

Quality Attributes son propiedades relevantes del sistema que permiten evaluar su adecuación para stakeholders y contexto. Su satisfacción puede influir en responsabilidades, fronteras, comunicación, datos, deployment y operación. La relación entre propiedades evaluables y necesidades de stakeholders se desarrolla en Software Architecture in Practice, capítulo 4.

Performance, availability, reliability, security, modifiability, testability, deployability, operability, interoperability, portability y cost efficiency son ejemplos. No constituyen una lista universal ni exhaustiva. Lo importante es identificar qué significado tiene cada preocupación para este sistema y qué evidencia permitiría evaluarla.

Una arquitectura puede funcionar correctamente en una demostración y resultar inadecuada bajo carga, durante recuperación o ante cambios comprometidos. También puede satisfacer una expectativa técnica que nadie necesita mientras consume recursos necesarios para otra prioridad. El análisis comienza por contexto y objetivos, no por maximizar etiquetas.

Functionality y quality se influyen

Functionality describe aproximadamente qué hace el sistema; quality describe bajo qué condiciones y con qué propiedades lo hace. Es una distinción útil para conversar, pero no establece independencia perfecta.

Process Payment puede implementarse mediante colaboraciones diferentes según requisitos de latencia, disponibilidad, auditabilidad, seguridad y costo. Confirmar inmediatamente y conciliar después no ofrece necesariamente el mismo resultado que confirmar solo después de registrar una intención durable. La quality requerida puede obligar a precisar la función.

A su vez, los límites funcionales afectan las opciones de calidad. Si una operación debe modificar datos de varios propietarios bajo una promesa conjunta, no podemos analizar su latencia o recuperación ignorando esa colaboración. Describir responsabilidades concretas evita separar artificialmente comportamiento y cualidades.

Más allá de los adjetivos

«El sistema debe ser rápido», «debe escalar» y «debe ser seguro» expresan preocupaciones, pero no permiten discriminar arquitecturas. Dos equipos pueden aceptar esas frases e imaginar operaciones, cargas y amenazas diferentes.

Hay que preguntar qué estímulo ocurre, quién lo genera, qué parte queda afectada, en qué condiciones, qué respuesta se espera y cuánto es aceptable. quality-attribute-scenarios organiza esas preguntas como un modelo de seis partes, sin imponer una sintaxis documental.

Un ejemplo ilustrativo pide que 95% de las búsquedas termine dentro de 300 ms con 2.000 usuarios concurrentes. Ese enunciado ofrece un punto de partida verificable. Todavía necesita precisar mezcla de consultas, datos, tasa de llegada, punto de medición y tratamiento de errores. Concurrencia por sí sola no define toda la carga.

Para «seguro», quizá importe impedir que soporte consulte datos fuera de su autoridad y conservar evidencia de los accesos autorizados. El escenario debe identificar contexto y respuesta observable; un atributo general no demuestra qué controles ni qué arquitectura resultan suficientes.

El término Non-functional Requirements

Non-functional requirement, o NFR, es una expresión común pero imperfecta. Puede agrupar preocupaciones diferentes y sugerir erróneamente que solo las funciones describen comportamiento verificable.

Procesar una búsqueda antes de un límite, recuperar una capacidad tras un fallo o completar una modificación con esfuerzo acordado son respuestas observables. «Non-functional» no significa vago ni imposible de probar. Tampoco Quality Attribute y NFR deberían tratarse como equivalentes universales sin recuperar la convención de cada fuente.

Es más útil explicar la necesidad y su evidencia que discutir únicamente su casilla. Una exigencia de autorización puede implicar una función y una propiedad de seguridad; su clasificación no resuelve quién posee autoridad ni cómo se verifica el acceso.

Quality y constraint

Una quality describe una propiedad o respuesta deseada. Una constraint restringe el espacio de soluciones. «Todos los datos de clientes deben permanecer en Argentina» puede limitar almacenamiento, replicación y acceso operativo; «95% de las búsquedas termina dentro de 300 ms» describe una respuesta de performance.

Pregunta	Qué permite examinar
¿Qué resultado y condiciones necesitamos?	Quality requirement o comportamiento requerido.
¿Qué opciones no podemos elegir?	Restricción del espacio de soluciones.
¿Quién impone la condición y por qué?	Origen, autoridad y vigencia.
¿Cómo reconoceremos su satisfacción?	Evidencia y criterio de evaluación.

Las categorías pueden superponerse. Una restricción de residencia responde a un objetivo de gobierno o regulación y puede generar escenarios de acceso, recuperación y auditoría. También condiciona qué estrategias permiten alcanzar latencia o disponibilidad.

No hace falta crear una clasificación perfecta para cada frase. Sí distinguir entre una necesidad y una respuesta técnica elegida. «Debemos usar tres réplicas» puede ser una restricción real o una propuesta todavía no justificada; preguntar por su origen cambia el análisis.

Significancia arquitectónica

No todo requisito de calidad es un Architecturally Significant Requirement, o ASR. architectural-significance ayuda a reconocer cuándo condiciona materialmente decisiones del sistema.

Una modificación local bajo límites existentes puede satisfacer una necesidad sin cambiar arquitectura. Otra exige revisar estructuras, boundaries, tecnologías, datos, comunicación, deployment, failure handling, operación o costo de cambio. El impacto depende del compromiso y del contexto, no de que el requisito incluya la palabra performance.

architectural-drivers conecta esa selección con objetivos, restricciones e influencias prioritarias. Un driver puede surgir de una quality, pero también de capacidades del equipo, contratos externos o condiciones del negocio. La arquitectura debe considerar su interacción.

De objetivos a evidencia

Business goals
    → Requirements / ASRs
    → Architectural drivers
    → Quality attributes
    → Scenarios
    → Prioritization
    → Tactics / decisions
    → Trade-offs
    → Architecture
    → Evidence
        → refine goals, drivers, scenarios and decisions

Este esquema explica relaciones de razonamiento, no un proceso waterfall obligatorio. Un experimento puede mostrar que la medida inicial era inviable; una restricción puede aparecer mientras se compara una decisión; un incidente puede revelar un escenario omitido.

utility-trees ayuda a concretizar y priorizar escenarios. architectural-tactics conecta decisiones enfocadas con respuestas esperadas. quality-attribute-trade-offs examina consecuencias conjuntas. La evidencia puede provenir de análisis, experimentos, pruebas y observación del sistema.

El SEI propone razonar sobre arquitectura mediante requisitos de calidad precisos y escenarios, incluyendo efectos sobre otras propiedades. Reasoning About Software Quality Attributes. Adoptar ese foco no obliga a ejecutar un método completo para cada cambio.

Runtime, evolución y áreas operacionales

Las qualities incluyen runtime y development-time. La respuesta ante un fallo pertenece al primer contexto; modifiability analiza costo y propagación de un cambio concreto. evolvability observa adaptación sostenida; testability obtiene evidencia de comportamiento; deployability evalúa llegada segura a ejecución. Son focos relacionados que necesitan identificar trabajo, entorno y medida, sin declararlos sinónimos.

operability pregunta por comprensión y control durante operación; interoperability, por intercambio y uso correcto entre participantes; portability, por adaptación a otro entorno preservando comportamiento. Señales, conexión y packaging pueden contribuir, pero necesitan escenarios y evidencia propios.

cost-efficiency evalúa costo económico y recursos respecto del servicio requerido; sustainability examina impacto y capacidad de sostener el sistema durante su lifecycle. Requieren denominadores, horizonte y evidencia explícitos. Una factura menor no prueba menor impacto ambiental ni satisfacción de otras prioridades.

Según el Knowledge Map V0.3, aquí viven el tratamiento arquitectónico, los escenarios, drivers, tactics, trade-offs y evaluación. Security, Reliability y Performance pueden tener cuerpos operacionales detallados en otras áreas.

Por eso un escenario de recuperación puede enlazar retry o bulkhead sin duplicar sus políticas. Los documentos existentes conservan su identidad y metadata. Una misma solución puede participar en distintos marcos de análisis sin cambiar arbitrariamente su clasificación editorial.

Uso y errores frecuentes

Este marco aporta cuando necesitamos explicar por qué una arquitectura es adecuada, comparar alternativas o revisar compromisos. No exige inventar métricas para preocupaciones irrelevantes ni modelar todo el catálogo antes de entregar valor.

Errores frecuentes son elegir tecnologías antes de precisar resultados, tratar adjetivos como evidencia y optimizar una cifra ignorando fallos o costos. También convertir la lista de qualities en requisitos igualmente prioritarios, sin stakeholders ni contexto.

architecture-profile ayuda a comparar paquetes de decisiones; ninguna etiqueta garantiza las propiedades deseadas. quality-attributes organiza la navegación del cluster. La pregunta final debe poder conectar objetivo, escenario y evidencia, dejando explícito qué incertidumbre sigue abierta.