Tagged with 需求分析

[需求分析培训] 非功能需求-(6)

1、用户看不到的功能几乎都是非功能需求; 2、对非功能需求做定性描述就会千篇一律无法引起开发重视;如果定量描述又十分困难;所以一般采取场景化的方法描述。下图为目标场景决策卡:   场景有需求人员写,决策和理由风险由开发人员写; 3、UI要求: 1)需求文档中的UI不是最终设计,这点需要跟开发强调,只是约束(用户的要求)和建议(需求人员根据自己对用户需求的理解给出的建议); 2)UI需求要包含交互过程、静态页面和设计元素的说明; 4、易用性: 1)共性:行为支持 2)个性:信息呈现方式、功能布局、功能交互模式、出错提醒 5、用户帮助手册的结构:角色(作为一级目录)+场景(作为二级目录) 6、给客户演示时,让客户第一次就注意产品功能,而不是在界面上挑毛病。功能的缺陷不解决,界面反复改也不会满足客户的真正需求。   ——————需求分析训练营的全部内容结束了——————    

[需求分析培训] 理清数据架构-(5)

1、数据需求包括如下几点: 1)*数据关系——多用领域类图表示; 2)数据构成和派生方法——DD/决策表、决策树、公式; 3)数据与流程的关系——CRUD矩阵; 4)长生命周期的对象的变迁过程——状态机图; 2、类图——类之间的三种关系 1)关联:用一条直线连接; 2)整体部分之间的聚合关系:用直线加菱形连接; 3)类别:用连接; 备注:聚合中松散和紧密的区别举例说明 a)例如部门和员工之间的关系,部门由员工组成,但删除了部门员工不一定删除,所以二者之间算作松散聚合; b)订单和订单项之间的关系,订单由订单项组成,删除了订单,订单项也就随着删除了,所以二者之间算作紧密聚合; 3、领域建模方法——彩色建模:用红、黄、绿、蓝集中颜色。 1)先用红色表达出过程数据; 2)再用黄色表达出角色; 3)其次用绿色表达人、地点、事物; 4)最后用蓝色表达出规则和可配规则等; 一个示例: 备注: 1)缺红和绿,整个图画的不对; 2)缺黄,不灵活; 3)黄外必有绿;    

[需求分析培训] 理清行为脉络-用例和用户故事-(4.1)

用例和用户故事的区别: 范围不同:用户故事包含的范围小于用例,一个事件流就可能是一个用户故事, 标准不同:用例的粒度是以业务分工为标准的,用户故事的粒度是一开发量为标准的; 描述不同:用例通常写的比较详细,用户故事写的比较概括;用例描述比较契约化(有固定的模板),用户故事的描述比较不正式。   (一)用例 用例图一些方法铺天盖地的,也可以直接到这里看看 本文只记录本次培训老师讲的内容 1、用例中的actor是相对系统来说的一个角色,use case 是用户要达到的目的;另一个方面,end user 是终端客户,不见得等价于actor;function是实现的功能,不能等价于用例; 2、用例是用户通过系统完成的特定的工作,实现特定的业务价值;一个用例的粒度是可以通过人来判断的,没有统一的标准;一般情况下,一个完成的、不会在分的(是指不会分成多个人分步完成)、可汇报的粒度就可以了。由于分工不同,用例的粒度也不同; 3、举个例子说明 技术动词+业务名词不一定等于用例:        1)“新增图书”这类不是用例,是功能;(给销售介绍产品时,也要介绍产品的价值,而不是产品的功能。销售给客户介绍时同理。)      2)用例是要有场景的,针对前面的功能,可以这样思考“什么时候需要新增图书呢?”; 4、通过一个用例图说明:   1)用例之间的三种关系:      a)包含:被包含的一定会执行,例如预订座位是一定要去检查座位信息;      b)扩展:扩展的优先级低,不一定会被执行的,例如预订座位时不一定要处理等候队列;      c)泛化:后期抽象出来的,例如办理结账可以分为现金和银行卡; 2)actor之间的关系:可能会有泛化关系,表示角色之间权限的继承。 3)从用例指向actor表示调用外部系统或者通知外部actor; 4)各个用例之间不能有判断产生分支的情况,因为用例图主要强调的是人到事之间的关系;   5、如何识别用例?一般采取流程派生发,也就是通过前期调研访谈和分析得到的流程图来抽取用例,具体步骤如下: 1)在泳道图中,把不是end user的泳道、泳道内的活动和判定去掉; 2)对剩下的各个泳道做角色画的抽象; 3)判断每个活动,需要系统实现就留着,不需要系统实现就忽略掉; 4)对每个判定菱形做一次判断,属于某个活动不需要系统支持的就忽略,其他的不属于某个活动且需要系统单独支持的就抽象成一个用例。   (二)用户故事 1、用户故事不适合强流程系统,一般大项目的早期都不会用到,除非新增几个小功能的时候可以采用; 2、用户故事一般的过程是这样的: 1)找几个人代表不同的角色,用”作为××角色,我希望系统提供××功能“的巨型表达需求; 2)让开发估算工作量,2人周能否实现这个故事?如果能就结束,如果不能,拆开故事,描述一个更小的故事,直至估算通过;  

[需求分析培训] 理清行为脉络-(4)

