需求工程，Requirement Engineering，RE，帮助软件工程师更好的理解他们将要解决的问题，其中所包含的一系统任务有助于理解软件如何影响业务，客户想要什么以及最终用户将如何和软件交互。
软件工程中摘取了一段有效需求实践的书籍的前言，大概情况是这样的：在项目后期，客户突然说，所做是并不是他想要的。
有这样一种现象：开发人员并不是很清楚的了解用户的需要，并不很透彻的理解客户的需求，就迫切的投入到编写工作。而且认为：
随着编写的过程的开展，事件就会变得清晰；
软件的早期版本发布上线后，项目的共利益者才能更好的理解需求；
需求工程是不必要的，是浪费时间；
只要开发一个可运行的程序即可，其它都是次要的。
需求工程在设计和构造之间建立起联系的桥梁。从软件过程角度来看，RE是一个软件工程动作，开始于沟通并持续到建模。虽然某些情况下，会选择一些简洁的方法，但必须严格执行全面的需求工程所定义的每项任务。
需求工程的任务
需求工程为以下工作提供了良好的机制（摘自百度百科的对机制一词的解析：一是事物各个部分的存在是机制存在的前提，因为事物有各个部分的存在，就有一个如何协调各个部分之间的关系问题。二是协调各个部分之间的关系一定是一种具体的运行方式；机制是以一定的运作方式把事物的各个部分联系起来，使它们协调运行而发挥作用的）：
理解客户需要什么；分析需求，评估可行性，协商合理方案；无歧义地详细说明方案；确认规格说明，管理需求以至将这些需求转化为可运行系统。需求工程过程通过执行7个不同的活动来完成，需求工程7活动：起始，导出，精化，协商，规格说明，确认，管理。
（1）起始
在项目起始阶段，软件工程师会询问一些好像与项目无直接关系的问题。目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步交流和合作的效果建立基本的了解。
通常在当确定了商业要求或发现了潜在的新市场、新服务时项目才开始。业务领域的共利益者定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。共利益者如业务管理人员，市场营销人员。
（2）导出
通过沟通询问客户、用户和其他人，系统或产品的目标是什么，要实现什么等来导出需求是很困难的。以下一系列问题说明导出需求为什么难：
范围问题：系统边界不清楚，或客户的说明带有多余的技术问题，这些细节可能会混淆系统的整体目标
理解问题：客户或用户不完全确定需要什么，由于客户或用户缺少软件开发或技术等多种因素的限制，对问题域没有完整认识，在与工程师沟通时存在问题。
易变问题：需求随时间变化。
（3）精化
精化阶段将对在起始和导出阶段所获得的信息进行扩展和提炼，开发一个精确的技术模型，用以说明软件的功能，特征和约束。精化的结果是形成一个分析模型，模型定义了问题的信息域，功能域和行为域。
（4）协商
需求矛盾的出现，需要通过协商来解决。例如：不同客户或用户提出了相互冲突的需求，且都坚持自己的需求是重要的；业务资源有限，但提出了过高的需求目标。这些必须通过协商来调解。确定优先级；识别和分析需求关联的风险；估算开发量，评估成本和交付时间；采用迭代方法，删除，组合或修改需求，使各方都能达到一定的满意。
（5）规格说明
规格说明：specification对不同的人有不同的含义。一个规格说明可以是一份写好的文档，一套图形化的模型，一个形式化的数学模型，一组使用场景，一个原型或以上各项的任意组合。规格说明是需求工程完成的最终工作产品，将作为软件工程师后续活动的基础，它描述了一个基于计算机系统的功能和性能，以及影响系统开的约束。
（6）确认
需求确认要检查规格说明以保证：所有系统需求已经被无歧义的说明；不一致性，疏漏，错误已经被检测出来并纠正；工作产品符合为过程、项目和产品建立的标准。需求确认对需求工程的工作产品进行质量评估。正式技术评审是最主要的需求确认机制。评审小组包括：软件工程师，客户，用户和其他共利益者。他们检查系统规格说明，查找内容或解释上的错误，以及一些可能需要进行一步解释澄清的地方，丢失的信息，不一致性情，冲突的需求或不现实的需求。
（7）需求管理
需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。需求变更从标识开始。需求被标识后，开始建立跟踪表。每个跟踪表将标识的需求与系统或其环境的一个或多个方面相关联。跟踪表很多种，例如：
特征跟踪表：显示需求与重要的、客户可见的系统/产品特征的关系
来源跟踪表：标识每个需求的来源
依赖跟踪表：需求之间如何相互关联的
子系统跟踪表：按需求所控制的子系统对需求分类
接口跟踪表：显示需求与内部和外部系统接口的关系
启动需求工程过程
（1）确定共利益者
共利益者定义：直接或间接从正在开发的系统中获益的人。容易理解的共利益者有：业务操作管理员，产品管理人员，市场营销人员，内部和外部客户，最终用户，顾问，产品工程师，软件工程师，支持和维护工程师及其他人员。
在开始阶段，需求工程师应该创建一个人员列表，列出有助于诱导出需求的人员。
（2）识别多种观点
因为存在很多不同的共利益者，所以系统需求调研也要从很多不同的视角开展。这些参与者中的每个人都会为需求工程贡献信息。因为多个角度收集的信息，所以形成的需求很可能存在不一致或相互矛盾。需求工程师的工作就是把这些信息分类，分类的方法应该是便于决策制定者为系统选择一个一致的需求集合。
（3）协同合作
（4）首次提问
项目起始阶段的提问应该是无环境无关的。
第一组与环境无关的问题集中于客户和其他共利益者、整体目标和收益，可能的问题：
谁是这项工作的最初提出者；谁将使用该解决方案；成功的解决方案将带来什么样的经济收益；存在别的解决方案吗。
这些问题有助于识别共利益者，还确认了某个成功的可度量收益以及定制软件开发的可选方案。
第二组问题有助于软件开发组更好的理解问题，并允许客户表达其对解决方案的看法，可能的问题是：
如何描述由某成功的解决方案产生的良好的输出；该解决方案强调了什么问题；能向我们展示解决方案的使用环境吗；存在影响解决方案的特殊性能或约束吗。
第三组问题关注于沟通活动本身的效率，即元问题，可能的问题是：
你是回答这些问题的合适人选吗？你的回答是正式的吗；我的提问和你想解决的问题相关吗；我的问题是否太多了；还有其他人员提供更多信息吗；还有我应该问的其他问题吗。
导出需求
（1）协同需求收集
共利益者和开发人员的团队共同完成：确认问题，为解决方案的要素提供建议，协商不同的方法及说明初步的解决方案需求集合。
协同需求收集方法原则：
软件工程师和客户共同举办和参与会议；制定筹备和参与会议规则；指定会议议程，既要正式，但也鼓励自由交流；主持人控制会议；使用定义机制；识别问题，提出解决方案的要素，协商不同的方法以在有利于完成目标的氛围中刻画初步解决方案的需求问题。
会议就是为收集需求。提出话题域列表，然后组合列表。完成意见一致的列表后，由子团队试图为每个列表中的一个或多个项目编写小规格说明。小规格说明是对包含在列表中的单词或短语的精炼。然后，小规格说明会提交到所有与会人员进行讨论，进行添加、删除和进一步细化工作。小规格说明完成后，与会人员提出针对产品/系统的确认标准列表并把它提交给团队，然后完成一个意见一致的标准列表。最后以会议结果为输入，撰写完整的规格说明草案。
（2）质量功能部署
质量功能部署，Quality Function Deployment,QFD，是一种将客户需求转化成软件技术需求的技术。QFD确认了三类需求：
正常需求：这些需求反映了和客户开会时确定的针对某产品或系统的目标。
期望需求：隐含在产品或系统中，可能是是因为非常基础以至于客户没有显示说明，但会导致客户明显不满。例如：操作友好性
令人兴奋的需求：反映了客户期望之外的特点的需求，如果实现后会令客户非常满意。
（3）用户场景
场景通常称为用例，提供了系统将如何被使用的描述。可以识别对将要构建的系统的使用线索。
（4）导出工作产品
根据将要构建的系统或产品的规模不同，需求导出后产生的工作产品也不同，但对大多数产品来说，工作产品包括：
必要性和可行性陈述；系统或产品范围的界限说明；参与需求导出的客户、用户和其他共利益者的列表；系统技术环境的说明；需求列表以及每个需求适用的领域限制；一系列使用场景；任何能更好定义需求的原型
所有参与需求导出人员需要评审这些工作产品。