Appearance
软件需求
软件需求目前并没有统一的定义，但都包含以下几方面的内容。
- (1)用户解决问题或达到目标所需条件或权能。
- (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
- (3)一种反映上面（1)或（2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求、质量标准或者设计限制。
软件需求包括3个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。
- 业务需求：反映了组织机构或客户对系统、产品高层次的目标要求。
- 用户需求：描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两种构成了用户原始需求文档的内容。
- 功能需求：规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。所谓特性是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
作为补充，软件需求规格说明，它描述了。它包括。所谓约束是指对开发人员在软件产品设计和构造上的限制，常见的有设计约束和过程约束。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。
需求工程是指应用己证实有效的原理、方法，通过合适的工具和记号，。需求工程覆盖了体系结构设计之前的各项开发活动，主要包括。需求工程的目标简单明了：。
- 需求工程的活动：。
- 软件需求开发的最终文档经过评审批准后，则。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定。。
- 需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理规划，。需求管理的主要活动如图所示。
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明
分为需求开发和需求管理两大过程，如下所示：
软件需求分类
软件需求是描述用户对软件系统期望的一系列条件或能力。层次：业务需求 > 用户需求 > 功能需求。
| 类别 | 说明 | 提出方 |
|---|---|---|
| 业务需求 | 企业/客户对系统高层次目标要求，确定项目视图和范围 | 投资人、客户、市场部门 |
| 用户需求 | 用户的具体目标，描述用户使用系统的场景 | 用户访谈、问卷调查 |
| 系统需求 | 从系统角度详细说明，含功能需求、非功能需求、设计约束 | 需求分析人员 |
系统需求细分：
| 类型 | 说明 |
|---|---|
| 功能需求（行为需求） | 规定开发人员必须实现的软件功能 |
| 非功能需求 | 系统必须具备的属性或品质（可维护性、可靠性、效率等） |
| 设计约束（限制条件） | 对系统的约束说明（特定技术、框架、数据库、操作系统等） |
需求定义
产物：软件需求规格说明书（SRS），是项目干系人共识文档，设计/实现/测试的依据。
两种定义方法：
| 方法 | 假设 | 特点 |
|---|---|---|
| 严格定义（预先定义） | 所有需求都能预先定义 | 图形或文字完整描述最终系统 |
| 原型方法 | 并非所有需求都能预先准确说明 | 迭代循环开发，逐步纳入需求，直到需求确定后遵循严格方法 |
需求验证
目的：确保需求准确无误，与用户实际期望一致。
步骤：
- 需求评审：正式评审（会议）或非正式评审（日常交流）
- 需求测试：设计测试用例验证需求可实现的正确性
关键概念：
- 需求验证通过 → 用户签字确认 → SRS 成为需求基线
- 需求基线是稳定参考点，之后任何更改需通过正式的需求变更流程
需求获取
需求获取是确定和理解项目干系人需求和约束的过程。
需求获取参考步骤：
- 1 )：建立一个业务模型，描述用户的业务过程，确定用户的初始需求。
- 2)：项目范围描述系统的边界以及系统与系统交互的参与者之间的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。
- 3)。用户角色可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这些系统或硬件的人员作为用户代表。
- 4)。获取每个涉众的具体、完整和详细的需求。
- 5)。具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。
- 6)。最后对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。
常见的需求获取方法：
- （1)：1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。面谈过程需要认真的计划和准备；面谈之后，需要复查笔记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进一步澄清的问题。
- (2)：将相关涉众集中在一起集体讨论，与会者可以在应用需求上达成共识，对操作过程尽快取得统一的意见。参加会议的人员包括主持人、用户、技术人员、项目组人员。
- (3)：用户多，无法一一访谈。可用于确认假设和收集统计倾向数据。
- (4)：主要是通过观察用户实际执行业务的过程，来直观地了解业务的执行过程，全面了解需求细节。执行业务可能是手工操作，也可能是在原有的业务系统上执行。
- (5)：在需求的早期，用户往往在具体的需求定义上存在很多不确定性。此时往往可以通过，解决在早期阶段需求不确定的问题，尤其是在人机界面等高度不确定的需求。
- (6)：在一些新业务拓展的软件项目中，由于业务是新出现的，而且业务流程存在高度的不确定性，例如互联网上的新业务系统、App等，一群人围绕该业务，发散思维，不断产生新的观点，参会者敞开思想使各种设想在相互碰撞中激起大脑的创造性风暴，从而确定具体的需求。
需求变更和需求追踪 ⭐️
为了使开发组织能够严格控制软件项目，应该确保以下事项：
- 仔细评估已建议的变更
- 挑选合适的人选对变更做出判定。
- 变更应及时通知所有相关人员。
- 项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。
变更控制过程如图所示：
- (1)。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
- (2)。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
- (3)。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。
定义需求基线
CCB 变更控制委员会
- ，负责裁定接受哪些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，。
- 变更控制委员会应该有一个总则，用于描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤。过程及操作步骤为：
- 需求跟踪提供了由。需求跟踪的目的是建立与维护 “需求一设计一编程一测试”之间的一致性，
需求跟踪有两种方式：
- (1)正向跟踪。检查《产品需求规格说明书》中的每个需求：
- (2)逆向跟踪。检查设计文档、代码、测试用例等工作成果。
正向跟踪和逆向跟踪合称为“”。不论采用何种跟踪方式，都要建立与。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
需求变更和风险
CCB（变更控制委员会）：对项目中任何基线工作产品的变更都可以做出决定。
需求变更管理流程：问题分析和变更描述 → 变更分析和成本计算 → 变更实现。
需求的稳定性属于需求属性之一。CMM 可重复级有 6 个关键过程区域（非 3 个）。
需求管理补充
- 好的需求陈述：完整、准确描述功能；能够在约束内实现；是用户真正需要的
- ⚠️ 不是所有需求都同等重要— 需求必须区分优先级
- 需求取（elicitation）是迭代过程：需求发现→分类组织→协商→文档化
- 需求专题讨论会的优势：有效解决不同涉众之间的需求冲突
需求跟踪
🎯 一句话结论：正向跟踪=需求→下游工作产品；逆向跟踪=下游→回溯需求；需求跟踪矩阵可追溯从源头到实现的一致性。
| 跟踪方式 | 方向 | 用途 |
|---|---|---|
| 正向跟踪 | SRS 需求→后续设计/代码/测试用例 | 检查每个需求是否都实现了 |
| 逆向跟踪 | 后续工作产品→回溯到需求 | 检查每个实现是否有需求依据 |
⚠️ 常见坑：「重构跟踪」不属于需求跟踪方式。
需求状态跟踪是需求管理活动之一。需求管理员活动包括：变更控制、版本控制、需求跟踪、需求状态跟踪（不包括文档管理）。