重视需求开发
需求开发是在问题及其最终解决方案之间架设桥梁的第一步，是软件需求过程的主体。一个项目的目的就是致力于开发正确的系统，要做到这一点就要足够详细地描述需求，也就是系统必须达到的条件或能力，使用户和开发人员在系统应该做什么，不应该做什么方面达成共识。
我们都知道开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。
需求开发就是为了解决这些问题，它必不可少的成果就是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。
这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。
首先，软件需求不能如实反映用户的真正需要。比较常见的一种误解是需求的简单和复杂程度决定了用户是否能够真正理解相应的内容：误认为客户只能看懂简单的需求，但是对开发没有直接帮助；只有复杂的需求才有用，但是大多用户又不可能看得懂。事实上，造成这类问题的主要原因是捕获的需求不能反映用户的视角，因而，用户站在自己的立场上很难判断需求是否完备和正确，特别是在开发活动的早期。
其次，软件需求不能被开发团队的不同工种直接共用。理论上，开发团队所有成员的工作内容都受软件需求制约；现实中，如果不采用理想的需求捕获方式，只有分析人员的工作看起来和软件需求的内容直接关联，其它人的工作内容和软件需求的关联并不直观，形式上的差异或转述往往不易察觉地造成了诸多歧义、冗余或者缺失。
本文并不会就此开始探讨需求开发的问题，只是强调需求开发过程的重要，以及需求开发过程对需求变更的影响。就拿笔者亲身参与的一个项目来说：我们遵循一般的软件开发过程，通过前期一段时间的调研，做需求分析，客户基本确认之后，开发人员就投入到紧张的开发工作中，由于项目时间要求紧迫，在经过测试人员的简单确认之后，进入到试运行阶段。
结果是，在客户的试运行报告中，提出了很多问题，其中就有一条，关于一个数据查询条件的设置，客户要求的是模糊匹配查询，而实现的却是精确匹配查询。在相关的需求文档中，却找不到任何相关的需求说明。
需求开发完成之后，进入系统构建阶段，下面我们来谈构建过程中如何做好需求跟踪，以便于后期需求变更的管理。
构建过程中的需求跟踪本文转自项目管理者联盟跟踪需求是高质量软件开发过程中必需的一个特性。用以保证开发过程中每一个步骤的正确性，以及该步骤与上一步的一致性。经验表明，在需求规格、架构、设计、开发和测试阶段，对需求的跟踪能力是确保实现高质量软件的重要因素，同时也为需求变更管理提供有力的支持。
跟踪这些需求在每个阶段的变化，并且分析变更带来的影响，是现代软件过程的一个主线，尤其是在一些事关重大的软件工程项目中，需求跟踪的影响更加突出。
历史数据表明，如果需求没有被完整的跟踪，那么总会有遗失的需求或者是没有解决的需求，或者是需求的变更没有彻底进行，导致部分影响被忽略了，而往往是这样的失误导致很严重的安全问题和可靠性问题，给客户带来不可估量的损失。
这样的教训往往是非常惨痛而且印象深刻，笔者至今尤对这样的一次“事故”记忆犹新。那是参加的一个预算项目，在我们开发即将结束的时候，客户由于业务情况发生变化，提出了一条业务数据修改规则的变更。
对于这个这个业务数据的写规则，虽然我们在需求文档中有记录，但是没有将其与设计、开发构件一一对应，建立它们之间的关联，导致在处理这条变更的时候，开发人员遗漏了一种情况的处理。
而这样的问题直到在客户的应用系统运行半年之后才由客户发现，虽然事情最后通过升级软件、人工加工数据处理了这次意外，但是，事故给企业带来的不仅是金钱上的损失，也给企业的声誉带来非常不利的影响。
在图2跟踪模型中，箭头代表的是跟踪的方向，模型表明，不仅在需求定义的领域跟踪需求，而且我们也在实现领域和测试领域跟踪需求。
在系统定义领域，包括有三个方向的跟踪：从业务需求到产品特性的跟踪；从用例到产品特性的跟踪；从变更的需求到产品新特性的跟踪。对于每一种跟踪，我们都可以使用类似于如下的一个表格来管理。在实际项目中，要做好需求的跟踪管理并非易事，也许我们可以使用电子表格，办公软件来协助处理，确实，它们对于项目的管理非常有用。
但是，表格的问题在于难于维护，特别是当项目较大，存在复杂的关联关系的情况，改变一个链接可能涉及到很多相关的链接，在这种情况下，维护就成了一场噩梦。
在这种情况下，我们要么简化需求跟踪处理，对大的模块进行跟踪；要么使用专门的需求管理工具。如果是大型项目，最好使用工具来进行管理。这样，在我们面临需求变更的时候，才能有备无患。
