登入帳戶  | 訂單查詢  | 購物車/收銀台( 0 ) | 在線留言板  | 付款方式  | 運費計算  | 聯絡我們  | 幫助中心 |  加入書簽
會員登入 新用戶登記
HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類瀏覽雜誌 臺灣用戶
品種:超過100萬種各類書籍/音像和精品,正品正價,放心網購,悭钱省心 服務:香港台灣澳門海外 送貨:速遞郵局服務站

新書上架簡體書 繁體書
暢銷書架簡體書 繁體書
好書推介簡體書 繁體書

三月出版:大陸書 台灣書
二月出版:大陸書 台灣書
一月出版:大陸書 台灣書
12月出版:大陸書 台灣書
11月出版:大陸書 台灣書
十月出版:大陸書 台灣書
九月出版:大陸書 台灣書
八月出版:大陸書 台灣書
七月出版:大陸書 台灣書
六月出版:大陸書 台灣書
五月出版:大陸書 台灣書
四月出版:大陸書 台灣書
三月出版:大陸書 台灣書
二月出版:大陸書 台灣書
一月出版:大陸書 台灣書

『簡體書』软件需求与可视化模型

書城自編碼: 2950615
分類:簡體書→大陸圖書→計算機/網絡软件工程/开发项目管理
作者: [美]Joy Beatty Anthony Chen著 方敏
國際書號(ISBN): 9787302457152
出版社: 清华大学出版社
出版日期: 2017-01-01
版次: 1
頁數/字數: 376页
書度/開本: 32开 釘裝: 平装

售價:HK$ 100.1

我要買

 

** 我創建的書架 **
未登入.


新書推薦:
百酿成金 全球15家经典酒庄的品牌故事(精装)
《 百酿成金 全球15家经典酒庄的品牌故事(精装) 》

售價:HK$ 154.9
变局与应对: 全球经济金融趋势与中国未来
《 变局与应对: 全球经济金融趋势与中国未来 》

售價:HK$ 106.5
四大古国文明与河流:大河文明展
《 四大古国文明与河流:大河文明展 》

售價:HK$ 372.7
国家、族群与战争: 公元前西亚三千年
《 国家、族群与战争: 公元前西亚三千年 》

售價:HK$ 118.6
万千心理·成人情绪障碍跨诊断治疗的统一方案:治疗师指南
《 万千心理·成人情绪障碍跨诊断治疗的统一方案:治疗师指南 》

售價:HK$ 66.6
想要发财也无可厚非
《 想要发财也无可厚非 》

售價:HK$ 58.1
交易者
《 交易者 》

售價:HK$ 94.4
国际秩序:法律、武力与帝国崛起(1898—1922)
《 国际秩序:法律、武力与帝国崛起(1898—1922) 》

售價:HK$ 95.6

 

建議一齊購買:

+

HK$ 94.3
《 可伸缩架构:面向增长应用的高可用 》
+

HK$ 114.6
《 架构真经:互联网技术架构的设计原则(原书第2版) 》
+

HK$ 100.1
《 DevOps:软件架构师行动指南 》
+

HK$ 87.0
《 最佳工作场景:比发钱更有效的办法 》
+

HK$ 85.6
《 数源思维:业务导向的数据思维秘籍 》
+

