中国移动需求分析培训
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
文档
客户需求
质量属性 非功能需求
用例文 档
其它非功能 需求
设计约束
软件需求
功能需求
SRS
业务需求
▪ 业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求，业 务需求就是系统目标。
▪ 背景描述：XX公司希望充分利用日益完善的移动通信 技术，在原有的办公系统的基础上进行扩展，使得在 外的业务人员能够及时地获得客户、业务相关的动态 信息，与此同时，实现企业内部的即时通信。
▪ 业务需求/目标 ：通过该系统的实施，将人工办理业务、 人工稽核两项业务效率提高10％以上，使企业内部沟 通效率大幅改善，以帮助企业运转效率得以提高。
客户需求
▪ 用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。
用户访谈
▪ 一般建议不超过1小时，否则应安排下一次面谈
▪ 时间安排： > 开场白：陈述理解 > 预先计划问题：主体工作 > 即兴问题：展开性 > 总结：陈述理解
需求分析培训
目录
.
需求概述
3.
需求开发活动
3.
业务功能需求模板
需求概述
需求问题的症状（1）
▪ 症状：在软件项目中，变更频繁，而且集中出现在项 目的中后阶段。
▪ 分析要点： > 变更是对原需求的背离，还是补遗(需求不完整)? > 背离发生在什么方面(流程间/流程内/数据使用…)？ > 这些变更是需求阶段是否可能预见的? > 是否存在无效的变更响应(管理有问题)?
> 性能与能力 > 操作环境 > 可靠性 > …… ▪
需求：导致项目失败的罪魁祸首
▪ 根据Standish Group对23000个项目进行的 研究结果表明，28%的项目彻底失败，46% 的项目超出经费预算或者超出工期，只有约 26%的项目获得成功。
▪ 而在于这些高达74%的不成功项目中，有约 60%的失败是源于需求问题。
测试性 ▪ 可移植性：适应性、易安装性、一致性、易替
换性
设计约束
▪ 也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。
▪ 例如：必须采用国有自主知识版权的数据库系 统…
▪ 再如：必须运行在UNIX操作系统之下 ▪ 再如：用户将在户外完成作业
优秀的需求
▪ 完整性：完整描述即将交付使用的功能 ▪ 正确性：经过用户的审阅 ▪ 无歧义：对所有读者只有一种一致的解释 ▪ 必要性：每项需求记录的功能都应是用户真正
的需求捕获技术（宽带通信、固有灵活性、各类信息） ▪ 弊：占用时间长（特别当客户忙时更显示出其不足）、
面窄而容易造成信息的片面性。 ▪ 要点：首先要有准备：通常包括说明对流程的理解，
并征得客户的意见；预先根据流程中的不明确点设计 要询问的问题，并将客户的反馈记录下来；应留有一 些即兴的空间，根据实际情况应变，以确保信息完善。 第二是要有计划性：计划好时间、计划好人员、计划 好策略。
项目成功的因素
▪ 用户的参与：15.9% ▪ 管理层支持：13.9% ▪ 清晰的需求描述(13.0%)； ▪ 合适的规划(9.6%)； ▪ 现实的客户期望(8.2%)； ▪ 较小的里程碑(7.7%)； ▪ 有才能的员工(7.2%)
软件需求曾经让我们如此狼狈
-
需求是什么？
业务需求
项目Байду номын сангаас 图/范围
▪ 有时还需要考虑相关联的硬件、环境方面的需 求
功能需求
▪ 功能需求是需求的主体，是需求的本质 ▪ 功能需求定义了：系统必须完成的那些事，即
为了向它的用户提供有用的功能，产品必须执 行的动作
▪ 零散（需求项）整理（特性、用例）
非功能性需求
▪ 可靠性：成熟性、容错性、易恢复性 ▪ 易使用性：易理解性、易学习性、易操作性 ▪ 效率：时间特性、资源特性 ▪ 可维护性：易分析性、易更改性、稳定性、易
> 二次开发量最要集中于什么方面(业务规则/ 用户界面/流程顺序/流程细节/报表格式)? ▪ 改进方向： > 工作流模型顺序/细节 > 弹性设计业务规则/UI > 报表格式理解数据模型
需求问题的症状（5）
▪ 症状：产品/项目完全不可用或崩溃。 ▪ 分析要点：
> 忽略了哪方面非功能需求? ▪ 改进方向：
▪ 改进方向： > 变更的可预测性需求阶段标识(需求捕获/分析) > 变更渠道单一化、统一化(需求管理)
需求问题的症状（2）
▪ 症状：软件项目上线运行时遇到很多阻力。 ▪ 分析要点：
> 是否为组织因素? > 阻力源于操作层还是管理层? ▪ 改进方向： > 清晰的业务需求导向 (需求定义) > 面向不同层面的需求分析 > 正确识别组织因素(需求捕获)
▪ 也就是说，有近45%的项目最终因为需求的问 题最终导致失败。
我们在哪里会摔跤
▪ 在Standish Group的报告中总结了导致项目 失败的最重要的8大原因中，有5个与需求相关：
▪ 不完整的需求(13.1%)； ▪ 缺乏用户的介入(12.4%)； ▪ 不实际的客户期望(9.9%)； ▪ 需求和规范的变更(8.7%)； ▪ 提供了不再需要的(7.5%)
▪ 用户有不同类型： > 管理型、事务型 > 决策层、使用层
> 信息系统、人 > 常用者、偶用者
▪ 组织方法：用例、用户故事、特性
▪ 例子：对快到期的客户，系统将通过短信 将业务信息发给客户
软件需求
▪ 从系统实现的角度描述的需求。 ▪ 开发人员（设计及分析人员）在业务需求、用
户需求的基础上生成的。
需要的 ▪ 有优先次序：提供了实现优先级 ▪ 可行性：在已知能力和约束条件中实现 ▪ 可验证性：可以设计测试方法来检查
需求开发活动
需求开发活动
需求获取的常用技术
▪ 阅读背景资料 ▪ 讨论分析 ▪ 文档考古 ▪ 面谈（用户访谈） ▪ 用户调查 ▪ 现场观摩
用户访谈
▪ 用户访谈是最基本、最常见的技术 ▪ 利：直接有效、形式灵活、交流深入，应该做为主要
需求问题的症状（3）
▪ 症状：软件项目上线运行后效果很差。 ▪ 分析要点：
> 为什么不使用(用户界面/功能/手工系统)? > 使用者的成本/效益分析? ▪ 改进方向： > 抓准业务需求(需求定义) > 不同层面用户的分析(需求捕获/分析)
需求问题的症状（4）
▪ 症状：产品二次开发量大。 ▪ 分析要点：
客户需求
质量属性 非功能需求
用例文 档
其它非功能 需求
设计约束
软件需求
功能需求
SRS
业务需求
▪ 业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求，业 务需求就是系统目标。
▪ 背景描述：XX公司希望充分利用日益完善的移动通信 技术，在原有的办公系统的基础上进行扩展，使得在 外的业务人员能够及时地获得客户、业务相关的动态 信息，与此同时，实现企业内部的即时通信。
▪ 业务需求/目标 ：通过该系统的实施，将人工办理业务、 人工稽核两项业务效率提高10％以上，使企业内部沟 通效率大幅改善，以帮助企业运转效率得以提高。
客户需求
▪ 用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。
用户访谈
▪ 一般建议不超过1小时，否则应安排下一次面谈
▪ 时间安排： > 开场白：陈述理解 > 预先计划问题：主体工作 > 即兴问题：展开性 > 总结：陈述理解
需求分析培训
目录
.
需求概述
3.
需求开发活动
3.
业务功能需求模板
需求概述
需求问题的症状（1）
▪ 症状：在软件项目中，变更频繁，而且集中出现在项 目的中后阶段。
▪ 分析要点： > 变更是对原需求的背离，还是补遗(需求不完整)? > 背离发生在什么方面(流程间/流程内/数据使用…)？ > 这些变更是需求阶段是否可能预见的? > 是否存在无效的变更响应(管理有问题)?
> 性能与能力 > 操作环境 > 可靠性 > …… ▪
需求：导致项目失败的罪魁祸首
▪ 根据Standish Group对23000个项目进行的 研究结果表明，28%的项目彻底失败，46% 的项目超出经费预算或者超出工期，只有约 26%的项目获得成功。
▪ 而在于这些高达74%的不成功项目中，有约 60%的失败是源于需求问题。
测试性 ▪ 可移植性：适应性、易安装性、一致性、易替
换性
设计约束
▪ 也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。
▪ 例如：必须采用国有自主知识版权的数据库系 统…
▪ 再如：必须运行在UNIX操作系统之下 ▪ 再如：用户将在户外完成作业
优秀的需求
▪ 完整性：完整描述即将交付使用的功能 ▪ 正确性：经过用户的审阅 ▪ 无歧义：对所有读者只有一种一致的解释 ▪ 必要性：每项需求记录的功能都应是用户真正
的需求捕获技术（宽带通信、固有灵活性、各类信息） ▪ 弊：占用时间长（特别当客户忙时更显示出其不足）、
面窄而容易造成信息的片面性。 ▪ 要点：首先要有准备：通常包括说明对流程的理解，
并征得客户的意见；预先根据流程中的不明确点设计 要询问的问题，并将客户的反馈记录下来；应留有一 些即兴的空间，根据实际情况应变，以确保信息完善。 第二是要有计划性：计划好时间、计划好人员、计划 好策略。
项目成功的因素
▪ 用户的参与：15.9% ▪ 管理层支持：13.9% ▪ 清晰的需求描述(13.0%)； ▪ 合适的规划(9.6%)； ▪ 现实的客户期望(8.2%)； ▪ 较小的里程碑(7.7%)； ▪ 有才能的员工(7.2%)
软件需求曾经让我们如此狼狈
-
需求是什么？
业务需求
项目Байду номын сангаас 图/范围
▪ 有时还需要考虑相关联的硬件、环境方面的需 求
功能需求
▪ 功能需求是需求的主体，是需求的本质 ▪ 功能需求定义了：系统必须完成的那些事，即
为了向它的用户提供有用的功能，产品必须执 行的动作
▪ 零散（需求项）整理（特性、用例）
非功能性需求
▪ 可靠性：成熟性、容错性、易恢复性 ▪ 易使用性：易理解性、易学习性、易操作性 ▪ 效率：时间特性、资源特性 ▪ 可维护性：易分析性、易更改性、稳定性、易
> 二次开发量最要集中于什么方面(业务规则/ 用户界面/流程顺序/流程细节/报表格式)? ▪ 改进方向： > 工作流模型顺序/细节 > 弹性设计业务规则/UI > 报表格式理解数据模型
需求问题的症状（5）
▪ 症状：产品/项目完全不可用或崩溃。 ▪ 分析要点：
> 忽略了哪方面非功能需求? ▪ 改进方向：
▪ 改进方向： > 变更的可预测性需求阶段标识(需求捕获/分析) > 变更渠道单一化、统一化(需求管理)
需求问题的症状（2）
▪ 症状：软件项目上线运行时遇到很多阻力。 ▪ 分析要点：
> 是否为组织因素? > 阻力源于操作层还是管理层? ▪ 改进方向： > 清晰的业务需求导向 (需求定义) > 面向不同层面的需求分析 > 正确识别组织因素(需求捕获)
▪ 也就是说，有近45%的项目最终因为需求的问 题最终导致失败。
我们在哪里会摔跤
▪ 在Standish Group的报告中总结了导致项目 失败的最重要的8大原因中，有5个与需求相关：
▪ 不完整的需求(13.1%)； ▪ 缺乏用户的介入(12.4%)； ▪ 不实际的客户期望(9.9%)； ▪ 需求和规范的变更(8.7%)； ▪ 提供了不再需要的(7.5%)
▪ 用户有不同类型： > 管理型、事务型 > 决策层、使用层
> 信息系统、人 > 常用者、偶用者
▪ 组织方法：用例、用户故事、特性
▪ 例子：对快到期的客户，系统将通过短信 将业务信息发给客户
软件需求
▪ 从系统实现的角度描述的需求。 ▪ 开发人员（设计及分析人员）在业务需求、用
户需求的基础上生成的。
需要的 ▪ 有优先次序：提供了实现优先级 ▪ 可行性：在已知能力和约束条件中实现 ▪ 可验证性：可以设计测试方法来检查
需求开发活动
需求开发活动
需求获取的常用技术
▪ 阅读背景资料 ▪ 讨论分析 ▪ 文档考古 ▪ 面谈（用户访谈） ▪ 用户调查 ▪ 现场观摩
用户访谈
▪ 用户访谈是最基本、最常见的技术 ▪ 利：直接有效、形式灵活、交流深入，应该做为主要
需求问题的症状（3）
▪ 症状：软件项目上线运行后效果很差。 ▪ 分析要点：
> 为什么不使用(用户界面/功能/手工系统)? > 使用者的成本/效益分析? ▪ 改进方向： > 抓准业务需求(需求定义) > 不同层面用户的分析(需求捕获/分析)
需求问题的症状（4）
▪ 症状：产品二次开发量大。 ▪ 分析要点：