品質評価
品質評価は、ValiAssistant に統合された機能です。この機能は、INCOSEのルールに基づいて選択された要件のテキストを分析し、品質スコアと、スコアが低い場合に要件を改善する方法に関する品質コメントをユーザーに提供します。こ の情報は、 Requirements テーブルで有効にす る こ と がで き る、 "Quality Assessment Comment" と "Quality Assessment Score" と呼ばれる 2 つの列に書き込まれます。要件の全体的な品質に関する情報は、 要件モジュールのInsights ダッシュボードでも強調表示されます。
品質評価には、 3 つの異なる場所からアクセスできます。アクセスする場所によって、評価のために送信されるオブジェクトのコンテキストが異なります。
ValiAssitant ボタンからのアクセス
特定の仕様または "すべての要件 "を選択している場合、ユーザーは、図に示すように、右上隅にある ValiAssitant にアクセスして、"品質評価 "を選択することができる。
一般的な品質評価 - ValiAssistant からのアクセスValiAssistant から品質アセスメントにアクセスすると、現在の要件テーブルのすべての要件が分析されます。
アクション列からのアクセス
品質アセスメントは、図に示すように、個々の要件または一括選択した要件の [アクション] 列から直接起動できます。
個別の品質アセスメント - アクション列から品質アセスメントにアクセスする場合は、個別または一括選択された要件のみが考慮されます。アクション列から品質アセスメントにアクセスする場合は、現在の要件テーブルで選択された個々の要件または一括選択された 要件のいずれかが分析されます。
インサイトを介したアクセス
品質ア ッ セ ス メ ン ト は、 図に示す よ う に、 仕様レ ベルの イ ン サ イ ト ダ ッ シ ュ ボー ド か ら 呼び出す こ と も で き ます。
品質アセスメントのインサイト - 仕様または「すべての要件」のインサイトセクション内の品質アセスメントにアクセスする。インサイトを通じて品質アセスメントにアクセスすると、現在選択されている仕様のすべての要件が分析されます。
品質評価のフロー
品質アセスメントを開始すると、Requirements & Systems Portal に、分析される要件の数が表示されます。

その後、Requirements & Systems Portal は、品質アセスメントが成功したことを通知します。

最後に、図に示すように、"品質評価コメント" と "品質評価スコア" によって、要件テキストの品質に関する追加情報が提供されます。
追加品質情報 - この情報は、ここで強調表示されている 2 つの列に表示されます。
採点基準
-
Score: 0-20 / 1 (レベル1 - 不十分)-
基準要件テキストは複数のINCOSE標準に違反している。構成に欠け、受動態を使用し、曖昧な用語を含み、文法と句読点が悪い。明確な責任主体がない、または曖昧である、または実行不可能である。
-
-
Score: 21-40 / 2 (レベル 2 - 改善が必要)-
基準:要件はいくつかの基準に従っているが、重大な問題がある。ある程度構造化されているが、受動態を使用していたり、逃げ句が含まれていたり、具体的で測定可能な目標が欠けていたりする。
-
-
Score: 41-60 / 3 (レベル 3 - 満足)-
基準:要件は概ね基準に従っているが、若干の問題がある。主に構成されているが、細かい文法的な誤りがあったり、具体的な単位が欠けていたりする。
-
-
Score: 61-80 / 4 (レベル 4 - 良好)-
基準:要件はほとんどの基準を満たしている。よく構成され、能動態で、具体的な測定可能目標があるが、1つか2つの小さな問題があるかもしれない。
-
-
Score: 81-100 / 5 (レベル 5 - 優れている)-
基準:要件が基準に完全に準拠している。明確に構成され、能動的で、具体的な測定可能目標があり、文法的な誤りがなく、明確で実行可能である。
-
品質評価後、総合的な品質スコアがインサイトダッシュボードに通知され、図に示すように、スコアに基づいて「Low」(スコアが 50 未満)、「Medium」(スコアが 50 ~ 70)、「High」(スコアが 70 以上)と表示されます。
Insights Quality Score - 分析された要件の総合的な品質スコアボード。
INCOSEのルールを考慮した評価
R1 - 構造化された完全な文を使用する:主語、動詞、目的語。 R2 - 必要性または要求文の主文構造では能動態を使用し、責任主体を文の主語として明確に識別する。 R3 - ニーズまたは要求事項の文の主語と動詞が、そのニーズまたは要求事項が参照するエンティティに適切であることを確認する。 R5-不定冠詞 "a "ではなく定冠詞 "the "を使用する。 R6 - 数量を記載する際には、適切な単位を使用する。すべての数値には単位を明示する。 R7 - 「いくつか」、「どれでも」、「許容範囲」、「いくつか」、「たくさん」、「いくつか」、「ほとんどいつも」、「ほとんど」、「ほぼ」、「ほぼ」、「ほぼ」、「ほぼ」、「ほぼ近い」、「ほぼ」、「おおよそ」などの曖昧な用語の使用は避ける。 R8-「可能な限り」、「可能な限り少なく」、「可能な限り」、「可能な限り」、「可能な限り」、「必要と証明されれば」、「必要であれば」、「必要な程度に」、「適切であれば」、「必要であれば」、「実用的な程度に」、「実用可能であれば」などの逃げ口上は避ける。 R9- "including but not limited to"、"etc."、"and so on "のようなオープンエンドの句は避ける。 R10- "be designed to"、"be able to"、"be capable of "のような余計な不定詞は避ける。 R12, 13, 14 - 正しい文法、スペル、句読点を使う。 R15 - 「[X AND Y]」、「[X OR Y]」、「[X XOR Y]」、「NOT[X OR Y]」のような論理表現は、決められた規則で表現する。 R16 - "not" の使用を避ける。 R17 - km/hrのような単位以外では、斜め記号("/")の使用を避ける。 R18 - 関連する小節によって条件づけられ、修飾された一つの考えを含む一つの文を書く。 R19 - "and"、"or"、"then"、"unless"、"but"、"as well as"、"but also"、"however"、"whether"、"meanwhile"、"whereas"、"on the other hand"、"otherwise "などの、節をつなぐ組み合わせ記号は避ける。 R20 - 必要性や要求の目的を示す表現は避ける。 R21 - 従属テキストを含む括弧や括弧は避ける。 R22 - セットの名前にグループ名詞を使う代わりに、明示的にセットを列挙する。 R24 - 代名詞や不定代名詞の使用は避ける。 R26 - 100'%の信頼性、100'%の可用性、all、every、always、never などの、達成不可能な絶対値の使用は避ける。 R28 - 特定の条件に対する行動を列挙するのではなく、一つの行動に対して条件の命題性を明示する。 R29 - 対応する問題やシステムの側面に従って、ニーズと要求を分類する。 R31 - 設計入力を定義するときは、設計を制約する根拠がない限り、解決策を述べることは避ける。どのように "という解決策よりも、"何を "という問題に焦点を当てなさい。 R32 - 普遍的な定量化を意図する場合は、"all"、"any"、"both "の代わりに "each "を使用する。 R33 - 数量は、それが適用され、エンティティが検証または妥当性確認されるエンティティに適した値の範囲で定義する。 R34 - 必要性または要求事項が記載され、エンティティが満たすことが検証されるエンティティに適切な、具体的で測定可能なパフォーマンス目標を提供する。 R35 - "最終的に"、"まで"、"前に"、"後に"、"として"、"一度"、"最も早く"、"最も遅く"、"瞬時に"、"同時に"、"最後に "などの不定な時間的キーワードを使用する代わりに、時間的依存関係を明示的に定義する。 R38 - 略語の使用は避ける。