HK$ 71.1
《 软件架构与模式 》
編輯推薦:
聚焦于软件需求中的目标、人、系统和数据;重点介绍四大类需求可视化模型的实践运用
內容簡介:
需求文档的模糊性和歧义性是导致很多软件项目最终无法满足用户需求的主要原因。针对这一现状,本书主要侧重于以视觉化方式来表达软件需求,介绍了4大类22个可视化需求模型,旨在指导读者通过软件需求的视觉化模型来进一步明确需求,促进开发人员对需求的理解,从而进一步推动软件项目的成功。本书取自需求领域两位专家十多年的实践经验,具有重要的指导和参考意义,可以帮助读者准确理解需求,开发出满足用户需求和可以帮助用户达成任务目标的软件产品。
關於作者:
Anthony Chen(安东尼陈)Seilevel联合创始人兼总裁。在过去十几年间,Anthony与财富500强许多公司有广泛的合作。他是Seilevel的战略负责人和软件需求创新技术的开发负责人。他针对软件需求技术、用户体验和需求分析思路写过很多文章。他拥有伊利诺大学电子工程和微生物学双学士学位,德州农工大学微生物和免疫学硕士学位。
Joy Beatty(乔伊贝迪)软件需求社区的领袖,Seilevel公司副总裁,认证以业务分析师(CBAP)。经过15年的专业经验积累,Joy找到了如何运用最佳实践来改进需求收集和建模。她协助财富500强很多企业建立了卓越业务分析中心。她培训过的业务分析师数以千计。Joy毕业于普渡大学,拥有计算机科学与数学双学士学位。工作之余,Joy还热爱划船、游泳、外出野炊。
方敏微软公司前资深软件架构师,早期微软美国华人协会联合创始人。他具有丰富的技术和管理经验和广泛的人生阅历,他高度重视用户对软件的需求,非常熟悉敏捷软件开发和经典软件管理,注重团队的优势和创新。他已与清华大学出版社翻译出版了几本价值极高的软件工程书籍。赴美之前,他在中国航天部计算中心从事过微机开发工作。他拥有清华大学电子工程学士和硕士学位,美国新墨西哥州矿业技术学院计算机科学硕士学位。方敏领导和参与和很多优秀书籍的翻译,包括《敏捷文化》、《Windows 程序设计》、《探索性软件测试》和《游戏创造世界:硅谷创新游戏练习》等。Anthony Chen(安东尼陈)Seilevel联合创始人兼总裁。在过去十几年间,Anthony与财富500强许多公司有广泛的合作。他是Seilevel的战略负责人和软件需求创新技术的开发负责人。他针对软件需求技术、用户体验和需求分析思路写过很多文章。他拥有伊利诺大学电子工程和微生物学双学士学位,德州农工大学微生物和免疫学硕士学位。
Joy Beatty(乔伊贝迪)软件需求社区的领袖,Seilevel公司副总裁,认证以业务分析师(CBAP)。经过15年的专业经验积累,Joy找到了如何运用最佳实践来改进需求收集和建模。她协助财富500强很多企业建立了卓越业务分析中心。她培训过的业务分析师数以千计。Joy毕业于普渡大学,拥有计算机科学与数学双学士学位。工作之余,Joy还热爱划船、游泳、外出野炊。
方敏微软公司前资深软件架构师,早期微软美国华人协会联合创始人。他具有丰富的技术和管理经验和广泛的人生阅历,他高度重视用户对软件的需求,非常熟悉敏捷软件开发和经典软件管理,注重团队的优势和创新。他已与清华大学出版社翻译出版了几本价值极高的软件工程书籍。赴美之前,他在中国航天部计算中心从事过微机开发工作。他拥有清华大学电子工程学士和硕士学位,美国新墨西哥州矿业技术学院计算机科学硕士学位。方敏领导和参与和很多优秀书籍的翻译,包括《敏捷文化》、《Windows 程序设计》、《探索性软件测试》和《游戏创造世界:硅谷创新游戏练习》等。
朱嵘在英国航空电子系统公司担任质量工程师期间,主要负责空客A320、空客A340、波音737、波音747等飞机机型的关键质量分析和故障维修,具有丰富的专业经验。赴美之前,她在中国航天部二院担任工程师,负责红七地对空导弹通信系统的研发。她拥有哈尔滨工业大学无线电工程学士学位。
目錄
第Ⅰ部分 需求模型介绍

第1章 需求建模语言入门 3
定义RML 3
传统软件需求实践的挑战 4
人脑的限制 4
图比文字更容易理解 5
需求模型 6
为什么不用UML 7
需求与设计 8
一个层面的需求是对另一个
层面的设计 8
确定业务的实际需要 9
定义需求 9
需求模型不等于游戏的结束 10
在项目中使用RML 10
其他资源 10
参考文献 11

第2章 模型分类 12
目标、人员、系统和数据模型 13
目标模型 15
人员模型 16
系统模型 17
数据模型 18
参考文献 19

第Ⅱ部分 对象模型

第3章 业务目标模型 23
业务目标模型模板 24
例子 26
创建业务目标模型 28
使用业务目标模型 33
常见错误 36
相关的模型 37
练习 37
其他资源 38
参考文献 38

第4章 目标链 40
目标链模板 41
例子 42
创建目标链 45
使用目标链 52
常见错误 55
相关模型 55
练习 55
其他资源 56
参考文献 56

第5章 关键绩效指标模型 57
KPIM模板 58
例子 59
创建KPIM 60
使用KPIM 62
常见错误 64
相关的模型 65
练习 65
其他资源 66

第6章 特性树 67
特性树模板 68
例子 70
创建特性树 71
使用特性树 73
常见错误 75
相关的模型 76
练习 76
其他资源 77
参考文献 77

第7章 需求映射矩阵 78
RMM模板 79
例子 81
创建RMM 82
使用RMM 87
识别无关的需求或缺失的步骤 88
常见错误 89
相关模型 90
练习 90
其他资源 91
参考文献 92

第Ⅲ部分 人员模型

第8章 组织结构图 95
组织结构图模板 96
例子 98
创建组织结构图 99
使用组织结构图 102
常见错误 105
相关模型 106
练习 106
场景 106
其他资源 107
参考文献 107

第9章 处理流程 109
处理流程模板 110
例子 113
创建处理流程 115
使用处理流程 119
常见错误 121
相关模型 122
练习 123
其他资源 124
参考文献 124

第10章 用例 125
用例模板 126
创建用例 129
写主要路径 133
写替代路径 134
使用用例 135
常见错误 139
相关模型 140
其他资源 141
参考文献 142

第11章 角色权限矩阵 143
角色权限矩阵模板 144
例子 145
创建角色权限矩阵 146
使用角色权限矩阵 151
常见错误 154
相关模型 154
练习 154
其他资源 155

第Ⅳ部分 系统模型

