《{企业通用培训}需求分析师培训-3》由会员分享，可在线阅读，更多相关《{企业通用培训}需求分析师培训-3（161页珍藏版）》请在金锄头文库上搜索。
1、需求分析师培训,Day03,Agenda,需求建模实例 业务流程与规则分析 数据需求分析与建模 需求描述最佳实践 需求管理最佳实践 需求过程总结,Agenda,需求建模实例 业务流程与规则分析 数据需求分析与建模 需求描述最佳实践 需求管理最佳实践 需求过程总结,需求建模实例确定业务需求,总经理：为什么我们的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是甚至无法给出一个相对比较明确的延迟时间。这样给市场的推广会带来很大的影响，不确定因素使得应对十分困难。 研发经理：唉这个问题我花了很多时间来解决，但一直收效不好。最初我用WBS方法，根据用例包、用例的方式来组织需求，然后将某个用例或子
2、用例作为工作任务分配的开发人员，并指定了相应的完成时间，但到了时间开发人员总是完不成，都反应时间安排不合理。后来，在技术顾问的指导下，改为自底向上的估计方法，任务明确后让开发人员反馈工作量及所需的工作天数。虽然有所好转，但还是有一些工作任务，开发人员反馈的天数到了，仍然无法完成，甚至无法告诉我要延迟多少天。汇总起来，就形成了这样的结果了。 总经理：这样呀，那有什么好办法呢？ 技术顾问：其实问题的关键还是在于“估算”的经验上，对于软件开发而言，实际上没有万能的、准确的估算公式,需求建模实例确定业务需求,（研发经理抢过话题） 研发经理：对对对！我一直在尝试使用FP、COCOMO模型来，仍然得 不出
3、合理的估计值，真难办。 技术顾问：呵呵，急了！其实估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的。因此关键在于积累这种经验数据。例如，我在编写技术书籍时，就采用了PSP（个人软件开发过程）的思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总是能够比较的准确。 总经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？ 技术顾问：呵呵，这是当然。PSP是个人软件开发过程，它本来就是为软件开发设计。它是CMM的创始人提出的，PSP、TSP和CMM分别针对
4、软件开发员、软件开发小组和软件开发组织。通过PSP的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。,需求建模实例确定业务需求,研发经理&总经理（几乎同时）：那我们就尝试一下！ 技术顾问：哈哈，不过贯彻PSP有两个困难。一是开发人员很难适 应，每天都要记录自己的工作时间很繁琐，而且产生数据不容易使用； 二是时间日志做出来后，管理者会忍不住用来考核开发人员，给他们带 来心理压力。 研发经理：那我们可以开发一套软件来帮助他们记录，通过写到数 据库中，这样数据的使用问题也就解决了。 技术顾问：对，这就是我的建议。那后者呢？ 总经理：我们不考核就是了！ 技术顾问：没那么简单！我认为要从以下
5、几点来进行：一是鼓励，鼓励记录时间日志，奖励估算准确的开发人员，从而避免做假时间的情况；二是宣扬，宣扬有效工作时间的概念，我的经验是每个开发人员一天有效的工作时间在4个小时之上就是比较好的，树立这种概念能够打消开发人员的顾虑；三是培训，从理论高度建立开发人员执行PSP的意识。,需求建模实例确定业务需求,总经理：好！我修订绩效考核，解决鼓励问题；小陈(研发经理)，我配合你树立“每天有效工作4小时”的概念；至于培训嘛只好拜托你了。 技术顾问：好！没问题。,为开发人员提供一个PSP工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。,需求捕获,技术顾问：根据我的经验，整个系统应该
6、包括以下几个主要的方面。第一，项目及任务安排，由研发经理或项目经理创建项目和任务，开发人员在接到任务后进行估算填写时间计划，研发经理或项目经理对其进行确认。第二，时间记录，开发人员对自己的开发时间进行记录，与任务关联起来。第三，产能分析，研发经理及公司领导可以根据任务和相应的时间记录，来统计公司员工的产能数据。 开发人员甲：我认为，开发人员自己应该能够通过这套系统来统计自己的产能数据。 研发经理：那么产能数据怎么表示呢？任务可是不同的呀。 技术顾问：我认为比较合适是KLOC/天(每天编写的千代码行数)。 开发人员乙：但不同的程序KLOC可能接近，但难度不同所花的时间是不同的。 技术顾问：对，我
7、们可以在每个任务中加上难度系数，产能中的KLOC=实际的KLOC*难度系数。 研发经理：那么测试任务怎么算？,需求捕获,技术顾问：我认为这套系统主要关注的是开发时间、而对于前期的分析和概要设计，以及后续的集成和系统测试等工作可以先忽略，放在系统范围之外，这里只考虑详细设计、编码和相应的测试工作。 研发经理：我明白了，就是对于一个任务而言所花的时间。对，这样比较合理。 开发人员甲：我希望系统能够在让我们填写估算值时，可以查询历史数据，否则仍然没有意义。 开发人员丙：查询历史数据时，还应该有类别吧！这样我们才能够根据自己将要完成的任务情况找到有参考依据的统计数据。 开发人员乙：还有就是时间记录一定
8、要方便，另外像我们这样经常要在现场开发，如何完成时间记录？ 研发经理：可以考虑有一个离线版本的时间记录程序，等回公司连接服务器后再进行数据同步。 ,获取需求特性表,建立概念模型发现类,建立概念模型关联分析,建立概念模型职责分析,建立用例模型识别参与者,建立用例模型合并特性获得用例,建立用例模型合并特性获得用例,建立用例模型绘制用例图,建立用例模型简要描述用例,建立用例模型划分用例优先级,建立用例模型详细描述用例,建立交互/状态模型,用户界面设计,Agenda,需求建模实例 业务流程与规则分析 数据需求分析与建模 需求描述最佳实践 需求管理最佳实践 需求过程总结,业务流程是信息系统的主脉落 业务
9、规则是变化的要点,什么是流程,目标性：有明确的输出 内在性：包含于任何事物或行为中 整体性：至少由两个活动组成 动态性：由一个活动到另一个活动进行 层次性：组成流程的活动本身也可以是流程 结构性：串联、关联、反馈等,流程设计的原则,流程应以产出为中心，而非任务为中心 让那些需要得到流程产出的人自己执行流程 将信息处理工作纳入产生这些信息的实际工作中去 将各地分散的资源视为一体 将并行的工作联系起来，而不是仅仅联系他们的输出 在决策点位于工作执行的地方，在业务流程中建立控制程序 流程多样化 单点接触客户,在IT系统中实现流程设计的本质,绘制流程图的核心步骤,提出业务流程清单：确定有哪些流程、流程
10、之间的界限，然后才是对流程的描述 流程的要素描述：针对清单上的每一流程，分析并识别现有业务活动、活动之间的关系、活动需要接受哪些信息、产生哪些数据（表单）、数据传送的路线、活动涉及哪些岗位等。重要抓住核心业务和主要活动点，部门内/外衔接、工作繁琐/反复环节、成本高/效率低/时间长的环节、任务转手次数多的环节 绘制流程图：跨职能流程图、带泳道的活动图,流程的ESIA,E：清除 过量产出 活动间的等待 不必要的运输 反复的加工 过量的库存 缺陷、失误 重复的活动 反复的检验 跨部门协调,S：简化 表格 程序 沟通 物流 I：整合 活动 团队 顾客 供应商,A：自动化 脏、累、乏味活 数据采集与传输
11、 数据的分析,跨职能流程图,业务流程图 系统流程图 可以体现数据流向,活动图：简单活动图,活动图：带泳道的活动图,业务流程与业务规则,业务流程Action 用户可以做的操作？ 权限控制的基础 业务规则Filter 用户的授权操作可以影响的数据范围？ 权限控制的补充 用例与业务流程：多个用例属于一个流程 用例与业务规则：一个业务规则应用于多个用例,业务流程与业务规则,结构事实：必须成立的事实或条件。例如：与客户第一次接触的永远都是销售人员。 行动约束：根据某种条件禁止的一种或多种行动。例如：不接受具有不能接受的信用历史记录的支票。 行动触发：当一个或多个条件转为真时，触发某个行动。例如：当所选商
12、品准备齐后，立即发货。 参照：当一个或多个条件转为真时，得出某种结论。例如：在一年内飞行10万公里以上的会员将成为金卡会员 计算：根据一组值计算另一个值。例如：销售量是商品总零售额，但是没有包含税收部分。,Agenda,需求建模实例 业务流程与规则分析 数据需求分析与建模 需求描述最佳实践 需求管理最佳实践 需求过程总结,数据是系统的核心内容,数据需求分析与建模,数据流通过程：数据流图（DFD） 数据存储方式：实体-关系图（ERD） 数据定义方式：数据字典（DD） 数据需求分析与设计要素,数据流图：基本元素,输入数据在此进行变换产生输 出数据，其中要注明加工的名称,数据输入的源点或数据输出的
13、汇点，其中要注明源点和汇点的名称,存放数据的地方，这些数据在以后使用，通常与实体-联系图中的一个数据实体相对应,被加工的数据与流向，箭头边应给出数据流名字，可用名词或名词性短语命名,当过程/加工执行时，外部实体与过程之间来回通信,数据存储/文件,数据流,实时连接,过程/加工,外部实体/源/宿,数据流图：图的结构,数据流图：分层的DFD,绘制数据流图：构建顶层图,绘制数据流图：绘制DFD片断,绘制数据流图：将DFD片断合并,数据建模过程,E-R图,概念结构设计的方法,实体-关系图：图例,实体分析法,确定局部视图的范围：实体的个数应适量 识别实体及标识 确定实体间的联系 分配实体及联系的属性,识别
14、实体及标识,实体分析法：确定实体间联系,一对一关系： 两个实体都是强制性的 仅有一类实体是强制的 两类实体均非强制性的 一对多关系 多端强制性 多端非强制性 多对多关系,确定实体间联系时的陷阱,E-R图到关系模式的转换,实体模型：每个实体转成一个模式客户（客户名，身份证号，地址，联系电话） 一对一关系模式：在两个关系模式中的任意一个模式中，加入另一个模式的键和联系类型的属性 校长（姓名，性别，职称，年龄，校名，任职时间） 学校（校名，地址，电话）,E-R图到关系模式的转换,一对多关系模式：在n端实体类型对应的关系模式中加入1端实体类型的键和联系类型的属性,校长（姓名，性别，职称，年龄，校名，任
15、职时间） 学校（校名，地址，电话）,E-R图到关系模式的转换,多对多关系模式：将联系类型也转换成关系模式，属性为两端实体类型的键加上联系类型的属性,学生（学号，姓名，性别，年龄） 课程（课程号，课程名，授课老师） 考试（课程号，学号，成绩）,数据字典应用,数据元素说明 数据元素名或标识：即对用户而言有意义的名称； 别名：可选择的名字 类型和长度：说明数据元素的组成部分，是数字、字母还是其他；而长度则是指其最大的组成个数 默认值：即数据元素的一个初始值； 可接受的值：即数据元素有效的合法取值范围 数据源：即对数据元素值的起源点的具体说明 安全：对于有权访问或更新每个数据元素的人或部门的标识 有责
16、任用户：负责输入/改变数据元素值的用户标识 描述和评论：加上一些更好的说明数据元素的注解,数据字典应用,数据流说明 数据流名或标识：即在DFD中所对应的数据流名称 描述：说明数据流的用途与目的 别名：可选择的名字 数据源：数据流的起点 目的：数据流的终止点 记录：每个数据流都代表了一组被称为记录或数据结构的相关实体 量和频率：描述单位时间内数据流发生的次数。,数据字典应用,数据存储（文件）说明 数据存储名或标识：在DFD中对应的数据存储名称 描述：说明数据存储的用途与目的 别名：可选择的名字 属性：输入或离开数据存储的标准数据流图名 量和频率：描述数据存储中记录出现的可估计的个数和更新频度 加工说明 加工名或标识：即在数据流图中所对应的加工名称 描述：说明加工的用
