Gestione dei requisiti
La pratica di Gestione dei requisiti è un approccio sistematico per individuare, documentare, organizzare e seguire i requisiti di un sistema con le modifiche relative.
Descrizione principale

Cosa è la gestione dei requisiti?

La Gestione dei requisiti è un approccio sistematico per individuare, documentare, organizzare e seguire i requisiti di un sistema con le modifiche relative.

Un requisito viene definito come "una condizione o una capacità alla quale il sistema si deve conformare".

La gestione dei requisiti viene formalmente definita come un approccio sistematico a quanto segue:

  • deduzione, organizzazione e documentazione dei requisiti del sistema
  • Stipula e gestione di un accordo fra il cliente ed il team del progetto al mutare dei requisiti del sistema

La chiave per una gestione efficace dei requisiti include mantenere un chiaro manifesto dei requisiti, insieme agli attributi appropriati e alla tracciabilità di altri requisiti ed altri artefatti del progetto.

La raccolta dei requisiti può sembrare un'attività piuttosto lineare. In realtà, tuttavia, i progetti incorrono in difficoltà per i motivi di seguito indicati:

  • I requisiti non sono sempre ovvi e possono provenire da molte fonti.
  • I requisiti non sono sempre espressi in modo facile o chiaro in parole.
  • Esistono molti tipi diversi di requisiti in diversi livelli di dettaglio.
  • Il numero di requisiti può divenire ingestibile, se non controllato.
  • I requisiti sono correlati gli uni agli altri ed anche ad altri componenti distribuibili del processo di progettazione software.
  • I requisiti dispongono di proprietà o di valori di proprietà univoci. Ad esempio, non sono ugualmente importanti né ugualmente semplici da soddisfare.
  • Esistono molte parti interessate, il che significa che i requisiti devono essere gestiti da gruppi di persone interfunzionali.
  • I requisiti cambiano.

Pur ponendo la massima attenzione possibile nella definizione dei requisiti, ci saranno sempre degli elementi che cambiano. Ciò che rende difficile la gestione delle modifiche dei requisiti non è solo che un requisito cambiato significa che è stato impiegato del tempo nell'implementazione di una nuova particolare funzione, ma anche che la modifica ad un requisito può avere un impatto su altri requisiti. La gestione delle modifiche include attività quali stabilire una linea di base, determinare quali sono le dipendenze di cui è importante tenere traccia, stabilire la tracciabilità fra le voci correlate e implementare il controllo delle modifiche.

In quale modo lo sviluppo viene guidato dai casi d'uso?

Il metodo consigliato per organizzare i requisiti funzionali è l'utilizzo dei casi d'uso. Anziché utilizzare un elenco puntato di requisiti, organizzarli in modo che descrivano come poter utilizzare il sistema. Ciò fornisce una maggiore completezza e coerenza, oltre che una maggiore comprensione dell'importanza di un requisito dalla prospettiva dell'utente.

Da un modello di sistema a oggetti tradizionale è spesso difficile stabilire il modo in cui un sistema esegue quanto previsto. Tale difficoltà deriva dalla mancanza di un "thread rosso" nel sistema quando esegue certe attività. In RUP (Rational Unified Process), i casi d'uso rappresentano tale thread poiché definiscono il comportamento di un sistema. I casi d'uso non fanno parte del tradizionale orientamento ad oggetti, tuttavia hanno acquisito un importanza persino più evidente. Ciò è ulteriormente sottolineato dal fatto che i casi d'uso fanno parte del linguaggio UML (Unified Modeling Language).

RUP utilizza un approccio guidato dai casi d'uso, il che significa che i casi d'uso definiti per un sistema sono la base per l'intero processo di sviluppo.

I casi d'uso hanno un ruolo in varie discipline.

  • Il concetto di caso d'uso può essere utilizzato per rappresentare i processi di business. Tale variante di caso d'uso viene definita "caso d'uso di business". Questo tipo di caso d'uso è trattato nella disciplina Modellazione del business.
  • I casi d'uso, come requisiti software sono descritti nella disciplina Requisiti. I casi d'uso costituiscono un concetto fondamentale che deve essere accettabile per il cliente, gli sviluppatori e i tester del sistema.
  • Nella disciplina Gestione progetto i casi d'uso vengono utilizzati come base per la pianificazione dello sviluppo iterativo.
  • I casi d'uso vengono realizzati nel modello di progettazione come parte della disciplina Analisi e progettazione. Le realizzazioni di casi d'uso descrivono il modo in cui il caso d'uso è supportato nella progettazione in termini di oggetti interattivi nel modello di progettazione.
  • I casi d'uso, infine, diventano scenari implementati e verificabili e, pertanto, sono un importante punto focale delle discipline Implementazione e Test. Queste vengono utilizzate per ricavare casi d'uso e script di test; la funzionalità del sistema viene verificata eseguendo scenari di test che utilizzano ciascun caso d'uso.
  • Nella disciplina Distribuzione i casi d'uso costituiscono un elemento fondamentale per ciò che viene descritto nelle guide per l'utente. I casi d'uso possono essere utilizzati anche per definire unità di ordinazione del prodotto. Ad esempio, un cliente può ricevere un sistema configurato con un certo insieme di casi d'uso.