第12章 生态系统图 159
生态系统图模板 160
例子 162
创建生态系统图 164
确认系统 164
使用生态系统图 166
常见错误 167
相关模型 168
练习 169
其他资源 169
参考文献 170

第13章 系统流程 171
系统流程模板 172
例子 174
创建系统流程 175
使用系统流程 178
推导需求 178
常见错误 180
相关模型 180
练习 180
其他资源 181

第14章 用户界面流程 182
UI流程模板 183
例子 184
创建UI流程 185
决定屏幕的范围 186
使用UI流程 190
常见错误 192
相关模型 192
练习 193
其他资源 193
参考文献 193

第15章 显示-动作-响应 195
DAR模型模板 196
例子 198
创建DAR模型 201
使用DAR 204
常见错误 206
相关模型 207
练习 207
其他资源 208
参考文献 208

第16章 决策表 210
决策表模板 211
例子 212
创建决策表 213
使用决策表 217
常见错误 218
相关模型 219
练习 219
其他资源 220
参考文献 220

第17章 决策树 221
决策树模板 222
例子 224
创建决策树 225
常见错误 230
相关模型 230
练习 231
其他资源 231
参考文献 231

第18章 系统界面表 233
系统界面表的模板 234
例子 234
创建系统界面表 235
使用系统界面表 237
常见错误 238
相关模型 238
练习 239

第Ⅴ部分 数据模型

第19章 业务数据图 243
BDD模板 244
例子 247
创建BDD 248
常见错误 255
相关模型 255
练习 256
其他资源 256
参考文献 256

第20章 数据流图 258
DFD模板 259
例子 259
创建DFD 260
使用DFD 262
常见错误 265
相关模型 266
练习 266
其他资源 267
参考文献 267

第21章 数据字典 268
例子 274
创建数据字典 276
相关模型 280
练习 281
其他资源 281
参考文献 282

第22章 状态表 283
例子 285
使用状态表 287
常见问题 290
相关模型 291
练习 291
其他资源 292
参考文献 292

第23章 状态图 293
状态图模板 294
例子 295
创建状态图 296
常见问题 299
相关模型 300
练习 300
其他资源 301
参考文献 302

第24章 报告表 303
报告表模板 304
例子 306
创建报表 308
确定报告 308
常见错误 312
相关模型 312
练习 313

第Ⅵ部分 大局图中的模型

第25章 项目模型的选择 317
根据项目阶段选择模型 317
根据项目特点选择模型 321
关于读者的思考 333
修改模型 334
练习 335

第26章 模型的综合应用 336
很多不同的视图 336
使用多个模型 337
需求架构 338
模型计划 340
相关模型 341
练习 352

第Ⅲ部分 附录

附录A 快速查找模型表格 355
附录B 一般性模型指南 357
附录C 练习答案 359
內容試閱
前 言
可视化需求模型是确认软件需求最有效的方法之一。这些模型帮助市场分析师确认,所有的项目利益相关者能够理解提出的解决方案,这些人士包括领域专家、商业利益相关者、高层管理人员和技术团队。可视化方式让项目利益相关者对项目更感兴趣,更乐于参与,其目的是找出需求方面是否存在差异。更重要的是,可视化创造了图形化的解决方案,帮助项目利益相关者理解解决方案交付什么结果和不包括什么。虽然可视化有这些优点,许多市场分析师和产品经理还是使用非可视化的电子表格或文本列出数千行条款。这些大量的文档让人吃不消,审查起来很枯燥,极不容易发现缺失的需求。这种实际状况反映当前需求专业培训有哪些问题症状,培训往往注重如何写出每条好的需求,而不注重如何分析整个解决方案。
这本书将帮助市场分析师、产品经理以及部门其他成员使用可视化模型捕获需求、建立模型和理解需求。本书描述了一种简洁而完整的语言RMLRequirements Modeling Language,需求建模语言,它用于建立软件需求的可视化模型,收集和规范了工业界中普遍使用的最佳实践模型。
谁应该读这本书
虽然这本书主要针对市场分析师和产品经理,但是我们认为项目经理、开发人员、架构师和测试人员也可以从这本书中获得巨大的价值,因为它可以帮助他们学习必要的信息标准,使他们的工作更容易。这本书通常把实际做工作的人称为市场分析师,在不同的部门里这个角色有着许多不同的职称。当提到你,我们也是指市场分析师。
事先告诉大家,我们的经验主要基于在现有基础架构上建设软件的项目,例如面向内部的信息技术系统IT、面向消费者的作为软件即服务SaaS的大型软件系统以及云系统。虽然我们已经在独立的软件包和嵌入式系统中使用了RML,但是这些类型的项目都不是我们的主打领域。根据我们对这些系统的有限经验,认为做这些系统工作的读者也会发现RML提供了令人难以置信的价值,我们期待着收到他们提出的改进意见。
本书的假设
本书假设你已具有编写软件需求的基础知识,因此不提供需求工作的基本信息。本书希望你对软件开发过程有些基本了解,例如,迭代方法、瀑布方法、和敏捷方法,知道它们是如何处理软件需求的。
谁不必读这本书
如果你刚刚开始做市场分析师,我们建议你在读这本书之前先阅读卡尔魏格斯所写的《软件需求》一书,了解需求领域的全面概况。如果你正在开发独立包装出售的软件,书里的一些概念还是有意义的,不过你可能会发现商业定位不同。如果你是一个产品经理,侧重于软件产品的战略和营销而不是开发软件,这本书可能对你不合适,因为它重点集中于如何设计软件功能使其受到高端用户的认可。
本书的结构
我们组织这本书的目的是将它作为参考指南。
第Ⅰ部分先介绍一般模型的情况,然后讨论RML语言和四类模型:目标模型、人员模型、系统模型和数据模型OPSD。
第Ⅱ部分到第Ⅴ部分的各章讨论全部RML模型,各章有相同的结构,其中包括:
有关模型的真实故事
模型的定义
模型的模板
建议创建模型的工具
虚构的例子
解释如何创建和使用模型
学习使用模型的练习
所有这些章的练习都围绕着一个样品项目而设计。
第Ⅵ部分解释如何选择模型以及如何使用模型来产生软件需求。
附录A包含两个快速模型查找表作为模型选择指导,附录B建议创建模型的一般准则,包括所有的模型元数据和模板提示,附录C给出书中所有练习的答案。还有一个词汇表定义本书用过的术语。
阅读本书的最佳切入点
可以直接阅读全书,但对有些人来说,在深入每个模型的细节之前,从第Ⅵ部分开始阅读会更好地理解上下文。下表提供了更多的指导。


