Un sistema pot fer exactament allò que se li va demanar —complir tots els seus requisits funcionals— i tot i així ser un fracàs: perquè és lent, cau cada setmana, no resisteix un atac o costa una fortuna mantenir-lo. Tot això ho governen els atributs de qualitat, també anomenats requisits no funcionals. Són, en gran mesura, allò que l'arquitectura busca aconseguir: el "com de bé" davant del "què fa". En aquesta lliçó aprendràs a identificar-los, a distingir-los dels requisits funcionals i, sobretot, a especificar-los de manera mesurable mitjançant escenaris de qualitat, perquè un atribut que no es pot mesurar no es pot dissenyar ni verificar.

1. Funcionals davant de no funcionals
2. Catàleg d'atributs de qualitat
3. El problema dels requisits vagues
4. Escenaris de qualitat: com especificar-los
5. Tàctiques arquitectòniques per aconseguir-los
6. Conflictes entre atributs

Convé tenir clara la frontera des del principi.

Els requisits no funcionals també es coneixen com a atributs de qualitat, NFR (Non-Functional Requirements) o -ilities en anglès (scalability, availability, etc.). Són responsabilitat directa de l'arquitectura: la funcionalitat es pot implementar de moltes maneres, però només algunes estructures aconsegueixen la disponibilitat o el rendiment exigits.

Existeixen taxonomies formals (per exemple, la norma ISO/IEC 25010). A continuació, els atributs més rellevants a la pràctica:

Nota sobre disponibilitat: el percentatge d'uptime té conseqüències molt concretes en temps de caiguda tolerat a l'any.

Cada "nou" addicional dispara el cost i la complexitat. Per això és un atribut que s'ha de negociar amb el negoci, no fixar-lo al màxim "per si de cas".

Compara aquestes dues maneres d'expressar el mateix requisit:

• Vague: "El sistema ha de ser ràpid."
• Mesurable: "El 95% de les cerques de productes han de respondre en menys de 300 ms amb 1.000 usuaris concurrents."

El primer és inútil: ràpid per a qui, en quina operació, sota quina càrrega, amb quin objectiu? No es pot dissenyar contra ell ni verificar si es compleix. El segon és mesurable, específic i verificable. La regla d'or és:

Un atribut de qualitat que no és mesurable no és un requisit, és un desig.

El SEI (Software Engineering Institute) proposa els escenaris de qualitat com a forma estàndard d'especificar atributs no funcionals. Un escenari té sis parts:

Llegit de corrido: "Un usuari extern llança una cerca de productes en el servei de catàleg en hora punta amb 1.000 usuaris concurrents; el sistema retorna els resultats en menys de 300 ms el 95% de les vegades."

Podem representar-ho de manera estructurada:

Aquest YAML formalitza l'escenari perquè es pugui discutir i verificar. L'important no és el format concret, sinó que cada escenari inclogui les sis parts. El camp percentil: 95 és clau: especificar un percentil (P95, P99) en lloc d'una mitjana evita enganys, perquè una mitjana baixa pot amagar un petit percentatge de peticions desastrosament lentes que arruïnen l'experiència.

Un escenari de disponibilitat es podria escriure així:

Aquí l'estímul no ve d'un usuari, sinó d'una fallada interna (la caiguda d'una instància). La resposta esperada és que el sistema es recuperi automàticament redirigint el trànsit, amb un objectiu de disponibilitat del 99,9% i un temps de recuperació màxim de 30 segons. Especificar-ho així permet dissenyar i provar la tolerància a fallades de manera concreta.

Una tàctica és una decisió de disseny que influeix en un atribut de qualitat concret. Algunes d'habituals:

• Rendiment: memòria cau, índexs, balanceig de càrrega, processament asíncron.
• Disponibilitat: redundància, failover automàtic, health checks, circuit breakers.
• Escalabilitat: escalat horitzontal (més instàncies), particionat de dades (sharding), cues per absorbir pics.
• Seguretat: autenticació i autorització, xifratge en trànsit i en repòs, principi de mínim privilegi.
• Mantenibilitat: baix acoblament, alta cohesió, modularitat, proves automatitzades.

