第3章 需求获取

1、1 第3章 需求获取 2 第3章 需求获取 软件需求获 取（简称需求获 取）阶段的任务 简单的说就是获 取用户的需求信 息。 其过程如 左图所示： 确定非功能需求和约束条件 实地收集用户需求信息 确定调查对象 建立项目范围和目标 确定需求开发计划 3 第3章 需求获取 3.1确定需求开发计划确定需求开发计划 3.2确定项目的目标和范围确定项目的目标和范围 3.3确定调查对象确定调查对象 3.4实地收集需求信息实地收集需求信息 3.5确定非功能需求确定非功能需求 3.6在收集需求信息中应注意的问题在收集需求信息中应注意的问题 3.7使用场景技术的需求获取使用场景技术的需求获取 4 3.1确定需求

2、开发计划确定需求开发计划 确定需求开发计划的基本任务是确定需求 开发的实施步骤，并给出收集需求活动的具体 安排和进度 。 需求开发计划需要注意以下几点： （1）只考虑与需求开发相关的工作； （2）应考虑困难性和灵活性； （3）应考虑书写和整理需求规格说明及其 文档所花费的时间。 5 3.2确定项目的目标和范围确定项目的目标和范围 此阶段的基本任务是根据项目目标把项目 相关人员定位到一个共同的和明确的方向上， 并决定软件系统的范围。 项目的范围与项目的目标特别是软件系统 的目标需求是密切相关的。 6 3.2确定项目的目标和范围确定项目的目标和范围 在收集目标需求时，目标需求会来源于各 个不同的人

3、，这些人对要开发的软件系统及该 系统最终能为用户或客户提供哪些价值有比较 清楚的了解。 7 3.3确定调查对象确定调查对象 本阶段的基本任务是明确地确定来自不同 层次的需求来源和用户，并将其分类。 应根据需求的层次来区分不同的用户： （1）提出目标需求的用户； （2）提出业务需求和功能需求的用户； （3）软件开发人员，主要是指系统分析员。 8 3.3确定调查对象确定调查对象 软件系统面临的用户是很多的，而这些用 户由于所在的部门、职责和掌握的知识不同而 存在差异，为了避免忽视和遗漏某些用户的情 况，可以根据用户的某些方面将用户分类。 9 3.3确定调查对象确定调查对象 在将用户分类后，在分类的

4、基础上进一步 寻找每类用户的代表或联络人，这些人代表了 一个特定的用户类，并可充当该用户类与开发 人员之间的“窗口”。 这些人也必须是真正的用户，而不是单纯 的代理人。 10 3.3确定调查对象确定调查对象 表3.1 用户代表的义务 1) 给分析人员讲解业务及说明业务方面的术语等专业问题。 2) 抽出时间清楚地说明需求并不断完善。 3) 当说明系统需求时，力求准确详细。 4) 需要时要及时对需求做出决策。 5) 要尊重开发人员的成本估算和对需求的可行性分析。 6) 对单项需求、系统特性或用例划分优先级。 7) 评审需求文档和原型。 8) 一旦知道要对项目需求进行变更，要马上与开发人员联系 9)

5、 在要求需求变更时，应遵照开发组织确定的工作过程来处 理。 10)尊重需求工程中开发人员采用的流程（过程）。 11 3.3确定调查对象确定调查对象 软件需求可来自与各个方面，而且用户类 也不一定都是指人。有时也可以把其它应用系 统或计算机硬件设备和接口等视为附加的用户 类成员，这样就可确定软件系统与哪些外部应 用系统或计算机硬件相关的需求。这就是说需 求信息来源除了来自用户类外，还可来自于其 它方面。 12 3.3确定调查对象确定调查对象 几个典型的软件需求来源： 1.直接和间接使用软件系统的用户； 2.系统需求规格说明； 3.市场调查和用户问卷调查； 4.已开发出的和待开发的同类软件系统的描

6、述 和文档； 5.对人工系统的存在问题的报告和增强要求； 6.观察正在工作的用户； 7.用户工作内容的分析。 13 3.3确定调查对象确定调查对象 当确定了用户类及明确了用户需求的主要 来源后，这样就可从不同的渠道和不同的人那 里收集到大量的需求信息。但这些需求信息既 包含了明确的用户需求，也包含了一些不一致 和含糊的需求，而且软件开发人员也难以解决。 因此，这就需要寻找需求的决策者。 在处理有问题的需求信息时，决策者并不 是固定不变的，而是根据实际中可能发生的具 体问题来确定。 14 3.4实地收集需求信息实地收集需求信息 在确定了需求的来源和调查对象后，下一 步就是实地收集需求信息。实地收

7、集需求信息 阶段的任务就是到现场实地调查和与用户交流， 收集和理解用户需求信息。 15 3.4实地收集需求信息实地收集需求信息 实地收集需求信息可能面临的困难： 1.能提出软件需求的用户可能觉得他们没有充 分的时间与开发人员进行交流和讨论 ； 2.有时用户希望通过简单的方法和说明，或者 通过简单回答开发人员的询问后，软件开发 人员就能清楚地理解他们的需求，而不需要 花费太多的时间进行讨论； 16 3.4实地收集需求信息实地收集需求信息 3.用户和开发人员都只考虑自己的利益；如： 有些用户由于缺乏使用计算机的经验，导致 产生畏难情绪；有些用户认为开发软件系统 自己的关系不大，对待需求信息的收集工

8、作 采取消极的态度。 4.用户本身不能提出明确的需求 ； 5.开发人员缺乏用户的业务知识，而用户也缺 乏计算机方面的知识，导致双方在交流中产 生许多的困难，以至收集工作难以进行。 17 3.4实地收集需求信息实地收集需求信息 实地调查的步骤： 1.向掌握“全局”的负责人调查； 2.向部门负责人调查； 3.向业务人员调查。 步骤（2）和步骤（3）是一个反复的过程， 而且每次调查之前要制定调查提纲，每次调查要 作记录，并交由用户审查核实，以保证需求信息 的可靠和准确。 18 3.4实地收集需求信息实地收集需求信息 实地收集需求信息的方式 1.以座谈会的方式； 2.以书面咨询的方式； 3.利用用例表

