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

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

一、需求分析相关概念

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、涵盖需求之间的冲突分析—保持需求一致性

扫描二维码关注公众号,回复: 11608106 查看本文章
3、需求管理

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

3.1 需求管理内容

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

猜你喜欢

转载自blog.csdn.net/runafterhit/article/details/106562581