用户界面设计员模拟系统的用户界面并进行原型设计。这项工作与用例的演进密切相关。
对每个需求有更深入的理解后，用例阐释者和系统分析员对其工作量、成本、风险以及其他属性值进行修正。
系统定义改进流程的结果提交给另一轮管理规模工作流程明细。对系统有更多的了解后，可能需要改变优先级。毫无疑问，如果必要，系统发布的规模将需要复审和改进。
工作流程明细：管理需求变更
当变更发生时 -- 变更是不可避免会发生的 -- 管理需求变更工作流程明细需持续应用于项目生命的全过程，这与管理系统规模工作流程明细一样。该工作流程的输出可能导致对每个工件的修改，这又要求在所有的项目团队成员和涉众之间进行有效的交流。
在这个工作流程中，我们引入了受需求工作流程影响的其他工件。需求的变更必然影响在分析设计工作流程中表示的系统模型。需求变更还影响用于验证需求是否正确实施的测试。在前面的例子中，这些工件是 Rational Unified Process 的组成部分，但不是本文论述的主题。在管理依赖关系流程中确定的可追踪性关系是理解这些影响的关键。
可追踪性
在需求领域，与可追踪性有关的事务有很多。许多事务都具有追踪单个客户需求到每个相关规约、测试、模型元素以及最终源码文件的特点。的确，一些可追踪性是成功的需求变更管理的关键。
然而，这里事先警告，在项目的整个生命周期中，建立和维护各种形式的可追踪性都需要投资。像所有的投资一样，可追踪性的投资回报点逐渐减少，这取决于具体情况。本文强调在不同需求类型之间进行追踪的价值。这是一个很好的起点，而且可以用 Rational RequisitePro、Rose、SoDA 和 TeamTest 这样的工具使之自动化。我们相信，你终将发现某个级别的需求可追踪性是好的投资对象。
要了解需求可追踪性策略的更多信息，请参见白皮书“通过用例进行需求管理的可追踪性策略” [6]。
管理需求变更工作流程的另一个重要概念是需求历史追踪。通过把握需求变更的性质和基本原理，复审员(工作受变更影响的任何软件项目团队成员)将收到对变更作出正确响应所需的信息。
图 15 - 管理需求变更
工作流程明细：管理需求变更
出于各种原因，任何涉众或项目团队成员都有可能提出变更需求的请求。所有变更请求 (Cr)，包括对需求或扩展请求甚至缺陷的变更，都应该通过同一个变更请求管理 (CRM) 流程进行疏导。至少，这应包括在一个集中数据库系统中记录并追踪请求，并由中央复审委员会执行复审。CRM 流程的详情见 Rational Unified Process 的其他小节。
文章来源于领测软件测试网 https://www.ltesting.net/
