Classificazione dei requisiti: FOCUS-TBD

Non esiste un unico modo corretto per classificare i requisiti software per tipologia:

  • ogni schema di classificazione riflette un particolare punto di vista, specifiche esperienze, sensibilità peculiari da parte di chi lo ha creato
  • a volte i requisiti possono rientrare in più di una dimensione semantica

Ho strutturato questo schema di classificazione in otto categorie principali, e con un acronimo facile da ricordare (FOCUS-TBD):

  • Funzionalità
  • Operatività
  • Conformità
  • Usabilità
  • Sicurezza
  • Tempi
  • Budget
  • Documentazione, manutenzione e supporto

Alcune tra le categorie di questo schema (ad esempio tempi, budget, conformità con standard e architetture esistenti, ecc.) vengono considerate da alcuni come “vincoli”, non Come “requisiti”.

Io preferisco non usare il termine “vincolo”. Un “vincolo”, secondo il mio modo di vedere, è un requisito non negoziabile. Capita, nella realtà, che alcuni requisiti ritenuti vincoli insormontabili, quando entrano in conflitto con altri requisiti più importanti per il committente, smettono di essere dei vincoli, e possono essere modificati o eliminati.

Lo schema è descritto in dettaglio, con definizioni ed esempi, nella guida Requisiti-by-Example , ed è usato nella template di elenco requisiti (disponibile in formato excel).


Dettaglio dello schema di classificazione

Funzionalità

Operatività

Conformità

Usabilità

Sicurezza

Tempi di progetto

Budget di progetto

Documentazione, manutenzione e supporto