需求管理

把自己定位为科学家的周铁人，带着激情发展了自己的开发方法论——Specification Drive Development（需求驱动开发）。

“管”不住需求的管理流程根本毫无作用，却像一座高墙禁锢我们的洞察力，让我们沉浸在“只要把报告补充完整就是做了需求管理”的虚假幻像中。

U9作为一款大型ERP产品，从产品构想到最终上市，整个过程历时5年，而需求设计阶段几乎占整个产品诞生所需时间的1/2。在这样一个时间跨度如此之大长的需求设计全过程，U9的需求设计人员是分为哪些阶段来实现的呢？

在敏捷开发中，控制和管理小版本发布是非常重要的工作，不仅能对需求变更作出及时的响应，而且还能够协调开发人员的工作，对整个软件开发过程进行有效的管理，大大提高软件开发效率，达到事半功倍的效果。

2009年的调查数据显示，在影响软件项目交付的主要原因中，变更频繁占到39.7%，需求不明确占到32.4%，其他包括软件质量问题占16.5%，进度控制占11.4%。可以看到，需求仍是影响软件交付的最大因素。

很多工程公司，培养了大量项目管理人员，编制了一大堆项目管理制度，而且在“执行力”上也很强调，但是项目管理水平还是很难提高？生产协调、进度和效益等问题还是得不到有效解决，其原因何在？上海复斯管理咨询公司的实践研究表明，常规组织体系和管理模式——项目管理的运行环境缺乏有效变革是症结。

最近做了一个关于医疗方面的项目，测试阶段有幸担任Leader，对软件测试有了进一步的了解，在此分享一下个人的体会。

需求文档是个麻烦问题。虽然我们可能真的需要那么多文档才能准确地制定出规格。而且，大量的需求文档里面还有重复内容及不一样的语言。此外，虽然团队中有人善于编写规格，但也有人不擅长或者需要压力才能做好。大家都想知道，有简化这方面工作的方法或工具吗？

软件需求说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。

客户需求，为什么总在变阿？做项目真辛苦阿！这样的感叹整天都挂在口上。客户需求变动确实是一个软件开发永远不变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？

本文总结了作者对敏捷开发的一些理解，其中，作者认为注重需求，同时在项目进行时齐头并进是敏捷中最重要的理念。

随着对项目管理理解的深入，自己对项目管理的两点有了深刻理解：需求开发与管理、项目组织结构。

客户的需求是否应该得到满足？软件工程是否目的就是满足客户的需求？这个问题看来是无法加以回答的，因为，它没有提供两个基本的解释，其一：客户 的需求即算从客户的利益立场出发，是不是合理的？其次，客户的需求有多大程度上是必要的？还是只是一种个人的喜好？

本文探讨了软件需求分析与管理过程中应该注意的十个问题。简单来说，需求工作涉及到需求开发和需求管理两方面，对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。

需求管理是团队的工作，只有这样才能保证统一的步调，使项目成功。Telelogic DOORS 企业需求管理套件（DOORS/ERS）是仅有的面向管理者、开发者与最终用户及整个生命周期的综合需求管理套件。

Total Metrics为国际知名FP服务提供商，其功能点计数和需求管理工具“SCOPE”将为中国企业实施基于功能点的估算和项目管理提供有力支撑。SCOPE不仅使企业能面对每个需求和项目变更进行详细的功能点计算，而且能保持功能点统计的自动更新。

在需求工程方法学中，用例技术和原型法都是需求建模的主要工具。作者在比较、分析其用例与原型法的基础上，引入基于面向对象的演化原型，提出了一种新的用例与演化原型法相结合的需求应用模型，并对该需求模型的实现进行了详细地描述。

项目产品的'DIY'，是指软件产品要成为用户自己的软件产品，虽然很可能还是由专业的软件公司来开发，但项目软件的生产在本质上是“用户自己做”的一个过程。

软件产品根据是否进行了客户化定制开发，可分为“开箱即用”的、直接面向客户使用的产品和加载了“顾客定义”的项目解决方案两类。本文中把前者简称为“产品”，后者简称为“项目”，并主要讨论两者在需求开发方面的差异。

本文主要结合作者本人早期在产品开发部门管理以及产品研发管理等具体工作中的一些教训，对面向产品的需求开发在实际操作过程中应注意的问题进行了讨论。