Linea guida: Piano di gestione requisiti
Un piano di gestione requisiti definisce le principali relazioni degli stakeholder e le relative responsabilità, voci di tracciabilità, gestione delle modifiche dei requisiti ed i report e le misurazioni relativi ai requisiti. Questa linea guida è utile per lo sviluppo di un piano di gestione dei requisiti completo ed efficace.
Relazioni
Descrizione principale

Relazione con gli altri piani

Il piano di gestione requisiti contiene informazioni che possono essere trattate, in modo più o meno approfondito, anche in altri piani.

Per una guida sulla personalizzazione, consultare il Prodotto di lavoro: Piano di gestione requisiti - Personalizzazione.

Organizzazione, responsabilità ed interfacce

Come descritto nel White paper: Applicazione della gestione requisiti ai casi d'uso, la gestione dei requisiti è importante per garantire il successo del progetto.  Le cause più comuni citate per il fallimento di un progetto sono:

  • Mancanza di input da parte dell'utente
  • Requisiti incompleti
  • Cambiamento dei requisiti

Anche gli errori relativi ai requisiti sono con tutta probabilità la classe di errore più comune e sono i più dispendiosi da correggere.

Una giusta relazione con gli stakeholder può essere utile con questo tipo di problemi.Gli stakeholder sono una fonte chiave di input per la definizione dei requisiti e la comprensione delle priorità dei requisiti. Molti stakeholder, tuttavia, mancano di consapevolezza relativa all'impatto sui costi e sui tempi delle funzioni richieste, e quindi l'organizzazione di sviluppo deve gestire le aspettative degli stakeholder.

Stabilire le relazioni con gli stakeholder include la definizione di:

  • Responsabilità degli stakeholder: il personale sarà disponibile sul posto per dei consulti? In orari prestabiliti?
  • Visibilità degli stakeholder nei prodotti di lavoro del progetto: libera visibilità per tutti i prodotti di lavoro? Visibilità limitata solo ai punti cardine pianificati?

Identificazione delle voci di tracciabilità

Descrivere le voci di tracciabilità e definire come devono essere denominate, contrassegnate e numerate. Consultare Concetto: Tipi di requisiti e Concetto: Tracciabilità.

Le voci di tracciabilità più importanti sono elencate nel Compito: Sviluppo del piano di gestione requisiti.

Specifica della tracciabilità

Una tracciabilità tipica, con una serie limitata di prodotti di lavoro essenziali, è descritta nel Compito: Sviluppo del piano di gestione requisiti.

Oltre ad identificare i collegamenti di tracciabilità, è necessario specificare la cardinalità dei collegamenti. Alcuni dei vincoli comuni sono:

  • Ogni funzione approvata del prodotto deve essere collegata ad uno o più requisiti supplementari oppure ad uno o più casi d'uso, o a entrambi.
  • Ogni requisito supplementare ed ogni sezione del caso d'uso devono essere collegati ad uno o più scenari di test.

Una trattazione più approfondita della tracciabilità è fornita nel white paper Strategie di tracciabilità per la gestione dei requisiti con il caso d'uso.

Esempi di attributi

Quelli che seguono sono degli esempi di attributi selezionabili, organizzati utilizzando i tipi di requisiti identificati nel Compito: Sviluppo del piano di gestione requisiti.

Esigenza dello stakeholder

Origine: lo stakeholder da cui ha origine il requisito. (Può anche essere implementato come tracciabilità per una voce di tracciabilità "Stakeholder").

Contributo: indica il contributo del problema all'opportunità globale di business o il problema di cui si occupa il progetto. Percentuale (da 0 a 100%). Tutti i contributi non devono totalizzare più del 100%. Di seguito è riportato un esempio di Diagramma di Pareto, che mostra il contributo relativo ad ognuna delle diverse esigenze degli stakeholder.

Grafico con l'impatto relativo di 5 problemi all'opportunità globale di business

Funzioni, requisiti supplementari e casi d'uso

Stato: indica se il requisito è stato revisionato ed accettato dal "canale ufficiale". Esempi di valori sono Proposto, Respinto, Approvato.

Potrebbe trattarsi di uno stato contrattuale o di uno stato impostato da un gruppo di lavoro in grado di prendere decisioni di collegamento.

