Avrei bisogno di un consiglio su come ottenere, da parte dei miei colleghi, informazioni sulle loro esigenze in termini di prestazioni. Avrei, inoltre, bisogno di sapere cosa è più indicato chiedere, se le pagine web, il caricamento dei file di dati, le ricerche/estrazioni dai database o i report.
Iniziamo con il definire i requisiti di prestazione come un particolare tipo di attributo di qualità, una categoria di requisiti “non funzionali”.
I requisiti prestazionali definiscono quanto bene il sistema sta svolgendo determinate funzioni in certe particolari condizioni. Alcuni esempi sono la velocità di risposta, il flusso di dati, il tempo di esecuzione e la capacità di memoria.
I livelli di servizio che includono i requisiti prestazionali si basano spesso su funzioni di supporto all’utente finale. Come la maggior parte degli attributi qualitativi, i requisiti prestazionali sono elementi chiave nelle fasi di progettazione e di test del prodotto.
Tali requisiti devono essere presi in considerazione insieme ad altri tipi di attributi di qualità (per es., affidabilità, robustezza, sicurezza e usabilità, oltre che disponibilità, interoperabilità, efficienza e flessibilità).
Alcuni attributi di qualità possono entrare in conflitto l’uno con l’altro e richiedere dei compromessi. Un esempio lo si trova tra i diversi tipi di requisito prestazionale: elevate prestazioni in termini di flusso di dati (capacità di processare il passaggio di un grande volume di informazioni in un dato intervallo di tempo) possono far peggiorare il tempo di risposta. Oppure, la durata delle batterie di un dispositivo hardware (altro requisito di prestazione) può avere un’influenza sull’intensità della luminosità di un display, con potenziale diminuzione della sua usabilità.
Due modi per individuare i requisiti prestazionali sono:
- definire in modo chiaro l’obiettivo del vostro progetto in modo tale da non perdere tempo su requisiti che non sono necessari
- formulare domande sulla base dei vostri modelli di analisi.
I modelli di analisi dovrebbero essere ideati in collaborazione con esperti delle varie aree di business. Questi modelli vi aiutano a scoprire e a omologare le esigenze degli utenti dandovi anche una base per ottenere informazioni circa i requisiti funzionali e non funzionali.
Diamo un’occhiata ad alcuni esempi di utilizzo dei modelli di analisi per ottenere dati sui requisiti necessari:
- Requisiti di comportamento dettagliati nelle mappe di processo o in casi pratici: con quale frequenza si verifica questa attività? Qual è il numero minimo, massimo e medio di esecuzioni per ora/giorno/settimana/mese/anno, o nei periodi di picco? Quando deve essere disponibile questa attività? Qual è il livello minimo, pianificato o desiderato, per quanto riguarda la velocità di flusso?
- Requisiti strutturali definiti nei modelli di dati o di oggetti, richiedete, per ogni area tematica: qual è il numero atteso di interrogazioni al giorno/settimana/mese/anno, o nei periodi di picco. Qual è il tasso di crescita progettato?
- Requisiti di interfaccia, definiti inizialmente su un diagramma contestuale e successivamente elaborati nelle informazioni contenute nei report o nei prototipi di interfaccia: cosa produce questa interfaccia? Con quale frequenza? Per un’interfaccia utente, quali sono le esigenze di usabilità, il livello massimo, minimo, quello pianificato e quello desiderato di completamento di un certo tipo di operazione? Quanto velocemente vi aspettate che i nuovi utenti imparino ad utilizzare il prodotto? Ci sarebbe bisogno di un numero minimo o massimo di battute o di click del mouse per alcune operazioni? Potrebbe essere importante la probabilità di completamento del lavoro? Queste specifiche domande vi aiutano a individuare i requisiti di prestazione come la facilità di apprendimento o di impiego e probabilmente anche di completamento di una serie di operazioni.
- Regole di business, per tutti i modelli: come dovrebbe reagire il sistema in caso di errori? Con quale frequenza potrebbero verificarsi gli errori? Quanto tempo dovrebbe richiedere ad un utente la risoluzione di un errore?
Queste domande rappresentano un buon metodo per ottenere dal mondo del business indicazioni sui requisiti di prestazione. Sono strettamente collegate all’obiettivo funzionale, non presuppongono un progetto né richiedono conoscenze tecniche approfondite. Sono espresse in termini comprensibili dagli esperti dei vari settori di business.
