工作流程明细：管理系统规模
在确定特性级别的需求，描述大多数主角、用例以及补充规约所指定的其他需求后，系统分析员应该收集需求属性(如优先级、工作量、成本和风险等)，并尽可能精确地为其指定属性值。这使得人们对如何确定系统发布的初始规模有了更好的理解，也让构架设计师能够从结构上确定具有重要意义的用例。
由项目和开发管理人员一起制定的迭代计划，首次出现在该工作流程明细：管理系统规模中。迭代计划也是一个开发计划，它定义为发布版计划的迭代次数和频率。早期的迭代应计划规模内风险最高的元素。
管理规模工作流程的其他重要输出包括软件构架文档的初始迭代和一个修订过的前景文档，前景文档反映分析员和关键涉众对系统功能和项目资源的加深理解。
与前面提到的商业理由一样，迭代计划的第一个问题是，软件构架文档不是需求管理工作流程的一个工件，尽管它与该工作流程有关而且是 Rational Unified Process 的一部分。这部分内容不在本文的讨论范围内。
经验告诉我们，成功管理规模的关键在于，仔细考虑分配给涉众需要、特性、用例和补充规约所指定的其他需求的属性值，与代表性涉众定期进行开放而诚恳的交流。
图 13 - 管理系统规模
工作流程明细：管理系统规模
构架设计师为用例的风险范围、构架重要性和构架覆盖范围确定优先顺序。尽管定义系统时用到了许多用例和补充规约需求，但通常只有用例的一个子集才是好的系统构架的关键。确定用例的优先级后，构架设计师改进迭代或开发计划，利用 Rational Rose 这类工具建立系统构架的用例视图模型。
系统分析员通过改进前景中特性的需求属性来管理依赖关系。他们还对用例和补充规约里的需求进行改进。系统分析员确保涉众需要、特性、用例需求和补充规约需求存在适当的可追踪性。这里特意使用了“适当的可追踪性”。请参见本文中插入的关于可追踪性的说明文字。
文章来源于领测软件测试网 https://www.ltesting.net/
