È necessario verificare che nel modello non vi siano stati a cui sia possibile trasferire una richiesta di modifica che successivamente viene ignorata. Ad esempio, se il modello dispone di uno stato Posticipato e l'elaborazione dei record in questo stato non è stata assegnata a nessuno, è possibile che alcune richiese di modifica non vengano mai rilevate o risolte.
Le cause di questo problema possono non essere immediatamente evidenti. È possibile che tre sviluppatori siano stati incaricati di gestire le richieste in uno stato Open, dove il valore del campo del componente è rispettivamente in rosso, verde e blu. Le richieste di modifiche il cui valore del campo del componente è giallo o vuoto potrebbero non essere mai rilevate.
È necessario considerare il bilanciamento tra un modello che ha meno stati con più attività di sviluppo per ciascuno di essi e un modello che ha molti stati con meno attività di sviluppo. Ad esempio, se un'attività di verifica viene eseguita su diversi punti durante una richiesta di modifica, è possibile avere uno stato di verifica singolo invece di includere attività di verifica in altri stati. Il raggruppamento di queste attività rende più semplice la gestione corretta della verifica. Mentre, la creazione di molti stati rende il modello poco maneggevole e difficile da gestire.
L'azione Duplica consente di contrassegnare un record in una serie di record duplicati come record attivo e gli altri come duplicati; i record contrassegnati come duplicati non possono essere modificati. Questa azione garantisce che tutto il lavoro su questa richiesta di modifica viene memorizzato da un record. Questa azione utilizza i campi integrati; può essere aggiunta ad uno schema aggiungendo i controlli Dipendente duplicato e Base duplicata in un modulo e creando le azioni Duplica e Annulla duplicazione. L'azione Annulla duplicazione restituisce il record nello stato in cui si trovava prima di essere contrassegnato come duplicato.
È disponibile una varietà di schemi predefiniti che includono funzioni specifiche o configurazioni. È possibile utilizzarli come punto iniziale per lo sviluppo di uno schema, ma è necessario confrontare con attenzione le funzioni dello schema predefinito con i requisiti. Per ulteriori informazioni relative agli schemi predefiniti, consultare Schemi predefiniti di Rational ClearQuest.
\Progettare uno schema in maniera tale che supporti lo sviluppo parallelo di più prodotti (o varianti del prodotto) che condividono risorse comuni richiede molto impegno. La progettazione deve anticipare ed adeguarsi a situazioni come ad esempio l'acquisizione e la gestione delle informazioni quando un difetto riportato viene memorizzato in risorse condivise che richiedono correzioni per più prodotti e la memorizzazione dello stato corrente del difetto quando sono necessarie più build (in pianificazioni potenzialmente differenti).
L'utilizzo di un record singolo per memorizzare questi lavori differenti non è un metodo efficace.
Un metodo alternativo è l'invio di più record per ogni prodotto interessato, che consente di memorizzare in maniera indipendente lo stato di ogni attività. Se si utilizza il meccanismo Save Default Values al primo record immesso e Load sui record successivi, è possibile evitare la duplicazione dell'immissione dati su ogni copia. (Questa funzionalità non è disponibile per il Client Rational ClearQuest Web). L'aspetto negativo è che ogni record viene isolato dagli altri; lo sforzo può risultare vano se il lavoro eseguito sulle altre problematiche non viene coordinato.
Un metodo più efficace è rappresentato dall'utilizzo di una struttura gerarchica, in cui il record padre caratterizza il problema e i record figlio vengono utilizzati per tracciare il problema relativo ad ogni prodotto, variante o versione. Il record padre può essere di tipo diverso rispetto ai record figlio oppure coincidere. Alcuni schemi utilizzano lo stesso tipo di record per i record padre e figlio, in modo tale che tutte le informazioni possano essere contenute nell'elemento figlio (riducendo la navigazione tra padre e figlio). Gli altri schemi utilizzano un tipo di record figlio semplice per implementare un tipo di promemoria per rivolgere lo stesso problema alle altre varianti, versioni o prodotti interessati e per memorizzare il relativo stato. Per ulteriori informazioni su uno schema che utilizza la struttura gerarchica, consultare la documentazione per lo schema ALM (Application Lifecycle Management).