Qualitätsbewertung
Die Funktion zur Qualitätsbewertung von ValiAssistant analysiert die Texte der ausgewählten Anforderungen anhand eines Satzes von INCOSE-Regeln und stellt dem Benutzer einen Qualitätswert sowie einen Qualitätskommentar dazu bereit, wie die Anforderungen verbessert werden können, wenn der Wert niedrig ist. Diese Informationen werden in zwei bestimmte Spalten geschrieben, die in den Anforderungstabellen mit den Bezeichnungen Quality Assessment Comment und Quality Assessment Score aktiviert werden können. Informationen zur Gesamtqualität der Anforderungen werden außerdem in den Insights Dashboards im Requirements Module hervorgehoben.
Auf die Funktion zur Qualitätsbewertung kann im Requirements Module wie folgt zugegriffen werden:
-
Durch Klicken auf die Schaltfläche
oben rechts, Auswahl der Option Quality Assessment aus dem Dropdown-Menü im sich öffnenden Fenster Choose Action und Klicken auf die Schaltfläche
.
-
Durch Klicken auf das Symbol mit den drei Punkten in der Spalte Identifier einer Anforderung und Auswahl des Befehls ValiAssistant » Quality Assessment aus den Hauptmenüs.
Je nachdem, von welcher Stelle aus darauf zugegriffen wird, variiert der Kontext des zur Bewertung gesendeten Objekts.
Weitere Informationen zum Zugriff auf ValiAssistant finden Sie auf der Seite ValiAssistant.
Die Qualitätsbewertung kann auch auf Spezifikationsebene über Insights Dashboards gestartet werden, indem Sie auf das Symbol
oben rechts im Bereich Quality Assessment klicken Wenn Sie auf diese Weise auf die Funktion zugreifen, werden alle Anforderungen in der aktuell ausgewählten Spezifikation analysiert.
Nach dem Start des Qualitätsbewertungsprozesses werden Sie darüber informiert, wie viele Anforderungen analysiert werden.
Klicken Sie auf
, um fortzufahren. Sobald der Prozess abgeschlossen ist, informiert Sie das nächste Fenster darüber, dass die Qualitätsbewertung erfolgreich war.
Die Spalten Quality Assessment Score und Quality Assessment Comment in der Tabelle der Spezifikation liefern zusätzliche Informationen zur Qualität Ihres Anforderungstextes.
Die Ergebnisse werden außerdem im Diagramm Quality Assessment im Insight Dashboard dargestellt.
Scoring Criteria
-
Score: 0-20 / 1 (Stufe 1 - Unzureichend)
-
Kriterien: Der Anforderungstext verstößt gegen mehrere INCOSE-Standards. Es fehlt an Struktur, es wird das Passiv verwendet, er enthält vage Begriffe sowie mangelhafte Grammatik und Zeichensetzung. Keine klar verantwortliche Entität oder mehrdeutig bzw. nicht umsetzbar.
-
-
Score: 21-40 / 2 (Stufe 2 - Verbesserungsbedürftig)
-
Kriterien: Die Anforderung folgt einigen Standards, weist jedoch erhebliche Probleme auf. Sie ist möglicherweise teilweise strukturiert, verwendet aber weiterhin das Passiv, enthält Ausweichklauseln oder es fehlen spezifische, messbare Zielwerte.
-
-
Score: 41-60 / 3 (Stufe 3 - Zufriedenstellend)
-
Kriterien: Die Anforderung entspricht im Allgemeinen den Standards, weist jedoch einige kleinere Probleme auf. Sie ist möglicherweise überwiegend strukturiert, enthält aber kleinere grammatikalische Fehler oder es fehlen spezifische Maßeinheiten.
-
-
Score: 61-80 / 4 (Stufe 4 - Gut)
-
Kriterien: Die Anforderung erfüllt die meisten Standards. Gut strukturiert, im Aktiv formuliert und mit spezifischen messbaren Zielwerten, kann jedoch ein oder zwei kleinere Probleme aufweisen.
-
-
Score: 81-100 / 5 (Stufe 5 - Ausgezeichnet)
-
Kriterien: Die Anforderung erfüllt die Standards vollständig. Sie ist klar strukturiert, im Aktiv formuliert, enthält spezifische messbare Zielwerte, keine grammatikalischen Fehler und ist eindeutig sowie umsetzbar.
-
INCOSE Rules was taken into Consideration for Assessment
R1 - Verwenden Sie einen strukturierten, vollständigen Satz: Subjekt, Verb, Objekt.
R2 - Verwenden Sie im Hauptsatz der Bedarfs- oder Anforderungsaussage das Aktiv, wobei die verantwortliche Entität klar als Subjekt des Satzes identifiziert sein muss.
R3 - Stellen Sie sicher, dass Subjekt und Verb der Bedarfs- oder Anforderungsaussage für die Entität geeignet sind, auf die sich der Bedarf oder die Anforderung bezieht.
R5 - Verwenden Sie den bestimmten Artikel „the“ anstelle des unbestimmten Artikels „a“.
R6 - Verwenden Sie geeignete Einheiten bei der Angabe von Mengen. Alle Zahlen sollten mit explizit angegebenen Maßeinheiten versehen sein.
R7 - Vermeiden Sie die Verwendung vager Begriffe wie „some“, „any“, „allowable“, „several“, „many“, „a lot of“, „a few“, „almost always“, „very nearly“, „nearly“, „about“, „close to“, „almost“ und „approximate“.
R8 - Vermeiden Sie Ausweichklauseln wie „so far as is possible“, „as little as possible“, „where possible“, „as much as possible“, „if it should prove necessary“, „if necessary“, „to the extent necessary“, „as appropriate“, „as required“, „to the extent practical“ und „if practicable“.
R9- Vermeiden Sie offene Klauseln wie „including but not limited to“, „etc.“ und „and so on“.
R10 - Vermeiden Sie überflüssige Infinitivkonstruktionen wie „be designed to“, „be able to“, „be capable of“.
R12, 13, 14 - Verwenden Sie korrekte Grammatik, Rechtschreibung und Zeichensetzung.
R15 - Verwenden Sie eine definierte Konvention, um logische Ausdrücke wie „[X AND Y]“, „[X OR Y]“, [X XOR Y]“ und „NOT[X OR Y]“ auszudrücken.
R16 - Vermeiden Sie die Verwendung von „not“
R17 - Vermeiden Sie die Verwendung des Schrägstrichsymbols ("/") außer bei Einheiten, d. h. km/hr
R18 - Schreiben Sie einen einzelnen Satz, der einen einzelnen Gedanken enthält, der durch relevante Nebensätze bedingt und qualifiziert wird.
R19 - Vermeiden Sie Verknüpfer, die Satzteile verbinden, wie „and“, „or“, „then“, „unless“, „but“, „as well as“, „but also“, „however“, „whether“, „meanwhile“, „whereas“, „on the other hand“ oder „otherwise“.
R20 - Vermeiden Sie Formulierungen, die den Zweck des Bedarfs oder der Anforderung angeben.
R21 - Vermeiden Sie Klammern und eckige Klammern mit untergeordnetem Text.
R22 - Zählen Sie Mengen explizit auf, anstatt ein Gruppenhauptwort zur Benennung der Menge zu verwenden.
R24 - Vermeiden Sie die Verwendung von Pronomen und unbestimmten Pronomen.
R26 - Vermeiden Sie unerreichbare Absolute wie 100'%' Zuverlässigkeit, 100'%' Verfügbarkeit, all, every, always, never usw.
R28 - Drücken Sie die aussagenlogische Natur einer Bedingung für eine einzelne Aktion explizit aus, anstatt Listen von Aktionen für eine bestimmte Bedingung anzugeben.
R29 - Klassifizieren Sie die Bedarfe und Anforderungen nach den Aspekten des Problems oder Systems, auf die sie sich beziehen.
R31 - Vermeiden Sie bei der Definition von Design-Eingaben die Angabe einer Lösung, sofern es keine Begründung für die Einschränkung des Designs gibt. Konzentrieren Sie sich auf das Problem, also das „Was“, und nicht auf die Lösung, also das „Wie“.
R32 - Verwenden Sie „each“ anstelle von „all“, „any" oder „both“, wenn eine Allquantifizierung beabsichtigt ist.
R33 - Definieren Sie Mengen mit einem Wertebereich, der für die Entität geeignet ist, auf die sie angewendet werden, und anhand dessen die Entität verifiziert oder validiert wird.
R34 - Geben Sie spezifische messbare Leistungsziele an, die für die Entität geeignet sind, für die der Bedarf oder die Anforderung formuliert ist und anhand derer verifiziert wird, dass die Entität diese erfüllt.
R35 - Definieren Sie zeitliche Abhängigkeiten explizit, anstatt unbestimmte zeitliche Schlüsselwörter wie „eventually“, „until“, „before“, „after“, „as“, „once“, „earliest“, „latest“, „instantaneous“, „simultaneous“ und „at last“ zu verwenden.
R38 - Vermeiden Sie die Verwendung von Abkürzungen.
).