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