Aquest exemple Java implementa de manera molt simplificada el patró circuit breaker (tallacircuits), una tàctica clàssica de disponibilitat. La idea: si un servei remot falla llindar vegades seguides (fallidesConsecutives >= llindar), el circuit s'"obre" (obert = true) i deixem de cridar-lo, retornant una resposta degradada immediata en lloc d'esperar que torni a fallar. Això evita que un servei caigut arrossegui tot el sistema (efecte dòmino) i li dona temps per recuperar-se. En producció s'usarien llibreries madures com Resilience4j, però el concepte és aquest.

Els atributs de qualitat gairebé mai no són independents: millorar-ne un sol perjudicar-ne un altre. Per això l'arquitectura és l'art dels compromisos (que veurem en detall en la lliçó següent).

La conclusió pràctica és que no existeix l'arquitectura "òptima" en abstracte: existeix l'arquitectura adequada per a un conjunt prioritzat d'atributs de qualitat. Per això la primera feina de l'arquitecte és aconseguir que el negoci prioritzi: què importa més, el cost o la disponibilitat?, la velocitat o la consistència perfecta?

• Deixar els NFR per al final. Els atributs de qualitat s'han de capturar a l'inici, perquè condicionen tota l'estructura. Afegir disponibilitat a un sistema que no es va dissenyar per a ella és caríssim.
• Especificar-los de manera vaga. "Ràpid", "segur", "escalable" no són requisits. Usa escenaris de qualitat amb mesures concretes.
• Demanar el màxim en tot. Voler cinc nous de disponibilitat, latència mínima i cost mínim alhora és contradictori. Cal prioritzar.
• Usar mitjanes en lloc de percentils. Una mitjana amaga els casos pitjors. Mesura P95/P99.
• Consell: converteix cada NFR en quelcom verificable. Si no saps com mesurar que es compleix, reescriu-lo fins que puguis.

Exercici 1. Reescriu el requisit vague següent en un escenari de qualitat amb les seves sis parts: "El sistema de login ha de ser segur i ràpid".

Exercici 2. Una botiga en línia exigeix un 99,99% de disponibilitat. Quant de temps de caiguda a l'any tolera, aproximadament? Quines dues tàctiques proposaries per assolir-lo i quin atribut es veuria perjudicat?

Exercici 3. Identifica el conflicte entre atributs en aquesta decisió: "Xifrarem totes les dades a la base de dades i validarem cada camp en tres capes diferents". Quin atribut millora i quin se'n ressent?

Solució 1. Exemple d'escenari per a la part de rendiment del login: Font: un usuari registrat. Estímul: envia les seves credencials. Artefacte: el servei d'autenticació. Entorn: operació normal amb 500 usuaris concurrents. Resposta: valida les credencials i retorna un token de sessió. Mesura: en menys de 500 ms el 99% de les vegades. (Per a la part de seguretat es redactaria un altre escenari a part, p. ex.: davant de 5 intents fallits en 1 minut des de la mateixa IP, el sistema bloqueja el compte i registra l'esdeveniment de seguretat.)

Solució 2. El 99,99% tolera aproximadament 52,6 minuts de caiguda a l'any. Tàctiques possibles: redundància amb diverses instàncies en diferents zones i failover automàtic amb balancejador i health checks. L'atribut perjudicat és principalment el cost (més infraestructura i replicació), i secundàriament la complexitat/mantenibilitat operativa.

Solució 3. Millora la seguretat (xifratge i validació exhaustiva). Se'n ressent el rendiment: el xifratge/desxifratge i la triple validació afegeixen latència i consum de CPU en cada operació. També pot afectar la mantenibilitat si la validació està duplicada en tres capes sense una única font de veritat.

Has après a distingir requisits funcionals de no funcionals, a manejar un catàleg d'atributs de qualitat, a especificar-los de manera mesurable amb escenaris de qualitat de sis parts, a aplicar tàctiques per aconseguir-los i a reconèixer que gairebé sempre entren en conflicte entre si. Precisament aquest xoc permanent entre atributs —disponibilitat contra cost, rendiment contra consistència— és el cor de la feina arquitectònica. En la lliçó següent abordarem de front com es prenen aquestes decisions difícils: les decisions arquitectòniques i els compromisos (trade-offs), incloent-hi mètodes formals d'avaluació com ATAM.