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.
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.
|