从目的出发,后台系统是管理的建模,是指标、制度、责权利、流程的建模。
微信公众号: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
网友评论