Risposta.

Storia della domanda:

Inizialmente nei progetti IT, gli analisti di sistema si concentravano principalmente sui requisiti di business, mentre le limitazioni tecniche venivano trasmesse o ignorate, portando a soluzioni non funzionanti o eccessivamente costose.

Problema:

Le limitazioni tecniche non sono sempre dichiarate: il cliente potrebbe non esserne a conoscenza, lo sviluppo potrebbe non tenerne conto, e il risultato potrebbe essere in contraddizione con le capacità dell'infrastruttura o dei sistemi di integrazione.

Soluzione:

L'analista di sistema intervista attivamente architetti, DevOps, QA e integratori:

• Definisce stack tecnologici, dipendenze di business e infrastruttura.
• Allinea i requisiti con i principi architetturali: SLA, resilienza, scalabilità, limitazioni di licenza o sicurezza.
• Documenta e valida i compromessi tra le possibilità e le esigenze del business.
• Applica approcci come "Scenario-based analysis" e "Non-functional requirements".

Caratteristiche chiave:

• Fissazione precoce di limitazioni e dipendenze con tutte le parti responsabili.
• Documentazione di compromessi e limitazioni implicite.
• Verifica continua delle soluzioni progettuali con l'architettura aziendale.

Domande ingannevoli.

Posso ignorare le limitazioni tecniche implicite se non sono espresse direttamente?

Corretto: No. Le limitazioni tecniche implicite (come i timeout di integrazione, il limite sulle dimensioni dei messaggi) richiedono sempre di essere elaborate e fissate, anche se non espresse chiaramente.

Deve l'analista partecipare a calls/workshop architetturali?

Corretto: Sì, l'analista di sistema è un anello di congiunzione tra business e architetti, trasmette i requisiti a entrambe le parti e fissa le decisioni.

È sufficiente raccogliere solo i requisiti di business senza analizzare le limitazioni ereditate?

Corretto: Non è sufficiente. Il codice ereditato, le licenze, le integrazioni (legacy) spesso impongono molte più limitazioni rispetto ai requisiti esplicitamente definiti.

Errori tipici e anti-pattern

• Sottovalutazione delle limitazioni nascoste e delle dipendenze dei vecchi sistemi.
• Ignorare le "regole non scritte" dell'architettura.
• Fissazione solo della parte business senza considerare la realizzabilità tecnica.

Esempio dalla vita reale

Caso negativo: L'analista ha fissato un'integrazione per un processo aziendale, ma non ha chiesto delle limitazioni sulla velocità di trasmissione dei dati nell'interfaccia.

Pro: Implementazione rapida della specifica. Contro: Il sistema non ha retto il carico, il business ha perso tempo e denaro.

Caso positivo: L'analista ha partecipato a sessioni architetturali, ha identificato limitazioni (massimo flussi = 100, integrazione una volta ogni 10 secondi), ha concordato con il business i limiti critici.

Pro: Soluzione funzionante, integrazione stabile. Contro: È stato necessario ridurre parzialmente le funzionalità e giustificarlo al cliente.