È ragionevole scrivere requisiti non funzionali come questo. Ma i tuoi partner hanno ragione che questo non è banale da misurare.
È importante ricordare come funzionano le reti. Per effettuare una chiamata API REST potrebbe essere necessario eseguire la ricerca DNS, eseguire un handshake TLS, trasmettere una richiesta, attendere fino a quando la richiesta viene elaborata e ricevere la risposta. Tutti quei passaggi richiedono tempo. A parte l'elaborazione del server, questi tempi dipendono in gran parte dalla latenza della rete (colloquialmente il "ping") e in parte dalla larghezza di banda disponibile.
Ai fini di un requisito, possiamo ora definire uno scenario di test in cui tali variabili sono fisse. Per esempio. possiamo supporre: un ping a round trip piuttosto atroce di 400ms. I dati trasmessi hanno dimensioni trascurabili. Una connessione è già stata stabilita. Possiamo quindi esprimere un requisito come "In una connessione di rete con un tempo di andata e ritorno non superiore a 400 ms, il tempo per il primo byte per ogni richiesta è inferiore a 450 ms". Questo lascia 50ms per il software del server per fare il suo lavoro.
In alternativa, possiamo supporre che le temporizzazioni siano prese direttamente di fronte al server di destinazione, in modo che la rete sia trascurabile. I tempi di risposta potrebbero quindi essere raccolti continuamente e visualizzati su un cruscotto. Potremmo esprimere questo requisito come "Ignorando gli effetti di rete, il server risponde a qualsiasi richiesta entro 50 ms".
A volte si verificano circostanze eccezionali, ad esempio perdita di pacchetti. Quindi non è ragionevole esigere che questo requisito sia soddisfatto per ogni connessione, solo per la maggior parte delle connessioni. L'utilizzo di un tempo di risposta medio non è sufficiente perché molte richieste potrebbero comunque presentare tempi di risposta molto lunghi, ma la loro media non verrà calcolata. Invece, è comune usare un percentile. L'uso del percentile 95% o 99% è comune. Poiché si tratta di una metrica statistica, è necessaria una finestra di campionamento, ad esempio 1 minuto. Ora potremmo chiarire questo requisito:
In qualsiasi finestra temporale di 60 secondi, il tempo di risposta del 95 ° percentile del server deve essere inferiore a 50 ms. Questa misura ignora qualsiasi effetto di rete come la latenza.
Si noti che il numero di richieste su quel periodo di tempo deve essere sufficientemente elevato da rendere significativo il percentile scelto. Per esempio. se quel periodo di tempo vede solo 5 richieste, allora il tempo di risposta del 95 ° percentile è più o meno lo stesso del peggior tempo di risposta, ma quella metrica è molto sensibile ai valori anomali e quindi inadatta. Volete più di una manciata di eventi al di sopra del percentile scelto perché questa metrica sia significativa. Per ottenere questo puoi aumentare il tempo di campionamento per ottenere più eventi o diminuire il percentile scelto, ma entrambe le azioni diminuiscono la sensibilità di questa metrica.
La specifica dei tempi di risposta misurabili è importante perché ora è possibile determinare se c'è un servizio degradato o un'interruzione. Per esempio. i tempi di risposta di 80 secondi sono assolutamente inaccettabili per la maggior parte dei casi d'uso. Mentre il servizio potrebbe tecnicamente funzionare, non soddisfa le tue esigenze. Quando il servizio non riesce a soddisfare il tempo di risposta richiesto, si tratta di tempi di inattività che potrebbero essere imputati al contratto di uptime / livello di servizio concordato.