9、示方法。 19 3.4实地收集需求信息实地收集需求信息 需求信息可大致分类如下： 1.目标需求； 2.用例说明； 3.业务规则； 4.功能需求； 5.性能需求； 6.外部接口需求； 7.限制 8.数据定义； 9.解决思想。 20 3.5确定非功能需求确定非功能需求 非功能需求是衡量软件能良好运行的定性 指标。由于缺乏定量指标，因此很难根据这些 需求来评价软件系统，这也是开发出来的软件 系统与用户所满足的软件系统之间存在差异的 主要原因。 21 3.5确定非功能需求确定非功能需求 用户所关心的非功能需求主要有： n可靠性； n可扩充性； n安全性； n互操作性； n健壮性； n易使用性； n可维

10、护性 n可移植性； n可重用性。 22 3.5确定非功能需求确定非功能需求 在收集非功能需求信息时常用的方法： 1.将不同用户类代表提出的可能很重要的非功 能需求进行综合，并根据其中的每个需求设 计出许多方法，然后根据用户的回答，使这 些需求更明确化； 2.开发人员与用户一起对每一个非功能需求制 定可测试和可验证的具体标准； 3.设计与非功能需求相冲突的假设示例，利用 反例来提示用户。 23 3.6 需求定义（rup模型） 24 关键五步:来源rup的智慧 在问题定义上达成共识 理解根本原因问题背后的问题 确定stakeholder和用户 定义解决方案系统的界限 确定加在解决方案上的约束 目标

11、 stakeholder 范围 约束 25 寻找客户的需求 n了解用户需求的第一步是在有关问题的定义上 和用户达成一致。 n用户陈述的问题往往是表面现象，我们有必要 和用户一起挖掘出问题背后的问题，即找出问 题的根源，从而从根本上解决问题。 n确定系统的涉众，除了开发团队和用户等直接 涉众，我们还要找到间接的涉众。 n系统边界确定了我们系统的内涵，即它究竟包 括哪些功能，可以解决哪些问题。 n确定解决方案的约束条件。 26 3.6.1在问题定义上达成共识 描述问题的模版 所谓的问题分析，就是理解真实世界中的问题和用户需求 并提出满足这些多方面的解决方案的过程。第一步是把问题拿出 来，达到所有人

12、的共识，采用统一的格式，rup为问题定义提供 了统一的模板，如下： 27 n下表是一个银行信用卡机构整理的问题定义描述 问题定义示例 项目内容 问题竞争性的市场使一家金融组织意识到，它必须 开始利用日常交易中包含的大量信息。企业的 资产很多，但它还具备预测信用卡使用情况和 利润率的情况。 影响信用卡部 结果在信用卡营销方面针对性不强，导致利润降 低 优点有效标识出用户特点与信用卡使用情况的关 系；标识出利润率较高的用户群体。 28 问题定义技巧:转换 n马的遍历问题：寻找一系列的移动步骤，使马 走完每个方块，而落入任何一个方块有且只有 一次 29 问题定义技巧: 本源 n问题：日内瓦湖上的山脉

13、中建成了一条很长的 汽车隧道，为了防止停电时发生灾难，必须提 醒司机进入隧道之前把车灯打开。 n解决方案一：“警告！前有隧道请打开车头灯警告！前有隧道请打开车头灯” n新问题：隧道出口风景很美，返回时发现汽车 没电忘了关车头灯！ n解决方案二：出口处立标牌出口处立标牌“关掉车灯关掉车灯” n新问题：夜行车也会关掉车灯？ 30 n案例： n小林在一次电子政务项目中遇到了这样一个问题，用 户要求对每个政务申请的各种处理都需要记录时间。 由于他们选择的是c/s结构，因此取时间时就遇到问题， 每台机器上的时间都不尽相同。 n“不就是时间不统一吗，让所有客户端登录时先从时 间服务器上取一个时间就搞定了！

14、” n但这个方案在实际的运行时却带来了不小的麻烦，由 于时间服务器写的不够稳定，经常会自动退出，当这 种情况出现客户端软件就根本无法进入，严重影响了 客户的正常使用。 在确定某问题的解决方案时，思考是否引发新问题在确定某问题的解决方案时，思考是否引发新问题 31 问题定义技巧:本源 n解决方案三：建充电站建充电站 n新问题：维护开支大，充电站也会坏 n解决方案四：授权私人经营充电站授权私人经营充电站 n新问题：风景区商业化，政府与游客均不接受 32 直接修改错误，不要用其他方案来弥补错误直接修改错误，不要用其他方案来弥补错误 n案例： n在小程负责的一个客户关系管理系统项目中，用户在 使用了一

15、段时间之后提出了这样一个问题：客户数据 库的数据比较乱，有重名、同客户多条记录等现象。 n小程毫不犹豫地说：“没关系，我可以为你们开发一 个功能强大的客户数据清理工具，通过工具可以自动 识别出这些混乱的数据，并且提供一些合并、汇总、 删除功能”。 n随着这个功能的开发，项目的范围也不断扩展，针对 这个功能的需求也层出不穷。这就是软件开发过程中 的“充电站”，成本付出了，但真的对项目有好处么？ n这样做，似乎很多人会举手赞成，但是也付出了巨大 的成本。如果我们细究一些，这个问题是怎么产生的 呢？为什么数据会混乱呢？ 33 n解决方案五：在隧道尽头，树立新标牌 如果是白天，并且车灯开着，请熄灭车灯