读者对象 建议步骤
总体上不熟悉需求建模或可视化建模 可以从前到后地阅读本书,看看需求模型的介绍,
了解每个模型的内容,最后把它们联系起来使用

熟悉可视化需求建模或者 建议浏览所有的章节,了解RML在可视化建模上与
是使用过类似模型的市场分析师 其他建模语言有什么不同。但是可能从第Ⅵ部分
开始了解更高级的内容更有帮助,如何选择模型
以及如何在项目中把多个模型一起使用。当项目
需要时,可以参考相关模型的章节

建模快速入门
这本书包含学习需求建模的大量信息。前景是美好的,为此我们开发了一种方法,使用尽可能少的模型但能为项目创造明显的价值。这种快速启动的方法适用于大多数IT项目。下面的流程图总结了这种方法。


如图所示,首先创建业务流程。接下来,根据流程步骤创建需求映射矩阵RMM。然后为流程步骤的截屏创建对应的显示-操作-响应DAR模型,将它们映射到业务流程步骤上。最后创建数据字典确保所有字段都包括,确认字段的验证规则。
虽然这张图没有提到很多其他有价值的模型,但给出了一系列读者容易理解的主要步骤。最后结果是,项目的需求将按照流程步骤来组织,截屏也将映射到流程步骤,以确保用户界面满足关键流程的需要。

