平台自营

5.00

商品评价 5

服务态度 5

发货速度 5

微信扫码查看移动端店铺

店铺

暂无联系方式

店内分类

商品详情

商品名称：软件需求与可视化模型

商品编号：545245299926

店铺：

重量：0.000千克

上架时间：2020-09-16 14:51:38

ISBN编号：9787302457152

书名：软件需求与可视化

出版时间：2017.1

定价：69.00元

是否是套装：否

更多参数>>

编辑推荐聚焦于软件需求中的目标、人、系统和数据；重点介绍四大类需求可视化模型的实践运用目录目录第Ⅰ部分需求模型介绍第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创建业务目标模 ...

编辑推荐

聚焦于软件需求中的目标、人、系统和数据；重点介绍四大类需求可视化模型的实践运用

在线试读

第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或4(Cowan, 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，当自动

基本信息

商品名称：	软件需求与可视化模型	开本：	32开
作者：	［美］Joy Beatty　Anthony Chen著　方敏　朱嵘译	定价：	69.00
ISBN号：	9787302457152	出版时间：	2017-01-01
出版社：	清华大学出版社	印刷时间：	2016-12-01
版次：	1	印次：	1

评论晒单

100 好评率 %

此商品还没有设置买家印象，陪我一起等下嘛

加载评价中...

网友讨论圈

全部帖子(0) 晒单帖(0) 讨论帖(0) 问答帖(0) 圈子帖(0)

店内分类

相关分类

最近浏览

商品详情

规格参数

评论晒单

网友讨论圈

1

2

3

4

新手上路

配送与支付

服务保证

联系我们

会员中心

领取成功！感谢您的参与，祝您购物愉快~

店内分类

相关分类

最近浏览

商品详情

规格参数

评论晒单

网友讨论圈

提示

1

2

3

4

新手上路

配送与支付

服务保证

联系我们

会员中心

领取成功！感谢您的参与，祝您购物愉快~