16、；如果是白天，并且车灯开着，请熄灭车灯； 如果天色已晚，并且车灯没开，请打开车灯；如果天色已晚，并且车灯没开，请打开车灯； 如果是白天，并且车灯没打，就别打开它；如果是白天，并且车灯没打，就别打开它； 如果天色已晚，并且车灯开着，请别关掉它。如果天色已晚，并且车灯开着，请别关掉它。 n新问题：谁能在行驶时读完？！ 问题定义技巧:本源 34 n在软件开发中，例如安装过程中的向导就是此 类例子：明知道大家都是闭着眼睛点击“下一 步”按钮的，那么为什么还要不断重复这样的 设计呢？这难道不就是一个蹩脚的标牌吗？ n如何解决？ q关键在于对问题的定义，先确定到底存在什么样的 问题？如下图分析： 车没电司

17、机忘关大灯缺乏提醒 寻找问题的本源 问题定义技巧:本源 35 n终极解决方案： q在出口处立标牌：你的灯亮着吗？你的灯亮着吗？ 问题定义技巧:本源 36 影响人群分析的技巧 n问题定义时，还可以对影响人群进行分析，得 出推断和结论。 q文氏图分析 解决方 案人群 影响 人群 ？ internet 用户 婴幼儿 母亲和 祖辈 ？ 实例：2006年投资开办母婴网站 37 3.6.2了解问题产生的根本原因了解问题产生的根本原因 n问题定义达成共识后，下一步分析问题背后的 问题，也就是寻找问题的本源。 n两种实用工具： q一种是定性分析的鱼骨图 q一种是定量分析的帕累托图 38 鱼骨图 n鱼骨图也称为

18、因果鱼骨图，它是一种以直观的 图形找出问题或现象的所有潜在原因的方法， 它有利于追踪出问题的根源。 n具有三个典型的好处： q使分析人员将问题的原因而不是症状放在首位。 q提供了一种运用集体智慧解决问题的新方法。 q直观、简明、易于操作。 通常鱼骨图分析的过程会结合头脑风暴。 39 鱼骨图 n绘制一个鱼骨图通常是一个团队在一起完成， 具体步骤如下： q选择问题 q头脑风暴 q确定原因类型 q分配原因 q分析根本原因 40 n案例：开发一个在线图书借阅系统。传统的借书方式 要求读者亲自来到图书馆，这显得非常不方便，而且 随着藏书的增加和读者群的增长，大量的读者来到图 书馆，使得图书馆的场地不足，

19、工作人员也不够了。 所以想到借助网络，让读者通过网络借/还书，这样可 以节省大量的场地维护和工作人员成本支出，同时计 算机可以方便地检索目录，让读者可以足不出户借到 需要的书。为了把书送到借阅人手里，联系了快递公 司，初步达成协议，由他们往返借阅人和图书馆之间， 把图书送出和收回。读者在网上出示和验证借书卡， 找到他们需要的书，提交申请，图书管理员确认后， 就会通知快递公司来取书。当然在这个过程中，读者 是需要付费的。还书基本上也是同样的过程。 41 鱼骨图 n选择问题 q首先必须选择一个具体的 问题或结果。在选择问题 时，要保证问题是专门的、 定义严谨的、范围相对较 小的，并且保证所有参与

20、人员能够切实理解分析的 内容。对于上一步定义出 来的每个问题都应该进行 一次独立的鱼骨图分析。 q先将问题定义在白板或纸 上写出来，画出第一层鱼 骨，如图所示： 42 鱼骨图 n头脑风暴 q就导致问题的所有可能原因进行头脑风暴。如果在 白板上进行，可以将大家提出的意见写在记事贴上， 然后将它们贴到鱼骨图上。 q注意：不能将原因和解决方案混为一谈。 头脑风暴法（brain stormingbs）： 一种通过集思广益、发挥团体智慧，从各种不同角 度找出问题所有原因或构成要素的会议方法。 bs有四大原则：严禁批评、自由奔放、多多益善、 搭便车。 43 鱼骨图 44 鱼骨图 n分配原因 q把头脑风暴得

21、出的潜在原因放在鱼骨图中，并且确 保每一项原因都归类于适当的类别中。如果原因看 起来可以放在多个类别中，就表示它是一个多重原 因：这种情况多次出现，就表示这个分类有问题， 应重新考虑分类是否合适。 q相关的原因在组织时是可以分级整理的，可以通过 提出“是什么？”、“为什么？”、“怎么样？”、 “在那里？”等问题来进一步发展更细等级的原因。 q注意：不要过于深究，否则陷入无尽的细节中，三 层细节是图表的实际限制。 45 鱼骨图 46 鱼骨图 n分析根本原因 q接下来要对鱼骨图中罗列出来的所有潜在原因进行 分析，考察造成某一结果的根本原因最有可能是什 么，或者说哪些原因是最核心的，可以通过一些几

22、个方面来考虑： n通过参与者之间的公开讨论来分享看法和经验； n寻找重复的原因，或与特定类别有关的原因的数目； n使用检查表收集资料、制作流程图或进行客户调查，通过 帕累托图分析法测试各种原因的相对强度； n一旦对一小部分主要原因达成一致意见，就可以用成对比 较法进一步缩小范围； n有时只考虑那些能够影响到的因素是有好处的。 47 鱼骨图 n小结 q鱼骨图是一种因果分析工具，它在需求定义、项目 管理、过程改进等活动中都是很有价值工作，可以 用来： n关注原因而非表面的症状； n获取一个群体的集体知识和经验； n提供了展现导致问题发生的所有原因和全景图； n为进一步收集资料和行动提供了坚实的基础

23、。 48 n定量分析 n帕累托80/20原则 q百分之八十的问题是百分之二十的原因所造成的。 帕累托图在项目管理中主要用来找出产生大多数问 题的关键原因，用来解决大多数问题。 n几个方面的作用 q为80%的问题找到关键的20%的原因； q一目了然地显示出每个原因的相对重要程度； q有助于预防在解决了一些问题后，却使另外一些问 题变得更糟的情况。 帕累托图（pareto chart） 49 2-8 原则* walker royce扩展了barry boehm提出的有关 软件项目管理的“二八定理”，构成了现代软 件管理过程框架的理论基础 n 80%的工程活动是由20%的需求消耗的 n 80%的软件

