探索需求pdf完整版是一个提供产品设计的电子书。为读者朋友们提供了关于设计学基础理论教程知识。主要从计算机软件设计、建筑设计以及家具设计等方面进行讲解。感兴趣的用户欢迎来绿色资源网下载。
图书内容介绍《探索需求-设计前的质量》是清华大学出版社出版的图书，作者是杰拉尔德。温伯格。目录本书着眼于系统设计之前的需求过程，它是整个开发过程（如何设计人们想要的产品和系统）中最有挑战性的那部分。通过对一些需求分析中的常见误区和问题的分析和讨论，从和客户沟通开始，深入研究一些可能的需求，澄清用户和开发者期望值，最终给出了能够大幅度提高项目成功几率的一些建议方法。
本书由该领域内公认的两位作者合着，搜集了他们在大大小小的公司里加起来超过60年的在工作中发现、提炼和检验之后的观点。在本书中描述的原则并不局限于软件开发，还涉及到所有需要为别人设计和制作产品的领域。这些技巧已经成功的应用于开发所有类型的产品和系统--包括计算机硬件和软件、家具、建筑和书籍等等。
探索需求pdf电子图书目录序言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