本书约定和功能
本书使用专门的约定确保信息易于理解,易于遵循。
每章开始处用斜体字向读者讲述一个非软件的故事作为引子。
整本书中所有RML模型名称都大写。用非RML的其他建模语言建的模型名称不大写。
RML模型的模块称为元素,这些模型元素名称没有大写,以免与模型名称混淆。
这本书结尾处的词汇表列出我们认为重要的RML术语。这些术语以斜体字贯穿全书。
每个模型的模板提供工具提示的读者帮助,建议使用何种工具创建该模型。
配套内容
如果项目需要创建本书的模型时,欢迎你下载使用RML模型模板。RML模型的全套模板下载网址如下:
http:go.microsoft.comFWLink?Linkid=253518
压缩文件中的使用说明介绍了如何使用模板。简单步骤如下:下载压缩文件,还原文件内容放到方便的地方。每个模型有一个模板,Visio文件格式的模型包括一个模板和一个模板文件,模板正常工作需要这两个部分。其余模板均为Excel格式或Word格式。快速模型查找表也在压缩文件中。
致谢
从我们Seilevel公司的团队到在世界各地做需求工作的同事,再到多年来一直支持和帮助我们改进RML的客户,没有你们的合作,这本书是不可能出版的。
非常感谢Seilevel公司的员工帮助研究、审阅、写作、编辑和起草模型,提出很难回答的好问题,他们是乔伊斯格雷普斯、詹姆哈尔根、贝琪斯托克代尔、迈克尔刘、坎达丝霍卡松、杰里高尔、巴拉吉维贾扬、马克塔尔博特、马特奥佛斯、阿贾伊巴德里、杰森菲尔德、杰拉尔丁蒙戈尔德、凯尔康登、克林特格雷厄姆、大卫莱因哈特、韦斯埃德森、阿卜杜勒马瑟、克里斯蒂森索、罗布斯巴克斯和洛瑞威策尔。
我们诚挚地感谢许多审阅人员,他们花时间阅读书稿,给出他们的想法和批评,帮助改进本书。他们是乔伊斯塔兹、肯特麦当劳、莎拉格雷戈里、列尔卡别乌斯-杜奇、玛丽戈若斯、卡尔魏格斯、埃伦戈特斯蒂讷、斯科特赛尔豪斯特、埃维胡克斯和安妮哈特利。特别感谢卡尔魏格斯和伊恩亚历山大,他们两人提供写作指导并和我们切磋关于模型的想法。
我们衷心感谢勤奋工作和富有情趣的编辑团队,他们把这本书变成了现实。同时感谢组稿和策划编辑德文郡马斯格雷夫和项目编辑卡罗尔迪灵汉,他们两人都在微软出版社工作。我们还要感谢项目经理和文稿编辑凯西克劳斯,排版人员吉恩特雷纳里、校对海梅奥德尔、美编珍妮克雷沃和索引人员扬巴德纳兹克。
最后,要感谢我们的家人一起忍受漫长的写作过程。乔伊感谢她的丈夫托尼汉密尔顿,在整个过程中帮助她保持幽默感;感谢她的女儿斯凯,她出生在这本书的写作期间,当我们完成写作时她已经学会了一觉睡到天明。事实证明,写一本书就像有一个孩子:许多月的孕育、准备、和喂养。安东尼感谢他的妻子格洛丽亚对他的支持,还有他的女儿梅森,她可以自己愉快地玩耍让爸爸工作,但在电话会议时她变得非常安静。最后,安东尼想感谢乔伊,如果没有她全力以赴地推动这本书的写作,此书永远不会出版。
勘误和支持
我们已经尽了一切努力来确保本书和配套内容的准确性。这本书出版之后所报告的任何错误都会列在我们的微软出版社网站:
http:go.microsoft.comFWLink?Linkid=253517
如果发现没有列出的错误,可以通过这个网址向我们报告。
如果需要额外的支持,发电子邮件到微软出版社的书籍支持:mspinput@microsoft.com。
请注意,微软的软件产品支持不是通过上面地址提供的。
我们期待着你的意见
在微软出版社,你的满意是我们的首要任务,你的反馈是我们最宝贵的财富。请通过下面的网址告诉我们你对这本书的看法:
http:www.microsoft.comlearningbooksurvey
这项调查很简短。我们会阅读每一条意见和建议,提前谢谢你的输入。


第1章 需求建模语言入门
离节假日旺季还有九个月,一家著名的网上零售商确定要在其网站上添加一组重要的新功能,这将大大增强消费体验,直接增加销售额,同时减少好几个国家的客户电话服务量。据估计,这些新功能会为公司每年增加1400万美元的收入,而实现这些功能的费用却不到200万美元。产品经理确定这些功能的要求和业务规则,开发团队和项目管理团队预估可以在节假日旺季节到来时轻松地完成项目。为了能按期交付产品,开发团队努力赶工,晚上和周末经常加班加点。
八个月之后,该团队进入最后的测试阶段,感觉良好。他们完成了一长串功能增强以求获得高额的回报。然而,一位测试人员发现税收的计算是不正确的。不幸的是,这些计算错误只是冰山一角,因为团队忽略了和税收团队交流。实际上,他们当时没有意识到必须这样做。如果与税收团队交流,他们会发现在有些国家营业时要遵守的税务规则极为复杂,必须与管理税收规则的第三方软件进行集成。项目被推迟,那个旺季1400万美元的回报也成泡影。项目经理被解雇,产品经理被调往其他小项目。

