目录
什么是需求工程
需求工程的概述
需求工程分类
需求工程的主要内容
需求工程的基本活动
需求工程的验证准则
什么是需求工程
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
需求工程的概述
需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需求工程(requirementengineering,RE)。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，并开始开展工作。
需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
需求工程分类
需求工程(RE)可分为
1.系统需求工程（如果是针对由软硬件共同组成的整个系统）
2.软件需求工程（如果仅是专门针对纯软件部分）。
软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。
需求工程的主要内容
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。80年代，HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。近来，MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证。
综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：
（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；
（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；
（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；
（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；
（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。
需求工程的基本活动
需求工程无疑是当前软件工程中的关键问题，从美国于1995年开始的一项调查结果就足以看出这一点。在这项调查中，他们对全国范围内的8000个软件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。
需求工程又是软件工程中最复杂的过程之一，其复杂性来自于客观和主观两个方面。从客观意义上说，需求工程面对的问题几乎是没有范围的。由于应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。其客观上的难度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性。从主观意义上说，需求工程需要方方面面人员的参与（如领域专家、领域用户、系统投资人、系统分析员、需求分析员等等），各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。
最初，需求工程仅仅是软件工程的一个组成部分，是软件生命周期的第一个阶段。虽然大家也都知道需求工程对软件整个生命周期的重要性，但对它的研究远远没有对软件工程的其他部分的研究那么深入。
在传统软件工程生命周期中，涉及需求的阶段称作需求分析。一般来说，需求分析的作用是：
系统工程师说明软件的功能和性能，指明软件和其他系统成分的接口，并定义软件必须满足的约束；
软件工程师求精软件的配置，建立数据模型、功能模型和行为模型；
为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型；
提供开发人员和客户需求规格说明，用于作为评估软件质量的依据。
但从当前的研究现状来看，需求工程的内容远不止这些。需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。
需求工程的基本活动包括：
抽取需求；
模拟和分析需求；
传递需求；
认可需求；
进化需求。
每个活动都有它基本的动机、任务和结果，也有各自的困难所在。
首先，开始一个项目是因为要对现行系统进行改造。要改造一个系统是因为现行系统存在需要解决的问题。如：现行系统与当前情况不符合、出现新的商机或者可能节省时间、资金和资源等，这就是抽取需求的动机。在这个阶段，需求工程师的任务是认识问题之所在，获取足够多的知识，最后成为问题领域的专家。需求工程师常采用W6H方法去认识问题领域，即6个以W打头的问题，一个以H打头的问题，如表1所示。
需求抽取是非常困难的，其主要原因有：
缺乏领域知识，应用领域的问题常常是模糊的、不精确的；
存在默认的知识，即难以描述的日常知识（常识问题）；
存在多个知识源，而且多知识源之间可能有冲突；
面对的客户可能有偏见，如不能提供你需要了解什么或不想告知你需要了解的事情。
需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法、组织会议法以及基于目标的方法等，还有知识工程方法，如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。
需求工程的第二个阶段是模拟和分析需求，目前有许多工作都以此为目标进行。需求分析和模拟的出发点在于：
指导抽取；
帮助需求工程师了解进展；
帮助发现问题；
帮助检查对问题的理解。
需求分析和模拟又包含三个层次的工作。首先是需求建模。需求模型的表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的特点，但它不利于捕获模型的语义，一般只用于需求抽取或标记模型。半形式化表示可以捕获结构和一定的语义，也可以实施一定的推理和一致性检查。形式化表示具有精确的语义和推理能力，但要构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。对需求概念模型的要求包括：
实现的独立性:不模拟数据的表示和内部组织等；
足够抽象：只抽取关于问题的本质方面；
足够形式化：语法无二义性，并具有丰富的语义；
可构造性：简单的模型块，能应付不同复杂程度和规模的描述；
利于分析：能支持二义性、不完整性和不一致性分析；
可追踪性:支持横向交叉索引并能与设计或实现等建立关联；
可执行性：可以动态模拟，利于与现实相比较；
最小性：没有冗余的概念。
需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。
企业模拟是一种软系统方法，涉及整个组织，从各个不同的视点分析问题，包括目标、组织结构、活动、过程等。有的企业模拟还建立可执行的领域模型。采用企业模拟方法产生的不仅仅是规格说明，还可以得到许多关于企业运作的状况分析。目前代表性的工作包括：信息模拟、组织模拟和目标模拟等。
功能需求模拟从不同视点为模拟软件提供服务，包括结构视点和行为视点等，主要方法有：结构化分析、面向对象分析和形式化方法。结构化分析是一种面向数据的方法，以数据流为中心。其核心概念包括：进程、数据流、数据存储、外部实体、数据组和数据元素。有代表性的模拟工具有：数据流图、数据字典、原始进程规格说明。面向对象分析以对象及其服务作为建模标准，比较自然，对象也具有相对的稳定性。主要模拟的元素有：对象、类、属性、关系、方法、消息传递、UseCases等。其主要原理包括分类继承层次、信息隐藏、汇集关系等。形式化方法从广义上说，是应用离散数学的手段来设计、模拟和分析，得到像数学公式那样精确的表示。从狭义上说，就是使用一种形式语言进行语言公式的形式推理，用于检查语法的良构性并证明某些属性。形式化方法一般用于一致性检查、类型检查、有效性验证、行为预测以及设计求精验证。引入形式化机制的目的是：
减少二义性，提高精确性；
为验证打下基础；
允许对需求进行推理；
允许执行需求。
但是人们常常不用形式化手段，因为：
形式化涉及太多细节，分析的级别较低；
形式化的核心问题是一致性和完整性，而不是获取需求；
没有合适的工具；
要求更多的代价。
传递需求的主要任务是书写软件需求规格说明，其目的是：
传达对需求的理解；
作为软件开发项目的一份契约；
作为评价后续工作的基线；
作为控制需求进化的基线。
对需求规格说明感兴趣的群体包括：用户、客户；系统分析员、需求分析员；软件开发者、程序员；测试员；项目管理者。
认可需求就是让上述人员对需求规格说明达成一致，其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。
进化需求的必要性是明显的，因为客户的需要总是不断（连续）增长的，但是一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化（变化）就成为软件进化的首要问题。对传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性并进行关于变化的推理。
需求工程的方法
需求工程包括需求开发和管理，而需求开发又包括这几个过程：需求获取，需求分析，需求规格说明和需求验证。在需求开发之前，还需要有一个知识培训的过程，需求工程也是一个项目工程，因此也包括了项目的管理。对于这些过程，有以下方法可以采用。
1.知识培训
需求分析员培训：需求分析员应该具有良好的交流沟通能力，同时理解产品，并掌握了需求工程的技能。
用户培训：用户也应该接受需求工程知识的培训，让他们理解需求的重要性，知道如何准确的描述需求，需求的风险性等。
开发人员培训：开发人员应该对用户的应用领域有一个基础的了解，明白客户的业务活动，术语，产品目标等
2.需求获取
需求包括业务需求，用户需求和功能需求以及非功能需求，在需求开发之前，我们需要先定义好需求开发的过程，形成文档，内容包括：需求开发的步骤，每一个步骤如何实现，如何处理意外情况，如何规划开发资源等
需求获取包括以下方法和技能：
项目范围确定：开需求开发前期，我们应该获取用户的业务需求，定义好项目的范围，使得所有的涉众对项目有一个共同的理解。
用户确定：确定用户群和分类，对用户组进行详细描述，包括使用产品频率，所使用的功能，优先级别，熟练程度等等。对每一个用户组确定用户的代言人。对于大型项目，我们需要先确定中心客户组，中心客户组的需求具有高级别的优先级，需要先实现的核心功能。
用例确定：与用户代表沟通，了解他们需要完成的任务，得到用例模型。同时根据用例导出功能需求。用例描述应该采用标准模板。
系统事件和响应：业务事件可能触发用例，系统事件包括系统内部的事件以及从外部接受到信息，数据等等，或者一个突发的任务。
获取方法：召开需求讨论会议，观察用户的工作过程，采用问答式对话，采用诱发式需求诱导等等。检查完善：问题报告和补充需求建议
3.需求分析
需求分析是对用户的需求获取之后的一个粗加工过程，需要对需求进行推敲和润色以使所有涉众都能准确理解需求。分析过程首先需要对需求进行检查，以保证需求的正确性和完备性，然后将高层需求分解成具体的细节，创建开发原型，完成需求从需求获取人员到开发人员的过渡。
绘制关联图：关联图确定系统和外部的交互。划分了系统的范围和界限，构建了系统对外的接口。
原型开发：对于敏捷方法，推荐完成一个界面的原型，一个初步的系统实现，通过原型，让所有涉众对开发的项目有了一个初步的映像，同时可以提供对需求的检验。
需求优先级别：采用分析的方法确定产品的功能，用例和单项需求的优先级别，以优先级为基础，确定各项功能和需求都包括在哪个版本中，在项目开发过程中，需求的优先级别根据实际情况进行调整。
需求建模：图形分析模型对需求描述更加抽象。主要可以采用UML的建模分析。
数据字典创建：建立系统中所用到的数据项和结构的定义，数据字典可以使参与项目开发的每一个人都使用统一的定义。
子系统：建立系统的结构，同时将需求分配到各个子系统和模块中。
4.规格说明
SRS应该是一个作为涉众对系统的统一理解。
采用SRS模板：定义一种标准模板。
需求工程过程能力评估与改进
1.过程能力评估
通过比较现有需求工程过程与过程参考模型之间的差别，可以评估现有过程的能力水平。具体而言，首先以调查表、面谈等方式收集组织中需求相关实践的执行情况；然后，与过程参考模型中的实践进行映射和比较，统计各能力等级下实践的执行情况；根据统计结果判定当前所处的能力等级。
需求工程过程参考模型，当“已执行级”的基础实践被全部规范执行时，需求工程过程达到“已执行”能力等级，否则，需求过程处在“不完整”能力等级；当执行了全部的“已管理级”实践时，需求工程过程达到“已管理”能力等级；当执行了全部的“已定义级”实践时，需求开发工程达到“已定义”能力等级。
2.过程改进策略
确定了组织需求过程所处的能力水平后，可以通过引入新实践或提高已有实践的性能，实现过程的改进。首先要明确过程改进的目标；然后分析组织的资源条件，确定过程改进的主要内容和手段。要遵循渐进的过程改进策略。一般来说，按照“由低到高”、“先规范后引入”的顺序逐提高过程能力，即先改进低能力等级的实践再改进高能力等级的，先规范已有实践再引入新实践，这样可以降低组织进行需求工程过程改进的风险。
需求工程的验证准则
需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源与错误的需求。因此，软件需求规格说明书完成以后，需要认真进行技术评审和修改。作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价，可按以下准则评价和验证。
1.正确性：正确性是最基本的要求之一，一般是指杂需求规格说明书中对于待开发系统的功能、行为、性能的描述必须与用户对目标软件产品的期望相吻合，正确性是相对与用户的应用需求而言的，由于具体应用的千差万别，需求规格说明书的正确性的判断标准也应各不相同。正确性检查属于技术问题，它并不能说明需求模型是否完全表达了用户需求。评价正确性时，可以按照建模规则去检查，或使用软件工具(如CASE)自动检查。当然，也可以请其他不参与该项目的同行校对，发现错误及时更正。
2.完整性：完整性是指需求模型中是否包含了用户所需的所有功能，这是最基本的要求，若不能满足，其它任何质量问题都无从谈起。因为需求分析的不完全，即使后面的设计与实现再好，也不能满足用户的要求。并且，在系统开发后期增加或更改用户需求，将会成倍地增加开发代价。因此，完整性评价是需求工程质量的关键。改进需求分析的完整性将有助于提高软件开发的生产率，但评价完全性问题却很难。因为用户有时不能完全表达其所有需求，开发者又没有预见，致使软件完成后才发现，维护代价相当大。为了及时发现问题，开发者最好跟班作业，对用户的业务进行深入地了解，从而对需求模型的完全性作出评价。具体评价方法可采用用户审阅、样例分析、业务规则验证、进程映像等方法。
3.实现性：实现性是指需求模型可以在规定的时间、经费预算和项目的技术约束下完成整个软件开发。这就要求我们在需求模型中不要出现这样或那样的假设，不要忽略各种实际因素，特别是技术和经费，以免到开发后期追悔莫及。评价可实现性主要应用下面两种方法:
（1）应用开发人员审阅。他们会重点审查系统实现的一些潜在问题，从技术和经济角度分析系统实现的可行性，发现问题可及早修改。
（2）开发代价估计。这是对需求模型的实现性进行定量测量的方法，通常质量越好代价越大，降低代价就要牺牲质量。只有权衡两者的关系，才能使系统的可实现性达到最佳。
总之，实现性是需求工程质量的最重要因素之一，实现可能性极小的需求模型，其它质量因素再好也无用。
4.适应性：适应性可以看作需求模型与用户的独立性，即当用户需求发生变化时，需求模型可以不做修改或只进行微小调整。
适应性是需求工程质量评价的最关键因素之一，但在实际系统开发中往往不被重视。很多需求分析人员就事论事，以完成系统的基本功能为目标，而忽略了其功能扩充或改变的可能性，这将会给系统维护造成困难。适应性评价要分析哪些需求将来可能改变、它们出现的可能性及其对需求模型的影响。由于系统未来可能发生的变化很难预测，所以适应性评价有一定困难。具体评价可采用如下方法:
（1）高层管理者评审。因为适应性评价涉及组织发展的战略目标，一般的业务工作人员无能为力，只有高层决策者才能把握企业未来的发展方向。
（2）行业专家评审。这些行业专家应该是业务咨询或学术专家，他们能更好地把握企业的发展方向，能够对潜在的市场变化及其可能性作出预测分析。
（3）技术专家评审。有经验的需求分析专家可以基于系统结构对系统的适应性作出评估，虽然他们并不一定熟悉企业的业务，但是可以从需求分析的技术角度评价系统的适应性。
5.集成性：在一个大的企业信息系统开发中，通常包括多个应用子系统，这些子系统之间的数据一致性问题显得格外重要。集成性就是指某个应用子系统与企业信息系统中其它应用系统之间的数据一致性，以减少应用系统之间的数据冲突。由于在某些项目开发中，各应用子系统的需求分析是相对独立的，这就不可避免地造成数据重复、系统之间接口复杂等问题。要防止出现类似情况，应尽可能地重复利用已有的数据资源或者进行适当的扩充，以适应新系统的要求。其次，对数据项的定义要保持命名和格式上的一致。
特别强调的是要用全局的观点看待数据，使需求模型具有通用性。
集成性的评价可采用如下几种方法:
（1）通过局部应用与全局应用模型的比较，发现数据冲突和结构冲突。
（2）将数据项向已有的数据源做映像，查看是否存在数据共享和重用的可能。
（3）让该应用系统以外的其它业务部门审阅，检查数据定义是否具有共性。
6.一致性：需求规格说明书的一致性要求：系统中不存在显式的或隐含的矛盾，也就是说，需求规格说明书中各个需求的描述必须不能相互矛盾，矛盾主要为：术语使用方面的冲突，功能冲突，以及时序方面的前后不一致等。一致性的评价可采用如下几种方法:
（1）同一意思要用相同的术语来表达。
（2）需求规格说明书中的各个部分的产品功能不得相互矛盾。
7.理解性：顾名思义，理解性是指需求模型的结构和描述易于理解。只有通俗易懂，才能更好地同用户交流。如果用户很难理解需求分析结果，他们就不可能检验需求模型是否完全准确地表达了他们的需求内容。另外，应用开发人员对需求模型的理解也至关重要，因为他们负责系统的设计与实现，不充分理解系统的需求，会使软件系统的实现结果同用户要求出现偏差，造成软件生产率下降。评价理解性常可采用以下方法:
（1）用户审阅。这是最常用的一种方法，检验需求模型的可理解性。但这种方法有一个缺点，用户可能只关心他们所熟悉的业务操作，而没有充分理解模型所表达的含义。
（2）样例分析。更有效的方法是让用户去使用这个模型，分析一个业务样例，来检验他们对模型的理解程度。
（3）应用开发人员审阅。虽然系统设计和编程人员不像需求分析人员那样熟悉用户的业务要求，但他们能有针对性地找出哪些地方描述得不清楚。同时，这一步也是应用开发人员认识需求模型的过程，有利于他们即将进行的设计工作，保证整个系统开发阶段的平稳过渡。