ValiAssistant 的质量评估功能根据一套 INCOSE 规则对所选需求文本进行分析，并为用户提供质量分数和质量评论，如果分数较低，则说明如何改进需求。这些信息被写入需求表中可启用的两个特定列，分别称为 Quality Assessment Comment和 Quality Assessment Score.需求 "模块中的 "洞察仪表板 "也会突出显示 "需求 "整体质量的信息。
质量评估功能可从需求模块中访问，如下所示：
根据访问的位置，发送评估对象的上下文会有所不同。
有关访问 ValiAssistant 的更多信息，请参阅ValiAssistant页面。
质量评估也可以从规范层的 Insights 仪表板启动，方法是单击区域右上方的
图标 ( )。 Quality Assessment区域 (
)。以这种方式访问该功能时，将对当前所选规范中的所有需求进行分析。
访问 "质量评估 "流程后，您将获知有多少需求将被分析。
单击
继续。流程完成后，下一个窗口将通知您质量评估成功。
和 Quality Assessment Score和 Quality Assessment Comment列将提供有关需求文本质量的更多信息。
结果也会显示在 Quality Assessment图表。
Scoring Criteria
INCOSE Rules was taken into Consideration for Assessment
R1 - 使用结构完整的句子：主语、动词、宾语。
R2 - 在需求或要求陈述的主要句子结构中使用主动语态，并明确指出负责实体为 句子的主语。
R3 - 确保需求或要求陈述的主语和动词与需求或要求所指的实体相称。
建议 5--使用定冠词 "the "而不是不定冠词 "a"。
建议 6--在陈述数量时使用适当的单位。所有数字都应明确说明计量单位。
建议 7 - 避免使用模糊词语，如 "一些"、"任何"、"允许"、"几个"、"许多"、"很多"、"几个"、"几乎总是"、"非常接近"、"几乎"、"大约"、"接近"、"几乎 "和 "近似"。
建议 8--避免使用 "尽可能"、"尽可能少"、"在可能的情况下"、"尽可能多"、"如 果证明有必要"、"如果有必要"、"在必要的范围内"、"适当"、"按要求"、 "在实际可行的范围内 "和 "如果切实可行 "等省略句。
建议 9--避免使用 "包括但不限于"、"等 "和 "等等 "等开放式条款。
建议 10--避免多余的不定式，如 "旨在"、"能够"、"能够"。
建议 12、13、14--使用正确的语法、拼写和标点符号。
R15 - 使用定义的约定来表达逻辑表达式，如"[X AND Y]"、"[X OR Y]"、"[X XOR Y]"、"NOT[X OR Y]"。
R16--避免使用 "不"。
R17--避免使用斜体（"/"）符号，除非是在单位中，如 km/hr
建议 18--写一个包含单一思想的单句，并以相关分句为条件和限定。
R19 - 避免使用连接分句的组合词，如 "和"、"或"、"那么"、"除非"、"但是"、"以及"、"但是也"、"然而"、"是否"、"同时"、"而"、"另一方面 "或 "否则"。
建议 20--避免使用表明需要或要求的目的的短语。
R21 - 避免使用包含从属文字的括号和括号。
建议 22--明确列举集合，而不是使用组名词来命名集合。
建议 24--避免使用代词和不定代词。
建议 26--避免使用无法实现的绝对值，如 100'%'可靠性、100'%'可用性、所有、每一个、总是、从不等。
建议 28--明确表达单个行动的条件命题性质，而不是针对特定条件列出行动清单。
R29 - 根据问题或系统的各个方面对需求和要求进行分类。
R31 - 在定义设计输入时，除非有限制设计的理由，否则应避免陈述解决方案。重点是问题 "是什么"，而不是解决方案 "如何做"。
R32 - 当需要普遍量化时，使用 "每个 "而不是 "所有"、"任何 "或 "两者"。
R33 - 定义量值范围要与适用的实体相适应，并与要验证或确认的实体相适应。
R34 - 提供具体的可测量的性能目标，这些目标应与需求或要求所针对的实体相适应，并 且实体应根据这些目标进行验证。
R35 - 明确定义时间依赖关系，而不是使用不确定的时间关键词，如 "最终"、"直到"、 "之前"、"之后"、"由于"、"一旦"、"最早"、"最近"、"瞬间"、"同时"、"最后"。
建议 38--避免使用缩略语。
AI-localized