质量评估

质量评估是 ValiAssistant 集成的一项功能。它根据一套 INCOSE 规则分析选定的需求文本，并为用户提供质量分数和质量评论，如果分数较低，则说明如何改进需求。这些信息被写入需求表中可启用的 "质量评估评论 "和 "质量评估分数 "两个特定列中。需求模块中的 "洞察仪表板 "也会突出显示需求的整体质量信息。

质量评估可以从三个不同的位置访问。根据访问位置的不同，发送评估对象的上下文也会不同。

通过 ValiAssitant 按钮访问

在特定规范或 "所有要求 "中，用户可通过访问右上角的 ValiAssitant 选择 "质量评估"，如图所示。 General Quality Assessment.

一般质量评估 - 通过 ValiAssistant 访问

通过 ValiAssistant 访问质量评估时，将对当前需求表中的所有需求进行分析。

通过操作栏访问

如图所示，质量评估可以直接从单个需求或一组批量选择的需求的操作栏中触发。 Individual Quality Assessment.

单个质量评估 - 通过操作栏访问质量评估时，只考虑单个或批量选择的需求。

通过操作栏访问质量评估时，将分析当前需求表中的单个或批量选定需求。

通过 "洞察 "访问

如图所示，质量评估也可以通过规范层的洞察仪表板触发。 Quality Assessment Insights.

质量评估洞察 - 在规范的洞察部分或 "所有需求 "中访问质量评估。

通过 "洞察 "访问质量评估时，将分析当前所选规范中的所有需求。

质量评估流程

触发质量评估后，"需求与系统门户 "将显示要分析的需求数量。

之后，Requirements & Systems Portal 会通知您质量评估已成功。

最后，"质量评估评论 "和 "质量评估分数 "将提供有关需求文本质量的其他信息，如图所示 Additional Quality Information.

附加质量信息 - 这些信息显示在此处突出显示的两列中。

评分标准

• Score: 0-20/ 1（1 级--不足）

  • 标准：需求文本违反了 INCOSE 的多项标准。它缺乏结构，使用被动语态，包含含糊的术语，语法和标点符号也很差。没有明确的责任实体，或含糊不清，或不具可操作性。

• Score: 21-40/2（2 级--需要改进）

  • 标准：要求符合某些标准，但存在重大问题。它可能有一定的条理，但仍然使用被动语态，包含转折句，或缺乏具体的、可衡量的目标。

• Score: 41-60/3（3 级--满意）

  • 标准：要求基本符合标准，但有一些小问题。要求可能结构完整，但有语法错误或缺少具体的计量单位。

• Score: 61-80/4（4 级--良好）

  • 标准：要求符合大多数标准。结构合理，语气积极，有具体的可衡量目标，但可能有一两个小问题。

• Score: 81-100/5（5 级--优秀）

  • 标准：要求完全符合标准。要求结构清晰，声音响亮，有具体的可衡量目标，无语法错误，明确且可操作。

质量评估后，总体质量得分将传递到 Insight Dashboard，并根据得分分为 "低"（得分低于 50 分）、"中"（得分介于 50 分和 70 分之间）和 "高"（得分高于 70 分），如图所示。 Insights Quality Score.

洞察质量得分 - 已分析需求的总体质量记分牌。

评估时考虑的 INCOSE 规则

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--避免使用缩略语。