Sì. I requisiti di prestazioni e scalabilità possono avere un grande impatto sull'architettura generale, quindi è assolutamente da prendere in considerazione.

Ma attenzione. Le decisioni architetturali a scopo di prestazioni e scalabilità sono spesso basate sulla superstizione e possono ostacolare seriamente un progetto. Come " Ovviamente abbiamo bisogno di un database NoSQL distribuito, altrimenti non scalerà! ". Nella mia esperienza, le cattive decisioni architettoniche fatte per il gusto di guadagni immaginati sono un problema altrettanto grande quanto la mancanza di considerazioni sulle prestazioni.

• Definire requisiti realistici e quantificabili. Non solo "il più velocemente possibile".
• Non introdurre una tecnologia se non si ha la prova positiva che effettivamente migliorerà le prestazioni / scalabilità.
• Non introdurre una tecnologia a meno che non ne abbia effettivamente bisogno. Per esempio. un certo schema potrebbe migliorare le prestazioni di un sottosistema 10x - ma se l'area non è un collo di bottiglia in ogni caso il miglioramento complessivo potrebbe essere trascurabile.
• Soddisfa sempre i vantaggi in termini di prestazioni e costi in termini di tempo e agilità degli sviluppatori. Per esempio. un'app web scritta in C ++ sarà probabilmente più veloce di una in Python, ma sarà anche molto più costosa da sviluppare e forse più significativamente, impiegherà più tempo per adattarsi ai mutevoli requisiti.
• Evita micro-ottimizzazioni come la peste.
• Pianifica in base a ciò che dovrebbe essere possibile nel tempo. Cioè potresti non aver bisogno di dire una cache distribuita fin dall'inizio, ma dovresti progettare l'architettura, quindi non preclude l'introduzione di una cache distribuita in un secondo momento. Qui YAGNI entra nel quadro: se progettate l'architettura generale con una chiara stratificazione, separazione delle preoccupazioni e così via, tali misure saranno molto più facili da implementare quando necessario.

Direi che i requisiti non funzionali, le prestazioni, la scalabilità, la sicurezza, la protezione dei dati ecc. sono le cose fondamentali a cui un architetto di software dovrebbe pensare il giorno 1

Il cliente non ha intenzione di richiederli, gli sviluppatori possono probabilmente gestire qualsiasi problema con i requisiti funzionali senza il tuo aiuto e se lasci queste cose fino alla fine possono essere dolorosi da inserire.

L'architetto dovrebbe pianificare le cose in modo che il sistema funzioni bene quando è finito. non solo lavoro.

Pensare in anticipo e anticipare i problemi difficili oltre al semplice 'funziona sulla mia macchina' è l'essenza del lavoro.

Ad esempio; in un incontro con il cliente o il PM, mi aspetto che l'architetto guidi su requisiti non funzionali con domande come:

• "quanti utenti di picco ci aspettiamo?"
• "quali dati utente dobbiamo memorizzare?"
• "Suggerisco questa impostazione di sicurezza, ne siamo soddisfatti?"

E davvero avere le risposte pronte prima che chiedano.

I requisiti non funzionali devono essere richiesti al cliente esattamente come i requisiti funzionali. Tutti i requisiti non funzionali dovrebbero essere rappresentati nelle storie degli utenti o nelle specifiche del sistema. In questo modo, l'architetto deve considerare i requisiti (funzionali e non funzionali) durante l'architettura del sistema. Non è esplicitamente il ruolo dell'architetto del software quello di soddisfare questi requisiti.

Detto questo, spesso mancano requisiti in elicitazione (funzionale o non funzionale), e probabilmente i requisiti non funzionali vengono saltati più spesso. Tutti gli stakeholder sono responsabili di esprimere preoccupazioni riguardo ai requisiti non funzionali mancanti. L'architetto può avere maggiore familiarità con i requisiti comuni non funzionali e l'architetto deve assicurarsi che i requisiti non funzionali per il sistema non vengano persi e che siano rappresentati nelle specifiche. I requisiti non funzionali avranno un impatto sulla pianificazione del progetto così come lo saranno i requisiti funzionali, quindi è importante enumerarli e trattarli con la stessa importanza dei requisiti funzionali. L'architetto non dovrebbe architettare per non-requisiti.

È interessante leggere la varietà di risposte diverse qui sul ruolo di un architetto del software e su come l'architettura del software gioca nel progetto. Serve solo a mostrare quante diverse scuole di pensiero esistono sul concetto.

Attributi di qualità del sistema

Le tipiche "personalità" vengono in mente quando si discute il concetto di qualità del sistema. Sono gli attributi qualitativi di un sistema che un architetto si sforza di ottimizzare. Questi sono intrinsecamente soggettivi e difficili da definire. Ciò inoltre li rende difficili da testare poiché il risultato non è sempre perfettamente chiaro. Per rendere le cose ancora più complicate, l'ottimizzazione di una qualità può essere una svantaggio di un'altra qualità, quindi spesso devono essere forniti i compromessi e le motivazioni per cui stiamo decidendo di progettare gli uni sugli altri (ad esempio Performance vs. Sicurezza). Questi rientrano nella categoria più ampia di Requisiti Non Funzionali.

Requisiti significativi dal punto di vista dell'architettura

