《软件需求与可视化模型》阅读笔记

“需求关注的是要建什么，设计关注的则是它如何起作用”。遗憾的是，这种严格的定义存在一个问题：“一个层面的需求是对另一个层面的设计”。不要用“什么”与“如何作用”的关系来区别“需求”和“设计”，这种方式不好。
   需求是企业需要在解决方案中实现的，可以包括功能性需求、非功能性需求、业务规则，甚至包括许多人传统上所称的设计。功能性需求是一个解决方案所提供的行为或功能而不加任何限定词。业务规则表示在修改功能性需求时必须满足的条件语句，包括但不限于什么时候该功能可以用以及允许谁执行该功能。非功能性需求是任何不属于功能性的需求（包括业务规则）。


RML模型分为：
目标模型。（解决方案的目标，业务目标模型界定目标）
人员模型。（正在使用解决方案的人员，组织结构图界定人员范围）
系统模型。（系统本身的结构，生态系统图界定系统范围）
数据模型。（正在处理的数据，业务数据图界定数据范围）
统称为OPSD。


数据操作只能是创建、更新、使用、移动、复制或销毁。


业务问题：阻止达成业务目标的问题
业务目标：在解决业务问题时具体指定可度量的目标
产品概念：企业为达成业务目标而决定实现的实际解决方案的愿景，通常用主要功能列表来描述愿景
成功标准：实际度量的业务目标，用来决定该项目是否成功，或者与解决方案有关的其他度量


可以把几乎每一个业务问题分类为增加收入或是降低成本。
产品概念包括理想中的主要特性。产品概念可以描述解决方案的许多方面，包括软件、硬件和业务流程。
指导原则可以是解决方案中市场期望的条款或者干系人的目的条款。


组织结构图有三个层面：部门，角色，人员。
可以用颜色来强调组织结构图以提供更多的信息。可以使用颜色来区别对项目有特殊类型影响的不同群体。同时建议使用一些可视化的差异，如不同的色调、图案或边界，为的是方便那些看不出颜色的读者或者打印黑白图表。
确认项目干系人，从最基本的层次，可以查看组织结构图中的每一个方框，并提出下面这些问题：
这个人或角色是不是一个系统用户？
这个组、角色或人对系统是否有任何的需求？
这个组、角色或人是否会受到我们正在做的系统的影响？
他们参与了过程的哪一部分？
有没有无人执行的流程？


创建组织结构图的步骤：定位现有的组织结构图-》确定级别-》完成组织的结构图
组织结构图何时使用：只要有内部用户出现在层次结构，就要使用组织结构图；何时不用：对于纯粹的消费者项目，组织结构图可能不合适。


生态系统图显示了系统间的交互作用和它们之间关系的性质。
如果描述接口性质需要更多的详细内容但受到生态系统图的空间限制，可以使用系统接口表记录每一个接口。
创建生态系统图的步骤：确认系统-》确认接口-》画出总图
确认系统的过程中，问以下问题：
哪个系统或哪些系统用于处理流程或系统流程中的每一步？
在数据流图中，哪些系统运行修改数据的流程？在哪个系统中数据是上线的？
哪个系统或哪些系统在业务数据图中创建、更新、使用、删除、移动或复制每个业务数据对象？


应该总是使用生态系统图，在任何项目中该图应该是创建的第一组模型。唯一的例外是，解决方案是一个完全独立的系统，不与任何其他系统进行交互。


业务数据图（BDD）是概念性的数据模型，从企业干系人的角度显示业务数据对象，而ERD（实体关系图）显示对象在数据库架构中的实际实现。
创建BDD的步骤：确定业务数据对象-》关联业务数据对象-》添加基数
主要有三种方法来发现哪些对象应该在BDD中：听取主题专家的意见，看看其他视觉模型，看看现有系统的数据模型。
创建BDD时，不要想象成设计一个数据库。你只构建BDD以反映企业干系人如何想象数据，并把数据设计的任务交给数据库架构师去做。
BDD帮助你从视觉上把企业干系人谈论的话题联系在一起；不仅可以帮助你了解业务术语，而且可以帮助你简明地定义语言以阐明需求；从企业干系人的角度而不是技术团队的角度展开业务数据对象；通过BDD一看就知道哪些对象是相关的。


BDD是否使用却决于是否涉及到数据库；BDD显示关系，但不显示对关系有更多限制的所有业务规则。