软件工程软件工程软件工程 (33).pdf

《软件工程软件工程软件工程 (33).pdf》由会员分享，可在线阅读，更多相关《软件工程软件工程软件工程 (33).pdf（31页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、1 需求获取过程中，最困难的不是记录用户需求，而是与用户探讨磋商，发现真正要解决的问题，确定适用的方案。Steve McConnell需求获取需求获取 需求获取技术需求获取技术 面谈 一样的地点，一样的时间 少量人参与，分析师驱动 问卷调查 不同的时间，不同的地点 很多人参与，分析师观察 群体诱导技术 相同或不同的地点，同样的时间 20人左右，分析师参与 参与调查法 同样的时间，同样的地点 分析师参与2 文档分析 头脑风暴 情景分析 原型化方法 建模方法 需求讨论会面谈面谈 问问题，听答案什么时候面谈?可以见到干系人 很少的人了解很多内容的时候 真正的专家存在的时候 干系人不能被聚到一起的时候

2、 问题不依赖交互来得到最后解答时 Gause&Weinberg,Exploring Requirements,Dorset House,1989.3 面谈面谈 类型 有组织的面谈通常事先制定议程，问题可以是开放的 自由面谈则无既定议程 面谈的优点 可以获得大量丰富的数据 有助于发现观点、感受、目标及事实 可以进行深入探讨，根据面谈前一阶段获知的内容调整后续的问题 面谈的缺点 大量的数据是定性的，难以分析 难于对问题的回答者进行比较 面谈技巧难于掌握4 面谈技巧面谈技巧 面谈开始 面谈开始时，谈一些比较轻松，不太敏感的话题天气，体育比赛、就受访者的照片、办公桌陈设发表感叹 询问受访者是否同意录音

3、 将录音笔放在受访者面前，提醒他们可在任何时候关掉 先问比较容易回答的问题 如个人信息：“您在这儿工作多久了?”根据对方提出的某些线索继续提问 关注用户说的能暗示你的方案可能错误的时候“您可以就此多谈谈吗?”将自由发挥性质的问题放在最后“您还有什么想补充的吗?”5 基于访谈的用户需求获取过程基于访谈的用户需求获取过程6 避免一组固定的问题 优先关注用户行为背后的原因 避免让用户成为设计师 避免讨论技术细节 避免诱导性问题 鼓励讲故事 访谈中注意！问卷调查问卷调查 F Fowler,Survey Research Methods,Sage,1993.owler,Survey Research M

