Linea guida: Decisioni importanti nei requisiti
Queste linee guida descrivono importanti elementi da considerare nella personalizzazione degli aspetti dei requisiti del processo.
Relazioni
Descrizione principale

Decidere le modalità di utilizzo dei prodotti di lavoro

Determinare quali prodotti del lavoro  utilizzare e le relative modalità d'impiego.  Oltre ad identificare i prodotti del lavoro da utilizzare, è importante anche personalizzarli in modo da farli aderire alle necessità del progetto. 

La tabella riportata di seguito specifica i prodotti del lavoro dei requisiti raccomandati e quelli facoltativi (da utilizzare ad esempio solo in certi casi). Per ulteriori considerazioni sulla personalizzazione, consultare la sezione relativa nella pagina descrittiva del prodotto del lavoro.

Prodotto di lavoro Scopo Personalizzazione (Facoltativo, Raccomandato)

Prodotto di lavoro: Modello di casi d'uso (Prodotto di lavoro: Attore, Prodotto di lavoro: Caso d'uso, Prodotto di lavoro: Pacchetto di casi d'uso)

I casi d'uso vengono utilizzati per definire i requisiti funzionali.

Consigliato per la maggior parte dei progetti.

I casi d'uso rappresentano il metodo consigliato per la cattura dei requisiti funzionali.

Prodotto di lavoro: Storyboard

I progetti con requisiti comportamentali non compresi veramente, potrebbero considerare la creazione di storyboard come un mezzo per dedurre i requisiti.

Facoltativo

E' possibile utilizzare altre tecniche di deduzione dei requisiti.

Prodotto di lavoro: Glossario Garantisce che chiunque, nel progetto, utilizzi un vocabolario comune.

Consigliato per la maggior parte dei progetti.

Prodotto di lavoro: Attributi requisiti Un database di attributi requisiti è d'aiuto per garantire che ai requisiti venga attribuita la priorità appropriata, che vengano seguiti e che ne sia tenuta traccia.

Facoltativo

Tuttavia, su progetti con un numero relativamente piccolo di requisiti, potrebbe non essere strettamente necessario un database di attributi requisiti.

Prodotto di lavoro: Piano di gestione dei requisiti Descrive le informazioni da raccogliere ed i meccanismi di controllo da utilizzare per la misurazione, la registrazione ed il controllo delle modifiche ai requisiti del prodotto. E' necessario un documento separato se la complessità di gestione dei requisiti o la visibilità del cliente lo autorizza.

Facoltativo

I progetti con un numero di requisiti relativamente piccolo potrebbero intraprendere un approccio leggero alla gestione dei requisiti il che può essere documentato direttamente nel piano di sviluppo software.

Altri progetti potrebbero selezionare e seguire un approccio più rigoroso, ma produrre una descrizione piccola oppure non formale. Ad esempio, l'insieme degli attributi requisiti da raccogliere potrebbe essere implicitamente documentato dalla configurazione dei tool.

Prodotto di lavoro: Specifica dei requisiti software Utilizzato per raccogliere l'insieme di tutti i requisiti in un documento formale fornito al cliente.

Facoltativo

In progetti meno formali, potrebbe non essere richiesto un documento formale.

Prodotto di lavoro : richieste degli stakeholder Cattura tutte le richieste effettuate sul progetto, oltre a come vengono indirizzate.

Consigliato per la maggior parte dei progetti.

Per creare un sistema che incontri le esigenze degli stakeholder, è importante sollecitare e riesaminarne le richieste.

Molti progetti gestiscono le richieste dello stakeholder come una semplice categoria di richieste di modifica. Altri progetti potrebbero catturare le richieste dello stakeholder solo informalmente.

Prodotto di lavoro: Specifiche integrative Utilizzato per catturare i requisiti non funzionali.

Consigliato per la maggior parte dei progetti.

 Prodotto di lavoro: Visione Cattura i requisiti di massimo livello ed i vincoli di progettazione, per offrire al lettore un'interpretazione del sistema da sviluppare.

Consigliato per la maggior parte dei progetti.


Decidere i report da utilizzare

