Risposta.

L'analista di business è responsabile della raccolta completa, della convalida e della documentazione non solo dei requisiti funzionali, ma anche di quelli non funzionali: velocità di funzionamento del sistema, sicurezza, scalabilità, disponibilità, facilità d'uso dell'interfaccia. Per questo, interagisce strettamente con gli stakeholder (soprattutto con il business e IT), utilizza scenari e analizza gli standard. Deve non solo raccogliere le aspettative esplicite, ma anche identificare i requisiti nascosti (ad esempio, la regolamentazione sulla protezione dei dati). Alla fine, l'analista formalizza i requisiti non funzionali nella documentazione, li approva con il team di progetto e tecnico, e controlla il rispetto di tali requisiti per tutta la durata del progetto.

Caratteristiche chiave:

• Identificazione di requisiti nascosti e specifici attraverso interviste e analisi degli standard
• Assicurazione della documentazione e dell'approvazione dei requisiti non funzionali
• Controllo della conformità dell'implementazione ai criteri non funzionali approvati

Domande ingannevoli.

È sufficiente descrivere i requisiti non funzionali nel testo senza metriche e concretezza?

No, le formulazioni astratte ("veloce", "sicuro") non sono adatte per la validazione. Servono parametri chiari: ad esempio, il tempo di risposta non superiore a 2 secondi.

I requisiti non funzionali sono solo una prerogativa degli specialisti tecnici?

No, l'analista deve identificare e formalizzare tali requisiti insieme al business, poiché il loro mancato rispetto porterà a insoddisfazione nei principali interessi del business.

È possibile rimandare il lavoro sui requisiti non funzionali alle fasi finali del progetto?

No, tali requisiti sono spesso critici per l'architettura della soluzione. La loro identificazione in fasi avanzate porta a rifacimenti e alti costi.

Errori tipici e anti-pattern

• Descrizione implicita, formale o troppo generale delle caratteristiche non funzionali
• Ignorare gli standard di sicurezza, SLA, requisiti legali
• Identificazione tardiva dei requisiti non funzionali con rischio di significativi rifacimenti

Esempio dalla vita reale

Caso negativo: Sono stati descritti nei requisiti attesi "comodità" e "velocità", ma non sono state fissate metriche specifiche. Vantaggi: Meno costoso al momento della redazione del documento Svantaggi: Non è stato possibile presentare reclami al team quando il risultato non ha soddisfatto il cliente.

Caso positivo: È stato concordato: "La velocità di caricamento della pagina deve essere di massimo 2 secondi con un carico fino a 1000 utenti, livello di SLA - 99,95%". Formalizzati i requisiti sulla protezione dei dati personali. Vantaggi: Controllo chiaro del risultato, riduzione dei rischi di rifacimenti, trasparenza per tutti i partecipanti Svantaggi: Ha richiesto tempo e approvazioni con IT e legali.