常见需求模型.docx
《常见需求模型.docx》由会员分享，可在线阅读，更多相关《常见需求模型.docx（13页珍藏版）》请在冰豆网上搜索。
常见需求模型
常见需求模型
、常见需求模型之业务流程模型——1
、业务流程模型的两种常见表示方法1中的泳道图来表示。
业务流程图一般用于对核心业务的细化描述，可以采用
单证。
表
，图最上方的方框内的“体检者”、“服务人员”、“收费人员”等表示业务中相应的岗位1如图，岗位下方对应的是该岗位相应的职责，箭头表示职责间的执行次序，箭头下方的图标表示岗位间传输的
示的体检者申请体检后填写个人情况单，服务人员开单后形成体检单，收费人员收费后出具1图收费单，各科室体检医生按单体检并记录体检结果，当全部体检项都完成后，由综合科医生出具报告，最后由服务人员将体检报告返还给
体检者。
命讳特理稚崔YF
vi的泳道图过于简单，有时为了追求美观，也用业务流程图是给甲方的业务领导看的，而由于UML
。
2so的流程图来表示，如图上层入库流程，其中手机图标表示可以用便携设备现场登记入库；中间层仓库管理流
程表示“库存管理”业务可以分解为“盘点”、“移库”、“信息维护”、“下；限自动提醒”等子业务，其最右方的菱形表示转到“采购流程”（该流程可单独再画一个流程图）最下方出库流程表示出库业务过程，其中库存不足，可自动转
到“申请采购”子业务。
、什么样的项目要采用业务流程模型？
2，对于一些项目的核心业务，特别是涉及业务变革、职能调整类的项目，尤其需要画出业务流程图明确未来业务在组织结构、业务职能和业务信息共享要求等方面的变化
情况，借助业务高层领导的支持，（详见推项目中，该模型也大有用武之地IT另外，在一些需要规范业务的避免变革
阻力向系统的传导。
。
1荐阅读、业务流程模型和上下文范围模型的区别3业务流程模型重点在核心业务流程，擅长描述核心业务中涉及的岗位变化、职责关系和业务流向；上下文范围模型重点在业务范围，擅长描述业务中的用户、例外处理等。
业
务流程模型一般是对上下文范围模型中某个核心业务的细化。
、常见需求模型之上下文范围模型一一2
上下文范围模型常用于开业务需求研讨会时，细化需求。
按步骤构建模型如下图:
，画好系统和参与者1比如在开体检业务系统的业务研讨会时，可以将该系统画在中间，将各类参会的人员画在周围。
，寻找主要外部参与者的核心业务事件2，由首先寻找单位的主要外部用户由于一个单位的价值一定是通过作用于外部用户而产生的，所以，所以他来激发单位内部的响应。
例子里主要外部用户是体检者，他提出了一个“申请体检”的业务事件1.画出从体检者到系统的箭头，并标注“申请体检”和标号，确定对核心业务事件的业务响应3，
依次响应如下：
服务单位外部的体检者提出“申请体检”后，将激发单位内部的一系列业务响应人员要“开单”；收费
人员要“收费”；体检科室要“体检并记录结果”；当所有体检结果都出来后，综
合科医生要“出具报告”；最终“返回报告”给体检者。
所以依次画出参与者到系统的箭头，并标注“开。
1“申请
体检”的业务响应1,表示是对业务事件单”、“收费”等信息，标号都为
，寻找非核心业务事件以及业务响应4，例子中非处理完主要外部用户的核心业务事件及其业务响应后，还得考虑非核心业务或例外事件核心业务事件主要有“申请改单”，对应的业务响应是收费人员的“处理改单”。
所以补充画出从
体检者。
例外事件如体检2和收费人员到系统的箭头，箭头上标注“申请改单”和“处理改单”，并将标号设为
通知用户取报告”。
者过期未取体检报告怎么办？
系统应主动提醒一次用户来取报告，这就是画出了“5，寻找其他
外部参与者的业务事件及其响应5如财务部门的“提交团队缴费情况”、客服中心最后考虑相对于体检部门的外部单位的业务事件，的“查询体检情况”、系统定时触发的“通知用户取报告”和维护人员的“管理体检项”等等。
该模型绘制的过程，其实就是业务需求讨论记录的过程。
模型的成果给出了系统大致的范围概览。
、常见需求模型之主题域模型——3
中的组件视图，将大型复杂系统需求先期分解为若干主题，再把每个主题当作主题域模型采用UML独立的系统，用
以初步描述子需求和需求之间的依赖关系。
客服管理子系统
有一体检医院，它光体检不看病，这类业务非常有“钱景”。
现在要为这类体检医院开发系统，捕由于涉及的业务较多，前期可以根据它原有部门的划分，分为如上图的三个主题域，确定三个子获需求。
。
系统再研究各部门之间原来
人员的信息交互情况，决定子系统间对外的接口和协作关系（注意是需求级。
例如，负责体检业务的部门经常要找负
责物资管理部门的人申领物资，所以如图标识“物的粗略分析）资申领”接口和调用请求；当体检业务部门的物资快消耗完毕时，他要提前通知物资管理部门负责采购的人员，所以如图标识“提交物资使用情况”接口和调用请求。
其
他接口也采用类似方法确定。
.
、常见需求模型之思维导图模型一一4
在需求分析时，我们一般使用思维图在访谈的时候做记录、计划项目和活动、对研讨会作总结。
总的来说，只要我
们需要简洁和智能的记录方式，就会用到思维图。
思维图是绘图和文字的结合，试图按照大脑存储信息的方式来展现
信息。
我们把每条新的信息与我们已经知道的某些事联系起来，思维图通过线把词和图联系起来的方式，实现了对大脑思维过程的模拟。
下图是对我们虚拟用户代表的思维图模拟。
阅连
计算乩
计算乩
新虹的于机
新虹的于机
複性醍」汕』‘
下雪
下雪
天气
气、専欢
/不喜歎
茶很行
薛求分折师
的舊藥把弃蛰社舍
<首雋架构U帀
儿子
imn3护
然后外一层分解展示了主，中心思想应该是有强烈视觉效果的图像。
思维图的中间应该是中心主题。
用一到两个词来写下这些思想，然后用线条来连接这些思要概念、话题、思想或者所选择的主题的分解.
想，最好用有颜色的线来描绘，这样人们更容易记住。
线条可以用箭头表示方向，但大多数情况下思想之间的联系
是双向的。
思维图并不总是从中心向外扩散的，有时候有一些想法，或者从记笔记中听到一些事情，这些东西最后的
图可能不那么漂与图上已有的东西之间没有联系，但也要画到图上去，因为将来可能会发现联系。
亮，但对思维是有
帮助的。
画思维图的纸要足够大，当然也可以用画思维图的软件来进行，不过我认为还是直接画图比较好，画图的过
程本身就是思维的过程，彩色钢笔的使用使画图的过程充满乐趣，并且新的思想由此源源涌出，在画的过程中，思想
的闸门被打开了。
在对风险承担者进行访谈询问的时候，我们可以使用思维图来记笔记。
当风险承担者告诉我们关于使用思维图来记录访谈他们的工作、以及需要的新产品的特征的时候，使用思维图的好处就体现出来了。
思维图可以是
一个多用途的记的内容，就更可能看到联系，并且发现客户没有提到但是应该解释的联系。
录工具，因为可以简单的
一条线来代替联系的文字。
所谓创造性思维，是善于把一个问题中松散的“遥远”的各个元素联系起来，从周围的环
境中广泛寻找自己经历过的东西，甚至无意中看到广告牌或者一次谈话都可以引发联想，得出问题的答案，这使得思
维图并不可能给出答案，但可以条理性的展示我们可能希望他们得以用已知的方法来有效的解决问题。
看到的东西，
这就是思维图的作用。
、常见需求模型之用例模型
一、用例模型的要点但是要绘制、一根连线，、一个圈（用例）用例图很简单，一般就是三个符号：
一个小人（角色）
好用例图并不简单，需要注意以下问题：
机系统中与银行系统的对接ATM1、如果本系统和外部系统有交互或接口,
月户
外部系统也是角色。
如例子，如下图;
产品用例中的角色是实际使用系统的岗位名，如在代售点的火车订票系统，其用例图如下图;
千
O
T-
H•鼠研也耒业曲辜护园
邛月决曲長检怕f
肆・F：
、用例模型的级别用例模型分为业务级、产品级和功能级三个级别，应在需求过程中逐步细化。
业务®用侧
配送人员
例子中表示配送人员业务上要干“配送”这件事；业务级用例是用于需求前期界定业务范围的，注产品级用例用于
甲乙双方签合时明确工作量的，反映了软件产品为支持“配送”业务提供的功能。
意如果自动化程度高的软件产品，
还能提供“自动生成配送路线”、“自动生成装箱计划”等功能，但在例子中表示未来软件产品将只提供“打印配送单”和“登记配送结果”两功能，其他功能不提供；例子中表示“打印配送功能级用例用于开发团队内部管理项目的，反
映了各个功能之间的依赖关系。
单”和“登记配送结果”功能都用到了“查询配送信息”功能。
三、功能级用例的结
构化关系。
比如下图所示，不同用用例通过扩展、包含、泛化等关系作为对需求细化的手段，称之为用例的结构化例如，“预定房间”和“登记入住”都需要：
一个用例的实现使用另一个用例的实现。
include）包含（RoomCheck参与者核对房间的可用性、以及查询有没有可用的房间等，这可以增加一个“核对房间清单（
ChickbulCustovir
一o
WindljVia
List
Ccuntir
Stiff
J%
之间的关系如下:
）”的包含用例。
Details例）：
基本用例不需要了解扩展用例的如何细节，扩展用例在这些扩展点上增加新的行为。
扩展（extend女口,酒店管理系统中有一个功能“待分配房间的预订人等候名单”，如果没有房间，系统就会把客户放进””
Roomlist”就是"预订房间（ReserveWaiting这个“等候名单（list””，因此，这个“Waiting
的扩展。
把扩展分离出来，可以使问题容易理解，这就不至于被过多的问题所纠缠。
例如，酒店管理系统中“预定房
间：
一个用例的实现从另一个抽象的用例继承。
generalization”泛化（”用例就可以泛化为“预定设施”，这样，以
后再有类似的“预定会议室”用例就可以直接从泛化的“预定设施”用例继承。
在细化确定需求规格说明时，如果存
在以下情况，一般进行用例结构化，将子流或备选流提升为单独用例：
、当一个子事件流被多个用例调用时；1、备
选事件流或子流开发量较大，需单独安排人员或时间时；2、准备在下一版本完成备选事件流时。
3
、常见需求模型之数据流模型——6
。
描述数据对于一些后台类和工具类的项目，由于其业务协作性不明显，可以采用数据流图来表示一般主要从输入、
处理、存储和输出的开发视角分级描述。
流图时，
级数据流图（即上下文范围模型）为：
“学术部”输入“课程安排数据”、“0例如学校选课业务
学生”输入“注册请求”，经过“课程注册系统”处理，输出“课程安排”给学生，“班级列表”给“教员”
再细化考虑“课程注册系统”内的情况，为“学术部”输入“课程安排数据”将由“课程安排”模块处理后存储在“提供的课程”信息中。
“提供的课程”、“学生”和“注册请求”三个信息输入到“注册学生”模块中，将输出“课程注册”信息中，并将“课程安排”信息输出给“学生”。
后面“产生班级列表”模块的输入和输出与前类似，不再累述！
•
升级会员 