Vantaggio: l'importanza dal punto di vista dello stakeholder.

  • Critico (o primario). Sono le attività principali del sistema, la sua funzione base e le funzioni per il quale è stato sviluppato. Se mancano, il sistema non riesce ad adempiere alla sua missione primaria. Guidano la progettazione strutturale e tendono ad essere i casi d'uso provati più spesso.
  • Importante (o secondario). Si tratta di funzioni di sistema di supporto, come la compilazione statistica dei dati, la creazione di report, al supervisione e la verifica funzionale. Se mancano, il sistema può ancora adempiere (per un po') alla sua missione principale ma con una qualità di servizi inferiore. Nella modellazione, verrà loro assegnata un'importanza minore di quella dei casi d'uso critici
  • Utile. Queste sono funzioni di "comodo", non collegate alla missione primaria del sistema ma utili per il suo utilizzo o per la collocazione commerciale.

Impegno: i giorni di impegno lavorativo stimato per implementare il requisito.

Ad es. potrebbe essere classificato come Basso, Medio, Alto. Per esempio, Basso = < 1 giorno, Medio = 1-20 giorni, Alto = >20 giorni.

Nella definizione di Impegno lavorativo devono essere indicate chiaramente quali spese generali (impegno per la gestione, impegno per i test, impegno per i requisiti ecc.) sono incluse nella stima.

Dimensione: le righe di codice stimate (SLOC), non di commento, escluso l'eventuale codice per il test.

Si può distinguere fra SLOC nuovo e riutilizzato, per poter calcolare meglio le stime dei costi.

Rischio: probabilità in % che l'implementazione del requisito comporti eventi significativi indesiderati come lo slittamento dei tempi, superamento dei costi o l'annullamento.

Ad es. potrebbe essere classificato come Basso, Medio, Alto. Per esempio Bassa = <10%, Media = 10-50%, Alta = >50%.

Un'altra opzione per il Rischio è seguire separatamente il rischio tecnologico -  probabilità in % di incorrere in serie difficoltà con l'implementazione del requisito a causa di mancanza di esperienza nel dominio e/o nelle tecnologie richieste. Il rischio globale quindi può essere calcolato come una somma ponderata basata su altri attributi, incluso la dimensione, l'impegno, la stabilità, il rischio tecnologico, l'impatto strutturale e la complessità organizzativa.

Complessità organizzativa: classificazione del controllo sull'organizzazione che sviluppa il requisito.

  • Interna: sviluppo interno in una sede
  • Geografica: team distribuito geograficamente
  • Esterna: organizzazione esterna all'interno della compagnia.  
  • Fornitore: subappalto o acquisto di software sviluppato esternamente.

Impatto strutturale: indica il tipo di impatto che avrà il requisito sull'architettura del software.

  • Nessuno: non influisce sull'architettura esistente.
  • Estende: richiede l'estensione dell'architettura esistente.
  • Modifica: l'architettura esistente deve essere modificata per poter inserire il requisito.  

Stabilità: probabilità che il requisito cambi o che cambi l'interpretazione del requisito da parte del team di sviluppo. (>50% = Alta, 10..50% = Media, <10%=Bassa)

Rilascio previsto: il rilascio del prodotto in cui si prevede verrà implementato il requisito. (Rilascio1, Rilascio1.1, Rilascio2, ...)

Livello di pericolo/Criticità: la possibilità di inficiare sulla salute, sul benessere o sulle finanze, in genere come risultato del software che non va in esecuzione come richiesto.

  • Trascurabile: non può causare danni fisici al personale né danni alle attrezzature.
  • Marginale: può essere controllato, senza danni fisici al personale o significativi danni al sistema.
  • Critico: può causare danni fisici al personale o danni significativi al sistema, oppure richiede un'immediata azione correttiva per la sicurezza del personale o del sistema.
  • Catastrofico: può causare seri danni o morte, o una completa perdita del sistema.

I pericoli possono anche essere identificati come dei tipi di requisiti separati ed essere collegati a dei casi d'uso associati. E' possibile inoltre seguire la probabilità di pericolo, le azioni correttive e/o le misure preventive.

Interpretazione: In alcuni casi dove i requisiti formano un contratto formale, può essere difficile e dispendioso modificare la formulazione dei requisiti.  Quando l'organizzazione dello sviluppo ottiene una migliore comprensione di un requisito, potrebbe essere necessario allegare del testo di interpretazione, piuttosto che modificare semplicemente la formulazione ufficiale del requisito.

Caso d'uso

In aggiunta a quanto specificato prima, è utile anche tenere traccia del seguente attributo del caso d'uso:

% di dettagli: grado in cui è stato elaborato il caso d'uso:

  • 10%: viene fornita una descrizione di base.
  • 50%: vengono documentati i flussi principali.
  • 80%: completato ma non rivisto. Sono pienamente specificate tutte le condizioni antecedenti e postume.
  • 100%: rivisto e approvato.

Scenario di test

Stato: segue l'avanzamento durante lo sviluppo del test.

  • Nessuna attività: non è stato eseguito alcun lavoro per lo sviluppo di questo scenario di test.
  • Manuale: è stato creato uno script manuale e convalidato come capace di verificare i requisiti associati.
  • Automatizzato: è stato creato uno script automatizzato e convalidato come capace di verificare i requisiti associati.

Attributi generali

Ulteriori attributi dei requisiti con applicabilità generale sono:

  • Iterazione pianificata
  • Iterazione effettiva
  • Parte responsabile

Selezione degli attributi

Gli attributi vengono utilizzati per tenere traccia delle informazioni associate ad una voce di tracciabilità, in genere per conoscere lo stato e per la creazione di report. Ciascuna organizzazione potrebbe richiedere delle informazioni di traccia specifiche, uniche per la propria organizzazione. Prima di assegnare un attributo, considerare:

  • Chi fornirà queste informazioni?
  • Chi utilizzerà queste informazioni e perché sono utili?
  • Il costo implicato nel seguire queste informazioni vale il vantaggio che se ne ricava?

Gli attributi essenziali per la traccia sono Rischio, Vantaggio, Impegno, Stabilità e Impatto strutturale, per poter consentire l'assegnazione di una priorità ai requisiti per la gestione dell'ambito e per assegnare i requisiti alle iterazioni. Devono essere tracciati inizialmente nelle funzioni, in seguito in tutti i casi d'uso e i requisiti supplementari.

Informazioni derivate

Oltre ad utilizzare direttamente gli attributi dei requisiti, si possono ricavare le informazioni dagli attributi di requisiti tramite la tracciabilità di altri tipi di requisiti. Alcuni tipici pattern di derivazione sono:

  • Derivazione verso il basso - Con la tracciabilità menzionata prima, si supponga che una funzione del prodotto abbia l'attributo "Rilascio previsto". E' possibile derivare che ogni sezione di caso d'uso tracciata da questa funzione del prodotto deve essere disponibile al momento del rilascio previsto specificato, o prima.
  • Derivazione verso l'alto - Con la tracciabilità menzionata prima, si supponga che una sezione del caso d'uso abbia l'attributo "Impegno stimato". Il costo di una funzione del prodotto può essere stimato sommando l'impegno stimato per le sezioni del caso d'uso di cui tiene traccia. Questa derivazione deve essere utilizzata con molta attenzione, perché più funzioni del prodotto potrebbero essere associate alla stessa sezione del caso d'uso.

Quindi, per poter assegnare gli attributi dei requisiti ai tipi di requisiti, considerare:

  • Quali informazioni/report derivati si desiderano creare da questo attributo?
  • A che livello della gerarchia di tracciabilità deve essere tracciato questo attributo?

Dipendenza degli attributi

Alcuni attributi possono essere applicati solo ad un determinato livello di sviluppo. Ad esempio, un attributo impegno stimato per un caso d'uso può essere sostituito dalle stime di impegno sugli elementi della progettazione quando il caso d'uso è pienamente rappresentato nella progettazione.

Report e misure

Di seguito sono riportati degli esempi di report e misure correlati ai requisiti. Selezionando l'insieme di report e misure richiesti/desiderati per il progetto, è possibile derivare gli attributi necessari per il piano di gestione requisiti.

Descrizione report/misura Utilizzato per
Priorità di sviluppo dei casi d'uso (elenco di casi d'uso ordinato per Rischio, Vantaggio, Impegno, Stabilità e Impatto strutturale). Possono essere degli elenchi ordinati separati o un singolo elenco ordinato secondo una combinazione ponderata di questi attributi. Utilizzato per il Compito: Assegnazione di priorità ai casi d'uso.
Percentuale di funzioni in ciascuna categoria di stato. Tiene traccia dell'avanzamento durante la definizione della linea di base del progetto.
 - classificato dal Rilascio previsto  - tiene traccia dell'avanzamento in base al rilascio
 - ponderato dall'Impegno  - fornisce una misurazione più precisa dell'avanzamento.