24、成本是由20%的构件消耗的 n 80%的缺陷是由20%的构件引起的 n 80%的软件废品和返工是由20%的缺陷引起 的 n 80%的资源是由20%的构件消耗的 n 80%的工程活动是通过20%的工具完成的 n 80%的进展是20%的人完成的 50 帕累托图（pareto chart） 51 3.6.3确定涉众和用户 n涉众 (stakeholder) ，在软件开发项目中主要 是指和这个项目有密切相关利益的人，他们共 同感兴趣的就是需求分析阶段。这些涉众包括 客户、用户、业务或需求分析员(负责收集客 户需求并编写文档，以及负责客户与开发机构 之间联系沟通的人)、开发人员、测试人员、 用户文档编写

25、者、项目管理者和客户管理者。 52 解析stakeholder n简单的项目健康评价方法 q问项目经理一个这样的问题：你们的团队和哪一层 客户打交道最多？ n如果答案是操作层，那么很遗憾，你的项目出现延误的可 能性极大，几乎是难以避免的；其中原因很简单，操作层 手中的筹码相对来说是很少的，可能只是几个铜板。 n如果答案是中层管理人员，那么只要在项目过程中尽力， 是有希望避免出现延误情况的，至少延误的比率相对较低； 原因是中层手中有一定的筹码，加上人数较操作层少很多。 n如果答案是高层管理人员，那么恭喜你，项目出现延误的 可能性几乎是没有的；高层管理人员手握着最有分量的筹 码，而且人数极少。 5

26、3 确定涉众的问题举例确定涉众的问题举例 54 案例：在线图书借阅系统中的涉众 55 3.6.4 确定系统的界限 n定义系统的关键首先是要给出系统的边界。该 边界把我们的系统和外部世界一分为二，换言 之，系统边界确定了我们系统的内涵，即它究 竟包括哪些功能，可以解决哪些问题。我们可 以根据确定的系统边界给出系统的环境模型。 它指出了我们的系统以及其它和它交户的系统 之间的关系。 n绝大部分书籍推荐使用上下文关系图来确定系 统范围，实际上就是 数据流图中的顶层图。 56 在线图书借阅系统的界限 57 3.6.5确定解决方案的约束条件 n潜在的系统约束 58 到期催还功能的约束分析 59 3.6.

27、6 实例 n问题描述： n一家制造和网上邮购物品公司，制造和销售家 用物品和个人用品。由于公司发现效益太差的 问题，采用了全质量管理（tqm）来解决问 题。公司量化了非质量成本之后，怀疑生产浪 费即“废品”是最主要原因。 60 n效益太差，找出 “废品” 的根本原因 n鱼骨图: 根本原因的鱼骨图 理解根本原因-问题背后的问题 61 根本原因的帕雷托图 原因数量比例 制造缺陷294.83% 制成品折旧457.50% 订单不准确31752.83 % 用户退货8213.67 % 运输损耗10717.83 % 其他203.34% 合计600100% n帕累托图 1) 确定问题与原因 2) 收集数据 3

28、) 绘制直方图 理解根本原因-问题背后的问题 62 n发现了一条根本原因：“不准确的销售订单” 产生了半数的废品。发现已有的订单系统有一 个不友好的用户界面，没有在线差错处理机制， 那么，开发一个新系统是减少废品的最好办法。 n一旦我们确定不准确的订单是一个值得解决的 根本原因之后，我们就可以生成一个如下表所 示的订单系统问题的称述。 63 销售订单问题陈述表 要素要素描述描述 问题不准确的销售订单 影响 订单操作者、客户、生产者、销售者以及 客户服务 结果 增加废品、额外的处理成本、客户不满意 以及收益低 优点 解决这一问题的新系统有如下优点： n增加了输入点订单的准确性 n增加了销售数据的

29、报告，以便进行管理 n更好的效益 64 用户用户其他风险承担人其他风险承担人 销售订单输入员mis主管以及开发团队 销售订单监督员首席财务官 生成控制人员生成管理人员 票据文员 确定风险承担人和用户 65 n订单系统的简化系统透视 定义解决方案系统的范围 66 确定解决方案的约束条件 销售订单输入系统的约束、约束源及理由销售订单输入系统的约束、约束源及理由 约束源约束源约束约束理由理由 操作性销售订单数据的一份完全备份 必须被保存在已有系统的数据 库中一年的时间 数据丢失的风险太大， 所以我们要并行运行至 少一年的时间 系统及操作 系统 这个应用在服务器上不应该占 用超过20m字节的空间 服务

30、器上可用的存储空 间有限 设备预算系统必须在已有的服务器和主 机上开发；用户使用的新的客 户端硬件可以被提供 成本控制以及已有系统 维护 人员预算固定的人力资源；没有外部资 源 在现有预算下操作成本 固定 技术要求应用新的面向对象的方法相信这种技术的应用会 增加生产率并增加软件 的可靠性 67 3.7 在收集需求信息中应注意的问题在收集需求信息中应注意的问题 1.应能适当的调整收集范围； 2.尽量把用户所持的假设解释清楚，特别是发 生冲突的部分； 3.尽量理解用户用于表达他们需求的思维过程， 特别是尽量熟悉和掌握用户具有的一些专业 知识和术语； 4.在收集需求信息时，应尽量避免受不熟悉细 节的

