从目的出发，后台系统是管理的建模，是指标、制度、责权利、流程的建模。

微信公众号：weitalks

总结：后台产品设计，最难的是抽象出实体以及实体的关系和相互动作，还有实体动作的各种case。基础工作是角色-流程-实体，抽象出哪些不变定了或重复形成规律了，哪些会变了，变了会怎样（建议设计成多对多）

目录：

1、设计管理系统时应该知道的点

2、相关图介绍

3、需求管理的参考思路和步骤

设计管理系统时应该知道：

1、管理系统分析：

凡是做管理系统的，相关制度文件是重要的需求分析来源，且管理系统是对人、事、物、条件/场景、规则的管理建模。所以思考时首先从管理上思考优化解决问题，再从软件系统思考优化解决问题。

to  c产品事件之间没有很强关联，着重场景；to b产品因为事件很多且事件之间强关联，着重流程。

2、一个系统需具备：

人事物可记录、数字化、可追踪、系统化（联系不孤立）、有边界（条件/输入/输出/规则）、可衡量（指标和量化）、标准化（去重）、流程化、自动化、可配置、可监控、是否可撤销、安全/隐私、可扩展、可回收、重要程度、频率。

3、需求分析的思路：

to c产品：

to b 产品：

上面业务分析欠妥，按下面来：

在第一阶段的分解我们可以看到以主题域为主线索，具体的分解过程为目标系统-》主题域-》业务事件，其核心就是要将主题域或子系统作为一个黑盒来分析，搞清楚边界和其于外部用户的交互，通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了，即业务事件+报表需求。

到了第二阶段则是以业务流程为主线索进行分解，具体为业务事件-》业务流程和业务活动-》领域类图和用例。在这个阶段我们看到两个重要输出，一个是静态的领域类涉及到领域建模，而领域建模的重点就是标识类，明确类之间的逻辑关系和数量关系，添加重要的结构规则。另外一个就是动态的用例

需求采集：计划、渠道、活动、内容

需求评审：筛选、分类、排序、审计

4、需求规格说明书包含以下几个要素:

4.1、背景/术语/约束-条件

4.2、目标/范围/指标/盈利模式/产品风险

4.3、涉及人员、组织架构和权限

4.4、产品架构、总体业务流程和功能清单

4.5、功能-业务规则/功能类型/业务实体/业务流程：业务实体一览图-类图/活动图/状态图

         业务规则包括模块、功能、详细业务逻辑描述、功能类型、涉及系统

4.6、详细设计，包括角色说明、业务/操作流程、界面设计、字段描述及操作逻辑

4.6.1、功能性需求，包括非用例功能性需求

4.7.2、非功能性需求：架构/接口/安全/性能/界面

4.8、参考文献/版本修订记录

要求：需要系统做什么描述清楚，可行性/无二义性/可验证性

5、需求分析时产出文档：

5.1、背景调查表

5.2、涉众问题表

5.3、条件/目标/范围/指标（项目双赢成功）

5.4、制度文件、现状组织架构图和分权手册、现状流程架构、上下文关系、现状业务流程

5.5、功能范围及与其他系统关系、流程架构总图、技术架构图、数据接口图、数据库/报表

5.6、一级/二级/三级/四级/五级流程图、五六级操作指导手册、流程清单/树状图

5.7、沟通及管理制度、绩效指标、部门角色岗位职责表、执行者/用例图

5.8、可能产生的新问题

5.8、问题分析表、需求变更表/版本更新记录、版本管理

6、一个用例通常包含以下几个要素：

触发事件（谁干了什么，触发了这个用例）、假设和约束、目标/主题范围/层次/指标、执行者、相关利益者、前置条件（在触发该用例相关操作前，用户、系统、商品等角色和业务实体必须达到的条件或状态）、后置条件（用例技术后系统所处状态）、最小保证、成功保证、业务规则（基于对象各种目的和实体各种状态抽象出来的场景和行为规则）、主成功场景-主流程/目的-步骤、分支流程、异常流程、数据变化、技术变化、输入/输出（表单/报表/接口）、重要程度-优先级、频率、发行版本、响应时间、执行渠道/平台。

其中业务规则：行为/数据/界面的要求
行为：主题域-》事件-》活动-》用例-》步骤

案例：买东西（完整正式版本）

主执行者：请求者

语境中的目标：请求者通过系统买东西，并得到说买的东西。不包括付款方面的内容。

范围：业务——整个购买机制，包括电子的和非电子的，正如人们在公司中说见到的一样。

层次：概要

项目相关人员和利益：

请求者：希望得到她订购的东西，并且操作要简单。

公司：希望控制花费，但允许必要的购买。

供货商：希望得到任何已发货物的货款。

前置条件：无

最小保证：每一个发出的订单都已经获得有效认证者的许可。订单具有可跟踪性，以便公司只对收到的有效货物开账单。

成功保证：请求者得到货物，修改预算，记入借方。

触发事件：请求者决定买东西。

主成功场景：

1．  请求者：发起一个请求。

