探索需求

章柏幸,王媛媛,谢攀,杰拉尔德・温伯格,

文学

需求分析 需求 软件工程 温伯格 思维 系统分析 用户体验 项目管理

2004-7-1

清华大学出版社

目录
目录 6 序言 13 第一部分 为共识而谈判 17 1 方法论是不够的 18 1.1 case,cad和灭蟑仪 18 1.2 方法作用于问题 19 1.3 映射及其符号系统 20 1.4 确保每个人都能读懂映射图 21 1.5 需求的映射图并不是需求 21 1.6 提示和变化 22 1.7 小结 24 2 在陈述需求中的含混性 24 2.1 含混性的例子 24 2.1.1 缺少的需求 25 2.1.2 含混的词语 25 2.1.3 无意中引入的假设 25 2.2 含混性的成本 26 2.3 为消除含混性而探索 27 2.3.1 需求的图片 27 2.3.2 需求的模型 28 .2.4 提示和变化 28 2.5 小结 28 3 含混性的来源 29 3.1 实例:收敛设计过程演讲 29 3.2 注意力的测试 30 3.3 聚类启发 31 3.3.1 观察和回忆错误 31 3.3.2 解释错误 32 3.3.3 错误来源的混合 32 3.3.4 人们交互的作用 32 3.4 问题陈述的含混性 33 3.5 提示和变化 35 3.6 小结 35 4 可靠但不真实的直接问题的用法 36 4.1 决策树 36 4.1.1 问题的次序 37 4.1.2 穿越决策树:一个实例 37 4.2 含混性投票的结果 38 4.3 可能会是什么错了? 39 4.4 现实生活比我们想象的要现实 40 4.5 提示和变化 40 4.6 小结 41 第二部分 开始之路 42 5 切入点 43 5.1 一个通用的切入点 43 5.2 不同切入点的通用化 43 5.2.1 来自解决方案的想法 43 5.2.2 来自技术的想法 44 5.2.3 比喻 45 5.2.4 标准 45 5.2.5 实体模型 46 5.2.6 名称 46 5.3 存在性假设 46 5.4 一个升降机的例子 47 5.4.1 命名我们的项目 47 5.5提示和变化 48 5.6 小结 48 6 自由问题 49 6.1 过程的自由问题 49 6.2 自由提问的潜在影响 50 6.3 产品的自由问题 50 6.4 连环问题 51 6.5 自由提问的好处 52 6.6 提示和变化 53 6.7 小结 54 7 找到正确的相关人员 55 7.1 辨别正确的人员 55 7.1.1 客户和使用者 55 7.1.2 为什么要包括使用者? 56 7.1.3 铁路的矛盾 56 7.1.4 产品能够创造用户群 56 7.1.5 失败者是使用者吗? 57 7.2 启发式包含使用者 57 7.2.1 列出可能的用户群 57 7.2.2 修葺使用者清单 59 7.3 参与者 59 7.3.1 谁参与? 60 7.3.2 他们什么时候参与? 61 7.3.3 我们如何得到他们的判断? 61 7.4 为抓获使用者而计划 61 7.5提示和变化 62 7.6 小结 62 8 为每个人准备会议工作 63 8.1 会议:离不开又无法忍受的工具 63 8.1.1 一个可怕而典型的会议 63 8.1.2 为度量而开会 65 8.2 参与和安全 65 8.2.1 建立一个打断机制 66 8.2.2 设置时间限制 66 8.2.3 反对人身攻击和贬低 66 8.2.4 缓解压力 66 8.2.5 承认结束时间,并且按时结束 66 8.2.6 处理相关问题 67 8.2.7 改进规则 67 8.3 不出席会议也感到安全 67 8.3.1 公布一个议程并且坚持它 68 8.3.2 不插手突发模式 68 8.3.3 处理好不相关的人员 68 8.3.4 包含正确的人员 68 8.4 设计你需要的会议 69 8.5 提示和变化 69 8.6 小结 70 9 自始至终降低含混性 70 9.1 利用记忆启发 70 9.2 延伸含混性投票 71 9.3 "玛丽从前有一只小羔羊"启发 71 9.4 详述"玛丽欺骗商人"启发 73 9.5 在星星问题上应用启发 75 9.6 提示和变化 78 9.7 小结 78 第三部分 探索机会 79 10 产生想法的会议 81 10.1 典型的头脑暴风雪 81 10.2 头脑风暴的第一部分 82 10.2.1 不允许批评和责备 82 10.2.2 让你的想象自由飞翔 83 10.2.3 为数量而努力 83 10.2.4 改变和合成想法 83 10.3 头脑风暴的第二部分 83 10.3.1 门限投票法 83 10.3.2 竞选演讲投票法 84 10.3.3 合成想法 84 10.3.4 应用判据 85 10.3.5 打分或者排名系统 85 10.4 有益的提示和变化 85 10.5 总结 85 11 右脑方法 87 11.1 地图工具 87 11.1.1 草图 87 11.1.2 画曲线图 87 11.2 头脑作图 88 11.3 右脑运动 88 11.4 有益的提示和变化 89 11.5 总结 89 12 项目的名称 91 12.1 工作名称,绰号和正式名称 91 12.2 名称的影响 91 12.2.1 一个命名的证明 92 12.2.2 命名完成了什么? 92 12.3 启发式命名方法 93 12.4 有益的提示和变化 94 12.5 总结 94 13 面临冲突时推动进程 95 13.1 处理无关紧要的冲突 95 13.1.1错误的时间,错误的项目 95 13.1.2 个性冲突 96 13.1.3 必不可少的人 96 13.1.4 组内的偏见 96 13.1.5 级别不一样 97 13.2 注意力完全集中的技巧 97 13.3 处理本质的冲突 98 13.3.1 重塑个性差异 98 13.3.2 协商 99 13.3.3 处理政治冲突 99 13.4 有益的提示和变化 100 13.5 总结 100 第四部分 明确期望 102 14 功能 103 14.1 定义功能 103 14.1.1 存在功能 103 14.1.2 测试功能 103 14.2 记录所有且唯一的功能 104 14.2.1 记录所有潜在的功能 104 14.2.2 理解明显的、隐藏的以及装饰性的功能 105 14.2.3 识别未注意到的功能 106 14.2.4 避免隐含的解决方案 107 14.2.5 "如果你能够就实现它"列表 107 14.3 有益的提示和变化 108 14.4 总结 108 15 属性 110 15.1 属性的愿望列表 110 15.2 改变愿望列表 111 15.2.1 区分属性和属性细节 111 15.2.2 揭示属性的含混性 111 15.2.3 组织列表 112 15.2.4 从改变后的列表揭示内幕 112 15.3 为功能分配属性 113 15.3.1 属性如何修改功能 113 15.3.2 从新格式中获取内幕 113 15.4 去掉属性 113 15.4.1 将属性分类为必须,需要和忽略 113 15.4.2 隐式和显式地排除属性 114 15.5 有益的提示和变化 114 15.6 总结 115 16 约束条件 116 16.1 定义约束 116 16.2 考虑作为边界的约束 116 16.3 测试约束 118 16.3.1 过于严格? 118 16.3.2 不够严格? 118 16.3.3 不清楚吗? 119 16.3.4 产生新的想法 119 16.4 相互关联的约束 119 16.5过度约束 120 16.6 心理约束 120 16.6.1 倾斜观念 121 16.6.2 打破约束 121 16.6.3 自负与糟糕设计的循环 122 16.7 约束产生自由 122 16.7.1 标准 122 16.7.2 语言和其他工具 122 16.8 有益的提示和改变 123 16.9 总结 124 17 优先级 125 17.1定义优先级 125 17.1.1一个例子 126 17.1.2 优先级的来源 126 17.2 让优先级可量化 126 17.2.1 针对度量的合理方法 126 17.2.2让优先级可量化 127 17.3 区别约束和优先级 127 17.3.1 满足进度是约束吗? 127 17.4 受到约束的优先级 128 17.4.1 它值什么图(what's-it-worth?graphs) 129 17.4.2 什么时候你需要它图(when-do-you-need-it?graph) 129 17.5 重新将约束定制为优先级 130 17.5.1 在优先级之间交易 130 17.5.2 产品开发的决定律 131 17.6 有益的提示和变化 132 17.7 总结 132 18 期望 134 18.1 限制期望的原因 134 18.1.1 人们不是完美的 134 18.1.2 人们并不都是有逻辑的 134 18.1.3 人们对事情的感受不一样 135 18.1.4 设计者也是人 135 18.2 采用期望限制过程 136 18.2.1 产生专门的期望列表 136 18.2.2 电梯的例子 136 18.2.3 产生期望列表 137 18.2.4 限制期望 138 18.3 限制条件不必被限制 138 18.3.1 轮椅的例子 138 18.3.2 让可能性保持公开 139 18.3.3 包括限制的来源 139 18.4 有益的提示和变化 139 18.5 总结 140 第四部分 极大地增加成功的可能 141 19 含混性度量 142 19.1 测量含混性 142 19.1.1 使用含混性投票 142 19.1.2 使用投票方法 143 19.1.3 在不同的基础上投票 143 19.2 将度量作为测试 143 19.2.1 度量三类含混性 143 19.2.2 解释结果 144 19.2.3 通过聚类得来信息 144 19.2.4 选择被投票的人群 144 19.3 有益的提示和变化 145 19.4 总结 145 20 技术评论 146 20.1 一个走过场的例子 146 20.2 技术评论的角色 148 20.2.1 正式和非正式的评论 148 20.2.2 技术评论与项目评论 148 20.3 评论报告 149 20.3.1 评论报告所需的东西 149 20.3.2 创造问题列表 150 20.3.3 技术评论总结报告 150 20.4 评论的主要类型 151 20.4.1 香草评论 151 20.4.2 检查 152 20.4.3 预演 152 20.4.4 联名声明评论 152 20.5 真实与理想的评论 152 20.6有益的变化和提示 153 20.7 总结 153 21 衡量满意度 154 21.1 创建用户满意度测试 154 21.1.1 测试属性 154 21.1.2 为每个项目采取的客户测试 154 21.2 使用测试 155 21.2.1 好处 155 21.2.2 绘制改变和趋势 156 21.2.3 解释评论 156 21.2.4 感觉就是事实 156 21.3 测试的其他用处 157 21.3.1 交流工具 157 21.3.2 贯穿项目的持续作用 158 21.3.3 对设计者的用处 158 21.4 其他测试 158 21.4.1 原型作为满意度测试 158 21.5 有益的提示和变化 159 21.6 总结 160 22 测试用例 160 22.1 黑箱测试 160 22.1.1 外部与内部的知识 160 22.1.2 构建黑箱测试用例 161 22.1.3 测试这些测试用例 162 22.2 应用测试用例 162 22.2.1 示例 162 22.2.2 反复测试和回答 163 22.2.3 清晰地指明含混性 164 22.3 以测试用例为证 164 22.4 有益的提示和变化 165 22.5 总结 166 23 学习已存在的产品 166 23.1 把现存产品当作标准来使用 166 23.2 访谈 167 23.2.1 新产品中有什么不见了? 167 23.2.2 为什么不见了? 167 23.2.3 在旧产品中遗漏了什么? 168 23.2.4 在旧需求中遗漏了什么? 168 23.3 用特征代替功能 169 23.4 有用的提示和变化 170 23.5 小结 170 24 达成协议 171 24.1 决策从哪里来 171 24.1.1 选择,假设和强迫接受 171 24.1.2 电梯设计决策的例子 171 24.1.3 撰写可追溯的需求 172 24.2 错误假设从哪里来 173 24.2.1 有效信息的缺乏 173 24.2.2 超时失效 173 24.2.3 收费公路效应 173 24.2.4 需求渗漏 174 24.3 把决策转化为协议 174 24.4 有用的提示和变化 174 24.5 小结 175 25 结束 175 25.1 对结束的害怕 176 25.2 结束一切的勇气 176 25.2.1 自动化设计和开发 176 25.2.2 堆土窑方式 176 25.2.3 冻结需求 177 25.2.4 重新谈判过程 177 25.2.5 对做出清晰假设的害怕 177 25.3 不够格的勇气 178 25.4 有用的提示和变化 178 25.5 小结 179 参考文献 179 索引表 179
【展开】
内容简介
本书将与您一起寻找"什么是客户真正想要的"这一问题的答案。 本书着眼于系统设计之前的需求过程,它是整个开发过程(如何设计人们想要的产品和系统)中最有挑战性的那部分。通过对一些需求分析中的常见误区和问题的分析和讨论,从和客户沟通开始,深入研究一些可能的需求,澄清用户和开发者期望值,最终给出了能够大幅度提高项目成功几率的一些建议方法。 本书由该领域内公认的两位作者合著,搜集了他们在大大小小的公司里加起来超过60年的在工作中发现、提炼和检验之后的观点。在本书中描述的原则并不局限于软件开发,还涉及到所有需要为别人设计和制作产品的领域。这些技巧已经成功的应用于开发所有类型的产品和系统--包括计算机硬件和软件、家具、建筑和书籍等等。 本书认为,开发是把人们的期望转化成一种能够满足其期望的产品的过程。本书的讨论围绕着需求过程--在开发中人们试图发现其期望的产品--的那一部分。通过对五个关键词语"期望"、"产品"、"人们"、"试图"和"发现"的层层分析,给出了大量使用的技巧和观点。 产品开发项目可能失败的原因非常多,最糟糕的莫过于在需求过程带入的缺陷。目前已有了很多书籍来阐述避免那些缺陷的方法,而本书则是集中在需求过程的以下三个危险而又被忽视的人性视角: 1. 在所有参与者中开发一种对需求的可靠的理解。 2. 开发一种项目的团队工作期望。 3. 开发一些必要的技巧和工具以能够有效的像团队一样来定义需求。 由于这些主题或多或少有些被有关系统开发的著作所忽略,《探索需求》可以用作对你当前的任何需求过程的一个补充,而不管其是否正式。本书的很多章节都设计成独立的模块,每一个都介绍了一到几种用于提高需求技术的工具或方法。读者可以逐页阅读本书,也可以在任何时间只读那些你最需要的章节。 全书通俗易懂、层次分明,其中共有上百幅插图,便于读者深入理解,是需求分析人员的入门和提高必备指南。
【展开】
下载说明

1、追日是作者栎年创作的原创作品,下载链接均为网友上传的的网盘链接!

2、相识电子书提供优质免费的txt、pdf等下载链接,所有电子书均为完整版!

下载链接
热门评论
  • 郭子毅_JOE的评论
    对自我的认知和对未知世界的探索,是我们成长这个需求的不竭动力。[拳头][拳头][拳头]
  • 中国永州新闻网的评论
    【胡颖:农村电商发展可推广永州经验】随着经济发展进入新常态,进一步开拓市场动力已成为越来越突出的问题。在出口需求增长乏力的严峻形势下,借助“互联网+”大力发展农村电子商务,加快农村流通体系创新便是一种新的路径探索。近年来,湖南农村电子商务发展突飞猛进,不仅解决了部分农产品滞销、农
  • 广西融水法院的评论
    近年来,为努力提高司法为民服务,不断满足山区群众日益增长的司法需求,融水法院积极探索青年干警队伍建设机制,择优选拔青年干警,进一步提升青年干警的司法能力,让青年干警在审判实践中形成学、赶、超的良好氛围。
  • 穿了谁的帮的评论
    突出系统性改革,围绕发展主题,切合发展实际,注重改革系统集成,增强改革的整体性、协同性;突出专题性改革,紧扣重点,把握次序,聚焦顽瘴痼疾,加大攻坚力度,提高改革方案含金量;突出探索性改革,坚持问题导向、需求导向,打通改革“最后一公里”,最终惠及人民生活。
  • 章文的blog的评论
    一切都顺其自然,何必执拗!无论是真理还是享受,有什么条件做什么事!做责任小的,轻松!做责任大的,激励!探索真理,为行业和社会服务!不需要就不服务!总是要把自己与社会需求结合起来才合适!关于人与人,只要不要超越正常的在意,没有谁是不和的!大不了,不认同的部分不参与!谁有义务一定要完善别人?
  • 中国社工简报的评论
    【实务 | 灾害应急服务,来自上海社工的经验与反思】近年来,上海探索在灾害应急服务中引入社会工作,坚持以受灾对象的专业化、人性化需求为导向,运用专业方法开展心理慰藉、社区融合等专业服务,取得了较好效果。 实务 | 灾害应急服...
  • 室内设计本的评论
    [欧式] 维塔空间设计-古典主义的实践设计公司:维塔空间设计主 设 计:朱俊翔项目地点:鸿威海怡湾项目面积:160平方完成时间:2016年5月本案例坐落于深圳蛇口高端住宅区,设计师选择优雅法式风格作为设计的原点,追求奢华浪漫的审美趣味,在设计中,设计师探索对应精神认同层面的需求和设计本身
  • 美美de梦想的评论
    有效处理冲突的秘诀:   第一个步骤:觉察表面立场。 各自偏好的满足需求的方案。要知道自己坚持的解决方案只是许多解决问题的方法之一。   第二个步骤:探索深层需求★即了解表面立场底下必须被满足的需求。   第三个步骤:并肩作战,合力寻求双赢的解决办法。
  • 安安丶2013的评论
    独居生活使人们可以在适宜的时间,以自己的方式做自己想做的事情。可以从家庭以及婚姻伴侣的需求和限制中解放出来,将注意力集中于自身,并有机会探索并认知自身生命的意义与目的。『独身,恰恰是一种新型社交方式』独身,恰恰是一种新型...
  • Ly_百度文库的评论
    然后,负责人首先带领我们参观“南方农业”,刚好该公司的经理接待了我们。他指出,互联网是一个快销的平台,而农产品是有时令季节性的慢销产物。让互联网带动农产品的发展明显存在一个延迟。在市场中探索了解市场的需求和饱和度,根据因地制宜清远可以四季生产柠檬的优势,控制果园的柠檬生产质量。