需求预测方法及模型总结报告

时间：2021-02-13 11:32:56 其他报告我要投稿

需求预测方法及模型总结报告

　　篇一：需求预测与模型总结

需求预测方法及模型总结报告

　　交通需求预测是交通规划中的核心内容之一。交通发展政策的制定、交通网络设计以及方案评价都与交通需求预测有密切的关系。现代交通规划理论中的交通需求预测习惯上被分为四个阶段，即交通产生预测、交通分布预测、交通方式分担预测及交通网络分配。下面就对交通需求预测的四阶段法以及其各自的模型进行总结。一、交通生成预测

　　Ⅰ、增长率法

　　增长率法是根据预测对象（如客货运量、经济指标等）的预计增长速度进行预测的方法。

　　预测模型的一般形式为： Qt=Q0（1+α）t

　　增长率法的关键在于确定增长率，但增长率随着选择年限及计算方法的不同而存在较大的差异。所以增长率法一般仅适用于增长率变化不大且增长趋势稳定的情况，其特点是计算简单，但预测结果粗略，较适用于近期预测。

　　Ⅱ、乘车系数法

　　乘车系数法又称为原单位发生率法，类似于城市交通预测中的类别发生率法，它用区域总人口与平均每人年度乘车次数来预测客运量。模型的形式为：

　　Qt=Ptβ

　　乘车系数可以根据指标的历年资料和今后变化趋势确定，但是乘车系数本身的变动有时难以预测，各种偶然因素会使其发生较大波动。此外，人口、职业、年龄的变化也使系数很难符合一定规律。

　　Ⅲ、产值系数法

　　产值系数法是根据预测期国民经济指标值（如工农业总产值、社会总产值、国民收入等）和确定的每单位指标值所引起的货运量或客运量进行预测的方法。模型的形式为：

　　Qt=Mtβ

　　Ⅳ、弹性系数法

　　弹性系数法是通过研究单位社会经济指标产生的小区交通出行量，预测将来吸引、发生量的一种方法。此法是综合考虑我国经济发展水平和产业结构和发展

　　趋势，参考O、D调查区域社会经济有关文献资料，确定弹性系数的大致范围，结合所得出的历史弹性系数及所处区域位置及相关运网历史交通量与直接影响区历史经济量的回归分析作为进一步的分析手段，确定出项目影响区的交通增长弹性系数，依此进行发生、吸引交通量预测。根据项目影响区经济发展速度预测结果和运输弹性系数，按下式计算交通量增长率：

　　交通量增长率=GDP增长率×运输弹性系数 Ⅴ、时间序列预测法

　　又称时间序列预测法，是收集和整理过去的交通量资料，从中找出交通量随时间而变化的规律，并用数学模型来表示这种规律，然后按此模型进行预测。该类模型包括： ① 趋势外推法； ②指数平滑法； ③灰色系统法；

　　④人工神经网络法、小波分析法等。

　　Ⅵ、回归分析法

　　回归分析预测法就是一种通过分析研究因变量与相关因素的联系规律从而进行预测的方法。

　　在诸多影响因变量的因素中，有些是与其它因素独立或近似独立的，有些则是密切相关的。我们选取其中主要的而且各自是相互独立的因素作为自变量。然后分析每个自变量与产生量大致的函数关系。

　　回归分析法又分为：线性回归分析法：一元线性回归分析，二元线性回归和多元线性回归分析；

　　非线性回归分析法：

　　如多元线性回归法，是从调查数据中，选取某个自变量与多个因变量的多组样本值，建立多元线性回归模型:

　　P=b0+b1X1+b2X2+…+bnXn

　　Ⅵ、灰色预测法

　　该理论是我国学者邓聚龙教授在上世纪80年代初提出的处理不完全信息的一种新理论，该理论应用关联度收敛原理、生成数、灰导数等观点和方法建立微分

　　方程模型。如GM (1,1)表示一阶单个变量的微分方程，是最常用的灰色预测模型。灰色预测在诸多领域(包括交通量预测)都有较好的应用。

　　设时间序列X（0）有n个预测值，X(0)=｛X(0)(1), X(0)(2), X(0)(3),…X(0)(n)｝加生成新序列X(1)=｛X(1)(1), X(1)(2), X(1)(3),…X(1)(n)｝，其中

