第四章改善需求过程.docVIP

第4章 改进需求过程 第3章介绍了几十种需求工程中的好方法，你应当考虑在实践中应用它们。把理论方法付诸于实践活动是改进软件过程（process）的核心所在。从根本上说，改进过程包括使用更多有效的方法避免使用过去使用过的令人头痛的方法。然而，改进之路却是从失败、错误开始，还要历经那些受影响人的抵制及因任务时间紧迫导致搁置改进这样的挫折。 软件开发过程的改进有以下两个主要目标： 解决在以前项目中或目前项目中遇到的问题。 防止和避免你可能在将来的项目中要遇到的问题。 如果你目前采用的方法好象也挺有效的，你可能觉得没有必要改变你的方法。但是，即便是很成功的软件组织在面临大项目、不同的客户群、紧迫的进度安排或全新的应用领域时也会感到力不从心。因此，至少你应该知道其它一些很有价值也颇有效的需求工程方法，并把它们加入到你的软件工程中。 本章介绍了需求与其它主要的项目过程和风险承担者之间的联系。关于软件开发过程改进的一些基本概念，并推荐了一种经改进的生存期。我把一些重要的需求“过程精华”罗列出来以供参考使用。本章还介绍了实施改进需求工程实践的一个流程蓝图。 需求与其它项目过程的联系 需求是软件项目成功的核心所在，它为其它许多技术、管理活动奠定了基础。变更你的需求开发和管理方法将对其它项目过程产生影响，反过来也会产生影响。需求与其它过程的联系见图4-1。下面简要介绍各过程间的接口。 制定项目计划。需求是制定项目计划的基础。因为开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。通常，项目计划指出所有希望的特性不可能在允许的资源和时间内完成，因此，需要缩小项目范围或采用版本计划对功能特性进行选择。 项目跟踪和控制。监控每项需求的状态，以便项目管理者能发现设计和验证是否达到预期的要求。如果没有达到，管理者通常请求变更控制过程来进行范围的缩减。 变更控制。在需求编写成文档并制定基线以后，所有接下来的变更都应通过确定的变更控制过程来进行。变更控制过程能确保： 变更的影响是可以接受的。 受到变更影响的所有人都接到通知并明白这一点。 由合适的人选来作出接受变更的正式决定。 资源按需进行调整。 保持需求文档是最新版本并是准确的更新文档。 系统测试。用户需求和功能需求是系统测试的重要参考。如果未说明清楚产品在多种多样条件下的期望行为，系统测试者将很难明确正确的测试内容。反过来说，系统测试是一种方法，可以验证计划中所列的功能是否按预期要求实现了。同时，也验证了用户任务是否能正确地执行。 用户编制文档。我曾在一个办公室里工作，办公室里有为商业产品准备用户文档的技术写作人员。我咨询其中一位写作人员为什么他们要工作那么长时间。“我们是食物链的终结者”她回答道,“我们要编写出用户显示界面及性能的最终变更版本 ”。产品的需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困难。 构造。软件项目主要产品是交付可执行软件，而不是需求说明文档。但需求文档是所有设计、实现工作的基础。要根据功能要求来确定设计模块，而模块又要作为编写代码的依据。采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和是否满足了相关的需求。跟踪每项需求与相应的设计和软件代码。 软件需求对其它项目风险承担者的影响 当软件开发队伍改变他们的需求过程时，与其它项目风险承担者沟通的接口也会发生变化。图4-2说明了一些外部组织功能，这些功能是通过一定的接口与软件开发队伍联系的，这些接口对项目需求活动起着重要作用。 为保持能顺利进行这些接口操作，要与其它领域的合作者多交流，让他们知道你的改进想法和调整计划。你要向他们说明改进后的新过程会带来什么好处。如在改进过程中需要获得合作时，可以从这样的谈话开始：“这些是我们曾经经历过的问题，而我们认为进行这些变更将会有助于问题的解决。这就是为什么我们要这样做的原因，我们需要得到你们的帮助。而我们的这些工作也会给你们予以帮助的”。反对变更是由于害怕变更带来的影响，因此要指明你进行的过程变更所可能带来的影响，从而减少大家的恐惧感。 向各个功能领域的人说明你从他们那里所需要获取的信息和帮助，从而有助于成功地开发整个产品。在开发过程中要遵从开发组与其它功能领域之间重要交流接口的规范和内容，如系统需求规格说明文档或市场需求文档。通常重要项目的文档从写作者角度是严格规范的，但往往不能给客户提供他们所真正需要的全部信息。 另一方面，询问其它组织需要从开发队伍中获取什么以有助于他们的工作。技术可行性方面哪些能帮助市场部更好地完成产品计划？什么样的需求状态报告能使管理者更充分地看清楚项目的进展情况？与系统工程部之间怎样的合作才能确保系统需求在软、硬件间的分配合理？努力在开发组和其它需求过程风险承担者之间建立