La decisione relativa ai report da utilizzare dipenderà dai tool dei report disponibili nel progetto. Se i tool di generazione report sono disponibili, si consiglia di generare i report per prodotti di lavoro orientati al modello o al database, come casi d'uso e attori. I report esistenti nella configurazione RUP sono disponibili dalle pagine di descrizione del prodotto di lavoro e raggruppati sotto il prodotto di lavoro relativo nel browser della struttura ad albero.

Decidere le modalità di conservazione dei "Requisiti di input"

Questa sezione di applica solo se, un contratto formale, un documento di specifica o standard impone i requisiti all'impegno di gestione dei requisiti. Vi si fa riferimento come alla "specifica requisiti di input".

Durante l'impegno dei requisiti, catturare i requisiti in questi documenti: Prodotto di lavoro: Visione, Prodotto di lavoro: Richieste degli stakeholder, Prodotto di lavoro: Modello di casi d'uso, Prodotto di lavoro: Specifiche integrative.

Decidere se la specifica dei requisiti di input verrà conservata o meno. Si desidera tornare indietro e aggiornare la specifica dei requisiti di input nel caso in cui si rilevi che un requisito è difettoso, sbagliato o inesatto? È inoltre necessario decidere come mantenere tracce o riferimenti tra la specifica della richiesta di input ed ilProdotto del lavoro: caso d'uso.

Scegliere una o una combinazione delle seguenti strategie:

  • Non aggiornare la specifica del requisito di input. Lasciare che i casi d'uso e la specifica integrativa specifichino le azioni successive del sistema.
  • Non aggiornare la specifica dei requisiti di input, ma conservare la Tracciabilità dai casi d'uso, tornando indietro.
  • Aggiornare la specifica dei requisiti di input con tutti i costi ed i lavori relativi.
  • Lasciare che la specifica dei requisiti di input evolva in una specifica integrativa che contiene i requisiti. I requisiti di input funzionali vengono trasferiti semplicemente ai casi d'uso.

Per la maggior parte dei progetti si ritiene che poiché il numero dei requisiti difettosi, inesatti o sbagliati sia così elevato, che non ha senso conservare la specifica dei requisiti di input originale. Solo in pochissimi progetti, i clienti sono disponibili a pagare per l'aggiornamento della specifica dei requisiti si input con le nuove informazioni raccolte durante la modellazione del caso d'uso.

Non enfatizzare questo argomento troppo presto. All'inizio di un progetto, si è fiduciosi riguardo alla specifica dei requisiti di input, tuttavia, dopo aver lavorato nell'area del problema con un caso d'uso, si acquista una diversa opinione relativamente alla specifica dei requisiti iniziale.

Decidere come approvare i casi d'uso

Decidere come approvare i casi d'uso. E' possibile risparmiare molto tempo limitando il numero dei casi d'uso che devono essere formalmente esaminati dal cliente. E' forse possibile che il cliente accetti di esaminare formalmente solo un sottoinsieme di tutti i casi d'uso.

Scegliere una o più delle strategie seguenti:

  • E' necessario che tutti i casi d'uso superino revisioni esterne formali con rappresentanti esterni al progetto.
  • E' possibile approvare alcuni casi d'uso secondari in un modo semplificato, con una revisione informale o con una revisione formale interna.

I casi d'uso secondari sono essenziali per il sistema ma non per il compito dell'utente primario; ad esempio, casi d'uso relativi alla gestione ed alla manutenzione del sistema, come l'aggiunta di utenti al sistema, la modifica dell'autorità relativa e l'esecuzione di backup. Il sistema non funziona senza questi casi d'suo, sebbene non siano di primario interesse per gli utenti principali.

La strategia utilizzata dipende dalla relazione con il cliente. I clienti hanno fiducia che i casi d'uso verranno utilizzati correttamente anche senza un processo di approvazione formale? Sebbene ciò consentirebbe di risparmiare una considerevole quantità di tempo, si raggiungerà la qualità corretta del modello di caso d'uso?

Nota: Una soluzione al problema potrebbe coinvolgere il cliente nell'impegno requisiti. Coinvolgendo i rappresentanti dei clienti, sarà possibile approvare o fornire raccomandazioni ad altri clienti, e coinvolgendo il cliente, il progetto guadagnerà credibilità.

Per ulteriori informazioni sui livelli di revisione, consultare Linea guida: Livelli di revisione.