31、影响； 5.应尽量避免讨论一些具体的解决方案； 6.需求信息收集工作的结束。 68 3.7.1需求获取的策略 n3.7.1.1需求获取应该是主动的需求获取应该是主动的 q强调了需求分析人员在整个过程中应该充分发挥主 动性。 q需求获取是撒网打渔，不是休闲钓鱼。 69 钓鱼模式 vs. 网罗模式 比较钓鱼模式网罗模式 心态 被动，愿者上钩主动，为了生计 目标 没有计划，时间到就结束 访谈是走过场 要抓到足够的鱼 一定要把计划问题问完 地点 找个环境好的地方 没预先计划访谈对象 要找有鱼的地方 选择合适的访谈对象 对象 不管什么鱼，不管大鱼小鱼 宏观、细节一把抓 选择不同密度的网 按访谈对象决定信

32、息层次 70 案例： “小张，你回来了” “唉，是呀！昨天赶晚班机回来的，到家都快两点了！” 小张显得一脸的疲倦。 “那你这次去客户那里了解到了什么情况？客户好像催 你们过去催的很急呀！” 小张面带笑容地回答说：“嗨，他们来了一个新的信息 主管，要和我们聊聊这个系统的规划和想法，也没有什么实 质的东西，就是东拉拉西扯扯的！最大的作用就是混了个脸 熟。” q结论：需求获取活动很低效。 问题关键在于需求分析人员是否善于去把握主动权， 是否能够根据每次访谈的对象制定相应的计划。 71 3.7.1.2需求获取应该是聚焦的需求获取应该是聚焦的 n捕获过程中的问题： q提不出需求 q提的需求太多 n解决方

33、案： 提出聚焦的问题 72 需求获取应该是聚焦的 q案例：老李和小赵是某软件公司的需求分析人员，有一次他 们共同参与了一个设备告警监控平台项目。他俩分别对监控 中心的小徐和小张进行了访谈。 q小赵问监控中心的小张：“你对这个系统有什么需求？” q小张说：“我想到的功能包括值班日志、告警的声光提示、 基于短信的告警通知，还有要为值班人员提供一个日程安排 工具、一个共享文件管理工具，还要能够自动填报各种上级 要的报表”。 q而老李问小徐的问题有很大的区别：当监控中心收到一个告 警的时候，希望以什么形式体现？收到后，你们一般会进行 什么样的处理？在这个过程中需要做什么配套工作？原来处 理时存在什么困

34、难？有哪些问题是比较棘手的？ q小结：案例场景中，小张提问方法导致整个捕获过程发散的， 而老李就能够使整个问题很聚焦，这样产生镀金需求、非重 要需求的可能性大大下降。 73 3.7.1.3破解需求的冰山模型 74 n3.未梦想的需求: q（系统架构师层面，找到最佳的技术解决方案） q用户对技术解决方案永远都不是擅长的，因此他们 无法构想出对其工作产生革新性变化的解决方案。 这就需要通过需求分析人员在对问题域充分利用的 基础上，选择合适的技术方案，才可能创造出用户 未梦想到的功能，成为优秀的需求分析人员 。 q即：善于利用技术为用户创造全新体验是优秀需求 人员的特质。 75 n案例：小宁为一个房

35、产中介公司开发一套信息管理系 统，访谈过程中，房产经纪人代表告诉他：“我以前 是准备了两个本子，一个记录房源信息，一个记录客 源信息，以便查找匹配的机会。但是现在客户多了就 产生问题了，一是记录很麻烦，二是查找很困难。” n小宁心想很简单嘛，创建两张数据库表，一个保存房 源信息，另一个保存客源信息，然后再开发一个数据 查询功能，这样就解决问题了。，于是很肯定的告诉 这位房产经纪人说：“我知道了，没问题！” n这就是意识到的需求，用户能够清晰地表示出来。但 是小宁却没有进一步分析，会产生问题吗？ 76 n当系统开发完成并交付使用之后，没过多久这位房产 经纪人就来找小宁，提出了这样的一个需求：现在

36、系 统提供的是一组查询，我希望改成多组查询。 n“啊！那你直接查询多次不就可以了吗？”小宁不解 地问。 n“不行，那样不方便使用！因为查询结果没有合并在 一起！” n“为什么要把不同次的查询结果合并在一起呢？”小 宁还是想不通。 n这就是无意识需求搞的鬼！小宁不了解这行所以想不 通，实际上这位房产经纪人提出这个需求的原因是客 户对房源的要求是多样化的，他可能需要的是某路段 的两房或另一路段的三房，经常是无法用一组查询条 件将它们结合在一起。而以前在本子上查找，人的脑 子是完全可以记录多组条件的。 77 n接到这个需求后，小宁找到公司的老张，问他： “你说这种需求我们应不应该响应？” n老张给小

37、宁一个建议：“我建议你增加一个记 录销售线索的数据库表，每当新增加一个房源 或客源时，就自动生成响应的销售线索，这样 你就可以告诉他连查询都不需要使用了！” n未梦想的需求 78 3.7.1.4破解阻碍需求捕获的心理现象 n1.言过其实心理 q解决方案 n1）用户言过其实时的表现：表述都非常肯定的语气，十 分流畅。因为此时他只需创造，而不需要回忆。 n2）验证；因为在没有串供的情况下，天下谎言皆不同 q验证有谎言存在时，解决方案 n1 ） 差异展现法： q把不同用户的不同表述展示给中层后，找共识 n2 ）瓶颈分析法 q对流程执行过程中的瓶颈进行分析（如都需经理审批），避 免流程瓶颈导致系统无法

38、顺利运转 79 n案例：有一次，小李在开发一个物资管理系统的时候 就遇到了这样的一个用户。在谈及物资管理的基本单 位时，这位用户说：“我们的设备价值都比较高，看 起来不起眼的东西都动辄几千块，甚至上万块！因此 必须采用按个管理的模式，每个设备都将拥有一个唯 一的id，系统需要能够对其整个生命周期进行跟踪。” n可是当系统实施后，却一直使用不起来。后来才发现， 虽然这些物资、设备的价值不菲，但量却也不少，而 且很多是备件，因此调配很频繁。再加上人手不足， 所以不管是主观还是客观上，都很难做到按个管理。 n小结：用户“言过其实”。无法确定是否真正言过其 实，采用验证手段。例如再找一个相关的用户代表

