I requisiti definiscono ciò che un prodotto deve fare — un’aspettativa documentata del risultato della realizzazione di un progetto. Questo documento raccoglie le aspettative del cliente e dello sviluppatore riguardo al programma, alle sue funzioni e al progetto nel suo complesso. I requisiti comprendono caratteristiche, costi, tempi e rischi. Pertanto, i requisiti rappresentano una dichiarazione di ciò che occorre sviluppare, ovvero una descrizione quantitativa precisa di ciò che ci si aspetta di ottenere come risultato della realizzazione del progetto. Una definizione carente dei requisiti è la causa principale dei problemi che sorgono durante l’esecuzione del progetto.
I requisiti specificano cosa deve essere fatto, con quale livello di qualità e sotto quali vincoli. Se i requisiti sono errati, il progetto e il prodotto risulteranno viziati. Requisiti, vincoli e ipotesi scompongono il problema in parti. Ciò determina il successo complessivo del progetto.
Tipi di requisiti:
- I requisiti funzionali definiscono ciò che un determinato elemento del sistema deve fare.
- I requisiti prestazionali definiscono i parametri quantitativi delle funzioni corrispondenti svolte dal sistema.
- I requisiti di vincolo derivano da limitazioni delle modalità operative, dalle condizioni ambientali, da considerazioni di sicurezza o dalla conformità normativa.
- I requisiti di verifica forniscono la certezza che il sistema possieda le caratteristiche specificate nel suo effettivo ambiente operativo.
- I requisiti di interfaccia definiscono le funzioni, le caratteristiche, le tolleranze e i vincoli di tutte le interfacce.
- I requisiti operativi specificano la prontezza operativa del sistema, concentrandosi sulle sue prestazioni, definendo al contempo il modo in cui il sistema interagisce con gli utenti.
Nella letteratura anglosassone si utilizza l’acronimo SMART per ricordare le caratteristiche di un buon requisito.
- Specific (specifico) — i requisiti devono riguardare una sola caratteristica del progetto o proprietà del sistema. Devono essere formulati in termini di cosa deve essere fatto e con quale livello di qualità, ma mai in termini di una possibile soluzione — ossia di come farlo.
- Measurable (misurabile) — un parametro misurabile è espresso in modo oggettivo e quantitativo.
- Achievable (raggiungibile) — un requisito deve essere tecnicamente realizzabile a un costo ragionevole.
- Relevant (pertinente) — un requisito deve corrispondere al livello del sistema prescelto.
- Traceable (tracciabile) — i requisiti di livello inferiore devono derivare esplicitamente da requisiti di livello superiore e/o essere supportati da essi. I requisiti privi di requisiti «genitori» sono considerati «orfani» e la necessità della loro attuazione deve essere valutata.
Necessità. Se sussiste il dubbio che un requisito sia necessario, basta porsi la domanda: «Quale danno subirebbe il sistema se questo requisito non venisse incluso nell’elenco?». Se non si trova una risposta, il requisito è probabilmente superfluo.
Verificabilità. Non appena un requisito viene formulato, è necessario stabilire come possa essere verificato. A tal fine occorre selezionare un criterio di conformità adeguato.
Raggiungibilità. Per essere raggiungibile, un requisito deve essere tecnicamente realizzabile entro i tempi e il budget stabiliti, nel rispetto di ulteriori vincoli. In presenza di incertezza circa la fattibilità tecnica di un requisito, occorre condurre uno studio adeguato o un approfondimento ulteriore. Se l’incertezza persiste anche dopo tale approfondimento, sarebbe opportuno formulare un obiettivo anziché un requisito. È evidente che, anche qualora un requisito sia tecnicamente realizzabile, potrebbe risultare irraggiungibile a causa di costi, tempi o altri vincoli, come il peso. Non ha senso formulare un requisito per qualcosa che è impossibile da realizzare: occorre essere pragmatici.
Chiarezza. Ogni requisito deve esprimere un’unica idea ed essere conciso e semplice. È importante che il requisito sia chiaro e privo di ambiguità. I buoni requisiti spesso non richiedono altro che frasi semplici.
Un requisito deve essere formulato in forma positiva e non deve mai iniziare con una negazione. Deve essere grammaticalmente corretto, privo di errori tipografici e omissioni. È necessario utilizzare una terminologia coerente a tutti i livelli del sistema.