Risposta.

Storia della domanda:

Inizialmente, il focus della formalizzazione dei requisiti era sulle funzionalità, ma nel tempo è diventato chiaro che i criteri "invisibili" a prima vista (prestazioni, sicurezza, resilienza, ecc.) sono critici per l'implementazione e la vita dei prodotti. Ignorarli portava a malfunzionamenti e comportamenti imprevedibili del software dopo il lancio.

Problema:

I requisiti non funzionali sono spesso registrati in modo standardizzato, senza studiare il contesto. Vengono indicati per "dovere" o formulati in modo troppo astratto, ad esempio: "Il sistema deve essere facile da usare" o "Il sistema deve essere veloce". Questo non fornisce a sviluppatori, architetti e tester KPI chiari.

Soluzione:

Il sistemista analista conduce sessioni con il business, IT e specialisti delle operazioni per identificare le vere limitazioni, registra metriche numeriche (ad esempio, SLA, TPS, indicatori di latenza), descrive i requisiti non funzionali in modo esplicito nelle specifiche e garantisce la loro testabilità attraverso il collegamento con casi di test e artefatti architettonici del progetto.

Caratteristiche chiave:

Utilizzo di caratteristiche quantitative (misurabili!).
Inclusione di una fase di formalizzazione e giustificazione attraverso il consenso con esperti IT chiave.
Collegamento dei requisiti con i metodi di test.

Domande insidiose.

Si possono lasciare gruppi di requisiti semplicemente come "Il sistema deve essere disponibile 24/7" senza dettagli?

No, è necessario chiarire i parametri di disponibilità (ad esempio, 99,95%) e le condizioni di ripristino.

È sufficiente indicare "il tempo di risposta deve essere veloce"?

No, tali formulazioni non sono praticabili. È necessario specificare, ad esempio: Tempo di risposta < 3 secondi per il 95% delle richieste con carico X.

I requisiti non funzionali sono formalizzati se scritti solo nel documento di specifica generale senza ulteriori dettagli?

No, devono essere decompositi e collegati alle soluzioni architettoniche e ai piani di test, altrimenti rimarranno non realizzabili o non validabili.

Errori tipici e anti-pattern

Lasciare formulazioni vaghe che non consentono il testing.
Copiare i requisiti da altri progetti senza analizzare la specificità.
Ignorare le consultazioni con IT/SRE e operazioni.

Esempio dalla vita reale

Caso negativo: Il progetto di e-banking è stato avviato con il requisito "disponibilità 24/7, lavoro veloce", senza specificare SLA.

Vantaggi:

Preparazione rapida dei requisiti

Svantaggi:

Malfunzionamenti frequenti, controversie irrisolvibili con il fornitore
Reclami dei clienti

Caso positivo: L'analista ha lavorato con il dipartimento operativo, ha fissato il 99,9% di uptime, tempo di risposta massimo 2 secondi, ha descritto gli scenari di degrado.