39、来 进行访谈。 80 n2.越俎代庖心理 q识别正确的被访谈者最为关键 q1）问题的层次是否正确 n高层宏观、中层脉络问题、操作-细节 q2）根据业务背景判断 n3.非正事心理 q解决方案：对访谈进行计划 n4.抗拒心理 q激将法，倾听对方的抱怨是化敌为友的有效手段 n5.推卸责任心里 q让被访谈者介绍工作场景 81 3.7.1.5不要忽视对变更可能的捕获不要忽视对变更可能的捕获 n针对常见变更类型的类型 q变更类型捕获问题流程变化快 n1.你们上次组织结构调整是什么时候？ n2.这个流程以前也是这样的吗？如果不一样，是什么时候 的事呢？ q业务规则变化快 n1.这些规则是来自外部法规，还是内

40、部制定的？ n2.如果是外部法规，这些法规通常几年会更新一次？ n3.如果是内部制定的，那么是由哪个部门制定的？依据什 么进行调整? q用户界面变化大 n1.用户界面设计一般由谁确定？ n2.你们最满意哪个系统的用户界面？ n3.你们最不喜欢哪个系统的用户界面？ 82 3.7.1.6需求协商的要点 n抛开立场，寻找利益 （卖二手车的交易谈判） （需求协商实例） n天下没有荒唐的需求，每个 荒唐的需求背后都有合理的解释。 n只有荒唐的解决方案，没有 荒唐的需求！ n协商的金钥匙“？” 谈判谈判 方方 立场立场利益利益 卖车 人 10000美元买到游 艇 买车 人 80009000美 元 买到车

41、83 3.7.2需求获取的方法 n用户访谈 q有效而直接的用户访谈技巧要求访谈者准备一个问 题列表，目的是了解真实的问题和潜在的解决方案。 n专题讨论会 q专题讨论会可以减少一部分需求冲突，绕开纷繁的 情况得到需求列表，以此作为进一步分析的基础。 n情节串联板 q制作情节串联板就是使用工具向用户说明系统如何 适应组织的需要，并表明系统将如何运转。情节串 联板的类型包括被动式、主动式和交互式，其复杂 度依次递增。 84 3.7.2.1用户访谈用户访谈 n有效而直接的用户访谈技巧要求访谈者准备一 个问题列表，目的是了解真实的问题和潜在的 解决方案。 n为了尽可能获得没有偏见的答案，需要确保提 出的

42、问题与背景无关（context free）。 问题列表 85 n优缺点和访问时机 n用户访谈的类型 n时间安排 n记录工作 n访谈的沟通技巧 用户访谈用户访谈 86 n1.优缺点和使用时机 q优点是直接有效、形式灵活、交流深入的宽带通信 形式（有文字、有声音、有图像）。 q缺点： n占用时间长：通常要访谈的人比较多，语言交流会占用大 量时间。 n信息存在片面性：用户代表经常各执一词，导致收集的信 息无法代表所有用户的想法，从而导致偏差的出现。 n用户访谈是需求获取中的主要技术，只要有可 能，就应该尽可能多地进行用户访谈。 用户访谈用户访谈 87 n2.用户访谈的类型 q根据被访谈者的不同，可以

43、将用户访谈分成不同的 类型；而在需求获取阶段最常见的被仿谈者包括高 层管理人员、中层管理人员、操作层、技术团队4 类。 被访谈者阶段话题中心目标 高层管理人员 需求定义问题/机会探讨系统的目标与范围 中层管理人员 需求捕获阶段一 业务事件理清需求的脉络信息 操作层需求捕获阶段二 业务活动填充需求的细节 技术团队需求捕获解决方案论证解决方案的可行性 用户访谈用户访谈 88 n3.用户访谈的时空安排 q一般建议不超过1小时，否则可以考虑中场休息或安排下一次 面谈。 n时间安排： n地点选择：适当的不受干扰和避免打扰 用户访谈用户访谈 89 n4.用户访谈中的记录工作 q自己做笔记（分神） q专门一

44、同事做笔记（成本高） q录音 （失去身体语言） q录像（难操作） q自己做笔记+录音 用户访谈用户访谈 90 n5.用户访谈中的沟通技巧 q制作访谈问卷并事先发给被访谈者 q把握语言节奏 q有效结合不同的问题类型 q善于安排问题顺序 q注意沟通细节 用户访谈用户访谈 91 n制作访谈问卷并事先发给被访谈者 q在访谈前整理一份访谈计划，罗列出要问的问题，然后 预先发送给被访谈者，以便对方能够更好地做好相关资 料的准备。 q发送访谈计划时，应该记住一个时间原则：2天前，1周 内！ q使问卷表尽可能的简短。通常，一个问卷表包含的问题 不超过10-15个。 q估计回答问题需要的时间。 q确保问题是前后

45、一致的，没有让人含混的理解 q为了保证不会理解含混，让与回答者关系密切的人员来 进行问卷调查，并保证他们对问题的理解是正确的。 q在制订问题前，先确定你需要得到怎样的答案 q分别列出所有可能的答案 q确保所有的需求能被问题覆盖。最后，剔除掉与需求无 关的问题。 用户访谈技巧：基础篇 92 用户访谈技巧:语言篇 n把握语言节奏 语言简单：短兵相接，句式简明短兵相接，句式简明 说话限制在说话限制在2033%以内以内 n问术语含义：你对xx是如何解释的？ 93 用户访谈技巧:语言篇 n有效利用各种问题的特点 q可以使用的问题类型有3种： n封闭式问题（判断题） n半封闭式问题（选择题） n开放式问题