这一部分主要讲确定业务范围后做的业务分解。 涉及到的图包括:跨职能流程图、活动图、用例图。 1、stakeholder 关注的是管理效益,引入信息化系统的目的是实现商业价值。所以通常在项目规定的业务范围内划分几个业务模块,对应事件列表、管控点列表和场景列表;对功能来说主要进行流程分析和场景分析;对数据来说需要进行领域建模;对质量来说需要分析质量场景。 2、一个信息化的系统,操作者关注的是自己要使用的具体模块,关注自己要做哪些事儿;而管理者是通过流程关注大家分工协作完成的一个具体的事件。 3、信息化系统中流程的本质是: 1)有目标:一个流程是否合理是从整体来评价的,所以一般做操作层访谈时不会涉及流程的事儿,因为他们不关心; 2)整体打通,有优先级:流程是系统交付的最小单元,如果一个业务流程只交付其中的几个步骤,那么对用户来说是无法正常使用的,也就是没有价值的,跟没交付一样。不同流程的优先级也不同,可以分步骤开发持续交付; 3)有层次:流程要分层次描述,例如有组织级、部门级和个人级别的。(例如组织级的流程,泳道图每个带区就是部门;部门级流程各泳道就是岗位) 4、描述流程会用到的一些工具,例如泳道图(注意避免长途线,当两个节点离很远又要相连时可以采用一个圈做过渡)、活动图(也是泳道图的一种,但目的不是表示流程,而是为了强调活动的内容,并且可以画并行和异步)、时序图和数据流图业务分析时不常用。 5、客户访谈现场出图: 1)一听:客户陈述时中途不打断,根据用户描述画出草图; 2)二问:从五个方面询问客户,细化草图 a)把客户描述时涉及到“部门”的地方转成“岗位”;(例如:这件事儿是这个部门的什么人负责) b)画出分支和判断条件; c)明确异常(什么是异常?例子我忘了) d)明确数据的展现形式,例如是否有固定的表单? e)规则 3)三读:把大概的图给用户讲一遍,达成共识; 6、流程为什么会变?——>从哪些角度优化流程? 流程为什么会变?因为企业的观点在随着企业的发展不断的变化,例如企业发展可以分为四大阶段,如下图:其中初创到成熟阶段流程变化会比较频繁。 如何优化流程?大约有如下四种方向: 1)删除无效:把无效的、不产生价值的流程删掉;(如果一个流程并没有带来什么效益,那么就不必费力开发和定制流程了) 2)简化高频:一个经常使用的流程,要进行简化; 3)整合依赖:互相有依赖关系的流程整合在一起;(例如现在的一站式办事大厅,把相互之间有依赖的办事窗口安排在一个大厅里) 4)自动化繁琐:繁琐的、重复性高的、枯燥的可以考虑自动化; 7、从业务角度描述功能时,用例对应场景(context);用户故事强调的是why;   》》未完待续,容我休息下再补充用例和用户故事的内容~

[需求分析培训] 规划项目的业务范围-(3)

这一节主要包括界定各个主题域,识别事件和管控点; 涉及到的工具是构件图; 但实际上这节的内容多为科普类,我感觉看看如何画构件图还是有必要的,经过老师这么一讲就清晰多了,不用死记硬背哪些符号的含义鸟~关于业务范围划分的内容下篇博客会有补充。   1、范围是无法通过问客户问出来的,需要我们自己紧扣目标和干系人的场景和核心需求识别出业务范围; 2、将一个大系统划分主题域是为了控制复杂度;究竟分即成合适,分到什么程度合适,都要根据要达到“控制复杂度”的目的决定; 3、划分子系统可以按照以下几个角度划分:划分的时候需要注意,子系统或业务子系统对组织架构是有映射的。 1)流程 2)业务场景 3)管理需要:例如报表、BI(Business Intelligence 即商务智能)、DM/DW(数据仓库/数据挖掘) 4、阶段和迭代的区别:  1)阶段是以任务是否结束为标志;  2)迭代是以时间是否结束为标志; 5、基线的目的是使需求可版本化,因为瀑布是做不到的。 6、其实SA(系统分析)应该是包含三方面的:BA(业务分析)、RA(需求分析)和Architecture(架构); 7、按照系统菜单(或者模块)进行的分析有利于开发,但不利于与客户沟通确认,容易漏掉客户的需求;按照业务场景分析有利于客户,但却不利于开发做设计; 8、如何画构件图 1)按照职能或者业务,列出不同的构件; 2)如果两个构件之间有联系,就说明两者间有接口; 3)每个接口之间,提供数据的构件和接口之间用实直线连接; 4)如果一个构件需要从接口取数据,就画一条从构件指向接口的虚线,空心箭头指向接口。 一个构件图的示例: (自己用rose没画出来,主要是找不到接口和实线怎么画出来,囧,先贴个老师给的图吧) 9、事件梳理是需求的关键,一般我们可以把事件认为是个流程。 10、分工是流程出现的开始,为什么会有分工咧? 1)规模增加了; 2)为了降低风险,所有共奏都交给一个人做是有风险的; 3)专业化,没项工作交给更专业的人去做; 【有了分工就有了活动,各个活动之间就需要协作。】 11、定义流程关注的三个要素:(因为有了分工,才需要有流程,如果没有分工,所有工作都一个人完成就不需要流程了。) 1)哪些事务需要定义流程——可以找出驱动事件; 2)如何定义有效的流程; 3)如何改进和优化流程; 流程的特点是一个入口,多个出口; 12、事件的边界是可以变化的,例如对于超市来说,客户购物的事件可以从客户进入超市选购到结账这个过程,也可以是用户做免费购物车到超市购物后坐免费购物车离开的这个过程; 13、活动是一个可以汇报的基本单元; 14、业务测试中,流程测试的优先级应该高于国内测试,需求找好的事件及流程可以作为测试用例设计中的参考依据。 15、大家对估算的误解,认为估算应该是准确的,一旦发现实际与估算有偏差就认为估算没用,其实估算不必要是准确的,估算是为了计划和监控,可以随时调整。 16、信息化的作用: 1)流程固化优化 2)数据辅助决策