常见需求模型

1、常见需求模型1、常见需求模型之一一业务流程模型1、业务流程模型的两种常见表示方法业务流程图一般用于对核心业务的细化描述,可以采用UML中的泳道图来表示.体检者效劳人员收裁入员体检医生壕合科医生图1体检者申请体检流程如图1,图最上方的方框内的“体检者、“效劳人员、“收费人员等表示业务中相应的岗位,岗位下方对应的是该岗位相应的责任,箭头表示责任间的执行次序,箭头下方的图标表示岗位间传输的单证.图1表示的体检者申请体检后填写个人情况单,效劳人员开单后形成体检单,收费人员收费后出具收费单,各科室体检医生按单体检并记录体检结果,当全部体检项都完成后,由综合科医生出具报告,最后由效劳人员将体检报告返还给体

2、检者.vi业务流程图是给甲方的业务领导看的,而由于UML的泳道图过于简单,有时为了追求美观,也用so的流程图来表示,如图2.上层入库流程,其中 图标表示可以用便携设备现场登记入库；中间层仓库治理流程表示“库存治理业务可以分解为“盘点、“移库、“信息维护、“下限自动提醒等子业务,其最右方的菱形表示转到“采购流程该流程可单独再画一个流程图；最下方出库流程表示出库业务过程,其中库存缺乏,可自动转到“申请采购子业务.2、什么样的工程要采用业务流程模型对于一些工程的核心业务,特别是涉及业务变革、职能调整类的工程,尤其需要画出业务流程图,明确未来业务在组织结构、业务职能和业务信息共享要求等方面的变化情况,

3、借助业务高层领导的支持,防止变革阻力向系统的传导.另外,在一些需要标准业务的IT工程中,该模型也大有用武之地详见推荐阅读1.3、业务流程模型和上下文范围模型的区别业务流程模型重点在核心业务流程,擅长描述核心业务中涉及的岗位变化、责任关系和业务流向；上下文范围模型重点在业务范围,擅长描述业务中的用户、例外处理等.业务流程模型一般是对上下文范围模型中某个核心业务的细化.2、常见需求模型之一一上下文范围模型上下文范围模型常用于开业务需求研讨会时,细化需求.按步骤构建模型如下列图:球季人免咳看人玩1,画好系统和参与者比方在开体检业务系统的业务研讨会时,可以将该系统画在中间,将各类参会的人员画在周围.2

4、,寻找主要外部参与者的核心业务事件由于一个单位的价值一定是通过作用于外部用户而产生的,所以首先寻找单位的主要外部用户,由他来激发单位内部的响应.例子里主要外部用户是体检者,他提出了一个“申请体检的业务事件,所以画出从体检者到系统的箭头,并标注“申请体检和标号1.3,确定对核心业务事件的业务响应单位外部的体检者提出“申请体检后,将激发单位内部的一系列业务响应,依次响应如下：效劳人员要“开单；收费人员要“收费；体检科室要“体检并记录结果；当所有体检结果都出来后,综合科医生要“出具报告；最终“返回报告给体检者.所以依次画出参与者到系统的箭头,并标注“开单、“收费等信息,标号都为1,表示是对业务事件1

5、“申请体检的业务响应.4,寻找非核心业务事件以及业务响应处理完主要外部用户的核心业务事件及其业务响应后,还得考虑非核心业务或例外事件,例子中非核心业务事件主要有“申请改单,对应的业务响应是收费人员的“处理改单.所以补充画出从体检者和收费人员到系统的箭头,箭头上标注“申请改单和“处理改单,并将标号设为2.例外事件如体检者过期未取体检报告怎么办系统应主动提醒一次用户来取报告,这就是画出了“5通知用户取报告.5,寻找其他外部参与者的业务事件及其响应最后考虑相对于体检部门的外部单位的业务事件,如财务部门的“提交团队缴费情况、客服中央的“查询体检情况、系统定时触发的“通知用户取报告和维护人员的“治理体检

6、项等等.该模型绘制的过程,其实就是业务需求讨论记录的过程.模型的成果给出了系统大致的范围概览.3、常见需求模型之一一主题域模型主题域模型采用UML中的组件视图,将大型复杂系统需求先期分解为假设干主题,再把每个主题当作独立的系统,用以初步描述子需求和需求之间的依赖关系.物资营理子索统QL客服治理子系统/蕊取公司客户旗费侑息股G线单制资申述赧或售户体检业务子系统1查世团队弊捡荒成情况有一体检医院,它光体检不看病,这类业务非常有“钱景.现在要为这类体检医院开发系统,捕获需求.由于涉及的业务较多,前期可以根据它原有部门的划分,分为如上图的三个主题域,确定三个子系统.再研究各部门之间原来人员的信息交互情

7、况,决定子系统间对外的接口和协作关系注意是需求级的粗略分析.例如,负责体检业务的部门经常要找负责物资治理部门的人申领物资,所以如图标识“物资申领接口和调用请求；当体检业务部门的物资快消耗完毕时,他要提前通知物资治理部门负责采购的人员,所以如图标识“提交物资使用情况接口和调用请求.其他接口也采用类似方法确定.4、常见需求模型之一一思维导图模型在需求分析时,我们一般使用思维图在访谈的时候做记录、方案工程和活动、对研讨会作总结.总的来说,只要我们需要简洁和智能的记录方式,就会用到思维图.思维图是绘图和文字的结合,试图根据大脑存储信息的方式来展现信息.我们把每条新的信息与我们已经知道的某些事联系起来,

