È possibile utilizzare l'attributo Domanda per immettere la domanda che si intende utilizzare durante la revisione degli elementi. Formulare la domanda in modo che, rispondendo Sì, si indica che l'elemento viene approvato. È possibile utilizzare i seguenti punti di controllo durante la revisione di differenti tipi di elementi, ovvero requisiti, casi d'uso, scenari di test e report di risoluzione dei problemi.
Nome | Domanda |
---|---|
Univocità | Il titolo e l'ID del requisito sono univoci? |
Comprensibilità | I lettori riescono a capire i requisiti? |
Ridondanza | Il requisito è privo di informazioni superflue? |
Completezza | Tutti gli attributi sono completi? |
Ambiguità | Il requisito è espresso chiaramente? |
Congruenza | Il requisito è privo di contraddizioni con altri requisiti e con i requisiti di sistema generali? |
Organizzazione | Il requisito si trova nel livello gerarchico corretto? |
Tracciabilità | Il requisito dispone di un requisito di origine e di un requisito di destinazione? |
Verificabilità | Il completamento del requisito è verificabile tramite esecuzione del test, dimostrazione, revisione o analisi? |
Responsabilità | È identificata la persona responsabile del requisito? |
Lingua | Il requisito è privo di errori grammaticali e parole difficili da verificare, quali ad esempio spesso, almeno e talvolta? |
Tipo | Il requisito è un requisito e non una soluzione di implementazione o progetto? |
Duplicati | Il significato del requisito è univoco? |
Suddivisione | Il requisito specifica un'esigenza ben definita? |
Raggruppamento | Si tratta di un requisito autonomo? |
Ambito | Il requisito si trova nell'ambito per il progetto? |
Prestazioni | L'obiettivo delle prestazioni di questo requisito è identificato? |
Riferimento | I riferimenti incrociati di questo requisito sono corretti? |
Dipendenza | Il requisito dispone di eventuali dipendenze per altri requisiti e, in tal caso, tali dipendenze sono specificate chiaramente? |
Nome | Domanda |
---|---|
Discretezza | Il caso d'uso è un'attività autonoma e discreta? |
Obiettivo | L'obiettivo o il valore misurabile del caso d'uso è chiaro? |
Attore | Gli attori che ottengono dei vantaggi dal caso d'uso vengono identificati? |
Livello | Il caso d'uso è scritto a livello essenziale (astratto), anziché come uno specifico scenario? |
Tipo | Il caso d'uso contiene dettagli di implementazione e di progetto? |
Completezza dei corsi | Tutti i corsi alternativi anticipati sono documentati? |
Eccezioni | Tutte le condizioni di eccezione note sono documentate? |
Suddivisione | Esistono eventuali sequenze di azioni comuni che possono essere suddivise in casi d'uso separati? |
Ambiguità | La sequenza di finestre di dialogo per ciascun corso è scritta in modo chiaro e completo, senza ambiguità? |
Pertinenza | Ogni attore e fase nel caso d'uso è pertinente al completamento dell'attività? |
Fattibilità dei corsi | I corsi del caso d'uso sono fattibili? |
Verificabilità dei corsi | I corsi del caso d'uso sono verificabili? |
Nome | Domanda |
---|---|
Input e output | Il caso d'uso include una descrizione completa dell'input e output previsti? |
Riferimento | Sono descritte tutte le dipendenze per questo scenario di test? |
Duplicati | Questa condizione viene verificata una sola volta? |
Completezza | Lo scenario di test è completo? |
Ambiguità | Lo scenario di test è privo di ambiguità? |
Riproducibilità | Lo scenario di test è riproducibile? |
Progetto | Lo scenario di test è progettato per mostrare la presenza di errori e non la loro assenza? |
Nome | Domanda |
---|---|
Comprensibilità | I lettori riescono a capire il report di errori? |
Completezza | Tutti gli attributi sono completi? |
Ambiguità | Il report di errori è espresso chiaramente? |
Duplicati | Esiste un report di errori duplicato? |
Riproducibilità | È possibile riprodurre l'errore del report di errori? |