Funzioni ordinate per Rischio  - identifica le funzioni rischiose. Utile per la gestione dell'ambito e per l'assegnazione delle funzioni alle iterazioni.
 - classificato dal Rilascio previsto, con il Rischio di sviluppo sommato per ogni Rilascio previsto  - utile per valutare se le funzioni rischiose sono state pianificate all'inizio o alla fine del progetto.
Sezioni del caso d'uso ordinate per Stabilità  - utilizzato per decidere quali sezioni del caso d'uso devono essere stabilizzate.
 - ponderato o ordinato in base a Influisce sull'architettura  - utile per assegnare ai casi d'uso strutturalmente significativi e/o ad alto impegno lavorativo la priorità di stabilizzazione.
Requisiti con gli attributi non definiti Quando i requisiti vengono inizialmente proposti, è possibile non assegnare immediatamente tutti gli attributi (ad es. utilizzando il valore predefinito "Non definito"). L'elenco di controllo: Specifica dei requisiti software utilizza questo report per cercare eventuali attributi non definiti.
Voci di tracciabilità con collegamenti di tracciabilità incompleti Un report di collegamenti di tracciabilità non corretti o incompleti viene utilizzato per l'Elenco di controllo: Specifica dei requisiti software.

Gestione delle modifiche dei requisiti Inizio pagina

