Es muss sichergestellt werden, dass das Modell keine Status umfasst, in die eine Änderungsanforderung versetzt und dann übersehen werden kann. Wenn beispielsweise für den definierten Status "Postponed" bislang kein Verantwortlicher zugeordnet wurde, der Datensätze mit diesem Status verarbeitet, können Änderungsanforderungen mit diesem Status auflaufen, die weder registriert noch abgearbeitet werden.
Die Ursachen dieses Problems sind mitunter schwer auszumachen. Angenommen, es sind drei Techniker damit betraut, Änderungsanforderungen mit dem Status "Open" zu verarbeiten, die im Komponentenfeld den Wert "Rot", "Grün" oder "Blau" aufweisen. Änderungsanforderungen, die Komponentenfelder mit gelben Werten oder aber leere Komponentenfelder enthalten, werden möglicherweise nie wahrgenommen.
Sie müssen die Vor- und Nachteile abwägen, die die verschiedenen Modelle haben. Ein Modell mit weniger Status bietet mehr Entwicklungsmöglichkeiten pro Status, wohingegen ein Modell mit vielen Status weniger Entwicklungsmöglichkeiten pro Status bietet. Beispiel: Tritt eine bestimmte Art von Prüfungsaktivität an verschiedenen Punkten im Lebenszyklus einer Änderungsanforderung auf, kann es sinnvoll sein, einen eigenen Status für die Prüfung zu definieren, anstatt die Prüfungsaktivitäten in jeden anderen Status einzubinden. Dadurch kann besser gewährleistet werden, dass die Prüfung ordnungsgemäß abgewickelt wurde. Andererseits kann ein Modell durch Erstellen zu vieler Status sehr komplex und schwer zu verwalten sein.
Die Aktion "Duplicate" ermöglicht das Identifizieren eines bestimmten Datensatzes aus einer Gruppe doppelter Datensätze in der Datenbank als den aktiven Datensatz und das Markieren aller übrigen als Duplikate des aktiven Datensatzes, um sie vor weiteren Änderungen zu schützen. Mit dieser Aktion wird sichergestellt, dass alle Arbeitsvorgänge, die für diese Änderungsanforderung ausgeführt werden, in einem Datensatz aufgezeichnet werden. Diese Funktion verwendet integrierte Felder. Sie kann einem Schema durch Hinzufügen der Steuerelemente "Duplikatobjekt" und "Duplikatbasis" in einem Formular sowie durch Erstellen der Aktionen "Duplicate" und "Unduplicate" hinzugefügt werden. Mit der Aktion "Unduplicate" wird der Datensatz in den Status zurückversetzt, in dem er sich befand, bevor er als Duplikat markiert wurde.
Es ist eine Vielzahl vordefinierter Schemas mit bestimmten Features oder Konfigurationen verfügbar. Sie können ein vordefiniertes Schema als Ausgangspunkt zum Entwickeln eines angepassten Schemas verwenden. Sie müssen dabei jedoch sorgfältig prüfen, ob das vordefinierte Schema Ihren Anforderungen genau entspricht. Weitere Informationen zu den vordefinierten Schemas finden Sie im Artikel Vordefinierte Rational-ClearQuest-Schemas.
\Das Entwerfen von Schemas zur Unterstützung der parallelen Entwicklung mehrerer Produkte (oder Produktvarianten), die Artefakte gemeinsam nutzen, ist eine Herausforderung. Der Entwurf muss Situationen vorwegnehmen, in denen sich Fragen wie die folgenden stellen: Wie sollen Informationen erfasst und verarbeitet werden, wenn ein gemeldeter Fehler auf gemeinsame genutzte Artefakte zurückgeführt werden kann, die Korrekturen an verschiedenen Produkten erforderlich machen? Wie soll der aktuelle Status des Fehlers überwacht werden, wenn mehrere Build-Vorgänge (womöglich mit verschiedenen Zeitplänen) erforderlich sind? Der Entwurf muss Lösungen für diese Fragen bieten.
Diese verschiedenen Ansätze in einem einzigen Datensatz zu erfassen, ist nicht effektiv.
Ein Lösungsansatz für dieses Problem ist, mehrere Datensätze für jedes betroffene Produkt zu übergeben, da dies die Möglichkeit bietet, den Status jeder Aktivität separat zu überwachen. Durch Verwendung des Mechanismus "Save Default Values" für den ersten eingegebenen Datensatz und des Mechanismus "Load" für nachfolgende Datensätze kann vermieden werden, dass der Dateneintrag in jeder Kopie dupliziert wird. (Diese Funktion ist für die Clientkomponente von Rational ClearQuest Web nicht verfügbar.) Der Nachteil dieses Ansatzes besteht darin, dass jeder Datensatz von den anderen isoliert ist. Dies kann zu unnötigem Mehraufwand führen, wenn die Arbeitsvorgänge hinsichtlich der anderen zugehörigen Probleme nicht koordiniert werden.
Ein effizienterer Ansatz ist die Verwendung einer hierarchischen Struktur, in der das Problem im übergeordneten Element beschrieben und mit den untergeordneten Elementen das gemeinsame Problem für jedes Produkt, jede Variante bzw. Version überwacht wird. Der übergeordnete Datensatz kann einem anderen Typ als die untergeordneten Datensätze oder demselben Typ angehören. In manchen Fällen verwenden die Schemas denselben Satztyp, so dass alle Informationen im untergeordneten Datensatz enthalten sein können. Dadurch wird das wiederholte Navigieren zwischen übergeordnetem und untergeordnetem Element reduziert. In anderen Fällen verwenden Schemas einen einfachen Satztyp, um an die Bearbeitung desselben Problems für die anderen betroffenen Produkte, Varianten oder Versionen zu erinnern und deren Status zu überwachen. Weitere Informationen zu einem Schema, das eine hierarchische Struktur nutzt, finden Sie in der Dokumentation zum ALM-Schema (Application Lifecycle Management).