　　X（1）（k）=

　　，k=1,2,…,n

　　则GM（1,1）模型相应的微分方程为

　　二、交通分布预测

　　交通分布预测模型，可以分为两大类。

　　第一类是比较适用于较短期交通分布的模型，它们往往比较简单，主要用于交通网络没有发生重大变化的短期交通分布预测中；

　　另一类是比较适用于长期交通分布预测或短期分布中交通情况有较大变化的交通分布预测模型，它们使用出行广义费用或其他较复杂的数学方法。

　　以下主要介绍增长系数法和重力模型法，它们适用于长、短期交通分布预测。 Ⅰ、增长系数法

　　增长系数法基本依赖于各交通小区间基年的交通分布情况，把预测年的交通发生量和吸引量按基年交通分布的比例分布到路网中。该方法适用于宏观交通量的分布，不限于个别因素的影响，着重于总的趋势，适应性较强。但基年交通分布的稍有偏差，对未来交通分布有较大影响。

　　它以平均增长系数法、Fratar法、Furness法和底特律法等方法为主。完全是基于出行起点与终点小区的交通增长特性，利用现状的OD分布量推算将来的OD分布量。它依赖于各节点间的基年分布情况，并假设区间的出行交通与路网的改变相互独立，或者在预测年限内交通运输系统没有明显的改变。这种方法适用于小地区或区域间出行不受空间阻挠因素的影响而只受地区间交通发生、吸引特性影响的出行空间分布形态，且这种方法不限于某些个别因素的影响，着重总的趋势，适用于交通量的宏观分布预测，但当基年OD分布稍有偏差时，对未来影响将会很大。模型不需标定，只需满足总量平衡即可。

　　增长系数法的算法步骤如下：

　　a 令计算次数m=0； b 给定现状OD

　　表中

　　及将来OD表中的

　　；

　　X；

　　c 求出各小区的发生于吸引交通量的增长率

　　d 求第m+1次交通分布量的近似值

　　e 收敛判别。

　　①常增长系数法：

　　增长函数为：②平均增长系数法：

　　增长函数为：③底特律法：

　　增长函数为：④福莱特法：

　　增长函数为：

　　⑤弗尼斯法：

　　增长系数为：

　　）

　　=常量

　　；

　　篇二：常见需求模型

　　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、常见需求模型之——思维导图模型

　　在需求分析时，我们一般使用思维图在访谈的时候做记录、计划项目和活动、对研讨会作总结。总

　　的来说，只要我们需要简洁和智能的记录方式，就会用到思维图。

　　思维图是绘图和文字的结合，试图按照大脑存储信息的方式来展现信息。我们把每条新的信息与我们已经知道的某些事联系起来，思维图通过线把词和图联系起来的方式，实现了对大脑思维过程的模拟。

　　下图是对我们虚拟用户代表的思维图模拟。

　　思维图的中间应该是中心主题，中心思想应该是有强烈视觉效果的图像。然后外一层分解展示了主要概念、话题、思想或者所选择的主题的分解。用一到两个词来写下这些思想，然后用线条来连接这些思

　　想，最好用有颜色的线来描绘，这样人们更容易记住。线条可以用箭头表示方向，但大多数情况下思想之间的联系是双向的。

　　思维图并不总是从中心向外扩散的，有时候有一些想法，或者从记笔记中听到一些事情，这些东西与图上已有的东西之间没有联系，但也要画到图上去，因为将来可能会发现联系。最后的图可能不那么漂亮，但对思维是有帮助的。

　　画思维图的纸要足够大，当然也可以用画思维图的软件来进行，不过我认为还是直接画图比较好，画图的过程本身就是思维的过程，彩色钢笔的使用使画图的过程充满乐趣，并且新的思想由此源源涌出，在画的过程中，思想的闸门被打开了。

　　在对风险承担者进行访谈询问的时候，我们可以使用思维图来记笔记。当风险承担者告诉我们关于他们的工作、以及需要的新产品的特征的时候，使用思维图的好处就体现出来了。使用思维图来记录访谈的内容，就更可能看到联系，并且发现客户没有提到但是应该解释的联系。思维图可以是一个多用途的记录工具，因为可以简单的一条线来代替联系的文字。

