在整个项目中，该步骤是最为重要的步骤之一。第一次，我们对所提议的系统了解如此之深，使得我们能对需求、项目资源和交付日期作出重大承诺。同时也必须理解，这些需求将会随着了解程度的加深而变更。如果在前三个工作流程对依赖关系进行管理，则执行这一步骤就会容易得多，将来进行变更也更容易。
贯穿项目的整个生命周期，随着形势和环境的变化，由于系统分析员必须就修改后的项目规模和前景与关键涉众进行协商，因此将会多次重新检查该工作流程明细。涉众和开发团队成员只有把该步骤看作一个自然前进过程 - 既不要让用户措手不及，也不要企图向组织索要更多时间和金钱 - 才能成功管理项目规模，使之与可用资源相符合。该工作流程在项目的主要里程碑处需重复多次，以便评估对系统及系统问题的新认识是否要求变更规模。尽管已承诺的需求、预算和期限很难更改，但随着对确定优先级的用例、补充规约和早期系统迭代的深入理解，不可避免会导致人们重新考虑系统规模。
需要重申，在到达改进阶段之前，以及在贯穿项目生命周期内发生变化前，项目团队应维持日常的规模管理，这一点很关键。涉众代表必须理解并相信，在难度不断增加的规模协商中，他们的优先考虑和利益始终得到认真的对待。在改进系统需求之前，只有重要的需求才有待于协商或修改。除非建立有效的规模管理制度，否则项目注定会变成一次“死亡之旅” - 规模过大的项目将残酷地走向延期和成本超支的绝路。
工作流程明细：改进系统定义
进入改进系统定义后，该工作流程明细假设已经概述了系统级别的用例并至少简要描述了主角。通过项目规模管理，前景中的特性再次确定了优先顺序，现在可以相信，这些特性在比较严格的预算和期限下是可以实现的。该工作流程的输出是对系统功能更深入的理解，这些系统功能在详细用例、已修订的补充规约以及系统本身的初期迭代中进行说明。
显然，不是所有的系统都有用户界面，不是所有的初期迭代都包括 GUI 元素。这里我们仅仅将它们作为初期迭代的示例。其他例子包括原型、模型和示意板。
图 14 - 改进系统定义
工作流程明细：改进系统定义
用例阐释者详述每个用例的事件流定义、前置和后置条件以及其他文本属性。为最大限度地减少工作量并提高可读性，建议使用标准文档格式或用例规约模板来记录每个用例的文字信息。创建考虑周全的用例规约对系统质量至关重要。制定规约要求对涉众需要以及与用例相关的特性有透彻的理解。让项目团队的若干成员(如软件工程师)参与用例创建是再好不过了。
同时，用例阐释者使用并非用例特有的附加需求对补充规约进行修订。
文章来源于领测软件测试网 https://www.ltesting.net/