项目经常因为需求的缺失、不完整或者不明确而受到困扰The Standish Group
2009。错误的需求实践普遍存在,所以大部分项目注定会失败Ellis, Keith.
2008。需求没做好是许多项目失败的根源,令人失望的是在过去20年中软件需求水平并没有显著提高。尽管学术界一直在稳步改善需求技术和工程方法,但是业务实践行为在很大程度上并没有什么变化。软件编程技术已经相当成熟,创造出各种新的技术,开发出丰富的工具,但是在写需求时,人们还是常常使用一长串的应该语句,把语句存在电子表格中。使用敏捷方法的项目也没有多少改进,还是经常把产品工作清单和用户故事作为一长串列表存在电子表格或其他工具中。
定义RML
RML需求建模语言是为建立需求视觉模型而专门设计的语言,它便于企业管理、业务和技术等项目干系人使用。RML不是一种学术上的建模语言。在开发RML期间,我们改进了现有模型的易用性,创建新的模型来弥补功能上的缺失。结果就有了一套完整的模型,是专门为软件需求建模而设计的,对于那些常常搞不懂复杂模型的项目干系人来说,更容易接受。我们已经在许多大型软件开发项目上成功使用了这些需求模型。
传统软件需求实践的挑战
传统的做法不得不使用几千行系统应该这样的需求描述句,其繁复程度如图1-1所示。这些需求通常是通过与企业项目干系人面谈或者举行工作会议之后产生的。因为一般人都受米勒魔数的制约参见下一节人脑的限制,下面的事情几乎是不可能发生的:人们在阅读了数以千计的需求条款后,突然确信项目的需求是全面的。此外,另一个较大的问题是需求规模会逐渐变化。等你有了上千个需求,如果没有某种方法把这些需求与价值联系起来,力求在解决方案层面上进行比较,将很难决定应该砍掉哪些需求。团队经常把需求进行逻辑分组,但这些分组通常还是过大,无法得到有效的处理。
敏捷方法,如Scrum,有产品工作清单、用户故事和验收标准。许多Scrum布道者说,产品工作清单应该是非嵌套的故事列表,这种做法比传统的需求列表好不了多少。验收标准也要求列出来,有时就列在便条卡的某一面上。做过大型系统的人都知道,在可能会有几百个项目干系人参加的项目上,这种缺乏信息组织结构的做法是行不通的。
人脑的限制
使用传统实践来创建软件需求的业务分析师在分析、组织和使用需求上会遇到同样的问题。传统的做法使用冗长列表来列出需求的文字描述,其形式是应该语句、用例、最近又增加的用户故事和产品工作清单。受限于人类的基本认知能力,冗长的清单列表使用起来都很困难。在20世纪50年代,认知心理学家乔治米勒发现,人类只能记住和处理7加或减2项内容Miller,
George A. 1956,这通常称为米勒魔数。
7-2
后来的证据表明基数甚至可能少到3或4Cowan, Nelson. 2001。这个数字代表大脑暂存器解决问题时所能保存的信息容量。无论实际数目是多少,如果要求普通人同时考虑大约15件事情,实际上最多只能记住和处理其中9件可能更少。如果要求处理的事情更多,一次只有几件可以同时处理,其他的会被快速切入或切出暂存器。想想去杂货店购买15件东西,如果没有一份写好的购物清单,你很可能漏掉东西或者买回的东西数量不正确。同样的道理,如果需求列表或产品工作清单中的事项成百上千,那么你的大脑根本没有办法处理这种复杂性,除非把它分解成更小的结构化分组。

需求文件
REQ001系统应该有姓、中间名首字母和名等字段。
REQ002系统应该显示名字如果存储的个人资料中已有一个。
REQ003系统应该要求姓名是完整的。
REQ004系统应该有职位或头衔字段。
REQ005系统应该要求头衔是完整的。
REQ006系统应该显示职位或头衔如果存储的个人资料中已有一个。
REQ007系统应该有电子邮件地址字段。
REQ008系统应该有备用的电子邮件地址字段。
REQ009系统应该显示电子邮件地址如果存储的个人资料中已有一个。
REQ010系统应该显示备用电子邮件地址如果存储的个人资料中已有一个。
REQ011系统应该要求电子邮件地址是完整的。
REQ012系统应该要求备用的电子邮件地址是完整的。
REQ013系统应该具有白天电话号码的字段。
REQ014系统应该显示电话号码如果存储的个人资料已有一个。
REQ015系统应该要求电话号码是完整的。
REQ016系统应该在验证电话号码字段中所有字符是数字当用户退出该字段时。
REQ017系统应该显示错误消息如果在电话号码字段不是所有字符都是数字。
REQ018系统应该有传真号码的字段。
REQ019系统应该要求传真号码是完整的。
REQ020系统应该显示传真号码如果存储的个人资料已有一个。
REQ021系统应该验证在传真号码字段中的所有字符是数字当用户退出该字段时。
REQ022系统应该显示错误信息如果在传真号码字段里不是所有字符都是数字。
REQ023系统应该有街道地址的两个字段。
REQ024系统应该要求街道地址字段是完整的。
REQ025系统应该显示地址如果存储的个人资料已有一个。
REQ026系统应该有城市的字段。
REQ027系统应该要求城市字段是完整的。
REQ028系统应该显示城市如果存储的个人资料已有一个。
REQ029系统应该有状态的字段。
REQ030系统应该显示状态如果存储的个人资料已有一个。
REQ031系统应该要求状态字段是完整的。
REQ032系统应该有邮政编码的字段。
REQ033系统应该显示邮政编码如果存储的个人资料已有一个。
REQ034系统应该要求邮政编码字段是完整的。
图1-1 冗长的需求列表
图比文字更容易理解
如何解决原始哺乳动物大脑的基本限制呢?有句话说得好:一图胜千言。模型是信息的视觉表现方式图形,它描述了流程、数据和解决方案内部和环境的互动。你可能每天都在使用视觉模型但可能没有意识到这一点。
最近我出差,参加一个在赌场酒店举办的会议,我在前台登记后领到了房间的钥匙,前台女服务员给我指路,告诉我怎么去我的房间。她说了类似这样的话:你从这里沿着右边走出去,然后沿着路向左行,穿过一个酒吧,路过几台老虎机,在喷泉附近向右转,走过一家餐厅,再走过一家餐厅,然后你会走到一个大厅,在那里向左转走过一条商业街,在路的尽头你会发现游泳池入口处有一个电梯。