Questi sono un sottoinsieme di tutti i Requisiti Funzionali e Non Funzionali che hanno qualche tipo di influenza o influenza sulle decisioni architettoniche e di progettazione di un sistema. Alcuni di questi requisiti potrebbero anche essere requisiti non funzionali derivati dagli attributi di qualità del sistema, altri potrebbero essere requisiti funzionali derivati dall'azienda o dal proprietario del prodotto.

Chiamarli in un'architettura è importante per la tracciabilità delle decisioni di progettazione rispetto ai requisiti. Un'architettura è molto più che la semplice descrizione di un sistema da uno o più punti di vista, ma anche una serie di argomenti e motivazioni in base al perché determinate decisioni sono state prese rispetto ad altre.

Chi è responsabile per i requisiti non funzionali?

Questa è una domanda scottante che entra nelle menti di molte persone e la risposta potrebbe essere diversa a seconda della tua organizzazione, del modo in cui organizzi i progetti e se usi le metodologie Waterfall o Agile.

In definitiva, la risposta è che i Requisiti Non Funzionali non possono provenire da un singolo stakeholder, tuttavia devono essere raccolti e suscitati da un numero di diversi stakeholder e quindi combinati in un singolo documento o in un backlog. Ad esempio:

NF1: The ABC service shall respond to requests in no longer than 5 seconds

NF2: The ABC service shall be synchronous and should not respond to or consume messages until a response is formed for the prior message.

Nei due esempi sopra, possono essere derivati da diverse fonti. Il primo requisito potrebbe provenire dal business. Si stanno interfacciare con una stanza di compensazione che ha un severo requisito SLA per i partecipanti alla rete.

Il secondo esempio è più di un dettaglio tecnico, ma nondimeno definisce alcuni attributi del sistema che devono essere seguiti. Le decisioni progettuali specifiche su come soddisfare questo requisito sono lasciate aperte, solo il requisito è descritto. Questo requisito può essere realizzato dall'architetto quando si considerano le qualità del sistema relative all'integrità dei dati nel sistema. In alternativa, l'architetto può realizzare attributi, vincoli e limiti di un sistema di interfacciamento a cui l'architettura deve tenere conto e difendersi. In tal caso, forse il mandato per la sincronicità si riduce a un fallimento per i messaggi che devono essere correttamente tradotti quando si interfaccia con un altro sistema di backend.

L'azienda o il cliente potrebbero non aver realizzato questo requisito senza l'assistenza dell'architetto.

Cosa viene prima? Architettura o requisiti?

Sapendo che i Requisiti Funzionali sono tipicamente derivati dall'azienda o dal cliente e che i Requisiti Non Funzionali possono provenire da molte fonti, e considerando che Requisiti Architettonicamente Significativi sono importanti per definire l'Architettura, è chiarire che i requisiti, almeno ad un livello elevato, sono un input importante per l'architettura delle applicazioni e il design delle soluzioni.

All'inizio di un nuovo progetto, i requisiti non funzionali non sarebbero normalmente in prima linea nella mia mente, il mio obiettivo sarebbe la produttività e stabilire un ciclo di feedback rapido, in particolare:

• Aiuta il Product Owner a trovare il modo più veloce per ottenere rapidamente un feedback iniziale da parte dei clienti. Il proprietario del prodotto potrebbe voler iniziare con un prototipo o un prototipo, oppure ciò potrebbe significare la definizione di un set di funzionalità mininmal per la versione iniziale.
• Inizia a creare il linguaggio onnipresente e descrivi concetti di alto livello, in modo che tutti i membri del team possano comunicare chiaramente i requisiti.
• Stabilire un architecto di alto livello in modo che tutti, in prima persona, siano chiari su come verranno implementate le funzionalità.
• Lavora con Ops per costruire una pipeline di distribuzione automatizzata con qualsiasi ambiente necessario.

Questo a volte viene indicato come Sprint Zero . Questo non è solo il lavoro degli architetti: l'architettura dovrebbe essere una responsabilità condivisa con tutti gli sviluppatori del team.

Vale la pena di essere a conoscenza di requisiti non funzionali (ad esempio scalabilità, disponibilità, sicurezza) all'inizio di un progetto, tuttavia in questa fase sono davvero una preoccupazione secondaria, con l'obiettivo principale di evitare di "dipingersi in un angolo". Il valore primario del software è la capacità di migliorare rapidamente il software nel tempo: se si è in grado di apportare rapidamente modifiche, è possibile rinviare l'implementazione dei requisiti non funzionali fino al momento in cui diventano preziosi.

Per un software arcitect, i requisiti funzionali sono solo dettagli. A livello architettonico stiamo pensando all'astrazione e le esigenze non funzionali diventano più importanti.

Questo non vuol dire che l'architetto non presta attenzione ai dettagli ... informano il design complessivo della soluzione.

Concentrandoti e progettando l'astrazione, è certamente possibile modificare i componenti a livello di dettaglio. Caso in questione, una volta ho progettato un sistema che utilizzava code di messaggi per gestire il flusso di dati, e mesi dopo dovevo passare alle tabelle di database a causa di un cliente che aveva problemi con le licenze. A livello astratto stavo semplicemente spostando i dati da un punto a un altro nel sistema e se ciò avveniva in coda o in tabella era solo un dettaglio di implementazione.