149
社区成员
发帖
与我相关
我的任务
分享第5组 Process patterns for requirement consistency analysis 读后感
导读
这篇读后感是关于PADMALATA V NISTALA, KESAV V NORI, SWAMINATHAN NATARAJAN等人于2016年发表的Process Patterns for Requirement Consistency Analysis这篇论文，论文主要从引言、相关工作、过程模式、案例研究以及结论与未来工作等几个方面入手，大致内容如下：
- 引言：介绍了需求一致性分析的重要性和挑战，以及本文的目的和贡献。
- 相关工作：回顾了需求一致性分析的定义、分类、方法和工具，以及它们的优缺点。
- 过程模式：定义了过程模式的概念和结构，并提出了两种用于需求一致性分析的过程模式：需求覆盖分析和需求追踪分析。
- 案例研究：展示了如何在两个不同类型的项目中应用过程模式来进行需求一致性分析，并评估了过程模式的有效性和适用性。
- 结论与未来工作：总结了本文的主要发现和贡献，并提出了一些未来需要进一步研究和改进的方向。
我会从论文简介、具体实现、有效性评估以及总结四个方面讲解我对这篇论文的理解。
论文简介
在需求空间中，模式在捕获需求知识以供重用并帮助识别需求方面变得越来越重要。需求规格说明的质量对于有效理解和实施需求至关重要。
论文介绍了一组过程模式，这些模式使用组合可追溯性的概念来分析需求规范或用户故事的制定情况，并识别其包含元素之间的不一致之处。
论文提出了两种已成功应用并发现对执行需求一致性分析和检测需求不一致很有用的模式:需求覆盖率分析和需求可追溯性分析。这些模式可以在需求阶段应用于项目，以审查和分析规定的需求。本文描述了这些模式，讨论了它的实施和项目案例研究的结果。
研究目的
需求分析侧重于评估记录需求的质量和识别需求中的错误的策略或技术。需求规范构成了主要利益相关者之间讨论、项目估算、开发规划和执行的基础。需求规格说明的质量对于有效理解和实施需求至关重要。
工业系统的统计数据显示，由于30-40%的需求缺陷的比例很高，导致返工和成本很高。 此外，与安全、性能目标等质量方面相关的要求也经常被遗漏。随后，在设计和开发阶段寻求对需求的许多澄清，导致在获得澄清、返工工作和里程碑延误方面损失了生产性开发时间。
在本文中提出了两种模式，可以帮助有效地进行需求分析并检测需求中的错误或不一致。
过程模式
需求覆盖分析
此模式适用于项目的需求阶段，用于审查客户提供的规定需求的活动。当团队必须审查需求、要求澄清并根据需求理解制定项目估算时，它特别有用。
需求覆盖分析模式解决了与隐式非功能性需求(NFR) 或一般问题分析维度相关的需求缺失问题，并通过识别额外需求来帮助加强需求。以确保对这些维度的覆盖。
需求可追溯性分析
此模式适用于需求阶段的项目，用于审查和分析客户提供的规定需求的活动。当团队必须验证需求以确保跨多个需求工件的规范的一致性，并验证规范中是否有足够的细节以进行下一阶段时，它特别有用。
需求可追溯性模式解决了项目中可追溯性实施不充分的问题，有助于创建具有向后和前向可追溯性的精心制定的需求可追溯性矩阵。
具体实现
需求覆盖分析
传统需求分析中的问题：
- 隐式的或者非功能性需求，例如安全性、兼容性等，此类问题在验收测试甚至生产期间，很晚出现在生命周期中，导致生产系统的计划延迟和中断
- 当一些重要的逻辑和规则并未包含在需求规范中时，但是在设计和开发阶段经常寻求澄清，客户主题专家可能无法随时澄清，从而导致时间的损失和延误。
解决方案：
多维分析是需求覆盖分析的原理。该模式使用行业标准产品质量维度和标准推理维度提供全面的维度覆盖。从非功能性需求（NFR）、推理、领域等多个维度进行需求覆盖率的分析。
分析步骤：
首先分析NFR维度的覆盖范围，ISO/IEC 25010软件产品质量模型中有一套全面的NFR定义。本模式以此为NFR覆盖率分析的参考模型。根据ISO模型中定义的质量特性（QC）来分析需求覆盖范围。
通过判断需求是否与QC/Sub QC的每个NFR分类相关。如果缺少QC的要求，则在覆盖跟踪器（RCT）中标记覆盖缺口
NFR维度分类如下图：
质量特性主要分为：
安全性、性能、可靠性、可用性、兼容性、可移植性、可维护性
每个质量特性都涵盖相应的子特性：
例如性能方面考虑时间和资源利用率
可用性方面考虑用户界面美观和易学习性
可靠性方面考虑可恢复性和容错
其次分析推理维度的覆盖率，使用5W1H(who when where what why how)分析推理方法来分析需求，如果可以针对该需求跟踪5W1H维度的需求视角，则判断它的覆盖范围在推理维度上是完整的。
推理维度如图：
5W1H指：
Who When Where What Why How
在需求视角中分别对应：
- WHAT：唯一引出需求
- WHY：目标一致性，以验证为什么需求是必要的
- WHERE：需求的适用领域
- HOW：流程与规范，关于如何实现需求的详细信息
- WHEN：在生产系统中执行需求的时间细节
- WHO：可以访问需求的负责角色
接着分析领域特定维度的覆盖范围，当项目有特定领域或者法规遵从性标准时，必须针对这些维度和标准执行覆盖分析。将发现的差距作为不一致记录在RCT中。
最后合并需求覆盖不一致。RCT记录了关于三个维度的需求覆盖范围的差距。需要和主题专家讨论不一致之处，并确保解决所有已识别的不一致之处。
分析举例：
ID为R36的需求缺少安全要求——未指定报表的访问角色信息；来源US1的第三行未提供地理的具体规则，解决方案是将需求更新为美国和澳大利亚是适用的地区；R37的需求未规定与强制性数据保护法案合规性相关的要求
需求溯源分析
此模式适用于需求阶段的项目，用于审查和分析客户提供的规定需求的活动。当团队必须验证需求以确保跨多个需求工件的规范的一致性，并验证规范中是否有足够的细节以进行下一阶段时，它特别有用。
需求溯源分析模式的产生源于以下问题的出现：
- 需求工程师不清楚跨多个需求工件陈述的需求是否一致，以及需求规格说明中的差距是什么，无法继续进行设计阶段。
- 无法清楚地看到需求地可追溯路径：需求地来源和相应地实现规范，使得难以识别更改需求的后果和识别依赖关系，在后期阶段寻求许多澄清，导致延迟和生成开发时间的损失。
使用场景
- 需要在短时间内审查需求并提供估计
- 需要延迟识别需求间的差距
- 项目团队缺乏经验来分析各种需求工件之间的不一致性，并在需求研讨会和审查期间提出相关问题，缺乏结构化的方法用于分析需求
- 在需求分析阶段之后，难以联系或得到客户主题专家的帮助
使用步骤
- 识别项目需求的可追溯元素
在项目中，需求信息通常被指定为跨工件的多层信息，例如项目章程，用户需求规范和软件需求规范。每个工件都包含一组需求元素。通用需求组合可以被视为包含四个关键层的元素：业务层，流程层，需求层，规范层。可追溯性元素可被识别为此四层，并创建需求可追溯性矩阵。
- 将需求填充到可追溯性矩阵(RTM)中，如下图
- 建立需求的向后可追溯性
对于向后可追溯性，每个需求都需要在部分或完全实现业务目标方面为项目章程做出贡献。为了向后追溯，需要分析和建立每个需求到一个或多个项目目标和业务流程的可追溯性。主要是此分析根据为什么需要它来验证需求
- 建立需求的前向可追溯性
对于前向可追溯性，规范元素需要在流程步骤，用户界面，计算逻辑等方面描述需求的系统实施指南，主要验证每个要求都是可实现的。
- 整合需求可追溯性数据
需求可追溯性矩阵整合了从需求起源到实施的完整需求追踪。矩阵的每一行对应一个要求，列分别从左到右依次是需求源、需求ID、业务层的需求元素、流程层的需求元素、规定的需求、需求元素规范层、跟踪标志、需求的不一致计数。
其中单元格中的差距表示需求中的差距，需要作为不一致提出并采取行动。
优点
该模式提供了一种结构化的方式来创建具有向后和向前可追溯性的格式良好的需求可追溯性矩阵。它有助于验证需求与业务目标的一致性，并检测需求规范中可能未检测到的许多不一致的地方。
手动维护大量需求和跨多个项目的表可能会变得困难，因此可以将此模式集成到整体需求流程和工具平台中，并和需求覆盖分析模式相辅相成。
有效性评估
当这两种模式应用于一个企业数据仓库报告系统时，该系统具有一组具有规定要求的用户故事。
从给定的集合中，六个用户故事被用于试点，涵盖35个需求。出于说明目的，考虑了用户故事US1"收入耗尽报告”。
该报告应该可供一组经理使用，以查看服务合同业务即将到来的和过去的收入用完的收入。
该用户故事对报表的过滤条件提出了要求:显示发票的金额;显示收入、计费天数等信息;从源数据库中提取数据，并将1000条记录导出到 Excel 的能力。
需求覆盖分析
在分析推理维度的需求时，发现需求中没有涵盖角色维度（who)、时间(when）和规范部分(how)。可以追踪到其他推理维度。因此，在“谁”需要运行报告、“何时”需要运行报告以及“如何”实施方面存在需求差距。
同样，在对需求进行NFR覆盖分析时，发现遗漏了一些关键的NFR：已经讨论了对角色的**安全要求的差距,**并且没有说明报告的性能目标。这些差距条目被记录到Requirement Coverage Tracker（ RCT ）中。对于每一行，标记新的要求标志或计数器随着每一行的间隙数递增。
- NFR维度上缺乏安全要求——未指定报告的访问角色信息，属于一个新需求，解决方案是限定报告的访问控制，即只能由财务经理访问。
- NFR维度上缺乏对性能的限定，即未提供导出1000条记录的目标相应时间，这属于一个需求缺口。
- 推理维度上没有提供地理（where）的具体规则，这也属于一个需求缺口。
- 领域维度中未规定与强制性数据保护法（DPA）合规性相关的要求。
在特定情况下，应用该模式的结果是需求数量从35个增加到63个，**覆盖率提高80%**，这表明基线需求得到了很好的扩展。
需求追溯分析
描述了合并到RTM中的项目需求元素的可追溯性的部分视图。红色标记的单元格表示需求不一致，其原因可能是缺乏业务层一致性或者缺乏字段映射或逻辑规则导致的不规范。
- 需求1的规范层中发票金额缺少来自源数据库的字段映射
- 需求4的规范层中未指定货币转换的计算逻辑
在35个需求中，只有7个需求可以向前追溯，28个需求在领域或逻辑规范上存在差距。RTM会根据每个需求的需求差距数量进行更新。
评估
应用模式所需的工作量为65小时。表5中计算出的修复不一致的总工作量为420小时。A=65小时，B=420小时。因此，节省的开发工作量=（B–A）/A=546%，表明由于应用模式而节省了大量工作量。
总结
需求一致性分析是软件开发中非常重要的一环，它的目的是确保软件系统各个阶段的需求与设计的一致性，从而最终构建出符合用户需求的系统。
在进行需求一致性分析时，我们可以遵循一定的过程模式，以保证分析的准确性和完整性。
首先，需求一致性分析的过程模式必须具备系统性和全面性。在进行分析时，我们不能只看某个需求或某个模块，而应该从整个系统的角度出发，全面地考虑每个需求的实现和相互之间的关系。只有这样才能保证系统的稳定性和可靠性。
其次，需求一致性分析的过程模式需要具备灵活性。在软件开发中，需求随时都可能发生变化，因此我们需要针对不同的需求变化，灵活地调整分析过程模式。这样才能保证分析结果的准确性和实用性。
最后，需求一致性分析的过程模式需要具备透明性。在分析过程中，我们需要与客户和开发团队沟通交流，及时反馈分析结果和意见。这样既可以避免分析结果出现偏差，还可以加强开发团队与客户之间的信任和合作。
总之，需求一致性分析的过程模式是软件开发中不可或缺的一环，只有在严格遵循系统性、全面性、灵活性和透明性等原则的基础上，才能保证分析结果的准确性和实用性，从而构建出高质量的软件系统。
...全文
请发表友善的回复…
发表回复
