Attività: Gestione modifica requisiti
Questa attività gestisce le modifiche ai requisiti e valuta il loro impatto in genere.
DescrizioneElemento di interruzione del lavoroAssegnazione teamUtilizzo del prodotto di lavoro
Scopo
Lo scopo di questa attività consiste nel valutare l'impatto delle modifiche richieste sui requisiti e di gestire l'impatto del downstream delle modifiche approvate da mettere in pratica.
Relazioni
Attività parent
Descrizione

Questa attività è indirizzata a quanto segue:

Le modifiche ai requisiti naturalmente influiscono sugli artefatti del downstream (ad es., prodotti di lavoro analisi e progettazione, prodotto di lavoro test, sviluppo artefatti ecc). Le relazioni di  Tracciabilità identificate e documentate durante  Gestione dipendenze definisce esplicitamente le relazioni tra i requisiti e gli altri prodotti di lavoro. Queste relazioni rappresentano la chiave per la comprensione dell'impatto delle modifiche dei requisiti.

Proprietà
Attivato da eventoYes
Ricorrenze multiple
In corso
Facoltativo
Pianificato
Ripetibile
Personale

Coinvolgimento del team esteso (stakeholder: rappresentante del cliente, esperti di dominio e altri). Include come Revisore tecnico chiunque nel team del progetto software il cui lavoro sia influenzato dalla modifica). Assicurarsi di gestire in modo efficace le risorse di revisione.  Non includere l'intero team esteso a meno che non si possa assicurare di aggiungere valore al progetto.

Il team esteso deve incorporare una buona conoscenza del dominio del problema, le difficoltà tecniche del progetto, nonché skill nella gestione dei requisiti e modellazione del caso d'uso.

Utilizzo
Guida all'uso

Questa attività dovrebbe essere eseguita quando i requisiti sono perfezionati.

Revisioni regolari, insieme ad attributi di requisiti e dipendenze, andrebbero eseguite quando vengono eseguiti gli aggiornamenti ai requisiti.

Si consiglia di organizzare una revisione del Modello del caso d'uso per ogni iterazione nelle fasi di inizio ed elaborazione, dove si revisiona il lavoro in atto; questo viene fatto e rilasciato inizialmente dagli utenti prima di sviluppare i Casi d'uso in dettaglio ed è un punto cardine molto importante, così che le risorse non sono impiegate nello sviluppo di casi d'uso non corretti. Quindi, alla fine della fase di elaborazio nel bisognerebbe organizzare una revisione dettagliata del modello del caso d'uso. Ricordare che alla fine della fase di elaborazione, è necessario avere un modello del caso d'uso, e possibilmente un modello di dominio che rappresenta il Glossario, che è completo all'80%. E' inoltre necessario organizzare una revisione del modello del caso d'uso per ogni iterazione nelle fasi di costruzione e transizione quando il modello del caso d'uso viene perfezionato. La revisione dovrebbe concentrarsi sulla parte del modello del caso d'uso sviluppato per l'iterazione.

Considerazioni chiave

Il team di sviluppo di base deve condurre poche revisioni interne: l'azzeramento delle incongruenze non necessarie prima del loro lavoro viene ispezionato e revisionato in modo più formale dal team esteso.

Bisognerebbe dividere il materiale fino a che il team non rivede tutto subito. Un meeting di revisione non dovrebbe impiegare più di un giorno. Ad esempio, se si vogliono condurre revisioni separate dell'interfaccia utente o scenari comportamentali o se si vogliono rivedere tutti gli artefatti dei requisiti correlati ad un certo sottosistema.

Un'altra importante considerazione è il controllo della cronologia del requisito. Catturando la natura ed il fondamento logico delle modifiche dei requisiti, i revisori ricevono le informazioni necessarie per rispondere correttamente alla modifica.