随着时间的发展，需求已经开始为人们所重视，因此，需求已经提升到了一个新的高度——需求工程。作为软件工程的子领域，需求工程的重要性和决定性越来越突出。需求中的一个不慎都有可能导致后续工作中的大量返工，甚至是项目的失败。Robert Glass在其著作《Software Runaways》中评述到：“项目需求无疑是在软件项目前期造成麻烦的一个***原因，一个又一个的研究已经发现，当项目失败时，需求问题通常正是其核心问题。”
需求工程定义
既然需求工程如此重要，那么，什么才是需求工程呢？在IEEE标准610.12 – 1990软件项目语境中将需求工程定义如下：
1．用户解决一个问题或达到某个目标所需要的条件或能力。
2．一个系统必须满足的条件或拥有的处理能力，或者一个能满足一项合同、标准、规格说明或其他正式文档的系统或系统组件。
3．前两项中的一个条件或能力的文档表示。
Abbot在他的著作An Integrated Approach to Software Development中将软件需求定义为：“为了实现系统的目标，用户需要且必须提供的符合或满足的任何功能、限制或其他属性”。
事实上，需求工程常被划分为需求开发和需求管理两部分，其中各部分包含四个子工程，如图1-1所示。这八个子过程是顺序递进的，且是以一次次迭代的形式贯穿于软件工程的整个生命周期之中的。
简而言之，需求工程的目的就是定义所需解决的问题。凡用于收集、分析、文档化、评审和管理软件需求的良好工程原则的使用就可以称作软件需求工程。
需求的重要性
美国于1995年开始的一项调查的结果有力的证明了需求的重要性。在调查中，他们对全国范围内的8000个软件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。
需求工程是软件工程中最复杂的一个部分。从人员角度讲，要想做出***质的需求就离不开最终用户的积极参与和设计人员对所涉及领域的了解，然而，这正是现阶段最难解决的问题。用户和设计人员不能完整、正确的了解对方领域的知识，加上沟通不充分，此外还有很多需求是隐性的，用户都说不清楚自己的需求，这些就必然会导致需求中会存在问题。从一个客观的角度讲，需求又是一个非常空泛的事情，没有人能够准确且完整的说出针对一个项目的所有需求，这就从侧面说明了，要想做出***的需求是不太可能的，需求中存在些许的遗漏是必然的。但是，作为开发人员来讲之所以会在只有1%的希望的情况下也要用100%的心去尽力完成需求，是因为在软件工程的一系列工程中，遗留的问题发现的越晚，所付出的成本就会越高，如图所示。
图：在各阶段纠正一个错误的成本对比
需求中面临的问题
需求是软件生命周期中的***个阶段，也是软件工程中最重要的一个部分。但是，人们却没有像研究软件工程一样深入的研究需求。
软件需求不同于其他行业中的需求那样的明确、可描述、客观、可验证。软件需求是模糊的、多变的、主观的，正因如此软件需求中才会存在如下的一些问题：
建设方领域知识的缺乏。
软件已经开始涉及到各行各业中，然而建设方中承担需求分析任务的分析人员大多是技术出身，而不是业务出身，他们的知识结构的重点是计算机。这种客观存在的因素导致分析人员即使在需求方面拥有丰富的经验，但是在许多项目中他们的知识仍然是不够用的。所以在一个从未接触过的领域里开展需求工作一定会面临很大的困难和障碍。
需求的描述问题。
目前在开展需求工作中我国普遍存在的现象是用户对需求描述不清。由于大多数用户虽然精通业务，但是在提及需求时却不知道应该提什么需求，或者说他们不知道什么才能算是需求，更甚者说他们对未来的目标系统仅仅只有一个模糊的概念。出于以上这些原因，想要出色完成需求工作是障碍重重。
需求理解的问题。
人和人的思维方式是不同的，因此对于用户表达的需求，不同的开发人员可能会有不同的理解。如果真的误解了用户的需求，将会导致后续阶段的开发方向的偏离。所以这个问题只有通过与用户增加交流和日后的需求验证加以解决。
需求的完备程度问题。
任何的完备都只是从一个相对的角度看待的，不存在绝对的完备。随着系统范围的扩大，要想穷举需求几乎是不可能的。因此，要想有一个相对完备的需求，只有先确定一个基线。
需求的细致程度问题。
对于这个问题，只能说是仁者见仁，智者见智，谁也下不清楚这个定义。而且，随着需求时间的加长，变化也会随之增多的。因此，在遵守需求工期的前提下尽量描述细致就可以了。
需求变更问题。
“需求的变化是永恒的”这句话想必是人人赞同的。当然，经常变更需求会给人力资源、经费以及项目进度带来巨大的影响，但是变更是不可避免的，有时需求变更也并不一定就是坏事，及早及时的发生变更可以有效地更正原有需求中的错误。既然是不可避免，也就不必畏惧，只要相应的变更措施跟上了就可以做到坦然处之了。
需求工程内容及管理探讨
需求获取阶段
需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了3个至关重要的因素：应搜集什么信息；从什么来源中搜集信息；用什么机制或技术搜集信息。再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。综合上述3个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。
需求分析阶段
需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息的基础上，结合软、硬件实现方案，并做出初步的系统原型给承建方做演示。承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。同时，用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。
需求文档编写阶段
需求开发的最终成果是，在对所要开发的产品达成共识后，所编写的具体的文档。需求文档是在需求获取和需求分析两个阶段任务结束时生成的，所以文档要包含所有需求。
在此阶段先要从软件工程和文档管理的角度出发依据相关的标准审核需求文档内容，确定需求文档内容是否完整。对需求文档中存留问题进行修改的工作。
需求确认阶段
需求确认主要是针对《需求规格说明书》的评审，保证需求符合优秀需求成熟的特征，并且符合好的需求规格说明的特征。在需求确认阶段需要保证以下几点：
软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征。
从系统需求、业务规则或其他来源中正确的推导出软件需求。
需求是完整的、高质量的。
需求的表示在所有地方都是一致的。
需求为继续进行产品设计和构造提供充分的基础。
需求跟踪阶段与需求复用阶段
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与维护“需求——设计——编程——测试”之间的一致性，确保所有工作成果符合用户需求。需求跟踪是一项需要进行大量手工劳动的任务，在系统开发和维护的过程中一定要随时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直接影响产品质量，降低维护成本，容易实现复用，同时，需求跟踪还需要建设方的大力支持。
需求跟踪的***步是要选择一个适于本项目的联系链，如图4-1所示。只有建立了明确的联系链才可以了解各需求之间的父子关系、相互连接和依赖关系。
某些可能的需求跟踪联系链
第二步，选择跟踪矩阵类型。跟踪矩阵分为单矩阵和多矩阵。两种矩阵都可以明确地显示一个需求的相关联系，而作为多矩阵的好处就是可以追溯到一个需求的特定用例，而且，便于自动工具的支持。
第三步，根据项目中各部分的重要性，有选择性的进行部分的跟踪。
第四步，更新联系链。在需求发生变动后一定要及时地更新联系链。
第五步，确定联系链的信息提供人员，以及管理人员。
第六步，要定期审查跟踪信息，以确保信息***。
需求跟踪的工作，首先是要保障需求跟踪管理工作在每次出现需求变更时都要及时进行，避免出现工作结束后在重新创建。其次要注意需求跟踪链和需求跟踪矩阵建立是否正确、合理、科学。并且要通过审查方式检查跟踪数据的完整和准确。待确立了需求跟踪矩阵后，依据矩阵中各需求间的关系检查是否每个底层的需求是否都能够向上找到一个高层的需求，并且在查找的同时还要再次检查每个需求是否都是有唯一的标识。
(6) 需求复用阶段
在软件项目实施过程中，许多不同项目间存在着许多相似的需求，尤其是类型相同的项目在不同的用户群众的实施中，需求的相似性就更加明显、更加普遍了。有了需求复用，建设方就能快速的形成一个需求的原型，这样，后期的需求工作只需要在此原型的基础上进行修改、扩充和完善即可，大大提高了需求分析的工作进度。所以，对于需求的复用就需要加以重视。
对于需求复用，首要责任就是要提取可复用的需求，对需求复用的理解和扩充。其次就是要保证需求复用不存在冲突。
(7) 需求变更控制阶段
需求变更在软件项目开发中是不可避免的。无休止的需求变更只会造成各种资源无休止的浪费，但是其中也不乏有许多是必要的、合理的需求变更。对于需求变更，首先是要尽量及早的发现，以避免更大的损失。其次，是要采取相应的、合理的变更管理制度和流程，这样同样可以降低需求变更带来的风险。
(8) 版本控制阶段
版本控制是管理需求规格说明和其他项目文档必不可少的一个方面，也是需求变更文档化管理的最有效办法。可以详细记录发生需求变更的需求文档版本的版本，发生变更的原因，变更发生的控制记录，并对变更后的需求文档进行唯一版本号的标识。使得每个成员都能及时访问***版本的需求文档。
实施版本控制的基础是需求基线，所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。
结 论
需求工程是近几年里提出的一个新概念，所谓需求工程就是所有与需求直接相关的活动。作为软件工程的子领域，需求工程通过需求开发和需求管理两个方面对需求工作进行全面的管理。而其在整个项目中的重要性和决定性也越来越突出。可是需求工程中同样会面临诸多的问题，所以有了需求工程实施管理的系统方法外，引入对需求工程进行监督管理的机制大有必要。
