常见需求模型预览.docxVIP

常见需求模型1、常见需求模型之——业务流程模型1、业务流程模型的两种常见表示方法 业务流程图一般用于对核心业务的细化描述，可以采用UML中的泳道图来表示。如图1，图最上方的方框内的“体检者”、“服务人员”、“收费人员”等表示业务中相应的岗位，岗位下方对应的是该岗位相应的职责，箭头表示职责间的执行次序，箭头下方的图标表示岗位间传输的单证。图1表示的体检者申请体检后填写个人情况单，服务人员开单后形成体检单，收费人员收费后出具收费单，各科室体检医生按单体检并记录体检结果，当全部体检项都完成后，由综合科医生出具报告，最后由服务人员将体检报告返还给体检者。业务流程图是给甲方的业务领导看的，而由于UML的泳道图过于简单，有时为了追求美观，也用viso的流程图来表示，如图2。上层入库流程，其中手机图标表示可以用便携设备现场登记入库；中间层仓库管理流程表示“库存管理”业务可以分解为“盘点”、“移库”、“信息维护”、“下限自动提醒”等子业务，其最右方的菱形表示转到“采购流程”（该流程可单独再画一个流程图）；最下方出库流程表示出库业务过程，其中库存不足，可自动转到“申请采购”子业务。2、什么样的项目要采用业务流程模型？对于一些项目的核心业务，特别是涉及业务变革、职能调整类的项目，尤其需要画出业务流程图，明确未来业务在组织结构、业务职能和业务信息共享要求等方面的变化情况，借助业务高层领导的支持，避免变革阻力向系统的传导。另外，在一些需要规范业务的IT项目中，该模型也大有用武之地（详见推荐阅读1）。3、业务流程模型和上下文范围模型的区别业务流程模型重点在核心业务流程，擅长描述核心业务中涉及的岗位变化、职责关系和业务流向；上下文范围模型重点在业务范围，擅长描述业务中的用户、例外处理等。业务流程模型一般是对上下文范围模型中某个核心业务的细化。2、常见需求模型之——上下文范围模型上下文范围模型常用于开业务需求研讨会时，细化需求。按步骤构建模型如下图：1，画好系统和参与者比如在开体检业务系统的业务研讨会时，可以将该系统画在中间，将各类参会的人员画在周围。2，寻找主要外部参与者的核心业务事件由于一个单位的价值一定是通过作用于外部用户而产生的，所以首先寻找单位的主要外部用户，由他来激发单位内部的响应。例子里主要外部用户是体检者，他提出了一个“申请体检”的业务事件，所以画出从体检者到系统的箭头，并标注“申请体检”和标号1.3，确定对核心业务事件的业务响应单位外部的体检者提出“申请体检”后，将激发单位内部的一系列业务响应，依次响应如下：服务人员要“开单”；收费人员要“收费”；体检科室要“体检并记录结果”；当所有体检结果都出来后，综合科医生要“出具报告”；最终“返回报告”给体检者。所以依次画出参与者到系统的箭头，并标注“开单”、“收费”等信息，标号都为1，表示是对业务事件1“申请体检”的业务响应。4，寻找非核心业务事件以及业务响应处理完主要外部用户的核心业务事件及其业务响应后，还得考虑非核心业务或例外事件，例子中非核心业务事件主要有“申请改单”，对应的业务响应是收费人员的“处理改单”。所以补充画出从体检者和收费人员到系统的箭头，箭头上标注“申请改单”和“处理改单”，并将标号设为2。例外事件如体检者过期未取体检报告怎么办？系统应主动提醒一次用户来取报告，这就是画出了“5 通知用户取报告”。5，寻找其他外部参与者的业务事件及其响应最后考虑相对于体检部门的外部单位的业务事件，如财务部门的“提交团队缴费情况”、客服中心的“查询体检情况”、系统定时触发的“通知用户取报告”和维护人员的“管理体检项”等等。该模型绘制的过程，其实就是业务需求讨论记录的过程。模型的成果给出了系统大致的范围概览。3、常见需求模型之——主题域模型主题域模型采用UML中的组件视图，将大型复杂系统需求先期分解为若干主题，再把每个主题当作独立的系统，用以初步描述子需求和需求之间的依赖关系。有一体检医院，它光体检不看病，这类业务非常有“钱景”。现在要为这类体检医院开发系统，捕获需求。由于涉及的业务较多，前期可以根据它原有部门的划分，分为如上图的三个主题域，确定三个子系统。再研究各部门之间原来人员的信息交互情况，决定子系统间对外的接口和协作关系（注意是需求级的粗略分析）。例如，负责体检业务的部门经常要找负责物资管理部门的人申领物资，所以如图标识“物资申领”接口和调用请求；当体检业务部门的物资快消耗完毕时，他要提前通知物资管理部门负责采购的人员，所以如图标识“提交物资使用情况”接口和调用请求。其他接口也采用类似方法确定。4、常见需求模型之——思维导图模型在需求分析时，我们一般使用思维图在访谈的时候做记录、计划项目和活动、对研讨会作总结。总的来说，只要我们需要简洁和智能的记录方式，就会用到思维图。思维图是绘图和文字的结