8、思维图通过线把词和图联系起来的方式,实现了对大脑思维过程的模拟.下列图是对我们虚拟用户代表的思维图模拟.侯尼嘴天下等身局1S6个人喜欢小装置解昂需庭计篁机工作新奇的 某银行需求分析师工工部门高性翡DVD播放器计苴机科学软件工程学与妓术、顼士学位幅长于此11有趣的工作、首席架构师儿子思维图的中间应该是中央主题,中央思想应该是有强烈视觉效果的图像.然后外一层分解展示了主要概念、话题、思想或者所选择的主题的分解.用一到两个词来写下这些思想,然后用线条来连接这些思想,最好用有颜色的线来描绘,这样人们更容易记住.线条可以用箭头表示方向,但大多数情况下思想之间的联系是双向的.思维图并不总是从中央向外扩散的

9、,有时候有一些想法,或者从记笔记中听到一些事情,这些东西与图上已有的东西之间没有联系,但也要画到图上去,由于将来可能会发现联系.最后的图可能不那么漂亮,但对思维是有帮助的.画思维图的纸要足够大,当然也可以用画思维图的软件来进行,不过我认为还是直接画图比拟好,画图的过程本身就是思维的过程,彩色钢笔的使用使画图的过程充满乐趣,并且新的思想由此源源涌出,在画的过程中,思想的闸门被翻开了.在对风险承当者进行访谈询问的时候,我们可以使用思维图来记笔记.当风险承当者告诉我们关于他们的工作、以及需要的新产品的特征的时候,使用思维图的好处就表达出来了.使用思维图来记录访谈的内容,就更可能看到联系,并且发现客户

10、没有提到但是应该解释的联系.思维图可以是一个多用途的记录工具,由于可以简单的一条线来代替联系的文字.所谓创造性思维,是善于把一个问题中松散的“遥远的各个元素联系起来,从周围的环境中广泛寻找自己经历过的东西,甚至无意中看到广告牌或者一次谈话都可以引发联想,得出问题的答案,这使得他们得以用的方法来有效的解决问题.思维图并不可能给出答案,但可以条理性的展示我们可能希望看到的东西,这就是思维图的作用.5、常见需求模型之一一用例模型一、用例模型的要点但是要绘制好用例图很简单,一般就是三个符号：一个小人角色、一个圈用例、一根连线,用例图并不简单,需要注意以下问题：1、如果本系统和外部系统有交互或接口,外部

11、系统也是角色.如ATM机系统中与银行系统的对接例2、产品用例中的角色是实际使用系统的岗位名,如在代售点的火车订票系统,其用例图如下列图;3、角色间可以使用继承关系简化设计,但意义不同；下列图左边表示三类用户点击的是同一按钮,看到的是同一界面,可以由同一个程序员开发的登录模块；下列图右边表示的是三类用户点击的是不同的按钮,看到的是不同的界面,可以分给不同的程序员分别开发的登录模块；4、用例中核心业务要详细突出,一页纸写不下的非核心业务可以合并,并在次级用例中展开;5、用例应该能为角色带来业务价值,别把动作过程当作用例.用例好比是主界面上的按钮,动作那么相当于点击按钮后在弹出窗口中的一系列操作.比

12、方查询是用例,而设置查询条件和获得查询结果就是查询用例的两个动作.6、采用用户的视角和术语命名用例,常为动名词,防止采用功能视角确定用例.如下列图处理设备缺陷工程,左侧是错误表达方式,右侧是推荐表达方式.、用例模型的级别用例模型分为业务级、产品级和功能级三个级别,应在需求过程中逐步细化.C业务级用例LU印配送专；、记配送站臬配送人员功能级用例彘一业务级用例是用于需求前期界定业务范围的,例子中表示配送人员业务上要干“配送这件事；产品级用例用于甲乙双方签合时明确工作量的,反映了软件产品为支持“配送业务提供的功能.注意如果自动化程度高的软件产品,还能提供“自动生成配送路线、“自动生成装箱方案等功能,

13、但在例子中表示未来软件产品将只提供“打印配送单和“登记配送结果两功能,其他功能不提供；功能级用例用于开发团队内部治理工程的,反映了各个功能之间的依赖关系.例子中表示“打印配送单和“登记配送结果功能都用到了“查询配送信息功能.三、功能级用例的结构化关系用例通过扩展、包含、泛化等关系作为对需求细化的手段,称之为用例的结构化.比方下列图所示,不同用例之间的关系如下：BoonDttultki加Customer?ihdudeKotrlCvunStaffChickout包含(include):一个用例的实现使用另一个用例的实现.例如,“预定房间和“登记入住都需要参与者核对房间的可用性、以及查询有没有可用的

14、房间等,这可以增加一个“核对房间清单(CheckRoomDetails)的包含用例.扩展(extend):根本用例不需要了解扩展用例的如何细节,扩展用例在这些扩展点上增加新的行为.例如,酒店治理系统中有一个功能“待分配房间的预订人等候名单,如果没有房间,系统就会把客户放进这个等候名单(Waitinglist),因此,这个Waitinglist就是预订房间(ReserveRoom)的扩展.把扩展别离出来,可以使问题容易理解,这就不至于被过多的问题所纠缠.泛化(generalization):一个用例的实现从另一个抽象的用例继承.例如,酒店治理系统中“预定房间用例就可以泛化为“预定设施,这样,以后再有类似的“预定会议室用例就可以直接从泛化的“预定设施用例继承.在细化确定需求规格说明时,如果存在以下情况,一般进行用例结构化,将子流或备选流提升为单独用例：1、当一个子事件流被多个用例调用时；2、备选事件流或子流开发量较大,需单独安排人员或时间时；3、准备在下一版本完成备选事件流时.6、常见需求模型之一一数据流模型对于一些后台类和工具类的工程,由于其业务协作性不明显,可以采用数据流图来表示.描述数据流图时,一般主要从输入、处理、存储和输出的开发视角分级描