系统设计
学习PMI-PBA的时候接触了很多商业分析和系统设计的工具，感觉非常实用，时间久了这些知识会逐渐忘记，
所以我把一些精髓放到博客，并附上自己对这些知识点的理解，以便今后复习。以下内容摘自《PMI 商业分析指南》。
系统交互图
系统交互图是一种范围模型，显示了解决方案中系统的所有直接系统和人机界面。
系统交互图清晰地描述了范围内的系统和所有的输入或输出，包括提供输入和接收输出的外部系统或参与者。
系统交互图通常应尽早创建以定义范围，并且可在识别新信息时进行更新。系统交互图还有助于识别接口需求和数据需求。
使用场景：构建新系统之前，要先搞清楚有哪些相关系统。新系统和这些系统有哪些交互，对哪些干系人造成影响，设计的时候需要考虑那些因素。
一旦新系统对原有系统的影响没有考虑到，后期可能会发生灾难性的问题。尤其做系统再构造项目的时候，前期必须弄清楚关联系统和人物角色。
数据字典
数据字典是罗列数据对象的数据域及其属性的一种数据模型。数据域是实体关系图中数据对象的补充细节。
数据域的属性详述了域的信息，包括数据执行的商业规则。数据字典通常在使用其他数据模型识别数据对象之后，
并且在数据对象需要指定更多细节时创建。数据字典可从现有系统中提取，以作为系统中所有数据的寄存器，并且可用作系统增强的输入。
它们通常与定义需求和验收标准一起创建。
数据流向图
数据流向图是描述数据在外部实体、数据存储和过程之间流动的一种数据模型。
外部实体可以是参与者或系统。数据流向图显示了每个过程的数据输入和输出。
决策树和决策表
生态系统图
生态系统图是一种范围模型，显示了所有相关的系统、系统之间的关系，以及流经它们的可选的任何数据对象。
这些系统是逻辑系统（商业角度），因此可能与实际物理系统（实施角度）的结构图并不匹配。
事件清单
报告表
以下内容引自https://blog.csdn.net/mxw2552261/article/details/79447798。
流程图
流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）产品经理做需求前一定要先把这些逻辑关系理清楚，如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。
图就是将你头脑中的逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，因为是图，你可以像你的版本迭代一样，当你的逻辑需要修改的时候拿出来迭代一下，同时因为有图，你还可以更好的给项目成员进行宣讲。
产品中设计的流程图主要有三种，业务流程图、任务流程图、页面流程图，下面我们来一一介绍。
业务流程图
业务流程图又称为泳道图，就是描述那些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：
1. 涉及到哪些主体？
2. 每个主体都有哪些任务？
3. 各个主体之间怎么联系的？一般涉及到多个主体，每个主体之间有联系。
任务流程图
泳道图一般是从战略上分析整个业务流程，让你对公司所做的业务有个大概的了解，而任务流程图就是在你的产品操作上，用户通过什么样的操作来完成它的目标，比如你去银行ATM机器上取钱，你是如何一步步操作把钱取出来的。
页面流程图
如果说业务流程图帮助你梳理战略，任务流程图帮助你梳理用户操作行为（主要给程序员看）、页面跳转流程在帮助你梳理各个页面之间的跳转关系（主要给UI和前端程序员看）这是一个逐步从整体到局部，从后端到前端的过程。
所有的产品都是由页面组成的，不论是APP、PC、H5都是由一个个页面组成的，页面流程图描述完成一个任务需要经过哪些步骤，你在画图的时候只需要清晰的表现出用户点击页面的什么地方，然后跳转到那个页面。主要由页面、行动点、连接线组成。
UI设计图标注
对于APP的页面，UI设计师会给出UI设计标注图，这样APP客户端开发人员，直接按照标注图进行页面的开发了。
产品设计完成后，架构师需要对产品进行软件的架构设计。包括技术的选型，模块的划分，开发人员的任务分配，工作量的评估等等.....
系统架构设计图
构架将在一次又一次迭代中不断演化、改进、精炼。
序列图
架构师一般在做详细设计的时候，会把程序模块之间的每一步调用过程很详细的画出来，这样开发人员拿到设计文档，就能直接开发。
类图
设计图有很多种，还包括用例图，状态图，活动图...... 不再一一介绍。画什么样的设计图，不是绝对的，不同公司，不同项目，需要画的设计图也是不同的，有些项目需要画原型图，有些项目只是对外提供服务，没有页面也就不需要画原型图。另外还要根据项目的工期，预算等等因素考虑。如果一个项目的工期也就一个月甚至更短，那基本上就是怎么简单怎么快就怎么做。
所以我把一些精髓放到博客，并附上自己对这些知识点的理解，以便今后复习。以下内容摘自《PMI 商业分析指南》。
系统交互图
系统交互图是一种范围模型，显示了解决方案中系统的所有直接系统和人机界面。
系统交互图清晰地描述了范围内的系统和所有的输入或输出，包括提供输入和接收输出的外部系统或参与者。
系统交互图通常应尽早创建以定义范围，并且可在识别新信息时进行更新。系统交互图还有助于识别接口需求和数据需求。
使用场景：构建新系统之前，要先搞清楚有哪些相关系统。新系统和这些系统有哪些交互，对哪些干系人造成影响，设计的时候需要考虑那些因素。
一旦新系统对原有系统的影响没有考虑到，后期可能会发生灾难性的问题。尤其做系统再构造项目的时候，前期必须弄清楚关联系统和人物角色。
数据字典
数据字典是罗列数据对象的数据域及其属性的一种数据模型。数据域是实体关系图中数据对象的补充细节。
数据域的属性详述了域的信息，包括数据执行的商业规则。数据字典通常在使用其他数据模型识别数据对象之后，
并且在数据对象需要指定更多细节时创建。数据字典可从现有系统中提取，以作为系统中所有数据的寄存器，并且可用作系统增强的输入。
它们通常与定义需求和验收标准一起创建。
数据流向图
数据流向图是描述数据在外部实体、数据存储和过程之间流动的一种数据模型。
外部实体可以是参与者或系统。数据流向图显示了每个过程的数据输入和输出。
决策树和决策表
决策树和决策表都是描述一系列决策和这些决策所导致的成果的规则模型。决策树和决策表都经常用于商业规则建模。
虽然两种决策模型的使用方式不同，但可能需要同时使用它们。决策树以可视化的方式显示了导致成果的决策和选择的流向，
并且可以显示有序排列的决策。决策表则有助于确保商业分析专业人士考虑了所有可能的决策场景及相应成果的组合。
虽然两种决策模型的使用方式不同，但可能需要同时使用它们。决策树以可视化的方式显示了导致成果的决策和选择的流向，
并且可以显示有序排列的决策。决策表则有助于确保商业分析专业人士考虑了所有可能的决策场景及相应成果的组合。
生态系统图
生态系统图是一种范围模型，显示了所有相关的系统、系统之间的关系，以及流经它们的可选的任何数据对象。
这些系统是逻辑系统（商业角度），因此可能与实际物理系统（实施角度）的结构图并不匹配。
事件清单
事件清单是描述触发解决方案行为的任何外部事件的范围模型。事件清单帮助定义解决方案必须做出反应或处理的范围内事件。
事件响应表是事件清单的延伸，用于描述系统对任何事件触发器的响应。
事件响应表是事件清单的延伸，用于描述系统对任何事件触发器的响应。
实体关系图
实体关系图也称为商业数据图，是一种显示产品中的商业数据对象或感兴趣的信息片段，以及这些对象之间的基数关系的数据模型。
基数是指一个实体和其他实体发生关系的次数，以及这种关系是否必需或可选。
在实体关系图中显示的数据对象不是数据库中确切的数据对象，而是从商业角度得到解决方案中数据的概念视图。
实体关系图有助于识别在系统中创建、被系统使用或从系统输出的数据。
当与过程模型一起使用时，实体关系图还可用于从过程的角度对重要数据进行建模。
基数是指一个实体和其他实体发生关系的次数，以及这种关系是否必需或可选。
在实体关系图中显示的数据对象不是数据库中确切的数据对象，而是从商业角度得到解决方案中数据的概念视图。
实体关系图有助于识别在系统中创建、被系统使用或从系统输出的数据。
当与过程模型一起使用时，实体关系图还可用于从过程的角度对重要数据进行建模。
特性模型
特性模型是一种范围模型，用树状或层级结构排列，以可视化的方式表示解决方案的所有特性。
大多数项目都具有不同层级的特性，顶层特性称为第1 级（L1）特性，其次是第2 级（L2）特性，等等。
特性模型有助于说明特性是如何组合在一起的，以及哪个特性是其他特性的子特性。
特性模型很实用，它们易于在单个页面中显示不同层级的许多特性，代表了整体解决方案的特性集。
大多数项目都具有不同层级的特性，顶层特性称为第1 级（L1）特性，其次是第2 级（L2）特性，等等。
特性模型有助于说明特性是如何组合在一起的，以及哪个特性是其他特性的子特性。
特性模型很实用，它们易于在单个页面中显示不同层级的许多特性，代表了整体解决方案的特性集。
目的模型和商业目标模型
目的模型和商业目标模型都是组织并反映与其他产品信息有关的目
的和商业目标的范围模型。目的模型通常显示了解决方案的相关方目的，并且指出了任何支持或冲突的目的关系。
商业目标模型与商业问题、商业目标和顶层特性有关。目的模型和商业目标模型通常都是在新项目集或项目的开始或更早的时候被创建，
以便于在项目组合中对项目集和项目进行排序。出于优先级目的，可以在任何时间点创建目的模型和商业目标模型。
商业目标模型与商业问题、商业目标和顶层特性有关。目的模型和商业目标模型通常都是在新项目集或项目的开始或更早的时候被创建，
以便于在项目组合中对项目集和项目进行排序。出于优先级目的，可以在任何时间点创建目的模型和商业目标模型。
过程流
过程流属于过程模型类别，用于以可视化的方式记录人们在工作中或与解决方案交互时所执行的步骤或任务。
通常情况下，过程流描述了人们采取的步骤，但也可用于描述系统步骤，称为系统流。
过程流又名泳道图、过程地图、过程图或过程流图。过程流可以分成多个层级，其中1 级（L1）过程流可用7～10 个步骤在高层级上显示完整的端到端过程。
L1 过程流中的步骤被分解为用户将要执行的下一级过程，用2 级（L2）过程流来表示。创建过程流可以展示原有和将来的商业过程，
以可视化的方式显示了对当前解决方案所做的变更或改进。过程流可能还附带更多的详细信息，以确保相关方能够理解每个步骤所发生的情况。
通常情况下，过程流描述了人们采取的步骤，但也可用于描述系统步骤，称为系统流。
过程流又名泳道图、过程地图、过程图或过程流图。过程流可以分成多个层级，其中1 级（L1）过程流可用7～10 个步骤在高层级上显示完整的端到端过程。
L1 过程流中的步骤被分解为用户将要执行的下一级过程，用2 级（L2）过程流来表示。创建过程流可以展示原有和将来的商业过程，
以可视化的方式显示了对当前解决方案所做的变更或改进。过程流可能还附带更多的详细信息，以确保相关方能够理解每个步骤所发生的情况。
原型、线框图和显示—操作—响应模型
原型、线框图和显示—操作—响应模型均为接口模型。原型是在构建预期解决方案之前的表示法，可分为低保真原型和高保真原型，
如屏幕布局草图是低保真原型，而交互式用户界面则是高保真原型。
线框图是原型的一种，专用于模拟用户界面设计，也用于呈现屏幕外观。线框图可以是低保真的，
如草图；也可以是高保真的，如能真实呈现最终用户界面外观样式。
显示—操作—响应模型采用扁平化的格式来描述页面元素及赋予每个元素的功能，通常与原型或线框图结合使用，
以连接用户界面元素需求和可视化的呈现方式。
如屏幕布局草图是低保真原型，而交互式用户界面则是高保真原型。
线框图是原型的一种，专用于模拟用户界面设计，也用于呈现屏幕外观。线框图可以是低保真的，
如草图；也可以是高保真的，如能真实呈现最终用户界面外观样式。
显示—操作—响应模型采用扁平化的格式来描述页面元素及赋予每个元素的功能，通常与原型或线框图结合使用，
以连接用户界面元素需求和可视化的呈现方式。
用户界面的设计可能由用户体验专家或用户界面分析师来完成，
商业分析则用于确定用户界面在解决方案的不同状态中如何显示和运行、如何协同工作，以及如何与底层商业逻辑进行交互。
商业分析则用于确定用户界面在解决方案的不同状态中如何显示和运行、如何协同工作，以及如何与底层商业逻辑进行交互。
报告表
报告表是描述单个报告的详细需求的接口模型。报告表既包括报告的整体信息（如报告名称或根据报告做出的决策），
也包括域级别的信息（如数据域的显示及计算）。
也包括域级别的信息（如数据域的显示及计算）。
状态表和状态图
状态表和状态图都是用于显示对象的有效状态并允许在它们之间进行过渡的数据模型。
对象可以是在分析解决方案时的商业数据条目或任何感兴趣的信息。
对象可以是在分析解决方案时的商业数据条目或任何感兴趣的信息。
故事地图
故事地图是一种根据用户故事的商业价值和用户通常执行它们的顺序来对用户故事进行排序的技术，
以便团队能够对将要构建的内容有共同的理解。故事地图有助于将能力分解为用户故事，并且可用于识别用户能力差距。
以便团队能够对将要构建的内容有共同的理解。故事地图有助于将能力分解为用户故事，并且可用于识别用户能力差距。
系统接口表
系统接口表是为单一系统接口获取所有详细层级需求的一种接口模型。系统接口表的创建使得每个系统与解决方案系统建立连接。
系统接口表中的信息包括：系统之间传递的数据域、数据传递的频率和数量，以及确保数据被正确传递和存储所需的确认规则等。
系统接口表中的信息包括：系统之间传递的数据域、数据传递的频率和数量，以及确保数据被正确传递和存储所需的确认规则等。
用户界面流
用户界面流是一种接口模型，显示了功能设计里特定的用户界面和常用的屏幕显示，
并且描绘了用户如何在界面间导航。用户界面流可以和过程流或用例组合使用，有助于以可视化的方式显示用户与系统的交互场景。
并且描绘了用户如何在界面间导航。用户界面流可以和过程流或用例组合使用，有助于以可视化的方式显示用户与系统的交互场景。
用例图
用例图是一种范围模型，显示了解决方案范围内的所有用例。
创建用例图包括识别解决方案的使用者和每个使用者将如何使用解决方案的可能场景清单。
用例图把用户和相关用例相关联，并且确定哪些用例在给定解决方案的范围内，哪些在范围外。有
创建用例图包括识别解决方案的使用者和每个使用者将如何使用解决方案的可能场景清单。
用例图把用户和相关用例相关联，并且确定哪些用例在给定解决方案的范围内，哪些在范围外。有
以下内容引自https://blog.csdn.net/mxw2552261/article/details/79447798。
流程图
流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）产品经理做需求前一定要先把这些逻辑关系理清楚，如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。
图就是将你头脑中的逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，因为是图，你可以像你的版本迭代一样，当你的逻辑需要修改的时候拿出来迭代一下，同时因为有图，你还可以更好的给项目成员进行宣讲。
产品中设计的流程图主要有三种，业务流程图、任务流程图、页面流程图，下面我们来一一介绍。
业务流程图
业务流程图又称为泳道图，就是描述那些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：
1. 涉及到哪些主体？
2. 每个主体都有哪些任务？
3. 各个主体之间怎么联系的？一般涉及到多个主体，每个主体之间有联系。
任务流程图
泳道图一般是从战略上分析整个业务流程，让你对公司所做的业务有个大概的了解，而任务流程图就是在你的产品操作上，用户通过什么样的操作来完成它的目标，比如你去银行ATM机器上取钱，你是如何一步步操作把钱取出来的。
如果说业务流程图帮助你梳理战略，任务流程图帮助你梳理用户操作行为（主要给程序员看）、页面跳转流程在帮助你梳理各个页面之间的跳转关系（主要给UI和前端程序员看）这是一个逐步从整体到局部，从后端到前端的过程。
所有的产品都是由页面组成的，不论是APP、PC、H5都是由一个个页面组成的，页面流程图描述完成一个任务需要经过哪些步骤，你在画图的时候只需要清晰的表现出用户点击页面的什么地方，然后跳转到那个页面。主要由页面、行动点、连接线组成。
UI设计图标注
对于APP的页面，UI设计师会给出UI设计标注图，这样APP客户端开发人员，直接按照标注图进行页面的开发了。
产品设计完成后，架构师需要对产品进行软件的架构设计。包括技术的选型，模块的划分，开发人员的任务分配，工作量的评估等等.....
系统架构设计图
构架将在一次又一次迭代中不断演化、改进、精炼。
序列图
架构师一般在做详细设计的时候，会把程序模块之间的每一步调用过程很详细的画出来，这样开发人员拿到设计文档，就能直接开发。
设计图有很多种，还包括用例图，状态图，活动图...... 不再一一介绍。画什么样的设计图，不是绝对的，不同公司，不同项目，需要画的设计图也是不同的，有些项目需要画原型图，有些项目只是对外提供服务，没有页面也就不需要画原型图。另外还要根据项目的工期，预算等等因素考虑。如果一个项目的工期也就一个月甚至更短，那基本上就是怎么简单怎么快就怎么做。