　　所谓创造性思维，是善于把一个问题中松散的“遥远”的各个元素联系起来，从周围的环境中广泛寻找自己经历过的东西，甚至无意中看到广告牌或者一次谈话都可以引发联想，得出问题的答案，这使得他们得以用已知的方法来有效的解决问题。思维图并不可能给出答案，但可以条理性的展示我们可能希望看到的东西，这就是思维图的作用。

　　5、常见需求模型之——用例模型一、用例模型的要点用例图很简单，一般就是三个符号：一个小人（角色）、一个圈（用例）、一根连线，

　　但是要绘制好

　　用例图并不简单，需要注意以下问题：

　　1、如果本系统和外部系统有交互或接口，外部系统也是角色。如ATM机系统中与银行系统的对接例

　　子，如下图；

　　2、产品用例中的角色是实际使用系统的岗位名，如在代售点的火车订票系统，其用例图如下图；

　　3、角色间可以使用继承关系简化设计，但意义不同；下图左边表示三类用户点击的是同一按钮，看

　　到的是同一界面，可以由同一个程序员开发的登录模块；下图右边表示的是三类用户点击的是不同的按钮，看到的是不同的界面，可以分给不同的程序员分别开发的登录模块；

　　篇三：需求分析建模技术

　　1. 需求分析概述

　　1.1 需求分析定义

　　需求分析是指理解用户需求，就软件功能和性能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到《用户需求说明书》和《需求规格说明书》两份文档。广义上，需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

　　狭义上的需求分析是指需求的获取、分析及定义的过程。需求分析的任务就是软件系统解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求的过程。

　　1.2 需求分析的根本任务

　　从实践角度考虑，需求分析不是分析如何实现用户的需求。实际上，需求分析是以业务分析为导向，将用户零散的需求串联起来，形成一个体系完成、组织合理、内容清晰的框架，为今后的设计开发工作打下良好的基础。

　　1、建立分析模型

　　将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征。和用户达成对信息内容的共同理解。

　　分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换

　　为知识的事物的信息。

　　2、创建解决方案

　　将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找解决方

　　案。

　　创建解决方案的过程是创造性的。

　　帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关系。这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案的正确

　　性。

　　1.3 需求的层次

　　1、业务需求

　　反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求 2、用户需求

　　描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的'场景进行整理，从而建立从用户角度的需求 3、系统需求

　　从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束

　　1.4 需求分析的重要性

　　如果投入大量的人力、物力、财力和时间，而开发出的软件却没人要，那么所有的投入都是徒劳。如果费了很大的精力开发一个软件，最后却不能满足用户的要求，而要重新开发，那么这种返工是让人痛心疾首的。所以，需求分析在软件开发过程中具有举足轻重的地位，具有决策性、方向性、策略性的作用，我们应对需求分析具有足够的重视。在一个大型软件系统的开发中，需求分析的作用要远远大于程序设计。

　　根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。失败的主要原因：

　　1、不完整的需求； 2、没有用户的介入； 3、不实际的客户期望； 4、需求和规范的变理； 5、提供了不再需要的

　　1.5 需求分析的一般步骤

　　需求分析的基本过程：

　　1. 需求获取

　　通过会议纪要、讨论纪要的形式。 2. 需求捕获技术比较

　　3. 需求分析

　　对收集到的需求进行提炼、分析和审查，为最终用户所看到的系统建立概念化的分析模型。关键是解决What（收集什么信息）、Where（从哪收集）、How（如何收集）。 4. 需求文档的编写

　　完成需求规格说明书的编写，并审核通过的规格说明书，其内容包含如下：分析需求可行性细化需求建立需求分析模型功能活动

　　分析问题类和类之间关系系统和类行为数据流

　　需求分析的本质就是抽象、映射、转换。：

　　2. 需求分析建模

　　需求分析是软件需求中最核心的工作，需求分析建模是需求分析的主要手段。建立系统模型的过程。又称模型化。建模是研究系统的重要手段和前提。凡是用模型描述系统的因果关系或相互关系的过程都属于建模。