具体描述
本书由资深IT专家亲笔撰写，详细讲解了情境驱动设计。
全书共三部分，13章。
第一部分（第1～4章）引出了情境驱动设计及设计的体系，以及这种设计方式与现有设计方式的异同。
第二部分（第5～11章）详细讲解了应用程序的设计，如何设计需求，如何确保应用程序与其他程序及数据库协同运作，用户界面的设计与易用性，数据库设计，以及技术设计的原则与结构。
第三部分（第12～13章）是本书的收尾部分，其中第12章讲解了程序设计中的安全问题，第13章总结了前面各章的重点，并展望了应用程序开发的趋势。
作者简介
克里斯·布里顿（Chris Britton），IT专家，曾就职于Unisys公司，从事过系统软件设计、大型数据库系统修复、营销支持、IT架构及管理等多种事务，并撰写了《IT Architecture and Middleware: Strategies for Building Large, Scalable Systems》一书。他于2001年离开Unisys，在自己的公司里做咨询工作并开发软件应用程序。
目录信息
译者序
前言
第1章 情境驱动设计入门1
1.1 对需求进行设计1
1.2 什么是设计7
1.2.1 专项的设计9
1.2.2 有计划的设计10
1.2.3 工程化的设计11
1.2.4 设计方法小结13
1.3 像工程学那样来开发IT应用程序14
1.4 重视IT架构14
1.5 小结15
第2章 设计体系16
2.1 为什么应该建立设计体系16
2.2 情境设计19
2.2.1 任务19
2.2.2 用户组21
2.2.3 数据表21
2.2.4 任务之间的消息21
2.2.5 任务之间的依赖关系22
2.2.6 把所有元素统合起来23
2.2.7 对情境设计做分析24
2.3 集成设计25
2.4 技术设计29
2.5 用户界面设计31
2.6 数据库设计32
2.7 实现33
2.8 这样做真的是工程化的设计吗34
2.9 小结37
第3章 复用现有的方法及做法38
3.1 敏捷38
3.1.1 个体与交互胜过流程与工具39
3.1.2 可行的软件胜过繁杂的文档40
3.1.3 客户协作胜过合同谈判41
3.1.4 响应变化胜过遵循计划42
3.1.5 小结43
3.2 逆向设计43
3.3 用例45
3.3.1 原子性45
3.3.2 设计层次不明确46
3.3.3 用例本身比较模糊47
3.3.4 大型的用例文档难以理解48
3.3.5 用例对工程化的设计起不到帮助作用48
3.3.6 小结49
3.4 成本估算问题49
3.5 BDUF为什么如此笨重52
3.6 迭代53
3.7 品质54
3.8 测试与检验55
3.9 把现有的做法运用到情境驱动设计之中56
3.10 学习型的组织57
3.11 小结58
第4章 大型应用程序所面临的问题60
4.1 应用程序的大小体现在多个维度上61
4.2 大型项目所面临的问题63
4.2.1 需求问题64
4.2.2 缺乏终端用户的支持65
4.2.3 技术设计有问题67
4.2.4 采购与外包69
4.3 能够避免大型的项目吗72
4.4 小结75
第5章 应用程序与业务的关系76
5.1 理解业务流程76
5.2 不能表示为流程的应该怎么办80
5.2.1 业务服务81
5.2.2 资源管理81
5.2.3 评审与监测82
5.3 用更广阔的视角来观察83
5.4 将商业策略运用到应用程序的开发中85
5.4.1 开发速度85
5.4.2 在成本、性能、可用性之间权衡86
5.4.3 试验性的商业计划86
5.4.4 利益要等多久才能变现86
5.4.5 安全需求86
5.4.6 针对现有的企业文化来做设计86
5.4.7 为公司所追求的文化气氛而做设计87
5.4.8 为计划的变更留出余地87
5.4.9 为打造学习型的组织提供支持88
5.4.10 非商务型的应用程序88
5.5 分析88
5.5.1 流程的格式是否正确88
5.5.2 对依赖关系进行分析89
5.5.3 目标分析91
5.6 小结92
第6章 应用程序与用户的关系93
6.1 添加详情93
6.1.1 任务细节94
6.1.2 任务片段97
6.1.3 共同目标组98
6.1.4 数据表98
6.1.5 消息99
6.1.6 非功能型的需求100
6.1.7 使用情境设计的人101
6.2 确定各类用户102
6.2.1 办理业务流程的用户103
6.2.2 对工作进行监控的管理型用户103
6.2.3 使用本程序数据的其他应用程序的用户106
6.2.4 执行数据分析的用户107
6.2.5 执行应用程序管理工作的用户108
6.3 对情境设计进行分析109
6.3.1 流程层面的分析109
6.3.2 任务细节分析110
6.3.3 数据表详情分析111
6.3.4 用户组详情分析112
6.3.5 消息详情分析112
6.4 对情境设计进行评审112
6.5 小结114
第7章 应用程序与其他IT项目的关系115
7.1 集成设计116
7.1.1 应用程序116
7.1.2 服务117
7.1.3 数据库119
7.2 服务接口设计122
7.2.1 定义服务接口123
7.2.2 设计可复用的服务127
7.3 现有的应用程序128
7.3.1 确定现有的应用程序128
7.3.2 替换现有的应用程序130
7.3.3 用现有的应用程序来制作服务133
7.4 回顾设计流程134
7.5 小结135
第8章 用户界面设计与易用性137
8.1 逻辑用户界面138
8.2 把任务描述转化为单击操作141
8.3 易用性145
8.3.1 功能146
8.3.2 信息147
8.3.3 导航147
8.3.4 文本148
8.3.5 帮助148
8.3.6 直观而亲切的应用程序149
8.3.7 针对易用性进行设计150
8.3.8 监测易用性152
8.4 事务与任务完整性152
8.5 用户界面设计与其他细节设计之间的关系155
8.6 小结155
第9章 数据库设计157
9.1 数据库设计157
9.2 数据库设计理论163
9.3 程序员与数据库设计者之间的关系170
9.4 数据访问服务172
9.5 NoSQL173
9.6 小结177
第10章 技术设计的原则178
10.1 单服务器环境下的高性能原则178
10.1.1 缓存179
10.1.2 多线程与多元处理181
10.2 多服务器环境下的高性能原则184
10.2.1 前端并行184
10.2.2 后端并行187
10.3 高弹性原则190
10.4 测试与性能评估的必要性192
10.5 技术设计的流程193
10.6 小结196
第11章 技术设计的结构197
11.1 程序结构197
11.2 什么是框架201
11.3 各种编程语言203
11.4 选择编程语言及框架207
11.4.1 选择与公司的技能组合相匹配的语言207
11.4.2 选择可以满足应用程序性能目标的语言208
11.4.3 选择可以满足集成需求的语言208
11.4.4 如果需要进行小组合作，请选择有利于小组合作的语言208
11.4.5 在选择编程语言的同时，选择相应的版本控制软件及项目管理软件209
11.4.6 选择与自己的开发方法相协调的语言209
11.5 对框架进行扩展210
11.6 实现通用的功能212
11.7 小结213
第12章 安全设计215
12.1 IT应用程序的安全原则216
12.1.1 认证217
12.1.2 访问控制218
12.1.3 用户管理219
12.1.4 安全保护219
12.1.5 安全监控221
12.2 每一种设计之中的安全因素222
12.2.1 情境设计222
12.2.2 集成设计225
12.2.3 用户界面设计226
12.2.4 数据库设计226
12.2.5 技术设计227
12.3 安全编程228
12.4 小结231
第13章 应用程序开发展望234
13.1 情境驱动设计如何改变应用程序开发234
13.2 情境驱动设计的机遇235
13.2.1 新工具236
13.2.2 情境设计与驱动设计237
13.2.3 用户界面设计与数据库设计238
13.2.4 技术设计238
13.3 应用程序开发所面对的挑战240
13.3.1 灵活性240
13.3.2 运营242
13.3.3 正确性242
13.3.4 品质243
13.3.5 职业精神244
13.4 小结245
附录A 情境设计核对表246
参考资料251
· · · · · · (收起)
读后感
上周说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。 今天和大家分享第二本《需求设计》。 如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。 如果运用得当的话，我们...
上周说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。 今天和大家分享第二本《需求设计》。 如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。 如果运用得当的话，我们...
上周说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。 今天和大家分享第二本《需求设计》。 如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。 如果运用得当的话，我们...
上周说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。 今天和大家分享第二本《需求设计》。 如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。 如果运用得当的话，我们...
上周说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。 今天和大家分享第二本《需求设计》。 如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。 如果运用得当的话，我们...
用户评价
这本书带给我的最大困惑是，它对于“创新性需求”的探索和引导似乎远远不够。我是一个喜欢挑战现有模式，总想在产品或服务中注入一些独特想法的人。所以我特别希望找到一本能够启发我如何发现和定义那些“别人没有想到的”需求的书。读了这本书，我发现它更多的是在讲如何规范化、标准化地处理“已知的”或者“显而易见的”需求。比如，它花了很大篇幅介绍如何进行用户故事的编写，如何制作原型图，这些都是非常基础且重要的工作，但它们更多的是在“如何表达”需求，而不是“如何发现”创新需求。我期待的是，书中能有一些章节，能够讲解一些非传统的、甚至有些“脑洞大开”的方法，去激发那些隐藏在用户行为、市场趋势、甚至技术发展背后的潜在需求。比如，有没有一些思维导图的变体，可以用来拓展思维边界？有没有一些案例，展示了创业公司是如何通过捕捉到某个微小但关键的需求而获得成功的？这本书在这方面给我的感觉是比较保守，它提供的更多是“安全牌”，而不是“惊喜牌”。
当我开始阅读这本书时，我最大的感受就是它似乎陷入了一种理论的泥沼，让我觉得有点空洞。我一直对如何将复杂的业务逻辑转化为清晰、可执行的技术方案很感兴趣，尤其是在面对一些新兴技术或者跨领域项目时，我希望能找到一些能够提供清晰框架和指导原则的书籍。这本书的标题“需求设计”听起来很有吸引力，我以为会看到一些关于如何构建健壮、可扩展的需求体系的深入探讨。然而，内容充斥着大量的抽象概念和模型，比如“需求层次理论”、“功能性与非功能性需求的权衡模型”等等。虽然这些概念本身有其理论价值，但在实际应用层面，它并没有提供足够多的“如何落地”的指导。我尝试着去理解那些模型，但感觉它们更像是学术论文里的讨论，而不是一本面向实践者的操作手册。例如，书中反复强调“需求的可追溯性”，但对于如何有效地实现这种追溯，尤其是当需求不断变更的时候，并没有给出详细的步骤或工具建议。它更多地是告诉我们“为什么要做”，而不是“怎么才能做好”。这种缺乏实践指导的理论阐述，让我觉得这本书更适合作为理论研究的参考，而不是作为日常项目开发的助手。
这本书我读了好几天了，实在没法深入下去。我本来是想找找看有没有什么新颖的、能够帮助我理清项目初期思路的方法论。这本书的封面设计倒是不错，很简洁，颜色搭配也很舒服，所以我一开始对它抱有很大的期望。但是翻开目录，就感觉有点不对劲。很多标题都像是那种泛泛而谈的，比如“理解用户需求”、“定义产品功能”之类的，这些概念太基础了，感觉就像是随便哪个项目管理入门书籍里都能翻到的内容。我希望这本书能提供一些更具体、更具操作性的工具或者案例，能让我看到别人是如何一步步把模糊的想法变成清晰的需求文档的。但它给我的感觉是，更多地是在陈述一个“应该怎么做”，而没有真正告诉你“怎么去做”。例如，在讲到“用户访谈”那一章，它列举了一些访谈的原则，比如“要开放式提问”、“要倾听”等等，这些都是常识。我更想知道的是，有哪些非常规的访谈技巧，能挖掘出用户自己都可能没意识到的深层需求？或者，有没有什么场景下，不适合做用户访谈，而应该采用其他方式？这本书在这方面给我的启发太少了，我总感觉它像是在隔靴搔痒，浮于表面。
读完这本书，我最大的感受是，它好像并没有真正触碰到我内心深处对“卓越设计”的追求。我一直认为，好的需求设计不仅仅是满足功能，更在于创造一种愉悦、高效的用户体验。这本书在讲解需求时，更多地是将需求视为一种“清单”，需要被一一满足。它在描述“用户体验”时，也更多地是从“可用性”和“易用性”的角度出发，这些固然重要，但我期望的是更进一步的探讨。比如，如何通过巧妙的需求设计，去营造一种“惊喜感”？如何让产品在不经意间就解决了用户尚未察觉到的痛点？它在讨论“用户反馈”时，更多的是如何去收集和处理反馈，以改进现有功能，但对于如何利用反馈去“预见”和“创造”未来的需求，着墨不多。这本书给我的感觉，更像是一本“合格”的需求设计指南，但它并没有激发出我对于“优秀”或“颠覆性”设计的渴望。我总觉得，它在“好用”的基础上，还缺少了那一层能够让人“爱不释手”的设计哲学。
总的来说，这本书给我的感觉是，它在“做什么”和“为什么做”上做了不少铺垫，但在“怎么做”这个最核心、最落地的问题上，给我的帮助却相当有限。我是一名正在创业的开发者，时间宝贵，我希望找到一本能够直接解决我当下痛点的书。这本书的章节安排，有时候会让我觉得有点绕。比如，它可能会先讲一个很宏大的概念，然后拆解成几个子点，每个子点又需要进一步理解。我需要的是那种能够快速建立起一个清晰的项目流程，并且在流程的每个关键节点，都能提供明确行动指南的书。它在“需求分析”的部分，列举了很多分析的维度，比如市场分析、竞品分析、技术分析等等，但是对于如何在实际操作中，将这些分析结果有效地整合，形成一份有说服力的需求报告，就没有给出太多的具体建议。我读完之后，还是不知道如何才能更高效地组织我的分析过程，以及如何将这些零散的信息汇总成一份有价值的产出。感觉像是给我了一堆食材，但却没有教我如何烹饪出一桌美味佳肴。
作者从软件设计用户，数据库，技术等多个角度，想做一个好的系统，介于敏捷和瀑布之间。情景设计有很多检验分析的环节，来提升设计效果，但分析的再多，我认为也不比去市场上检验，总的来说，作者提供了另外一个视角来看需求设计，还是不错。
这本书还没读完，但是觉得不像是写给需求人员的，而是写给设计人员的~
这本书还没读完，但是觉得不像是写给需求人员的，而是写给设计人员的~
小弟翻譯的書，請大家多多指教
其实没完全看完，但是挺有收获的
