|
第2部分 需求开发 |
||||||||||||||||||||||||
|
第4章 需求定义最佳实践 |
||||||||||||||||||||||||
|
4.1 需求定义任务概述 |
||||||||||||||||||||||||
|
4.1.1 需求定义的时机 |
||||||||||||||||||||||||
|
4.1.2 需求定义的理念与策略 |
1 破解混沌不清的项目目标 解决方案： 1、内部寻根；和项目发起人沟通 2、外部溯源； 2 需求定义的理念 关键：问题和机会 步骤： 目标→问题→可选方案→建议方案 目标：通过内、外部寻根方法将项目要解决的问题罗列出来 问题；针对目标层面的问题进行分析，找到导致该问题产生的根源 可选方案：针对每个问题罗列出可能解决的方案 建议方案：挑选出比较合理的方案 |
|||||||||||||||||||||||
|
4.2 问题分析的五步法 |
||||||||||||||||||||||||
|
4.2.1 在问题定义上达成共识 |
问题定义模板
|
|||||||||||||||||||||||
|
问题定义的技巧 1、转换（如棋盘中象棋的移动是一个迭代的过程，同样也可以转换为一个联通图遍历问题） 2、本源 |
||||||||||||||||||||||||
|
4.2.2 分析问题背后的问题 |
也就是寻找问题的本源 有以下两种工具： 1、鱼骨图 优点： 使分析人员将问题的原因而不是症状放在首位 提供一种运用智慧解决问题的新方法 直观、简明、易操作 绘制步骤： 1》选择问题 2》头脑风暴 3》确定原因类型；如人，设备、材料、环境、方法或过程 （ 4）分配原因 5》分析根本原因 6》小结 2、帕累托分析 少数的失误，应该为大量的质量成本复杂 |
|||||||||||||||||||||||
|
4.2.3 确定相关人员和用户 |
1、Stakeholders :筹码持有人 筹码有大到小的顺序：高层-》中层-》操作员 筹码越高说明项目健康度越高，也就越有可能成功 2、用户分析 |
|||||||||||||||||||||||
|
4.2.4 定义解决方案的界限 |
1、范围与边界 范围是指系统涉及哪些内容 边界是系统与人的职责边界 2、确定边界 3、边界谈判 4、创新边界 |
|||||||||||||||||||||||
|
4.2.5 确定加在解决方案上的约束 |
1、技术开发 技术约束（如平台） 预期软硬件环境（兼容性） 预期的使用环境（如户外，或特殊的作业环境） 2、项目实施 行政约束（如许可） 进度及资源约束（如进度要求） 环境约束（如合法） |
|||||||||||||||||||||||
|
4.2.6 小结 |
||||||||||||||||||||||||
|
4.3 需求定义的产物与要素 |
||||||||||||||||||||||||
|
4.3.1 需求定义的产物 |
1、项目综述（POS） 主要内容： 目标—业务目标 相关人员和用户 –与系统交互的人 限制条件—必须采用某设计方案，时间，经费等 关键术语 相关事实与假定---项目的提出背景，技术能力 工作范围 – 系统设计的内容范围 费用计划 风险—面临的主要风险 可行性 –包括技术、经济、社会可行性论证 2、愿景Vision 主要内容
|
|||||||||||||||||||||||
|
4.3.2 需求定义的要素 |
||||||||||||||||||||||||
|
1、目标 满足: 1>具体 2）可度量 3）可达到 4）和其他目标具有相关性 5）必须具有明确的截止期限 |
||||||||||||||||||||||||
|
4.4 定义需求范围 |
||||||||||||||||||||||||
|
4.4.1 案例说明 |
||||||||||||||||||||||||
|
4.4.2 划分主题域 |
1、主题域的定义 划分主题域的原因： 由于利用子系统的划分方法，在进行需求捕获和分析是就会发现各个子系统和模块与客户部门是交错在一起的，每个模块都需要对不同的部门进行调研。它只是一种逻辑划分，并没有很好地把业务结构体现出来，它只是采用“业务名字+管理”的形式命名的，其中业务名词实际上就是业务实体，也就是物的线索；对于大多数业务系统而言都不是最佳的分解方式，因为这些业务实体会牵涉到大量的业务流程。 合适的划分是根据业务流程，也就是以“事”为线索 2、为什么使用构件图 使用构件图与系统的层次结构图只能体现系统的组成关系相比，更能体香每个主题域之间的关系 1》 服务接口的重要性 尽早的标示出各个主题域之间的接口，可以有效地避免后续系统对当前系统的影响 2》构件图解析 3》构件 4》服务接口：利用职责驱动设计的思想设计接口
|
|||||||||||||||||||||||
|
4.4.3 确定主题域范围 |
||||||||||||||||||||||||
|
1、上下文关系图绘制的要点 |
通过绘制上下文关系图来确定主题域的范围 步骤： 1、首先画一个矩阵，写上系统的名称 2、找到该系统的所有客户，考虑这些客户会发起什么事件，这些事件会引发内部工作人员的什么工作，将这些序列列出 3、最后看看每个内部工作人员有没有一些主动发起的事件 第一步：对主题域有哪些外部用户和内部要做些什么
第二步：体检者除申请体检之外还有什么独立行为：如修改体检项
第三步：寻找是否有除系统主要发起人之外的用户发起的事件；如财务部门
第四步：考虑内部的Worker是否有主动的行为。
|
|||||||||||||||||||||||
|
4.4.4 标识业务事件与报表 |
||||||||||||||||||||||||
|
1业务事件解析 |
业务事件是业务流程的触发点，标示出业务事件能够帮助我们认识业务流程，而业务流程是为了响应业务事件而触发的一系列业务活动，它通常是由于不同部门、不同岗位协作完成的，业务流程的信息掌握在中层管理人员的手里，它属于脉络信息。 业务活动是一个特定的业务流程，它是一个人的活动，因此一个业务流程应该是有一个或多个业务活动组成的：而业务步骤是完成某个业务活动所需要的具体步骤。因此业务活动和业务步骤的信息是掌握在操作层人员手里，它属于细节信息。 |
|||||||||||||||||||||||
|
2业务事件标示要点 |
1、业务事件类型 业务事件可以分为外部事件（系统参与者发起）和内部事件（如状态事件和时间事件） 2、业务事件标识要点 业务事件是主动触发的，直接作用于系统的，也就是将触发系统行为，并且会产生一系列后续行为 如： 客户想买一件衬衫（业务事件）—》 客户开车到购物中心---》 客户在xx点试穿衬衫---》 客户走进我们的店铺---》 客户在我们店铺试穿衬衫----》 客户购买一件衬衫； 注意事项：在梳理业务是应该先把诸如数据备份、更改密码之类的技术性活动放在一边，因为我们梳理的是业务事件，而不是系统事件 |
|||||||||||||||||||||||
|
2案例分析 |
||||||||||||||||||||||||
|
4.4.5 生成需求大纲 |
||||||||||||||||||||||||
|
4.5 小结 |
||||||||||||||||||||||||
|
第5章 需求捕获最佳实践 |
|||||||||
|
5.1 需求捕获的策略 |
|||||||||
|
5.1.1 需求捕获应该是主动的 |
需求捕获是撒网打渔，而不是休闲钓鱼 |
||||||||
|
5.1.2 需求捕获应该是聚焦的 |
捕获过程中的问题： 1、提不出需求 2、提的需求太多 解决方案： 提出聚焦的问题，产生镀金需求 |
||||||||
|
5.1.3 破解需求的冰山模型 |
1、意识到的需求： （用户层面） 位于海平面之上，用户自己能够设想到的需求，（大量的需求以变更的形式出现） 2、无意识的需求 （开发者层面） 实际的工作场景，开发者能够对场景“感同身受”的话，那么就可以大大减少变更的数量，需加强业务知识的捕获 3、未梦想到的需求； （系统架构师层面，找到最佳的技术解决方案） 用户对技术解决方案永远都不是擅长的，因此他们无法构想出对其工作产生革新性变化的解决方案。这就需要通过需求分析人员在对问题域充分利用的基础上，选择合适的技术方案，才可能创造出用户未梦想到的功能，成为优秀的需求分析人员 即：善于利用技术为用户创造全新体验是优秀需求人员的特质 |
||||||||
|
5.1.4 破解阻碍需求捕获的心理现象 |
1、言过其实心理 解决方案 1）用户言过其实时的表现：表述都非常肯定的语气，十分流畅。因为此时他只需创造，而不需要回忆。 2）验证；因为在没有串供的情况下，天下谎言皆不同 验证有谎言存在时，解决方案 1- 差异展现法： 把不同用户的不同表述展示给中层后，找共识 2- 瓶颈分析法 对流程执行过程中的瓶颈进行分析（如都需经理审批），避免流程瓶颈导致系统无法顺利运转 2、越俎代庖心理 识别正确的被访谈者最为关键 1）问题的层次是否正确 高层—宏观、中层—脉络问题、操作---细节 2）根据业务背景判断 3、非正事心理 解决方案：对访谈进行计划 4、抗拒心理 激将法，倾听对方的抱怨是化敌为友的有效手段 |
||||||||
|
5.1.5 不要忽视对变更可能的捕获 |
针对常见变更类型的类型
|
||||||||
|
5.1.6 需求协商 |
1、揭开解决方案后面的问题 2、共赢性谈判 共赢的谈判就是抛开立场，追求满足大家的利用诉求 3、转换技巧 1 --） 相对重要à 相对次要 2 --） 关注点转换 3---） 隐喻 |
||||||||
|
5.2 需求捕获的主要方法 |
|||||||||
|
5.2.1 用户访谈 |
考虑因素： 1、优缺点与使用时机 2、用户访谈的类型 3、时间安排 开场白 – 陈述预先的理解 预先计划问题 -- 寻求问题的答案 即兴问题 ---扩大需求信息量 总结 – 总结访谈内容 4、用户访谈中的记录工作 5、用户访谈中的沟通技巧 1—） 制作访谈问卷并事先发给被访谈者 2--） 把握语言节奏 3--） 有效结合不同的问题类型 开放式问题 封闭式和半封闭式问题 4--）善于安排问题顺序 金字塔结构：一种归纳过程 漏斗结构：一个演绎的过程 菱形结构；上述两个结构的混合 5--） 注意沟通的细节 让模型成为访谈过程中的工具 避免出现一些干扰访谈的暗示 注意隔行如隔山 善于观察异常 不要遗漏问题 6） 用户访谈计划 计划时间、人员 计划内容 |
||||||||
|
5.2.2 用户调查 |
1、优缺点与使用时机 （调查与访谈）、大样本用户\跨地域用户 2、用户调查问卷设计要点 --1）注意问题的篇幅与布局 问题的顺序：由易到难、注重逻辑相关性 --2）注意问题的类型选择 半封闭是问题是首选 --3）封闭式问题相关的两个技巧 跟随策略 C选项：采用大样本结果放在中间 D选项：考虑考察结果可能受影响的 3、用户调查问卷的分析要点 筛选无效问卷 对问卷的填写人进行分类 |
||||||||
|
5.2.3 文档考古 |
1、优缺点与使用时机 2、文档考古的使用要点 1—》注意文档的历史性 2—》化被动收集为主动索取 |
||||||||
|
5.2.4 情节串联板 |
|||||||||
|
5.2.5 现场观摩 |
|||||||||
|
5.2.6 联合开发 |
突破双方需求盲区的有效手段 联合开发的使用要点： （1）会前准备 目的是：在理念上建立共识 （确保真正的Stakeholder参与 、准备好相关材料） （2）会中有控制 （控制氛围、进程） （3）会后有总结 |
||||||||
|
5.3 需求捕获的记录工具 |
|||||||||
|
5.3.1 工具的选择与定义 |
沟通决定内容，内容决定格式 |
||||||||
|
5.3.2 任务卡片 |
任务卡片的内容包括 任务 目的 触发 前提 频率 关键情况 子任务（如具体业务步骤） 任务变体（如异常） |
||||||||
|
5.3.3 场景说明 |
|||||||||
|
5.3.4 其他工具 |
|||||||||
|
5.4 小结 |