46、（简答题） 94 用户访谈技巧:语言篇 n开放式问题 q被访谈者在回答问题时没有任何限制，答复可能是 两个词，也可能是一段话，因此通常理解为简答题。 q例如：用户提交一个申请后，会进行怎样的处理？ q优点：能够让被访谈者感到更自在、更有兴趣；能 够反馈更丰富的信息；允许更多的自发性；访谈者 也更容易措词。 q缺点：会产生太多不相干的细节；访谈过程可能失 控；回答内容需花费大量时间提取有用信息。 95 用户访谈技巧:语言篇 n封闭式和半封闭式问题 q都属于封闭式问题范畴，给被访谈者一个明确的答 案范畴，让他从几个候选答案中选择一个。 q半封闭式问题是指提供了多个选项。“选择题” q封闭式问题则是

47、两极式问题，例如是或不是、真或 假、同意或不同意。“判断题” q优点：节省时间；容易切中要点；易于对不同被访 者的回答进行比较；可以保持对访谈过程的控制； 在探讨大范围问题时更快速；可以得到更贴切的数 据。 q缺点：容易使被访谈者感到厌烦，无法得到丰富的 细节，易于失去主要思想，不利于双方友好关系的 建立。 96 n三种问题的比较 n访谈中应尽可能采用开放式问题作为主体，而 在开场时、访谈出现僵局时就应该通过封闭式、 半封闭式问题来缓解。 比较项封闭式 半封闭式开放式 信息收集有效性最弱较弱最强 被访谈者回答难度 最简单 较简单较难 对被访谈者诱导性 较容易 容易不会 访谈所需时间节省节省可能

48、会浪费 信息的广度和尝试 较窄较窄较广 97 用户访谈技巧:语言篇（善于安排问题 顺序） n正金字塔探索 倒金字塔聚焦、破局 在库存 管理方面 有问题吗? 这个问题表现在 什么方面? 你认为怎样才能解决这 些问题呢? 请概括一下，你认为怎样才 能使库存管理更加有效 你对新的物资管理系统 有何看法? 它在使用过程中会 遇到什么障碍 你最关心的 障碍有哪些 可用性问 题关注 吗? 98 用户访谈技巧:体态篇（注意沟通细节） n避免出一些干扰访谈的不良暗示： 1）我的时间比你宝贵眼神不聚焦，看表 2）不知道你在说什么、做什么不良打断 暂停时打断 断点恢复 n基本的体态语言 现象内涵 语速极快、描述过

49、程逻辑性强 1. 用户很熟悉 2. 可能是理想化的 语速缓慢、中间有很多的停顿 1. 用户不够熟悉 2. 容易产生变化，需注意 突然改变语气、脸色1. 问题是对方很敏感的 2. 传递的信息有明显的误解 99 用户访谈技巧:体态篇 现象内涵 回答问题时眼珠常向左上方转动 很可能在回忆，信息相对真实 回答问题时眼珠常向右上方转动 很可能在“创造”，真实性待确认 坐姿很随意，诸如翘着二郎腿对访谈内容重视度不高 回答比较强势，甚至有攻击性对信息系统的建设有反对意见或敌意 身体或腿部晃动十分厉害情绪较不安 n有趣的体态语言： n座位里的奥秘： 助手用户 访谈 对抗 100 用户访谈技巧:计划篇 n高层访

50、谈 1） 准备：发现的问题、认为的机会抛砖引玉 2）产物：目标、主要业务范围 n中层访谈 1） 准备：业务事件列表、预构思的管控点列表 2） 产物：流程图、领域类图片段、用例图片段、 细化后的管控点列表，stakeholder关注点 n操作层访谈： 1） 准备：业务活动列表、各类细节问题 2）产物：事件流(上下文)、问题(why)、原始需 求(what) 101 用户调查 n利：面广，能获得更多用户的反馈。 n弊：不够深入，易形而上学。 n时机： 1） 跨地域用户流程级差异 2）大样本用户细节差异 n要点：结合用户访谈技术使用 1） 先访谈，后调查验证访谈结果 2）先调查，后访谈理清方向 n价

51、值：搜索某项假设的统计依据搜索某项假设的统计依据(主主) 获取意见与建议获取意见与建议(次次) 102 用户调查的困难与应对 n相关的问题不能事先决定 先访谈，后调查先访谈，后调查 n问题会对答案会造成偏颇 尽量避免使用简单的判断题尽量避免使用简单的判断题，用选择、排序，用选择、排序 代替代替 n难以继续用户的模糊响应 需求调查应实名制需求调查应实名制 103 调查问卷设计要点 n篇幅与布局 1.由易到难 2.逻辑相关性 3.控制在13页内 n问题类型选择 1.封闭性问题半封闭性问题 2.开放性问题：跟随策略简短 n小技巧： 1.c现象 2.d现象 104 案例： n20世纪可口可乐公司在计划

52、更新可口可乐的配方时做 了一次调查，其中一个问题是： 你喜欢新口味的可口可乐吗？你喜欢新口味的可口可乐吗？ 喜欢喜欢 不喜欢不喜欢 无所谓无所谓 调查结果显示：有百分之九十几的被调查者喜欢，因 此高层就决定停产旧配方，但市场却最终投入反对票！ 问题出在哪呢？当然问题很多，但这个问题的设计就 是原因之一。 这个封闭式的问题诱导了用户，更合适的方法是改成 一个半封闭式问题，使用户的意愿更容易表达出来： 请根据你的喜爱程度对以下饮料进行排序：请根据你的喜爱程度对以下饮料进行排序： 老口味可口可乐老口味可口可乐 新口味可口可乐新口味可口可乐 百事可乐百事可乐 七七 喜喜 美年达美年达 105 用户访谈

