简图记录-需求分析 基础概念总结

简图记录总结，关于需求分析 基础概念总结

一、需求分析相关概念

1、需求

1）用户解决某个问题或者达到某个目标所需的条件和能力。2）一个系统或组件为了实现某个契约、标准、规格说明 或者 其他要遵循的文件 二必须满足的条件或具备的能力。 3）以上两条件或者能力文档化表示。

1.1 需求分类

功能性需求：比如 特性的 输入/输出 描述，异常行为描述 等；
质量需求： （客户角度）性能，可靠性，易用性等；（开发角度）可维护性，可移植性，可复用性，可测试性；
约束：符合XXX规范，符合XXX标准要求，兼容XXX平台，兼容XXX版本接口。

1.2 需求难以收敛的原因

客户（经验不足） 不知道 自己真正需要什么，无法提出正确的需求。
客户 知道 自己需要什么，（表达能力不足）无法清晰表达需求。
客户 准确的表达 了 自己的需求，但是 需求分析者（相关知识/经验不完备，信息识别偏差） 误解了客户的需求。
需求分析者 正确理解了客户表述，但是 遗漏了 隐含意义/条件，优先级 或者 关键细节。
即使以上都没问题，市场总会变化，需求也会变化。

2、需求分析

准确理解用户的要求，进行调查分析，将用户非形式化的需求陈述 转化为 完整的需求定义，再转化到相应需求规格说明的过程。
需求分析是一个迭代细化的过程，首先要理解客户的视角（组织结构）和诉求（业务知识/流程/使用场景/产品目标），通过一些分析或者调查 引导 客户 逐步 澄清/细化/纠偏 需求。

2.1 需求分析常见问题

（1）客户理解不够，需求调查不够细致全面 ，没有站在客户的视角理解 客户的组织结构（不能混乱的胡子眉毛一把抓 混乱的做需求调查），客户也有各类部门组织关注点不同，弄清决策者是谁（每个领域要分开调研，集中在领域专家意见 配合 部分操作者拓展调查），不同层级关注点也不同（上层 领导 更关注 方向规划，中层管理 更关注 特性价值/收益，底层执行 更关注 协作复杂度，计划匹配执行情况），没有理解 客户产品相关 业务知识/业务流程/使用场景/目标/问题，原始需求应该是站在客户角度出发。
（2）客户关系处理问题，过于迎合或者抵制客户，维护好客户关系非常重要，但是 过于低姿态 会 丧失引导权，造成客户什么需求都提，导致 伪需求落地/需求反复/低价值的需求打乱项目计划，建议更多的要塑造专家形象，要通过理性的分析 引导 客户 逐步 澄清/细化/纠偏 需求，建立良好的合作关系。
（3）输入混乱，没有聚焦客户价值，客户关注的特性需求，bug fix，内部规格特性增强 混为一谈，抓不住重点。
（4）细节缺失，表述不清晰不具体，如用词 “一般情况” ，“某些异常下”，“适当条件下”，没法很好的支持 设计/开发/测试 的 分析。
（5）分析遗漏，或者 需求之间存在冲突，导致业务开发特性场景缺失，或者 遗漏，引发返工。

2.2 需求分析分解流程

（1）整体需求分解活动流程
愿景方向–（按 场景/质量/功能 维度划分专题做产品定位，通过 市场分析/竞争分析/技术趋势 分析，确定每个专题的设计目标）–产品目标–（按场景进行目标分解，配合竞品分析，用户痛点，技术可行性分析，工作量评估 明确产品特性）–产品特性–（以场景分析入手，进行系统需求指定，要考虑质量需求 和 约束需求）–系统需求–（对场景进行概念建模，明确 模块职责/模块交互流/模块间数据流）–模块需求：
（2）单个需求分析落地流程
需求收集-需求方案设计（需求间冲突决策）-系统设计方案确认（系统设计审核）-系统方案分解/模块设计方案确认（模块设计分解审核）-需求实现（模块特性开发）-需求验证（测试验收）

2.3 需求分析的方法

（不展开，当前理解还不够深刻，后续总结）
原型机：针对 从未存在 或者 实现难度大的需求，通过 快速demo实现一部分，在真实的系统中开发验证
场景建模（如UML）：针对 相对技术可行性 难度不高的 需求，通过 如UML建模 等 进行场景的分解分析，如 usecase等。

2.4 需求分析质量标准

完整性：覆盖了完整的场景，考虑了 性能/可靠性/可维护性 等 质量因素 和 约束（满足涉及的设计规范）。
正确性：用户/客户/研发团队 维护 确认了需求的正确性，实时更新保持最新可用的状态
可验证性： 相关人员能对系统是否满足要求进行验证。
一致性：需求之间没有矛盾冲突，需求可以追踪来源。

2.5 需求设计描述注意事项

1、不涉及实现方案—黑盒方式描述。
2、有量化指标或者可观察表现—需求可测试。
3、用词准确恰当，完整刻画业务过程 —表述清晰完整。
4、涵盖需求之间的冲突分析—保持需求一致性

3、需求管理

一种获取、组织 并 记录 需求的 系统化方案，使客户与项目团队 对 不断变更的需求 达成和保持一致的过程。

3.1 需求管理内容

变更控制：变更需求 必须经过 正式的评估（影响/价值/可行性/优先级）和批准，然后 与项目计划同步匹配，融入项目开发流程。
版本控制：项目团队 和 客户 对 功能特性 基线 达成一致。非 几个版本交付，包含哪些特性，版本时间点等。
需求跟踪：每个需求 都要 与 设计文档/源码/测试用例 关联起来。
状态跟踪：需求的实现状态 和 变更情况。