2．  批准者：检查预算中的资金，检查货物的价格，完成提交请求。

3．  买者：检查仓库的存货，找出最好的供货商。

4．  认证者：验证批准者的签名。

5．  买者：完成订购请求，向供货商发出PO（订单）。

6．  供货商：把货物发送给接收者，得到发货收据（这一点超出了本系统的设计范围）。

7．  接收者：记录发货情况；向请求者发送货物。

8．  请求者：设置请求已被满足标志。

扩展：

1a）请求者不知道供货商和货物价格：不填写这些内容，然后继续。

1b）在收到货物之前的任意时刻，请求者都可以修改或取消请求：

如果取消，则把这个请求从执行处理中取消。（从系统中删除吗？）

如果降低价格，则不影响其处理过程。

如果提高价格，则把请求送回批准者。

2a）批准者不知道供货商或货物价格：不填写这些内容，留待买者填写或返回。

2b）批准者不是请求者的经理：只是批准者签名仍然可行。

2c）批准者拒绝申请：送回给请求者，要其修改或删除。

3a）买者在仓库中找到货物：将存货先发出，并从申请者要求的总购买者中减去已经发出的这部分货物量，然后继续。

3b）买者填写在前面活动中没有填写的供货商和价格信息：请求重新发回给批准者。

4a）认证者拒绝批准者：发回请求者，并将此请求从执行处理中取消。

5a）请求涉及到多个供货商：买者创建多个PO

5b）买者将多个请求合并：相同的过程，但是用被合并的请求标记PO

6a）供货商没有按时发货：系统发出没有发货警告。

7a）部分发货：接收者在PO上做部分发货标记，然后继续。

7b）多个请求PO的部分发货：接收者给每个请求分配货物数量，然后继续。

8a）货物不对或质量不合格：请求者拒绝接收所发送的货物。

8b）请求者已经离开公司：买者同请求者的经理进行核实，或者重新指派申请者，或者返还货物并取消请求。

技术和数据变动列表：无

优先级：多种

发行版本：几个

响应时间：多样

使用频率：3/天

主执行者的渠道：网络浏览器、邮件系统或类似系统

次要执行者：供货商

次要执行者的渠道：传真、电话或汽车

未解决的问题：

什么时候从系统中删除被取消的请求？

要取消一个请求需要那些权限？

谁能修改一个请求的内容？

请求中需要保留哪些修改历史记录？

当请求者拒绝已经发送的货物时，会发生什么情况？

申请和订货在运作上有什么不同？

订购如何参考和使用内部存货？

相关图介绍

结构建模主要分析系统业务的概念及其关系，行为建模的工作，主要是分析系统的业务流程.

结构建模：类图，对象图，构建图，部署图，包图。

行为建模：活动图，状态机图，顺序图，通信图，用例图，时序图

活动图：

顺序图：

涉及角色之间交互频繁

下面是基本语法

：

案例

有条件分支下：

状态图：

用例图u：

角色who在哪个系统上做了什么事情。

用例表模板：
目标，规则说明，条件，流程，异常，结束状态。

部署图：

和拓扑结构很相似

结构图：

包：

表示用户之间的关系

实战：考勤系统

做to b项目是双赢。

分析思路：

业务分析：结构建模和行为建模

战略分析/背景：

需求分析（目标/涉众/待解决的问题/范围/范围/项目成功标准）

目标：

涉众/待解决的问题

越是高层的涉众越容易准确全面提出自己期望，越是基层员工越容易提出界面级别的要求

范围：

项目成功标准：

考勤系统的业务概念分析：可以用类图来画业务概念图

类图分析的步骤：

实体，属性，关系。

业务概念图的重要程度和高难度：吃透需求和业务、数据库设计

打卡记录：

请假申请：

请假类别既可以作为属性，又可以作为类。因为请假类别比较重要，可以抽象出类。

外出申请：

1）审批活地图

2）审批状态机图

3）申请类图

外出申请审批内容，数据库表可以不必按照上图设计这么多类，在数据库中设计一张表就可以了。写这么多是想让自己工作占据主动。

管理系统的进一步思考：

如何应对多变的流程？

执行者与用例分析：

执行者有人或者系统两种。

普通员工的用例分析：

用例表：

根据之前贴出的用例表模板来填

行政员工、财务员工用例分析

部门经理、总经理用例分析

用例分析总结：

非用例的功能需求

系统的非功能性需求：

安全、易用、性能、接口

如何编写需求规格说明书？

有先天缺陷的MIS系统：

财务软件、CAD软件等行业软件能立马提高用户的工作效率，能很快为用户带来实际的价值，这类软件很容易做到受用户欢迎。这类软件与MIS系统最大的区别是，这类软件改善的是用户的工作技术和工作技能，而MIS系统改变的是管理习惯、工作思维习惯。MIS系统的实质就是用一套新的管理思想和工作习惯来要求你，它是管理思想的载体，并不是所谓的办公自动化，无纸办公这样的表面化东西。