53、的五个阶段 n准备访谈 n计划和安排访谈日程 n访谈开始和结束 n引导访谈 n后续的访谈整理工作 106 3.7.2.2专题讨论会专题讨论会 n常见的专题讨论会 n专题讨论会模板 107 需求专题讨论会需求专题讨论会 l需求专题讨论会 项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为1 1 至2 2 天，与会者可以在应用需求上达成共识、对操作过程尽快取得 统一意见。 l优点 协助建立一支高效的团队，围绕项目成功的目标； 所有的风险承担人都畅所欲言； 促进风险承担人和开发团队之间达成共识； 揭露和解决那些妨碍项目成功的行政问题； 能够很快地产生初步的系统定义。 108 需求专题讨论会需

54、求专题讨论会 l专题讨论会准备 参加会议人员：主持人、用户、技术人员、项目组人员 安排日程：通常在具有相应支持设备的专用房间进行 l举行会议 可能出现行政间的责备或冲突，主持人应掌握讨论气氛并 控制会场。 会议最重要的部分是自由讨论阶段，这种技术非常符合专 题讨论会的气氛，并且营造一种创造性的和积极的氛围， 同时可以获得所有相关者的意见。 注意分配会议时间，记录所有言论。 109 110 需求专题讨论会需求专题讨论会 111 3.7.2.3情节串联板 n情节串联板是通常就是一系列图片，通过这些 图片讲故事。一种很生动的技术，它经常被称 为原型法。（强调借助原型来加速需求获取过 程） n情节串联

55、板就是使用工具向用户（主角）说明 （有时是动画演示）系统如何适应组织的需要， 并表明系统将如何运转。 n利：友好、交互性强，以突破用户盲区 n弊：需求捕获速度相当慢 112 情节串联版 n类型：被动式、主动式和交互式。 q其复杂度依次递增 q被动式通常由草图、图片、屏幕截图、幻灯片等组 成。 q主动式试图使用户能够看到类似“电影样片”。可 以自动播放的，描述系统在典型用法和典型场景中 的行为方式。 q交互式让用户能体验系统的行为。系统需要用户的 参与才能继续运行。可以是仿真器、实物模型甚至 是抛弃式原型。 n静态工具：纸和铅笔、白板、即时贴、powerpoint等。 n动态工具：flash、m

56、acromedia director和其他动画 工具。 113 确保以“情节”为线索 n案例： n“这帮用户真是有意思！当时给他展示用户界 面的时候，什么意见也没有，都表示同意！现 在可好，等系统做好了，又提出了一大堆意见， 真不知道他们之前干什么去了”，一位饱受需 求变更之苦的开发人员向他的同事抱怨着。 “唉，这就是程序员的生活”，他的同事的话 里也体现了许多无奈。 n难道真的只是用户的责任么？开发团队是否也 要承担一半的责任呢？ 114 理解“串联”的本质 n串联体现了原型的动态性、交互性，用户不仅 仅关心用户界面的样子，更关心用户界面的流 转过程、交互过程。 n不要只关注于界面的静态效果

57、，交互才是情节 串联板的本质。 115 情节串联板 n情节串联板的复杂程度与成本 116 定义系统 n项目范围涉及三个要素：项目所要提交的功能，项目可用资源， 实现项目可用的时间。 n让客户满意并不意味着就要满足客户所有的需求。 n建立的项目需求基线必须满足：至少对客户来说，是可以接受的； 在开发团队看来，具有合理的成功可能性。 n前景文档获取用户的需要、系统的特性以及项目的其它需求。它 的范围跨越需求金字塔的上两级，在较高的抽象级别上定义问题 和解决方案。 117 项目的范围问题 118 案例：xx体检医院背景资料体检医院背景资料 n背景介绍背景介绍 n企业概括：企业概括： qxx体检医院椒

58、一家只开展体检业务的专业医院，它主要针对 企业/团体、vip客户、散客三类客户提供服务。当前除了有 一套记账用的财务软件之外，还没有任何信息系统。 n问题点：问题点： q经过一段时间的经营，该医院的领导发现在管理上有两个方 面存在很大的问题，希望通过信息系统来解决。 q一方面是预约安排不合理、销售不够高效，因为针对企业/团 体的销售人员没有进行统筹安排，经常会出现一天内安排太 多体检单的情况，而且也经常出现相互抢客户的问题。 q另一方面是物资供应存在脱节的现象，造成这个现象的原因 是物资在使用的过程中没有对存量进行有效管理，当体检科 室发现某类物资不足时，采购部门才开始采购，但很多供应 商是无

59、法马上提供的，这样就产生了一些时间差。 119 组织结构组织结构 n经过第一轮的调查，需求分析人员整理出了它们的 部门设置情况，以下是对各个部门职责的总结： q客服中心：客服中心：负责完成销售工作，为vip和企业/团体客户安 排预约时间，预约时将根据已预约情况进行调整。 q服务中心：服务中心：负责现场的开单工作（如果已经预约则直接领 取体检单即可）、收费（如果企业/团体也统一通过转账付 过费用，则直接盖上“收费已讫”的章）、返回报告（这 是统一的窗口，公司客户的体检单可以由客服中心到此代 领，再寄给客户）。 q体检科室：体检科室：负责完成体检，并记录体检结果（系统上线后 将实现电子化）。 q综

60、合科：综合科：出具诊断报告（根据体检结果给出建议）。 q物资：物资：完成相关物资的采购、申领、仓管工作。 q财务：财务：当企业/团体采用转账形式付费时，则由财务部门负 责收取。 120 n业务范围是关键！ n业务大块事件与管控点 n黑盒思路灰盒思路 定义解决方案系统的范围 121 范围：no.1 确定主题域 122 n划分主题域的原因： q由于利用子系统的划分方法，在进行需求捕获和分 析是就会发现各个子系统和模块与客户部门是交错 在一起的，每个模块都需要对不同的部门进行调研。 它只是一种逻辑划分，并没有很好地把业务结构体 现出来，它只是采用“业务名字+管理”的形式命 名的，其中业务名词实际上就