5.2 需求工程 ★★★★★
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
软件需求包括3个不同的层次：业务需求、用户需求和功能需求(也包括非功能需求)。
(1)业务需求 (business requirement) 反映了组织机构或客户对系统、产品高层次的目标要求。
(2)用户需求 (user requirement) 描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两种构成了用户原始需求文档的内容。
(3)功能需求 (functional requirement) 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。
需求工程的活动主要被划分为以下几个阶段。
(1)需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕 获和修订用户的需求。
(2)需求分析：为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
(3)形成需求规格(需求文档化):按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述规约作为后续软件系统开发的指南。
(4)需求确认与验证：以需求规格说明为输入，通过用户确认、复审会议、符号执行、模 拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性 和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
(5)需求管理：包括需求文档的追踪管理、变更控制、版本控制等管理性活动。
软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线 (Baseline)。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定 (Agreement)。
需求约定是需求开发和需求管理之间的桥梁。
5.2.1 需求获取 ★★★★☆
1.需求获取的基本步骤
1)开发高层的业务模型
对应用领域（系统的应用环境）构建业务模型，描述用户的业务过程，确定用户的初始需求
2)定义项目范围和高层需求
项目范围描述系统边界、系统与系统交互的参与者之间(包括组织、人、硬件设备、其他软件等)的关系。
高层需求不涉及过多的细节，主要表示系统需求的概貌。
常见的建模手段包括系统上下文图和系统顶层用例图等。
3)识别用户角色和用户代表
系统所涉及到的各类人员
4)获取具体的需求
具体、完整和 详细的需求
5)确定目标系统的业务工作流
6)需求整理与总结
2.需求获取方法 ★★★★☆
1)用户面谈
最为常见的需求获取方法，是理解用户需求的最有效方法。
面谈过程需要认真的计划和准备；面谈之后，需要复查笔记的准确性、完整性和可理解性；把所收集的信息转化为 适当的模型和文档；确定需要进一步澄清的问题。
2)需求专题讨论会
是需求获取的一种有力技术。在短暂而紧凑的时间段内将相关涉众集中 在一起集体讨论，与会者可以在应用需求上达成共识，对操作过程尽快取得统一的意见。参加会议的人员包括主持人、用户、技术人员、项目组人员。 专题讨论会具有以下优点。
(1)协助建立一支高效的团队，围绕项目成功的目标。
(2)所有的风险承担人都畅所欲言。
(3)促进风险承担人和开发团队之间达成共识。
(4)揭露和解决那些妨碍项目成功的行政问题。
(5)能够很快地产生初步的系统定义。
(6)可以有效地解决不同涉众之间的需求冲突。
3)问卷调查
问卷调查可用于确认假设和收集统计倾向数据。存在的问题是：相关问题不能事先决定，问题背后的假设对答案造成偏颇，难以探索一些新领域，难以继续用户的模糊响应。在完成最初的面谈和分析后，问卷调查可作为一项协作技术收到良好效果。
4)现场观察
通过观察用户实际执行业务的过程，来直观地了解业务的执行过程，全面了解需求细节。
5)原型化方法
在需求的早期，用户往往在具体的需求定义上存在很多不确定性，此时可以通过原型化方法，通过开发系统原型以及与用户的多次迭代反馈，解决在早期阶段需求不确定的问题，尤其是在人机界面等高度不确定的需求。
6)头脑风暴法
在一些新业务拓展的软件项目中，业务流程存在高度的不确定性，一群人围绕该业务，发散思维，不断产生新的观点， 参会者敞开思想使各种设想在相互碰撞中激起大脑的创造性风暴，从而确定具体的需求。
5.2.2 需求变更 ★★★★☆
1.变更控制过程
(1)问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析， 检查它的有效性，产生一个更明确的需求变更提议。
(2)变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评 估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设 计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
(3)变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型 执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的 需求分析、设计和实现等步骤；在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执 行过程中。
2.变更控制委员会(Change Control Board,CCB)
CCB是项目所有者权益代表，通常工作是通过评审手段来决定项目是否能变更，但不提出 变更方案。
过程及操作步骤
1)制定决策
2)交流情况
3)重新协商约定
5.2.3 需求追踪 ★★★☆☆
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。
需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式：
(1)正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
(2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说 明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟 踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。