ValiAssistantの品質評価機能は、INCOSEのルールに基づいて選択された要件のテキストを分析し、品質スコアと、スコアが低い場合に要件を改善する方法に関する品質コメントをユーザーに提供します。この情報は、Requirements テーブルで有効にできる 2 つの列 Quality Assessment Commentと Quality Assessment Score.要件の全体的な品質に関する情報は、 Requirements Module のInsights Dashboardsでも強調表示されます。
品質評価機能は、 要件モジ ュ ールか ら 次の よ う にア ク セ ス で き ます：
-
右上の
ボタンをクリックし、要件モジュール内のドロップダウンからオプションを選択します。 Quality Assessmentオプションを選択します。 Choose Actionウィンドウのドロップダウンからオプションを選択し、
ボタンをクリックします。
-
をクリックします。 Identifierをクリックし、メインメニューから ValiAssistant » Quality Assessmentコマンドをメイン メニューから選択します。
このコマンドにアクセスする場所によって、評価のために送信されるオブジェクトのコンテキストが異なります。
ValiAssistant へのアクセスの詳細については、『ValiAssistant』のページを参照してください。
品質アセスメントは、仕様レベルのインサイトダッシュボードから開始することもできます。 Quality Assessment領域(
)の右上にある アイコンをクリックします。この方法でこの機能にアクセスすると、現在選択されている仕様のすべての要件が分析されます。
品質評価プロセスにアクセスすると、分析される要件の数が通知されます。
をクリックして次に進みます。プロセスが終了すると、次のウィンドウで品質評価が成功したことが通知されます。
次の Quality Assessment Scoreおよび Quality Assessment Comment列には、要件テキストの品質に関する追加情報が表示されます。
結果は Quality Assessmentチャートにも表示されます。
Scoring Criteria
-
Score: 0-20/ 1 （レベル 1 - 不十分）
-
Score: 21-40/ 2 (レベル 2 - 改善が必要)
-
Score: 41-60/ 3 (レベル 3 - 満足)
-
Score: 61-80/ 4 (レベル 4 - 良好)
-
Score: 81-100/ 5 （レベル 5 - 優れている）
INCOSE Rules was taken into Consideration for Assessment
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 - 普遍的な定量化を意図する場合は、「すべて」、「いずれか」、「両方」ではなく、「それぞれ」を使用する。
R33 - 数量は、それが適用され、エンティティが検証または妥当性確認されるエンティティに適した値の範囲で定義する。
R34 - 必要性または要求事項が記載され、エンティティが満たすことが検証されるエンティティに適切な、具体的で測定可能なパフォーマンス目標を提供する。
R35 - "最終的に"、"まで"、"前に"、"後に"、"として"、"一度"、"最も早く"、"最も遅く"、"瞬時に"、"同時に"、"最後に "などの不定な時間的キーワードを使用する代わりに、時間的依存関係を明示的に定義する。
R38 - 略語の使用は避ける。
AI-localized