需求工程第三讲-需求获取

v
v
要点：需要有一个经验丰富、能够把控大局的主 持人。 如何计划并实施需求专题讨论会
§ 专题讨论会准备 § 实施 § 总结
会前有准备
推销概念：充分的准备是会议的关键，要推销需 求专题讨论会的好处 v 确保真正的风险承担人参与 v 后勤保障 v 热身材料：在开会前散发资料 > 项目专有信息：需求文件草案、已排序的特 性… > 摆脱束缚思想的：提供创新方法、自由讨论规 则… > 2天~1周内散发，太早会使人忘记！
需求获取技术-问卷调查
v
当潜在使用者太多或分布太广时，可以考虑采用 问卷调查方式。是面最广的技术。
§ 利：面广，能够获得更多的人的反馈。这点是对用户 访谈技术不足之处的最好补充。 § 弊：不够深入，容易形而上学。而这点是正是用户访 谈技术所能够解决的。
v
一般来说，问卷调查适合于大型企业或公众信息 系统的设计，因为它所涉及的使用范围或对象太 广，需求分析人员无法逐一亲自调查，所以利用 问卷调查方式来收集使用者需求比较好。
v
用户访谈：异常现象
案例练习1：期刊传阅
v
v
v
v
一个约有1000名员工的保险公司订阅了大约50份期刊（杂志、 报刊）。期刊在公司内部传阅，员工可以要求加入传阅队列。目前 的传阅过程是：图书室登记公司收到的期刊，为期刊附上一份传阅 名单，并交给名单中的第一位员工。期刊经由公司内部邮递系统传 递。员工应在三个工作日完成阅读，并在名单上签名及写上日期， 然后交给名单的下一位员工。最后一位员工阅读完毕后，将期刊交 还图书室以便共用。 但是，员工经常忘记已收到期刊，或者未将其传递给名单中的 下一位员工。在一段时间后，无人知道期刊应该在谁手上。整个传 递过程难以记录，员工也往往互相指责健忘、粗心等。 公司的IT部门负责开发内部商业应用，该部门建议一个计算机 管理系统以记录期刊的传阅情况。员工阅读完毕后通知系统，系统 回应下一位阅读者，下一位员工必须确认已收到期刊。系统也应能 在员工忘记传递期刊时发出提醒信息。 管理图书室的人事部门认为这是一个很好的主意。尤其是他们 系统能够根据假期（员工请假两周将无法阅读），以及根据员工是 否守时（能否在三天内将期刊传递给下一位员工），安排传阅名单 的次序。
v
构建需求变更的感应器
流程变化：流程顺序变化，流程细节变化，流程 负责人变化，流程输入变化，流程输出变化。 v 数据变化：数据格式变化、数据规则变化、数据 输出变化、数据项变化 v 业务规则：规则增加、规则减少、规则变化 v 系统表现形式变化：界面、风格、输入形式、 展现方式、访问方法、网络环境 v 目标变化
v
问：怎样获取需求?
答：
用户 开发商 引导
需求采集 需求分析
方法论
《需求规格说明书》 《需求分析建议报告》
需求定义
获取需求定义
1
需求采集
采集什么内容？ § 系统建设目标
从哪里采集？ § 横向：各业务 科室 § 纵向：省、部 标准规范 § 经验：核心平 台、同行业其 他城市、现有 系统
怎么采集？ § 调查问卷 § 座谈 § 考察、培训
用户访谈的类型
用户访谈
一般建议不超过1小时，否则应安排下一次面谈 v 时间安排： > 开场白：陈述理解 5～15 Min > 预先计划问题：主体工作 25～30 Min > 即兴问题：展开性 20～30 Min > 总结：陈述理解 5～10 Min v 地点选择：适当的不受干扰和避免打扰 v 记录：自己做笔记（分神）、专门一同事做笔记 （成本高）、录音 （失去身体语言）/录像（难 操作）à自己做笔记+录音
记录需求理由
v v v v
需求理由是指关于某需求的原因的概要信息 效益：提高对需求的理解 实施 可能存在的问题
§ 使人误解的理由 § 不一致的理由
实际工作的指导原则
针对产品方向建立需求获取问题模板； v 对每个需求问题记录原因和目的； v 在实际工作中不断完善和改进；
v
需求获取前管理准备
需求分析前最好明确系统要采用的技术体 系 v 组织队伍 v 准备相应的文档 v 联系和了解用户方 v 编写计划
v
重点
需求获取的重要性 v 需求获取的策略 v 需求获取前准备 v 需求获取的主要技术 v 需求获取的相关工具
v
需求获取的方法（技术）
访谈（面谈）与问卷调查 v 会议(需求讨论会、重点问题讨论会、业务 专题讨论会、设计专题讨论会） v 文档研究 v 任务示范（观察） v 用例与角色扮演 v 原型设计（小规模试验） v 研究类似公司
难以探索一些新的领域 v 难以继续用户的模糊响应
v
用户调查：问卷设计
v
篇幅与布局 1.由易到难 2.逻辑相关性 3.控制在1~3页内 问题类型选择 1.封闭性问题à半封闭性问题 2.开放性问题：跟随策略＋简短
v
需求获取技术-需求专题讨论会
v
一种适用于任何情景的技术。最理想的技术。
§ 优点：客户、开发人员直接的头脑风暴，是击破需求 盲点的关键手段。 § 缺点：成本高，如果缺乏控制会变成一次闲扯大会。
获取需求准备一-相关人员分析
不同层次的用户需求也截然不同
1
需求采集
2
需求分析
3
需求定义
相关人员分析
v v v
相关人员是指那些直接或间接从开发的系统中受 益的人。 效益：发现所有可能的需求源 识别项目相关人员的方法：
§ 系统潜在的最终用户 § 系统打算支持的业务过程描述以及与这些过程相关的 人 § 与管理部门讨论，询问谁会受到系统引入的影响 § 考虑使用系统的组织的客户 § 负责开发和维护系统的工程师和维护人员 § 考虑可能希望给系统添加需求的监管机构和认证机构
准备二-需求获取应明确的问题
v v v v v v v v v v
当前整体业务需求的目的和可行性陈述 系统或产品范围的限制性陈述 要求提供的需求功能列表和应用于每个需求的领域 限制 将来发展的设想 明确服务器、客户机的软、硬件及性能要求（容量、 速度、可操作性等） 用户目前相关的技术人员和业务人员情况 将来最终系统操作人员的技术及业务人员情况 用户需求的系统及用户本身或其它系统的接口要求 一组使用场景，提供在不同运行条件下系统的使用 情况 为更好地定义需求而开发的任意原型
用户调查
v 要点：结合用户访谈技术使用。
> 先访谈，后调查à用调查验证访谈结果 > 先调查，后访谈à用调查理清方向 v 如何进行问卷调查：设计问卷、预先测试、 调查对象划分、问卷总结等
用户调查：主要用途
v
搜索某项假设的统计依据：设计一些封闭的问 题，例如“从现有系统中取得客户统计资料的难易 程度：非常困难、相当困难、容易、非常容易”
v v v
v
v v
v v
确定需求获取计划和问题清单 确定能够帮助刻画需求和了解他们组织的人员 定义系统将放置其中的技术环境（如计算体系结构、 操作系统、电信需要） 确定“领域约束”（即特定于应用领域的业务环境的特 征），这些约束将限制待建造系统的功能和性能。 定义一种或多种需求获取方法 要求很多人员参与，以使得需求能够从不同的视角进 行定义；确定每个要记录需求的理由。 确定有歧义的需求为原型实现的后选 创建使用场景，以帮助客户/用户更好地确定关键需求
需求获取与分析的两个层次
v
项目中标前
§ 目标：项目应标成功 § 获取的要点：全局性、业务需求和用户需求
v
项目中标后
§ 目标：确定项目范围 § 获取的要点：用户需求、功能需求
需求获取的误区
v 缺乏计划性：随意、走过场，预先没计划 v 缺乏科学性：未从本质入手 v 捕获对象不明确，甚至造成岐义 v 过于迷信现有文档 v 过于迷信“听”到的东西
v
会中有控制
中间休息 迟到 1次自由 廉价攻击
规则：每人先发一张，允许迟到一次 而后向罚款箱投入xx元 目的：保持会议的动向
规则：每人先发一张，允许自由攻击 或批评任何个人或部门，而后 再出现就向罚款箱投入xx元 目的：逗趣并提醒人们注意发言
v
措施：设计文档（相关人员列表和需求原因）
用户群划分
§ 明确各类人员的需求权威
v决策层：系统建设目标、原则，业务流程优化程度 v业务人员:业务的把握、政策的把握、业务流程的把握 v技术人员：数据项描述、性能需求 v操作人员：界面的操作风格、输入输出数据项
决策层 技术人员 业务人员 操作人员
用户群划分
v
需求获取技术-用户访谈
v
用户访谈是最基本、最常见的技术
§ 优点：直接有效、形式灵活、交流深入，应该做为主 要的需求捕获技术（宽带通信、固有灵活性、各类信 息） § 缺点：占用时间长（特别当客户忙时更显示出其不 足）、面窄而容易造成信息的片面性。
v
要点：
§ 首先要有准备：通常包括说明对流程的理解，并征得 客户的意见；预先根据流程中的不明确点设计要询问 的问题，并将客户的反馈记录下来；应留有一些即兴 的空间，根据实际情况应变，以确保信息完善。 § 第二是要有计划性：计划好时间、计划好人员、计划 好策略。
搜索意见、建议：询问与用户访谈类似的开放性 问题，例如“日常工作中的三个最大问题是 什么？”，“你对能够更好地支持日 常工作的IT系统有什么建议”。 v 存在的主要问题
v
用户调查：主要困难
相关的问题不能事先决定 v 误解你的问题，你误解他的回答 v 问题背后的假设对答案会造成偏颇
v
§ 例如：这功能符合你的期望吗？ § 假设：你有期望，所以这是一个有意义的提问
v
构建需求变更的感应器
转换--捕获时的有效策略
需求捕获阶段一
需求捕获阶段二
事件流
⑤
相关需求
界面原型
规则与约束