我茫然地盯着她。那一刻我能想起的就只有我刚刚从出租车走到前台时所看到的很多老虎机和赌桌。我假设在去房间的路上会走过更多的老虎机和赌台,女服务员刚才讲的已经记不清楚,反而把我搞得更糊涂。后来她给了我一点儿希望:这张图画了怎么去那里。她画出从前台到电梯的路线图,如图1-2所示。我松了一口气,因为我只记住了她所说的前几步,其他记不住,但现在我有了一个模型,我糊涂的时候可以参考。一张图!总而言之,当人类解释信息时,图比文字更容易理解。

图1-2 一张穿过赌场的地图,对应于女服务员所说的路线
需求模型
需求模型组织和展示了大量信息,帮助你发现缺失的信息,并给出上下文细节Gottesdiener, Ellen.
2002。最重要的是模型可以从视觉上进行分组,使你能够通过短期记忆能力快速分析大量截然不同的信息。在有几千条系统应该句式的需求文档中,阅读、解释并找出差异是很困难的,而视觉模型能够提供帮助。
想象在你面前零乱摆放的字母如图1-3所示,要你找出字母表中哪些字母没有出现。


图1-3 零乱摆放的字母中,缺了哪个字母
如果你只是盯着混乱的字母或甚至把字母无序地排成一行,是很难发现缺了哪个字母的事实上,你可能刚刚试着把它们按顺序排列起来。如果按字母顺序排列如图1-4所示,瞬间就会发现缺失的字母。
要找到缺失的需求,关键是利用一个事实,每一个需求与其他需求都有着某种联系。当你得到一长串系统应该的需求条款时,要想保证其完整性是极其困难的,但如果重新组织需求就可以利用这种联系,每次只在较小的分组里分析信息从而大大简化任务。
需求模型用于项目的整个生命周期。这些模型可用于多种场合,有助于分析需求,有助于向项目干系人提出需求和验证需求,有助于与开发人员和测试人员沟通需求。

图1-4 排列已有字母,找出缺失的字母
为什么不用UML
一个直接的问题出现了:为什么不使用统一建模语言UML?|UML是一种专门用于以可视化方式设计软件系统的语言请参阅文献Object
Management Group.
2007。UML为需求建模奠定了合理基础,但它不满足需求建模的全部要求,因为它缺少有关需求与业务价值的模型,缺少从最终用户的角度展示系统结构的模型。此外,它在技术上过于复杂使得业务项目干系人难以掌握,因为它的模型侧重于软件系统的架构建模。最后,UML用于描述系统的技术设计和结构,顶多在建模方面对UML进行翻新改造以支持业务收益、用户操作和业务规则。
当一个模型只聚集于解决问题的一个或两个方面时,它是最有用的。如果一个模型具有许多类型的信息或者模型的语法规则过于复杂和难于理解,项目干系人绝对不会用。事实上,我们的经验说明,模型的复杂性是造成大型企业不用一些现有建模语言的主要原因之一。
RML模型是用最简单的语法设计出来的,还可以传达必要的信息。RML的目的是提供一致的语法和语义结构供业务干系人分析和理解项目模型。设计该语言的目的是让整个团队容易学习和使用,包括但又不局限于业务项目干系人、开发人员和测试人员。模型简化到只有最基本的符号和格式,但还能保证在需求方面取得预期的结果。RML不只针对软件开发方法,也可以容易适应于与任何开发方法或工具套件结合使用。
需求与设计
许多RML模型在业务分析师看来通常属于设计领域。例如,显示-操作-响应模型使用线框或屏幕截图来描述用户如何与屏幕元素交互,用户界面流模型展示用户如何浏览各种用户界面。
有一句关于需求的谚语:需求关注的是要建什么,设计关注的则是它如何起作用。需求和设计之间的区别很重要,因为很多人强调任何设计都不应该和需求混在一起,设计文档不应该由业务分析师来写。遗憾的是,这种严格的定义存在一个问题:一个层面的需求是对另一个层面的设计。
一个层面的需求是对另一个层面的设计
在自上而下的解决方案中有不同的概念层面,如果考虑一个层面是有关什么的,那么它的下一层面将是有关如何作用于它的。因此,基于这种什么与如何作用的定义,如果一个层面是需求,那么下面的层面就应该是对需求的设计。
例如,项目干系人可能需要降低网站的购物车放弃率。在下面的细节层面,产品经理可能会提出几个不同的解决方案力求降低购物车放弃率。例如,该团队可以减少结账过程中的步骤,可以提供保留购物车内容的功能方便顾客下次购买,或者可以提供免费送货服务。提出的每一个解决方案都是有关如何作用即设计的,满足的是什么需求即降低购物车放弃率。此外,最初的什么即改进系统降低购物车放弃率可能同样也是如何作用即试图改进整个网站转化率。
不要用什么与如何作用的关系来区别需求和设计。这种方式不好。
确定业务的实际需要
另一个常见的定义是,任何有关实际解决方案的都属于设计而不是需求,例如算法的使用、外观和感觉、用户界面元素等。但是,在有些情况下,特定的请求有时可能是需求,而有时可能是设计。例如,在某些行业中,一个产品为了竞争的需要必须使用专门的加密算法,因此它是一种需求。对于另一个应用程序,它完全不关心使用专门的加密算法,唯一重要的是应用程序必须使用某种算法来加密信用卡号码。
用户要求是不是需求,关键要看业务项目干系人是否真正需要它。我们都知道,项目干系人实际上并不需要他们宣称自己想要所有的特征,所以要对请求作出判断,它是否真正是需求,用户是否真的需要。
定义需求
需求是企业需要在解决方案中实现的。因此需求可以包括功能性需求、非功能性需求、业务规则,甚至包括许多人传统上所称的设计。可以使用模型方法帮助项目干系人真正明白需要什么,而不是告诉他们允许他们选择什么类型的需求。
本节定义一些用于全书的需求术语。功能性需求是一个解决方案所提供的行为或功能而不加任何限定词。业务规则表示在修改功能性需求时必须满足的条件语句,包括但不限于什么时候该功能可以用以及允许谁执行该功能。业务规则包含诸如如果何时和然后等词汇。非功能性需求是任何不属于功能性的需求包括业务规则。特性是一个功能区域的简短描述,解决方案将最终实现该特性以达到业务目标。特性是需求的集合,用来清楚描述和组织需求。表1-1给出了几个例子。
表1-1 需求的例子
需求
类别
系统应该能够自动批准或驳回信用申请 功能性需求
当信用指标高于750,系统应该自动批准信用申请 业务规则
对于信用指标低于750,当自动决定是否批准信用申请时,系统应该使用下列算法:[算法将加在这里] 业务规则
审批过程应该在30秒内返回给用户 非功能性需求

