对需求的一点看法

      需求是什么，如何来做好需求，在CMMI 模型里都给予了说明。模型将需求分为两个部分，一个是二级的需求管理，另一个是三级的需求开发；之后又看了RUP 对需求的描述，它没有明确对需求管理与开发进行划分，它的工作流包括了以下几个部分：问题分析，理解涉众需要，定义系统，管理项目规模，改进系统定义，管理需求变更。

       相对来说，CMMI 从宏观上来讲需求，定义两个过程域相关的活动及各个活动的工作产品，指出了在需求工程里所要关注的东西，但感觉起来，多少有些学院派的气质。而RUP 更多则是考虑实际，从CMMI 中裁剪得出自己的流程，多少有些现实的气息。这两者就像理想与现实一样，理想给了行动的路线与方针，而现实给了行动的依据。不过反过来说，比喻有点不恰当，因为现实不可裁剪，而RUP 也有可以裁剪的地方。总的来说，两者都给出如何解决需求问题的方法与步骤。

       在实际的项目中，要想把需求固定下来不是一件容易的事。真正做好需求的，往往意味着成功。从问题收集，分析，到最后的评审通过，经历了一个渐近明晰的过程。开发客户需求、开发用户需求、分析确认需求，这是需求开发过程域所要求的。每一活动都与其它活动相关，这一点倒是有点RUP 的味道。在需求管理过程域里，既要取得对需求的理解与承诺，还要维护需求的变更。但在实际的项目中没有太多的界限划分。一个朋友这样说，CMMI 是对所有项目工程的框架进行描述，它给出了这一步应做什么，下一步应做什么，不仅仅适用于IT 项目，还有其它工程项目。而RUP 则是细化了模型的要求，以另一方式表达了一个项目所应进行的过程。两者都可以根据实际项目的情况进行裁剪。

最近在研究RequisitePro 的过程中，感到它是一个非常适合于RUP 模式的开发，在需求不稳定的情况下对需求进行维护，从最初的需求到最终的代码实现、测试用例都可进行追踪，方便标识变更的需求。

在生命周期模型中，工程活动一直随着项目的进行。对于瀑布模型，需求基线的确认意味着需求开发的结束，接下来说是对需求进行管理，保证下一个活动的进行。而对于迭代模型，如何来保证需求的有效性，也即是目前大多数项目的情况，就只能采用动态维护的手段了。可以使用工具或其它方式，对评审通过的需求打上基线，作为下一步设计的基础。设计人员最烦的是什么，就是在设计过程中得到需求的变更。因此，在项目开始的时候，就要首先确定项目的范围，确定项目的范围并等于确定了需求的范围，但至少加上了一些需求的约束，减小需求变更的范围。现实中的大多数项目后期出现的变更基本上都超出最初的项目范围，把这类变更也算在需求变更的范围内，个人觉得不是太合适，超出项目范围的变更，就不应再属于项目内某一活动的变更。

动态地维护需求变更，对于需求管理人员来说就是在设计之前将需求确定下来。目前广泛采用的方法是基于用例的需求获取方法。对于用例，它只告诉了涉众所需要的东西，并不是指项目的功能点。以前对用例的认识是，只要开发出了一个用例，就好比找到了项目的一个功能点，在看了 http://coffeewoo.itpub.net/ 之后，感觉只使用了用例的很小一部分功能。现在要让我做出更深层次的解释，尚拿不出，只能通过不断的学习加深理解。