需求工程是一门学科，它使用成熟的技术和方法来分析需求，确定客户需求，帮助分析师理解问题并定义目标系统的所有外部特征。它通过适当的工具和标记，系统地描述要开发的系统、其行为特征和相关约束，形成需求文档，支持不断变化的需求演化。
随着计算机的发展，需求工程发展起来。在计算机开发的早期阶段，软件规模较小，软件开发侧重于代码编写，很少关注需求分析。后来，生命周期的概念被引入到软件开发中，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析和定义在软件开发和维护的整个过程中变得越来越重要，直接关系到软件的成败。人们逐渐意识到需求分析活动不再局限于软件开发的初始阶段，而是贯穿于系统开发的整个生命周期。
需求工程包括需求开发和需求管理(包括变更管理)，如下图：所示
需求工程是软件工程中最复杂的过程之一，其复杂性来自客观和主观两个方面。客观地说，需求工程面临的问题几乎是无限的。由于应用领域广泛，其实施无疑与各应用行业的特点密切相关。它的客观困难也反映在非功能性需求及其与功能性的关系上
由于需求之间复杂的联系，非功能性需求分析和建模技术的缺乏大大增加了需求工程的复杂性。从主观上讲，需求工程需要来自各个方面的人(如领域专家、领域用户、系统投资人、系统分析师、需求分析师等)的参与。).各方面的人起点不同，知识背景不同，沟通困难给需求工程的实施增加了人为的困难。
需求定义
需求定义是一个迭代的过程。传统的软件开发方法假设可以一次获得完全正确的需求。长期的开发实践证明，这个假设过于干瘪和理想化，在实际工作中不成立。现代软件开发实践表明，很难一次得到完全正确的需求。项目开发总是伴随着不完整的需求，关键在于如何有效降低需求不确定性的风险。
一个有效的方法是反复开发和验证需求。典型过程如下图所示
需求的监督和调节
由于需求必须被正在构建的系统所遵守和遵从，而需求是否被满足决定了项目的成败，因此找出需求是什么，记录它们，组织它们，并在发现变化时进行跟踪是非常有意义的。这个过程就是需求管理。
简单的说，需求管理是
获取、组织和记录系统需求：的系统方法是使客户和项目团队达到并保持与不断变化的系统需求一致的过程。需求管理模型
需求分为不同的层次和类型，如下图需求金字塔所示。可以在不同级别的需求和同一级别的需求之间建立跟踪关系：
为了建立一个真正满足客户需求的系统，需要确定系统能够解决的问题。然后，我们必须确定利益相关者，获取业务和用户需求，描述它们并确定它们的优先级。从高层次的期望或需求出发，就产品或系统功能集达成一致。然后，从产品特征中提取软件需求。在需求管理模型中，软件需求以用例模型的方式描述。从测试的角度来看，第一个测试项来自于软件需求，即软件需求中确定了哪些需求，测试就应该按照这些需求来制定和实施。
通常，一种需求可以分解成其他类型的需求，需求的分类可以使
需求定义和管理
%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。需求工程最佳实践
需求工程最佳实践对于保证需求的质量具有重大意义:
- 明确定义需求工程过程
多数软件项目都是基于团队协作的，为了保证团队所有需求相关人员能够步调一致地进行合作.必须为他们提供统一的工作流程和方法，以便相互之间能够顺利地进行沟通与协作.确保在统一的流程和方法指导下进行协同的需求开发和管理
- 业务建模-保证完全理解客户或者行业业务过程
业务建模架起现实世界与计算机系统之间的桥梁，有效的业务建模可以为需求的正确性、无二义性、易于理解等质量维度提供保证。
通过业务建模手段来描述组织的组织架构,描述当前的业务过程找出当前存在的问题并确定改进的可能性。而改进通常都是通过自动化现行业务过程中的若干环节,来优化用户的业务过程.提高业务效率和/或业务质量,以期带来更多的商业价值。
- 用例建模--站在用户的立场上来描述需求
用例建模是被业界广泛接受的需求开发与描述方法,有效的用例建模可以为需求的全部质量维度(正确性、完备性、一致性、无二义性易于理解)提供保证。验证的方式描述目标系统的预期行为，描述系统如何与最终用户以及/或其他系统进行交互。与简单的需求列表方法不同，用例按照叙事的方式讲述用户可能怎样使用系统。因此，用例易于被业务部门理解.可以清晰定义目标系统的边界。用例模型在系统功能与功能的最终用户之间建立了明确的关联.便于用户业务部门安排合适的需求评审人员对其相关需求进行评审、既可以提高需求评审的效率又可以保证需求的正确性。
用例主要描述系统的功能性需求，系统的非功能性需求则通过需求补充规约进行描述。
用例模型的主要元素包括用例图和用例规约。用例图以图形的方式描述主角(Actor.即系统外部与系统交互的用户或其他系统)和用例的关系。可以从不同的角度建立多个用例图来帮助直观理解系统的功能需求。用例规约则以叙事的方式讲述用户可能怎样使用系统
下图是ATM用户取款的用例模型示例：
用例是衔接用户业务与开发团队的纽带，用例同时也是项目开发计划、测试案例以及系统文档撰写的基础，因此在项目中扮演举足轻重的作用。
- 采用统一的需求描述手段
采用统一的需求描述手段可以增强需求的可理解性和一致性，便于对需求内容进行审核，保证需求的正确性。
统一的需求描述手段包括项目前景文档，用例图，用例规约.补充规约等,并建立规范的需求文档模板，采用集中手段管理需求(如借助需求管理工具将全部需求信息存于关系数据库中)。
- 综合运用多种需求定义技术
辅助的需求开发技术有:用户界面原型和需求研讨会。
通过用户界面原型可以及早收集业务部门的反馈,验证对需求理解的正确性，及早发现并纠正问题，有效降低纠正需求理解错误的代价。
需求研讨会在项目的早期是非常有效的需求开发手段。用户方面的与会者包括管理者、项目经理、业务部门代表等;项目开发团队方面的与会者包括项目经理、业务分析员、架构师,开发人员代表等。通过需求研讨会可以集思广益,协助开发团队理解用户的业务过程收集用户的业务需求,及早纠正对需求的错误理解，把握需求的优先级等。
- 分类并且量化管理需求
系统越大越复杂出现的需求类型就越多。需求类型对需求进行分类,通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。不同类型的需求之间要建立起追踪关系，以便方便的进行追逐和影响分析。
为了对需求进行进一步的管理。我们还可以通过对需求的深入分析，给每条需求添加必要的属性，如优先级、来源、稳定性、成本、难易程度、风险等等.实现需求的量化管理。通过对需求进行量化管理，有助于加深对需求的理解.方便对需求进行查询和排序。
- 管理不同类型需求之间的追踪关系
用户的业务需求逐步会转化为目标系统的软件需求，但业务需求与软件需求之间并非简单的一对一的关系，相反往往是一个多对多的复杂关系，即某个业务需求可能与多个软件需求相关，反过来，某个软件需求可能也与多个业务需求关联。有效管理业务需求和软件需求之间的追踪关系可以确保所有的业务需求都被软件需求覆盖了.从而保证了需求的完备性。
管理业务需求和软件需求之间的追踪关系还可以帮助开发人员了解需求的来源.帮助项目经理管理项目的规模.评估需求变更对项目的影响.管理需求的变更.评估测试失败对需求的影响等。
可以借助需求管理工具来自动化管理业务需求和软件需求之间的追踪关系。
我有一套简易的需求管理工具，可共享给你。