4、ethods,Sage,1993.预先定义的问题面对广泛涉众的时候使用统计分析的结果看起来更科学什么时候使用问卷调查?大基数的被访者 需要关于良好定义的特定问题的答案 验证有限次面谈得出的结论 当你需要一个特定的结果的时候 J7 Use a Ques(onnaire Prepare interview ques0ons in advance Ask open-ended ques0ons Ask essen0al ques0ons What?Why?When?Who?How?Where?问卷调查问卷调查 优点 可快速获得大量反馈 可以远程执行 可搜集关于态度、信念及特性的信息缺点 简单的分类导

5、致对上下文的考虑较少 留给用户自由表达其需要的空间较小8 问卷调查注意事项 选择样本时可能存在偏见 自愿的问卷回答者可能存在偏见 样本规模太小 自由发挥问题难于分析 对答案有诱导性的提问 问题的妥当性 含糊的问题 问卷调查需要原型化和测试 群体诱导技术群体诱导技术 在同一个房间中聚集3-20个干系人 每个人都将自己的观点大声说出来 群体的答案往往比个体好 什么时候采用群体诱导技术?当很多人各自知道关于整体的一小部分时 当人们需要彼此交互来得到一个最优的答案时 当你能把人们聚在一起时 需要匿名？采用一些工具 在不同的地方？采用一些工具最好的资源:Gottesdeiner,Requirements

6、 by Collaboration,Addison-Wesley,2000.9 群体诱导技术群体诱导技术 类型:专题小组会议 头脑风暴 优点 人们的交互比正式的面谈来的自然 可以抛砖引玉（运用实体模型、情节串联板）缺点 分组不一定自然（可能会令某些参与者不适应）少数服从多数所带来的危险 可能对技术问题仅给出表面化的回答 需要训练有素的协调人 注意事项 样本偏见 统治与屈从10 由几个人控制时 引导者角色 5分钟规定时段陈述 一些人缺少参与 引导者角色 “好主意”券 无理的参与者 “恶意中伤”券 需求研讨会需求研讨会 目标 介绍项目成员和干系人 收集需求列表 在会议过程中，运用头脑风暴、故事板、

7、角色扮演、现有系统评估等方法获取需求 指导原则 主持人组织研讨:给每个人发言的机会 保持研讨话题的相关性 定义需求属性 记录需求发现 总结并作出结论会议会议 用于总结成果或取得反馈 在每个阶段结束时与干系人安排会议 讨论信息搜集阶段的结果 对需求做出结论 对某项设计取得一致意见 通过会议来确认所获得的信息，讨论新的发现 会议是重要的管理手段 用于推进系统开发项目的进展 需首先确定会议的目标 需对会议进行仔细筹划12 会议会议 会议是重要的管理手段 需首先确定会议的目标例如：陈述介绍、解决问题、协调矛盾、项目进展分析、搜集和汇总数据、培训、计划 需对会议进行仔细筹划 日程及设施安排 确定日程并提

8、前通知 根据会议目的决定会议形式 会议期间控制进度和程序进展 对会议进行书面总结，并分发给与会者 正式的陈述报告、项目预演及头脑风暴应遵循一定的规则13 头脑风暴头脑风暴 目标 通过群组效应，激发对新产品和系统的新想法 在需求不完全明确的情况下比较有用 指导方针 采用有组织的研讨会形式 百花齐放，不评价、不争论、不批评 不受现实可行性限制 新观点多多益善 抛砖引玉 互相启发Broad ideas may yield good requirements or result in requirements creep Set expecta;ons for par;cipants IDEA GEN

9、ERATION 参与观察法参与观察法 分析师观察干系人进行日常工作 分析师越被动越好 观察影响观察到结果 观察参与者时，进行“动作研究”什么时候观察?当有人或事需要观察的时候 当知识无以言表的时候最好的资源:Goguen&Jirotka,Requirements Engineering:Social and Technical Issues,Academic Press,1994.15 参与观察法参与观察法 方法 纵深调查：观察者参与被观察对象日常活动，成为组织中的一员 优点 总是上下文相关的 能够发现其它方法无法发现的细节 缺点 时间成本和开销很大 获取过于丰富的细节，难于分析 无法就改进建

10、议所带来的结果给出更多评论 注意事项 有被同化的危险16 亲身实践亲身实践 目标 通过观察和提问了解工作内容 实时实地开展工作 立即反馈 指导原则 用户太忙无法安排专门时间来参加面谈 人们并没有意识到在做什么 反复观看一个任务的执行过程 学习任务技能并作给用户看 与用户或顾客建立密切联系NotesBusiness Event1.Performed2.Distributed3.“Nobody can talk be=er about what they do,and why they do it,than they can while in the middle of doing it.”Bey

11、er and Holtzbla=文档分析文档分析 目标 理解待解决的问题 作为下一步业务流程建模和访谈的基础 指导方针 确定当前业务流程或产品的优缺点 找出产品或信息中可充用的部分 从多个来源获取用户需求Documents Request for Proposal Statement of Work Contract/Task Order Proposal Standards Other Documents 原型、仿真原型、仿真 目标 明确含糊、不确定的需求 简化需求文档，确认需求 尽早获得最终用户和客户的反馈 指导方针 用于确认需求 用于提供需求评估的数据基础 用于评估不同的用户界面方案 帮

12、助用户可视化关键的功能 直观、有效的沟通工具Header Footer Title LOGO Ar A picture says a thousand words!情景分析情景分析 目标 清楚定义有用户参与完成的业务事件的步骤 获取用户可见的动作 指导原则 确定与用户间可能的交互：业务事件、感兴趣的领域性质 将业务事件细化为具体业务活动和业务过程And then I.概念建模概念建模 目标 用图形描述现实 建立未来系统模型，即未来系统的抽象表示 在建模过程中对原始需求进行评估、扩展 清楚、完整、正确、一致的描述 指导原则 模型类型 分解 数据 面向对象 用例 过程 活动竞争性需求分析 Need

13、Need（需求（需求）现在市场上未被满足但又急需满足的客户需求是什么？ApproachApproach（方法（方法）要满足这种需求，我能够提出什么独特的方法吗？Benefits Benefits（收益（收益）该方法给顾客提供的便利是什么？Competition(Competition(竞争竞争)对于竞争对手和其他可选择的方案来说，这种单位成本收益的优势在哪里？D Deliveryelivery (推广推广)产品研发完成后的交付与推广方案？22 A/A/B测试B测试 确定待试验的两种UI 确定衡量标准 确定数据搜集流程 确定试验运行时间 确定人数（5-10%的用户）A/B测试的技术实现 搜集数据

14、 分析数据 作出结论23 用户行为数据在线采集 n用户操作数据采集交互过程数据、眼动数据、页面访问时间、访问内容数据、用户偏好数据等n操作数据统计厂商、版本、IP地址、日访问量、地域信息、访问频次、用户身份、访问时长、打分等获取获取技术选择技术选择 建立完整精确的模型很难 建立完整的原型也不现实 要根据需要和客观条件灵活运用原型、情景与建模 参与观察、亲身实践、面谈和情景 业务逻辑 界面 信息 面谈、现有系统分析 注意事项注意事项RequirementsRequirements ElicitationElicitation用户需求获取用户需求获取是一门倾听的艺术是一门倾听的艺术 倾听干系人的艺

15、术 引导干系人的艺术，使得干系人的回答给出有价值的信息 协助和鼓励干系人表述他们需求的艺术27 什么是“足够好什么是“足够好”的需求管理的需求管理 什么是“足够多”的人寿保险?足够多，所以你晚上可以睡得很安心，即使你不在了你关心的人也能得到很好的照顾 但还没有太多，以致你因为担心保险支付的问题而无法入睡 什么是“足够好”的需求管理？足够好，所以你能让客户满意 但还没有超过一定限度，以致项目延期或超支28 比谁更聪明比谁更聪明？29 不要尝试向干系人证明你是聪明的 抓住所有的机会表现你认为干系人是聪明的 对比这两种情况 我的电梯太慢了 好的，告诉我为什么你觉得电梯慢？我不这么认为，我觉得你的电梯有吞吐量问题，不是速度问题 维护术语表维护术语表 经验表明很大一部分需求沟通错误是由术语表达存在歧义造成的。确定术语表 问这样的问题“X的含义是？”记录所有取得共识的术语定义30 采用合适的需求获取技术采用合适的需求获取技术 只采用一种获取技术是不够的获取技术的选择与项目参与人相关与待理解的需求相关与具体应用领域相关31