I cambiamenti sono inevitabili e devono essere pianificati. Possono verificarsi quando:

  • C'è stata una modifica al problema da risolvere. Potrebbe esser dovuto a nuove regolamentazioni, pressioni economiche, cambiamenti di tecnologie, ecc.
  • Gli stakeholder hanno cambiato idea o è cambiata la percezione di ciò che desiderano che il sistema sia in grado di svolgere. Questo può accadere per una serie di cause diverse, incluso un cambiamento del personale responsabile, una maggiore comprensione delle problematiche, ecc.
  • Durante la definizione dei requisiti originali non sono stati inclusi tutti gli stakeholder o non sono state poste tutte le giuste domande.

Le strategie di gestione dei cambiamenti dei requisiti includono:

  • Creare una linea di base con i requisiti
  • Stabilire un unico canale di controllo delle modifiche
  • Gestire una cronologia delle modifiche

Creazione di una linea di base con i requisiti Inizio pagina

Verso il termine della fase di elaborazione, l'analista di sistema deve creare una linea di base con tutti i requisiti noti. In genere viene eseguito verificando che sui prodotti di lavoro dei requisiti sia presente una versione di controllo e identificando l'insieme di prodotti di lavoro e le relative versioni che formano la linea di base.

Lo scopo della linea di base non è di "congelare" i requisiti. Piuttosto di consentire l'identificazione, la segnalazione, la stima ed il controllo dei requisiti nuovi e modificati.

Consultare anche Guida al tool: Creazione di una linea di base con un progetto Rational RequisitePro.

Stabilire un unico canale di controllo delle modifiche

Il desiderio di uno stakeholder di effettuare un cambiamento non significa che cambi ufficialmente il budget e i tempi. In genere prima di approvare una modifica deve essere avviato un processo di negoziazione o riconciliazione del budget. Spesso le modifiche devono controbilanciarsi le une con le altre.

E' di cruciale importanza che ogni modifica passi attraverso un singolo canale, il CCB (Change Control Board), per determinarne l'impatto sul sistema e per essere sottoposta ad approvazione ufficiale. Il meccanismo per proporre una modifica è di inoltrare una richiesta di modifica, che viene esaminata dal CCB.

Per ulteriori informazioni consultare Compito: Creazione del processo di controllo delle modifiche.

Gestire una cronologia delle modifiche

E' utile conservare una traccia di controllo delle modifiche dei singoli requisiti. Questa cronologia delle modifiche consente di esaminare tutte le modifiche precedenti apportate al requisito, oltre alle modifiche dei valori degli attributi ed il fondamento logico della modifica. Questo può risultare utile per la valutazione della stabilità effettiva dei requisiti e per identificare i casi in cui il processo di controllo delle modifiche non ha funzionato (ad esempio per identificare le modifiche di requisiti che non sono state riviste e approvate in modo appropriato).