需求工程
1、需求工程概念
软件需求可分为三个层次：业务需求、用户需求和功能需求（含非功能需求）。
- 业务需求反映了组织或客户对系统的高层次需要；
- 用户需求详细描述了用户使用产品必须要完成的任务；
- 功能需求则定义了开发人员必须实现的软件功能，确保软件满足用户的需要。非功能需求则关注软件系统的质量和性能等方面。
需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。需求工程覆盖了体系结构设计之前的各项开发活动，主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明。需求工程的目标简单明了：确定客户需求，定义设想中系统的所有外部特征。
需求工程的活动主要包括五个阶段：需求获取、需求分析、形成需求规格、需求确认与验证以及需求管理。
- 需求获取阶段通过与用户交流、观察现有系统和任务分析来捕获和修订用户需求。
- 需求分析阶段为系统建立概念模型，抽象描述需求并捕获现实世界的语义。
- 形成需求规格阶段则按照相关标准生成需求模型的文档描述，包括用户原始需求书和软件需求描述规约，作为用户和开发者之间的协约和后续开发的指南。
- 需求确认与验证阶段通过用户确认、复审会议、符号执行等方法验证需求规格的完整性、正确性、一致性等。
- 需求管理阶段则强调对需求基线的变动控制、项目计划与需求的一致性保持、需求版本的控制、需求联系链的管理以及需求状态的跟踪。需求分析的方法多种多样，后续将结合具体开发方法进行深入讨论。
2、需求获取
- 需求获取基本步骤包括：开发高层的业务模型、定义项目范围和高层需求、识别用户角色和用户代表、获取具体的需求、确定目标系统的业务工作流、需求整理与总结。
- 需求获取，方法针对不同类型的软件项目，需要采用不同的需求获取方法。常见的需求获取方法有用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法、头脑风暴法。
3、需求变更
变更控制过程
变更控制过程用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。
- 问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
- 变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评 估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
- 变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型 执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新做对应的需求分析、设计和实现等步骤；在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执 行过程中。
变更控制委员会
变更控制委员会 (Change Control Board,CCB) 是项目所有者权益代表，负责裁定接受哪些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
4、需求追踪
需求跟踪主要有两种方式：正向跟踪和逆向跟踪。正向跟踪是检查产品需求规格说明书中的每个需求是否在后继的工作成果中有对应点；而逆向跟踪则是检查设计文档、代码、测试用例等工作成果是否都能在需求规格说明书中找到来源。这两种方式共同构成了双向跟踪，旨在确保“需求-设计-编程-测试”之间的一致性。
