软件需求分析详解
2014-05-21 13:46
176 查看
第1部分 原理、模型与误区
第1章 需求实践现状分析
1.1 软件项目失败的根源
| 1.1 软件项目失败的根源 | |
| 1.1.1 chaos report 1994 | |
| 1.不完整的需求 2、缺乏用户参与 3、资源不足 4、不切实际的用户期望 5、缺乏执行层的支持 6、需求的变更频繁 7、规划不足 8、提供了不再需要的 9 、缺乏IT管理 10、技术能力缺乏 11、其他 | |
| 1.1.2 chaos report后续版本 | |
| 1.1.3 需求相关败因简要分析 | |
| 败因 | 解决方案： |
| 1 不完整的需求 | 采用业务导向让用户参与到完整性评价当中，在实际过程中利用树形层次结构将宏观信息与微观信息进行有效的剥离。 分析: 利用树形层次结构面向不同的层面：决策层，事务管理层，操作层，让合适的人验证相关的部分，这样可以有效的避免事不关己，高高挂起。让用户逃离无趣区和有效的启发用户的积极性，减少被专业人士排除在系统的完整性评价之外 |
| 2 缺乏用户参与 | |
| 3不切实际的用户期望 | 由于软件的无形和成本的不透明，需要说明软件中不能完成的需求的原因 |
| 4 需求变更频繁 | 对变更进行分类，统计，有针对性的改进需求过程，提高设计的弹性 |
| 5提供不在需要的 | 找到用户经常使用到的功能，也即用户的需求，放弃用户很少使用的功能模块的开发 具体方案：在每个功能模块入口处，放置一个计数器 |
| 失败的原因 | 分析原因与解决方案 |
| 1 沟通失真 | 分析： 每个角色（如项目经理，商业顾问等）更加自己的特点和需求对信息（漫画）进行了不同程度的加工，从而导致信息内容有很大的变化 |
| 解决方案： 1、 利用文档：防止信息在传递的过程中走样 2、Reviews （评审）：在此审阅，需求人员在此用语言复述软件需求。 | |
| 2、客户需求放大 | 分析： 1、客户希望支付的成本尽可能少，获得的效益尽可能多。 2、解决方案的选择权较给了不熟悉技术的客户。 |
| 解决方案1： 1、需要提升软件估算实践的有效性 2、提高产业成熟度 解决方案1： 需求捕获的过程中多问为什么 | |
| 3 项目经理的需求控制 | 分析： 需求捕获的过程中，导致需求产生了偏差，部分从技术的角度对需求进行了控制，造成无法对需求的有效理解 |
| 解决方案： 减少技术在需求提取过程中的不利影响 | |
| 4分析人员的技术加工 | 分析： 分析人员对技术能力的追求高于业务能力的追求 |
| 解决方案: 提高自己的业务分析能力 | |
| 5 编码人员的断章取义 | 解决方案：业务场景是需求之魂 |
| 1.2 透过表象，分析本质 | ||
| 1.2.1 需求变更频繁 | ||
| 1.2.2 上线阻力大 | ||
| 原因 | 解决方案 | |
| 1 利益冲突 | 需求分析 | |
| 2 工作量大 | 提高易用性、工作量价值化、将数据迁移，准备工作独立出来 | |
| 1.2.3 运行效果差 解决方案：从问题与机会入手，提高管理人员的推动力 从障碍和困难出发，解决操作人员的积极性 | ||
| 1.2.4 完全崩溃 分析：大多是由于忽略了非功能性需求（如：系统容量不足以支撑业务需求 解决方案：明确非功能性需求的特点,然后进行改进 | ||
| 1.3 方法论与需求工作 | ||
| 1.3.1 计算模式 | ||
| 如：C/S 与B/S | 从用户的角度选取 | |
| 1.3.2 软件工程方法论 | ||
| 方法论分两种：重方法和敏捷方法论 | ||
| 1.3.3 开发思想 | ||
| 1 成熟度 | 判断标准之一：见报率高，成熟度低 | |
| 2 溯源 | 了解本质 | |
| 3 了解局限性 | 了解局限性才不至于滥用，误用 | |
| 1.4 小结 | ||
| 第2章 不同软件项目的需求视图 | |||||||||||||||||||||||||||||
| 2.1 信息系统的需求视图 | |||||||||||||||||||||||||||||
| 2.1.1 信息系统的本质与分类 | |||||||||||||||||||||||||||||
| 信息系统的几个要素 | |||||||||||||||||||||||||||||
| 1支持企业日常运作 | |||||||||||||||||||||||||||||
| 2 支持解决问题 | 解决企业运作中存在问题的使命 | ||||||||||||||||||||||||||||
| 3支撑决策 | 加工处理数据 | ||||||||||||||||||||||||||||
| 信息系统的本质 | |||||||||||||||||||||||||||||
| 1 数据信息化 | 通过对数据的有效处理，从而得出对人们更有价值的信息 | ||||||||||||||||||||||||||||
| 2 信息系统的类别 | 联机事务处理系统(OLTP)---数据的生产者 管理信息系统(MIS)—数据的消费者（企业、组织中层管理者用于处理事务） 主管信息系统(EIS)--数据的高级消费者（企业中的高层管理者用于决策） 决策支持系统（DSS）---数据的高级消费者（中层管理者） 专家系统----对个人知识的沉淀，同时也是数据的消费者 办公自动化系统（OA）----对沟通和协作的支持 | ||||||||||||||||||||||||||||
| 2.1.2 联机事务处理系统——流程电子化 | |||||||||||||||||||||||||||||
| 电子化流程的好处 | 1、有利于流程的固化 2、对业务产生一定的约束 | ||||||||||||||||||||||||||||
| 2.1.3 管理信息系统——数据信息化 | |||||||||||||||||||||||||||||
| 1报表需求何时开始分析 | （1）OLTP是数据的生产者，MIS是数据的消费者 报表的数据从OLTP中来，传统需求实战中，我们却经常先分析业务功能性需求，在分析报表类需求，此时我们根本不了解消费者需求是就确定了生产者的需求，显然是一种草率的态度。 解决方案： 从管理场景入手，从理解报表的目的着手就能更好地完成与用户的沟通，而且也更加的高效。 | ||||||||||||||||||||||||||||
| 报表需求的要点： | Why | 目的 | 从管理场景出发，借助对管理控制点的理解来理解报表的目的 | ||||||||||||||||||||||||||
| 使用部门/职位 | 了解使用者 | ||||||||||||||||||||||||||||
| 相关场景 | 如用户数量 | ||||||||||||||||||||||||||||
| What | 关联实体 | 以类图或E-R图说明数据的来源 | |||||||||||||||||||||||||||
| 关键指标及计算规则 | 细化推导出关联字段，以及派生属性的基本方法 | ||||||||||||||||||||||||||||
| How | 展现形式 | 以虚拟窗口等形式 | |||||||||||||||||||||||||||
| 输入输出需要 | 说明是否打印，格式等 | ||||||||||||||||||||||||||||
| 2 解析报表的分类 | |||||||||||||||||||||||||||||
| 1事务类 2 决策类 | |||||||||||||||||||||||||||||
| 2.1.4 其他信息系统 | |||||||||||||||||||||||||||||
| 1决策支持系统 | 1、结构化问题： 利用历史积累经验，如安全库存量，现金流预警。可以建立模型利用计算机直接计算出来。 2、非结构化问题； 如广告投放，产品定位等问题都没有现成的模式可以依赖 | ||||||||||||||||||||||||||||
| 2 专家系统 | 个人知识转化为企业知识 | ||||||||||||||||||||||||||||
| 3办公自动化 | 协同信息化 | ||||||||||||||||||||||||||||
| 2.1.5 信息系统的多维视图 | |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
| 2.2 嵌入式系统的需求视图 | |||||||||||||||||||||||||||||
| 2.2.1 面向直接用户的嵌入式系统 | |||||||||||||||||||||||||||||
| 2.2.2 面向特定设备的嵌入式系统 | |||||||||||||||||||||||||||||
| 2.3 软件产品的需求视图 | |||||||||||||||||||||||||||||
| 1 信息类 | （1）、目标市场分析 1、目标客户分析 2、竞争对手分析 3、商业模式分析 | ||||||||||||||||||||||||||||
| （2）、产品体系设计 信息系统类软件产品的需求重点在于针对不同目标客户群体的不同商业模式分离变化点，经常需要减出通用性，在通过插接解决扩展性 | |||||||||||||||||||||||||||||
| 工具软件类 | 对现实世界中某种工具的仿真，例如计算器，便签 | ||||||||||||||||||||||||||||
| 2.4 小结 | |||||||||||||||||||||||||||||
| 第3章 软件需求与需求工程 | |||||||||||||
| 3.1 什么是软件需求 | |||||||||||||
| 定义 | 业务知识+问题列表+其他因素 | ||||||||||||
| 3.1.1 需求的三个层次 | |||||||||||||
| 1业务需求 | 定义：软件系统的建设目标。 需求定义的产物 也就是反映企业/组织对软件系统的高层次目标要求： 1、问题：解决企业运作过程中遇到的问题，如物资供应脱节、用户投诉量大 2、机会：抓住外部环境所带来的机会，以便为企业带来新的发展，如电子商务，网上银行 业务需求应该在项目立项的时候整理。 | ||||||||||||
| 2用户需求 | 定义：用户使用软件需要完成什么任务，怎么完成的需求。 需求捕获的产物 通常在业务需求定义的基础上进行用户的访谈，调查，对用户使用的场景进行整理，从而建立用户角度的需求。 1、零散；用户提出不同角度，层面，粒度的需求 2、存在矛盾：用户在企业中的不同层面导致对系统的需求不同 | ||||||||||||
| 3 软件需求 | 需求分析与建模的产物 | ||||||||||||
| 3.1.2 需求的三种类型 | |||||||||||||
| 1功能需求 | 以系统→子系统→模块→子模块方式组织 | ||||||||||||
| 2 非功能需求 | 常见的问题：是什么 保证信息的有效传递和注意局限性 1、信息传递的无效性，如高可靠性，扩展性 2、忽略了非功能需求的局部性，如查询时间<10s | ||||||||||||
| 3 设计约束 | |||||||||||||
| 1非技术性因素决定的技术选型 | 如：采用VC++平台 | ||||||||||||
| 2预期的软硬件环境和使用环境 | 实现技术受环境的影响如内存大小，海上使用 | ||||||||||||
| 3.1.3 优秀需求的标准 | |||||||||||||
| 1完整性 | 定义：需求没有遗漏，也就是说在需求变更中新需求都是因为外部环境的变化而产生的且所占量小 （1）用户才是验证需求完整性的合适人选 为了保证需求的完整性，就必须从业务角度来组织各种需求项，让用户验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤、困难与障碍点是否完整，更具操作性。 步骤：验证主题域-》中层-》操作层 | ||||||||||||
| 2不失真 | 1、正确性 2、无歧义性 | ||||||||||||
| 3有优先级 | |||||||||||||
| 1优先级有不同角度 | |||||||||||||
| 2必要性是优先级评价的盲区 | 必要性只是对优先级的补充 分析：优先级常从充分性来考虑的，这样会导致忽略了需求的必要性。利用满意（反映需求的充分性）\不满意（反映需求的必要性）模型来防止需求的蔓延。 | ||||||||||||
| 4有技术早期介入 | 1、可行性；就是指需要让开发团队早期介入，对需求中描述的解决方案进行评价。重点在需求项及复杂的解决方案 2、可验证性；说明需求规格说明书应该能够指导测试活动，也提供了验证所需的信息。 | ||||||||||||
| 3.2 需求工程解析 | |||||||||||||
| 3.2.1 需求工程的范畴 | 1、需求开发：收集、分析、整理、编写、验证 2、需求管理：对需求的实现变化进行追踪的全过程，重点在于确保开发的软件满足这些需求 | ||||||||||||
| 需求开发的三次循环 |
| ||||||||||||
| 分析说明： | |||||||||||||
| 1需求获取 | 需求的捕获，它们都是主动词，而现实的需求实践中最大的问题是比较被动的。主要体现在： 1、捕获范围不足（对业务知识的不足） 2、缺乏计划性（预先对问题、时间、采访对象没有计划） 3、缺乏科学性（如宏观与微观问题混在一起） 4、捕获对象不明确（很少主动寻找合适的被访者） 5、捕获手段不足（对场景不同时需求的捕获缺乏） | ||||||||||||
| 2需求分析 | 1需求分析是什么 定义： 1、需求分析是业务分析 2、需求分析是一种分解活动 3、需求分析是一种提炼与整合活动 4、需求分析是一种规格化活动 2内容与形式 分析是任务，建模时手段，利用建模可以用图形代替文本，以更加可视化的方法表示信息，产生的结果并不一定非得是规范性很高的模型 建模的主要要点: 1、尽可能进行团队建模 2、大胆使用草图建模 3何时开始与结束 迭代式需求分析： 1、分析活动逐渐从本质需求过渡到边缘需求 2、RUP中的细化阶段是需求分析活动最密集的阶段 3、到了RUP中的构建阶段，需求分析活动将逐渐减少 | ||||||||||||
| 3编写规约 | 良好的源代码和注释就是最好的文档 软件规格说明书应具有： 1、共享；可获得（软件开发团队可以在开发需要时获得最新版本的规格说明书），可获知（利用开发模板确保软件需求说明书的读者知道自己需要的信息在哪些章节） 2、更新；专人更新（按不同章节指定更新人），写作风格（确保一类信息只在一处描述） | ||||||||||||
| 4需求验证 | 需求验证的关键手段：评审 主要要点：分层次、分内容进行验证 | ||||||||||||
| 3.2.3 需求管理工作要点 | |||||||||||||
| 需求管理项之间的关系 | |||||||||||||
| 1统一、明确的需求项划分标准 | 成功的划分满足以下条件： 1、粒度均匀（如每个需求项的大小相当，即工时相当等） 2、大小合适（如每个需求项工作量以周为单位） 3、完整（最低一级的需求项应该涵盖所有的开发任务） | ||||||||||||
| 2 引入基线管理 | |||||||||||||
| 每次迭代都是一个小型的瀑布型生命周期；通过这样的分解，整个开发工作就被划分成了多个小项目，这种模式更容易使开发人员保持良好的工作节奏。 在划分基线是，通常需要完成三个方面的事情： 1、确立优先级；确保高优先级，高风险的需求项在尽早的迭代中完成； 2、工作量估算；确保每次迭代的时间安排是紧凑的 3、未完成项的合并 | |||||||||||||
| 3引入变更管理 | 客观存在的需求变更是引入变更管理成为必然 就需求管理而言主要完成： 1、业务影响分析： 从业务角度对变更的合理性、优先级以及对原有需求的影响进行分析，确定优先级 2、技术影响分析： 从技术角度对变更的影响范围、工作量进行分析，并决定是拒绝、在后续还是在本次的迭代中进行响应 3、项目影响分析： 基于前面的工作量分析，考虑是否对整个项目的时间、进度、成本产生较大影响 | ||||||||||||
| 4引入需求跟踪 | 引入需求跟踪能精确地评价在变更的影响分析过程中变更将影响的哪些需求项、哪些设计元素 | ||||||||||||
| 3.2.4 需求分析人员的技能组成 | |||||||||||||
| 1需求分析人员的来源 | 1、开发人员；2、用户；3、领域专家 | ||||||||||||
| 2各种能力培养的要点 | |||||||||||||
| 3.2.5 seru模型概述 | |||||||||||||
| 3.3 小结 | |||||||||||||
| 第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 小结 |
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 软件需求提取，分析，升华详解
- 软件需求提取，分析，升华详解
- 软件开发:需求分析的20条法则
- 系统分析员论文样例及评注－对论文试题1“论软件需求分析方法和工具的选用”写作的评注
- 如何做好企业管理软件开发的需求分析（1）
- 软件需求分析报告
- 软件项目中为什么要进行需求分析？
- 软件需求分析
- 软件测试项目启动、规划与需求分析
- 软件项目需求分析的20条法则
- 软件项目需求分析为什么困难？
- 论软件需求分析方法和工具的选用—论文4：IC行业内部的CAD应用
- 软件需求分析阶段
- 铁路售票系统应用软件需求分析报告
- 细谈软件需求分析过程：提取、抽象、升华
- 论软件需求分析方法和工具的选用—论文3：通信行业的应用
- 根据软件操作分析需求?
- 对国内外软件人才需求与培养结构的分析报告
- 软件开发:需求分析的20条法则