假设是做决策时所依据的真实陈述。假设包括对未来的任何预测或预报。假设对于需求非常关键,因为这些假设会不断被引用,但很少有人理解或能够有人讲清楚。事实上,如果让业务分析师写下自己的假设,他们通常写下一些琐碎的小事,既不具有影响力又缺乏重要性。如果这些例子中的假设被证明是不正确的,可能会导致业务目标无法实现。
很多人都愿意在网上搜索以解决他们的技术问题。
当遇到技术问题时,50%的人愿意等待以后再试。
90%的业务客户都在上网进行。
待解决的问题中有些问题可以由客户自行解决。
需求模型不等于游戏的结束
需求模型的使用并没有完全取消写需求。虽然模型提供上下文又创建了有关需求的完整图形,但是模型还不是系统开发人员和测试人员最终使用的形式,必须采取额外的步骤从模型中提炼出需求。就像按照货架走道来组织购物清单一样,要为开发项目的团队产生需求清单。模型的价值在于以某种方式帮助组织所有的需求,以便很容易看出需求有缺失、无关或不正确的情况。
创建的所有模型都应该纳入项目的全部需求中。文字需求和可视化需求共同描绘出待建的解决方案的全景Wiegers, Karl E.
2003。
在项目中使用RML
可以把这本书中介绍的RML模型想象成软件项目的模型模板工具箱。通常情况下,建议综合使用多个模型,有些常用的方法定义了在整个开发周期中何时使用特定的模型。把需求模型应用到项目时,可以和许多开发方法一起使用,例如敏捷方法、迭代方法和瀑布方法参见第25章。
其他资源
业务分析师的RML快速参考指南,两页篇幅的模型相关摘要:http:www.seilevel.comwp-contentuploadsRML-Language-for-Modeling-Software-Requirements.pdf
《软件需求》第2版第11章系统介绍了模型的价值Wiegers, Karl E. 2003

参考文献
l Chen, Anthony. 2010. What vs. How BRD vs. User Requirements vs.
Functional Requirements: http:requirements.seilevel.comblog201004
what-vs-how-brd-vs-user-requirements-vs-functional-requirements.html.
l Cowan, Nelson. 2001. The Magical Number 4 in Short-Term Memory: A
Reconsideration of Mental Storage Capacity. Behavioral and Brain Sciences
24, 87-114.
l Ellis, Keith. 2008. Business Analysis Benchmark Report. IAG Consulting.
http:www.iag.bizimagesresourcesiag%20business%
20analysis%20benchmark%20-%20executive%20summary.pdf.
l Gottesdiener, Ellen. 2002. Requirements by Collaboration: Workshops for
Defining Needs. Boston, MA: Addison-Wesley Professional.
l Miller, George A. 1956. The Magical Number Seven, Plus or Minus Two:
Some Limits on Our Capacity for Processing Information. Psychological Review
63, 81-97.
l Object Management Group. 2007. OMG Unified Modeling Language
Specification. http:www.uml.org#UML2.0.
l The Standish Group. 2009. CHAOS Summary 2009. West Yarmouth, MA: The
Standish Group International, Inc.
l Wiegers, Karl E. 2003. Software Requirements, Second Edition. Redmond,
WA: Microsoft Press.

 

 

書城介紹  | 合作申請 | 索要書目  | 新手入門 | 聯絡方式  | 幫助中心 | 找書說明  | 送貨方式 | 付款方式 香港用户  | 台灣用户 | 大陸用户 | 海外用户
megBook.com.hk
Copyright © 2013 - 2024 (香港)大書城有限公司  All Rights Reserved.