如何打造有竞争力的MIS系统？

要熟悉该客户的业务，至少需要在客户的公司工作几个月

怎样才能做一个能适应需求变化的设计呢？

如何让团队队员也了解需求？

如何让客户签署几十页甚至上百页的需求文档？

确认不同级别的需求：

让客户全方位参与需求：

需求过程

下图中的需求开放改成需求开发

问题定义&&鱼骨图：要素

业务事件/模块/报表：

获取模板

需求管理：

1、需求管理项：

2、基线、优先级、工作量评估：

需求基线：目前特定版本下将投入开发的需求。

优先级评价对象一般是每个主题域下的需求，评价类型一般是关键/重要/有用/一般。

所以在进行优先级评价之前，先整理目前基线需求内部各个需求的关系，也就是wbs结构。

优先级评价：业务价值（需求来源成本产出用户频率规模）》技术开发》项目管理

需求来指的是老板合作方内部等

需求拆解和优先级划分

敏捷开发除了简化流程，还可以对完整的需求、完整的产品进行拆解，拆解的前提是，保证每一个模块都是完整独立。也就是说，这个拆解出来的单独模块是能够走通一个分支流程的。

需求的拆解，需要遵循的是：独立模块，能够走通分支流程。

例如，一个电商产品，其可能包括有商品、物流、评价、退货、优惠券等需求。如果要对这个产品的需求进行拆解，应该如何拆解？假如把商品模块单独出来，所做出来的产品能够管理商品，但是做出来之后也不可能能够使用，这时候用“独立模块，能够走通分支流程”的原则来代入，商品模块没有满足“走通分支流程”，有商品却不能购买，不能走通购买的流程，因此，这样拆解所做出来的产品，即使上线了，也是不能够使用的。

优先级的划分，可利用KANO模型来进行分析：基本型需求、期望型需求和兴奋型需求。基本型需求是一个产品需要最先满足用户的，因此，对于一个从零到一的产品来说，这个是应该优先去做的，从基本需求到期望型需求，再到兴奋型需求，是一个从零到一的产品循序渐进的过程。

优先级的划分，可利用KANO模型来进行分析：基本型需求、期望型需求和兴奋型需求。基本型需求是一个产品需要最先满足用户的，因此，对于一个从零到一的产品来说，这个是应该优先去做的，从基本需求到期望型需求，再到兴奋型需求，是一个从零到一的产品循序渐进的过程。

产品策划提前两到三个版本的好处是，当开发过程中发现有余量时，可以把后续版本中的一些小的需求提前穿插到当前版本。

一般而言，在一个版本里面，我只会设置一到两个重点的需求，其余需求皆属于可调整范围内。版本的重点不是看某个需求体量的大小，而是看这个版本的产品目标是什么。每个版本的产品目标都是在进行版本规划时已经明确下来的了。比如我会把电商类产品的需求分为四大类：拉新、留存、活跃、销售。

工作量估（人周/人天）算：分主题域/分权重

基线划定，迭代和管理：

划定基线时按优先级筛选

3、迭代：

产生原因：如果一次迭代完成不了这些优先级的需求，可以分成不同的迭代。

迭代安排：

搜集每个需求对用户业务的价值、成本、风险、需求的规模、需求之间的依赖关系以及一次迭代可完成的工作量等方面的信息,然后确定出多个对于下一次迭代可行的需求组合.

可行的需求组合:

在满足可用工作量和依赖关系限制条件下,应优先选择那些优先级高的需求组合

BUG>>影响付费>>影响客户核心行为>>客户>>公司战略>>需求价值做与不做的影响

4、变更：统一渠道受理/统一管理平台记录

变更放在待处理需求。

注意变更产生的影响。

变更影响范围：行为/功能/数据/界面/系统非功能性/业务规则影响

常见变更类型：

变更管理平台：

5、需求跟踪：单个需求与系统（业务规则/架构/源代码/数据库/用例/文档）之间的关系。

收集/评估/审核/变更影响分析/维护

延伸：

如何发现职责？职责强调的是对目的、目标、行为的抽象

对象是行为和数据的统一体。职责来自于你的软件是如何工作。来自于软件的HOW。寻找和分配职责需要灵感，是一个创造性活动，是一个充满探索冒险发现新奇的乐趣活动，从下面几个方面寻找需求中职责：

1.来自用例分析中顺序图消息发送。

2.构造invention、 约束表达、策略、算法、规格和描述都可以成为职责。

3.系统要做的事情或要管理的信息

4.将实体对象看成一个演员(拟人化)，扮演一个角色应该知道哪些事情knows something、会做那些事情do sth.，能够控制或决定什么事情。

另外可以看看这篇 业务建模的推导过程，业务系统模板可参考这个 

复习时记得看看《火球UML》、《UML和模式应用》、《对象设计：角色、责任和协作》、《编写有效用例》、《OO系统分析员之路》

业务流程图：

http://blog.csdn.net/k7Jz78GeJJ/article/details/78644507?locationNum=3&fps=1

·