订单管理系统需求报告分析

订单管理系统需求报告分析（推荐8篇）

订单管理系统需求报告分析 篇1

1、采购基础数据功能包括：物料数据维护、订/交货方式维护、来源类别维护、采购员维护、采购系统维护。

2、采购计划管理功能包括：请购计划维护、请购计划合并、采购计划生成。

3、采购订单管理功能包括：采购订单维护、采购合同维护、订单终止或取消、订单结案。

4、采购询价管理功能包括：报价资料维护、询价资料维护。

5、供应商评估管理功能包括：供应商类型维护、供应商资料维护、供应商报价维护、供应商评估。

6、主要应用部门：财务部门，营销部门，生产部门，运输部门

2、系统业务流程分析

3、系统功能模块说明：

（1）、采购基础数据: 采购子系统的基本数据有采购员资料、供应商资料、采购提前期以及业务流程设置。对这些数据就及时加以维护。

（2）、采购计划管理: 通过物料需求（订货点控制、订货周期控制等生成的请购计划）来生成采购计划（或采购建议订单），并综合考虑物料的订货批量、采购提前期、库存量、运输方式以及计划外的物料申请，进行系统自动物料合并，也可以人工干预和修改。另外，有些原材料的采购提前期很长（有的进口件要半年以上的采购周期），因此有可能超过主生产计划制定周期。这类采购的采购计划应经过销售、财务与计划等部门的综合讨论与评估确定所需的数量和时间，然后制定材料的中期或长期采购计划。

（3）、采购订单管理: 根据订货批量、采购提前期、库存量、运输方式、用款计划以及计划外的物料申请进行物料合并，生成采购订单，并经过确认后即可进行订单输出，最后下达给供应商，也可以网上发布订单。对于临时追加的采购任务，可以通过与供应商协商直接下达采购订单。

（4）、采购询价管理: 落实采购订单的采购供应商。采购业务人员广泛利用市场的采购供应资源，进行价格咨询并商谈有关交货数量、交货期、质量要求与技术要求，落实每种物料的供应商。对新开发的供应商资源还要进行供应商的认证过程，经过相应的评审并合格后才能作为许可采购的供应商。

订单管理系统需求报告分析 篇2

1 需求管理和范围管理

1.1 需求管理

需求管理(Requirement management),是完整管理模式中的一环,一套需求管理应当是已知系统需求的完整体现,每部分解决方案都是对总体需求一定比例的满足,仅仅解决部分需求是没有意义的。不同的需求组合起来,构成了一套完整的需求模型,在整个项目管理过程中保证这些需求完整的按时的实现是需求管理的目的。

需求管理的过程,从需求获取开始贯于整个项目生命周期,我们可以看出需求管理所起的作用是力图实现最终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析,需求管理本就是一个动态的过程。需求管理直接关系到最终产品的成型。

1.2 范围管理

范围管理在计划阶段主要是:识别目标,标识业务要求,标识主要功能;在分析阶段是:定义详细需求,核实需求,确定范围,计划实现途径;在设计实现阶段是:控制范围蔓延,监控请求日志,评估变更请求。

在项目的范围管理中应确保如下工作在启动阶段就已经得到正确的界定或完成:

1)收集事实、信息、意见、需求;

2)探讨假设情况;

3)确定应包括的内容和应排除的东西。

范围标明了软件要实现的基本功能,并尽量以定量的方式界定这些功能。当明确了软件项目的目标和范围后,就可以考虑候选的解决方案。范围管理是项目管理的基础,也是项目管理工作的重点和难点。

1.3 项目需求与范围的区别和联系

项目的范围管理在需求管理之前,范围管理包含项目的需求管理。项目范围管理也就是对项目应该做什么和怎么做做出相应的定义和控制,事实上就是对需求的管理和项目过程的管理。

项目范围(Project-scope)包括项目的最终产品或服务以及实现改产品或服务所需的各项具体工作。从这个意义上讲就是项目应该做什么,不应该做什么,以及如何做。也就是说,项目范围事实上包括两个方面的内容:项目需求和项目过程。项目需求确定做什么,项目过程确定如何做。

2 按订单组织货源系统中的需求分析、范围管理

2.1 项目背景

订单采集系统(OCS)、客户经理工作站(MCS)、资源管理系统(RPS)是国家烟草专卖局在“大企业、大品牌、大市场”战略下,根据“按客户订单组织货源”的要求,按照行业统一的功能、流程、数据标准开发的福建省烟草公司福州市公司作为“按客户订单组织货源”试点工作的36个重点城市之一,于2008年全面实施“按客户订单组织货源”工作。

2.2 准确的需求分析

2.2.1 实际情况分析和采取的措施

订单采集系统要求全面收集客户的真实需求,模式变更为客户报卷烟后,系统不会显示卷烟合理定量(策略限量),需等客户报出需求量,接线生记录后,系统才会报出该客户的卷烟合理定量,这与原采集流程有较大差异,要求客户经理应做好对客户这方面的宣传工作,要求客户根据新订单系统的步骤,先报需求,然后客户才能知道自己的实际订货量。

福州烟草信息中心结合对全区的信息化考核工作,展开了对全区客户经理的一次大的需求调研工作。以求全面反映出系统各方面的需求,明确系统究竟要做什么,保证与开发商的沟通建立与在公司用户的充分沟通和调查研究的基础上。

因为用户和开发人员,系统集成人员,系统工程人员各自有不同的视角和立场,他们对需求的理解也是互不相同的。Kruchten在1995年提出过了一个“4+1”的视角模型。“4+1”模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。每一个视角只关心系统的一个侧面,5个视角结合在一起才能够反映系统的软件体系结构的全部内容。而扮演信息系统监理的信息中心工作人员就必须从这五个视角来作需求管理工作。如图1“4+1”的视角模型。

在充分听取客户经理、专管员、电访员以及送货员的意见后,通过与中软海晟的开发人员、系统集成人员结合公司的网络信息平台力求在按订单组织货源的系统中建立“四员”与客户的信息沟通平台。如图2四员互动示意图。

此外,由于原有的电话订货系统、客户关系管理系统、资源管理系统已经开发并使用了近三年,用户也有了一定的使用经验,业务基本流程本身也并没有特别巨大的变化,因此,我们把需求分析的过程分为三步:

1)分析原有系统的结构,主要是数据库结构和程序结构;

2)在获得第1)步结果的基础上写出基本需求,交由客户经理、市场经理评审补充;

3)在第2)步的基础上描述按订单组织货源会引起业务流程的变化以及新系统的一些新的功能,利用这个比较确定的系统功能描述与客户经理进行交流,从而获得最终可用的需求结果。

选用Rational公司的Requisite PRO作为我们的需求管理工具。这些需求分析工具可以对需求进行全面的管理,包括记录需求的变化情况,需求之间的依赖关系等等。但是,从信息系统监理的角度出发,我们只采用了其中最简单的一部分功能,那就是记录需求变更,记录需求之间的依赖关系,其他跟RUP有关的功能都给略去了。之所以这样做,主要是考虑到信息中心在整个项目的建设过程中只是起到信息系统监理,开发商与用户之间的沟通协商以及促进项目成功的作用。如图3项目管理示意图。

实际情况也正如前面所说,首先根据自己的理解并写出基本需求后,交由客户经理、营销部门做评审并做适当补充,将经过补充整理后的需求作为正式需求记录入Requisite Pro所维护的数据库中,并对各个需求进行分类,设定优先级等,这些工作完成后,就可以从数据库中直观地了解客户到现在为止提出了哪些需求,哪些需求是必须优先考虑的,哪些是难度较大的等等。在这个过程中,我们遇到了一些问题,客户经理不明白我们所描写的需求过程与他们所完成的业务之间的对应关系;另外是由于在进行需求管理,范围确定上的经验不足,在与中软海晟的开发人员沟通上仍然造成了不少反复,对于前者,我们的方法是想办法增加一些示意图,将大的流程分解为小流程,再与客户经理反复交流与沟通,最终达到双方理解一致的目的。对第二个问题,则参考了旧的系统中的一些例子,再结合国家局编制的电话订货系统标准,给予取舍或者选择,经过这一阶段的工作,基本上表达出福州对按订单组织货源的理解以及对新系统的需求。

2.2.2 预测模型的建立

由于严格按国家局要求收集零售户的需求,根据福建省烟草专卖局安排把订单采集模块独立成订单采集系统。福州的两万五千多零售户已经基本适应了先报需求的再判断有没有库存的这种订货方式,对进一步开展订单组织货源工作有极其重要的意义,有利于我们需求预测模型的建立和测试。

在订单预测模型研究上,结合福州消费市场的特点,建立以下三种模型:稳定形态的预测模型,趋势形态的预测模型(品牌上升、促销,下降、退出市场的各个阶段),季节形态的预测模型。

由此我们尝试建立适合福州的按订单采集货源的流程,如图4按订单采集货源的流程图。

在需求管理过程中,该流程图只是一个示意的图片,但可以通过这个流程图去诱导出真正需要的流程图,通过这种手段可以让更多的用户参与到讨论中来,让系统的思想成为普通用户也可以看得见,理解得了的东西,这样才能和他们日常业务逻辑统一起来,激发用户的思考和探索。

2.3 有效的项目范围管理

适逢烟草行业信息化建设的大好时机,这个项目也是我们第一次将项目管理知识体系知识灵活运用于实践之中。在项目管理中我们采用了MS Project2007作为项目管理工具。通过Project,建立项目的WBS。对WBS的每个任务明确了其可交付物,保证每一项任务都是可控的。由于我们并不涉及开发和设计,在项目管理中侧重对需求的管理和系统实施的管理

同时我们还制定了一些卡片用于记录用户对系统功能的理解和需求,并通过分类、整理最后制定项目范围管理计划,范围变更计划及规程,并交由信息中心集体讨论完善,联合营销部门一起制定系统进度安排表,由甲乙双方单位共同实施。充分考虑预先对进度如何计划?工作怎样就位如何?识别定义好的任务管理人员对结束时间如何掌握等问题。

我们知道范围管理保证项目包含了所有要做的工作而且只包含要求的工作,它主要涉及定义并控制哪些是项目范畴内的,哪些不是。范围管理的基本内容包括:项目启动、范围计划编制、范围核实、范围变更控制等等。所以编制范围计划,使用必要的技术和方法做好一个周密的范围计划把所需要进行的项目工作明细和归档出来,在项目的进行过程中不断的深入和细化。

由于严格按编制好的计划运作,保证了项目的顺利实施,但同时也由于采购、日常业务的冲突、人员安排等各种因素不可避免的会带来一些项目计划的变更。这就极大的挑战了信息中心的技术服务职能和管理职能之间的矛盾,需要充分发挥信息部门的沟通协调能力。我们的做法是,在编制计划的时候充分考虑各种因素和风险,冗余一定的时间,尽量保证项目的按计划顺利实施。由于前期的需求调研工作比较细致深入,需求方面的变更不大,存在的小的需求,归并入此次项目实施系统的辅助系统中予以解决。

3 结束语

结合烟草商业企业信息化工作,对信息系统监理工作过程中的需求管理和范围管理进行研究和探讨,把信息部门定位于信息系统项目监理的位置。信息中心必须同时具备计算机信息技术和公司业务知识这两方面的能力,特别是在项目的需求管理和范围管理方面,以及项目的进度安排、质量控制方面起着对项目的成功实施的促进和保障作用。

需求管理决定着整个项目的成败,用户往往从不同的角度提出自己的需求,这些需求可能是相互矛盾的,二义的,容易误解的或者技术人员难以理解的,需求管理做好了,就可以避免出现这些错误,把混淆和反复的可能性降到最低。

信息中心在履行项目监理这个工作职能的时候,强调对需求的管理,明确项目管理范围,在项目启动阶段就应充分收集各方面的信息、意见、需求,探讨各种假设情况,确定应包括的内容和应排除的东西;明确系统要实现的基本功能,并尽量以定量的方式界定这些功能。

好的需求管理是项目成功的关键因素,而范围管理是项目管理的基础。

参考文献

[1]张友生,林晓飞,陈志风.信息系统监理师辅导教程[M].北京:电子工业出版社,2005.

[2]刘晓霞,郝玉洁.软件体系结构的艺术[M].北京:机械工业出版社,2004.

[3]殷人昆,郑人杰.软件工程概论[M].北京:清华大学出版社,1998.

[4]Jalote P.软件项目管理实践[M].施平安,译.北京:清华大学出版社,2003.

学生成绩管理系统需求分析报告 篇3

学生成绩管理系统需求分析报告

2009-08-02 11:44

采用 vs2005.NET 2.0框架，数据库：sql server 2000，存储过程。

系统采用三层架构，结构清晰。以下为需求分析，貌似也不是很多。

中学生成绩管理信息系统是面向中学的管理系统，其目的是提高中学对中学生的科学化管理。本文针对中学的管理现状和要求，从理论和应用的角度论述了中学生成绩管理信息系统的特点、功能、设计思路，并给出关键技术实现的步骤。本系统主要包括五个模块：成绩录入、班级系统、年级统计和系统功能这四个模块基本实现设计本系统的目的，从而可以进一步满足中学对管理系统的要求。

1.1数据需求：

下面是中学生成绩管理信息系统所需要的输入、输出数据。

字段名类型宽度

学生：姓名字符型8

性别逻辑形1

学号字符型8

班级号字符型4

年级号字符型2

成绩：姓名字符型8

考试日期日期型8

考试类型名称字符型：16

语文数值型3

数学数值型3

外语数值型3

化学数值型3

物理数值型3

政治数值型3

历史数值型3

生物数值型3

地理数值型3

计算机数值型3

合计数值型4

平均成绩数值型3

班主任字符型8

班级人数数值型3 年级总人数数值型5

1.2功能需求：

“中学生成绩管理信息系统”包括四个模块：成绩录入、班级统计、年级统计、系统功能。这五个模块既相互联系又相互独立，班级统计、年级统计模块必须以成绩录入为基础。

(1)成绩录入模块：

主要功能用来对中学生的成绩进行收集和修改。具体包括中学生成绩录入、修改、增加、删除、查询、打印等功能，由于一些资料可以Word文档或Excel表格输入，故在此模块中增加了导入、导出数据功能。成绩录入需要分班级、分年级以及某个时间考试的各门功课的成绩。修改要与成绩录入相对应。增加、删除是对基本表的操作。查询条件设置应该齐全，可以班级查询，年级查询，也可以姓名查询，学号查询等等。分成绩单打印、报表打印等。

(2)班级统计模块：

主要功能用来对中学生的成绩以班级为单位进行处理。具体包括各班学生总成绩、平均成绩、班级排名及统计班级某分数段内的学生人数；各个学生该科成绩、班级排名及统计班级某分数段内的学生人数。各项统计仅对于某学期某次考试而言。

(3)年级统计模块：

主要功能用来对中学生的成绩以年级为单位进行处理。具体包括各年级学生总成绩、年级排名统计年级某分数段内的学生人数；各个学生该科成绩、年级排名及统计、年级某分数段内的学生人数。各项统计仅对于某学期某次考试而言，在统计时，还应注意各年级考试科目不同。

(4)系统功能模块：

包括帮助信息，关于系统及退出系统。

二、概念结构图

图2-

1图2-

2图2-

3图2-4

三、逻辑结构设计

设计逻辑结构时一般要分三步进行：

*将概念经过转化为一般的关系、网状、层次模型；

*将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；*对数据模型进行优化。

成绩管理系统数据模型：

学生(姓名、性别、年龄、学号、班级号、年级号)

成绩(姓名、学号、考试日期、语文、数学、外语、化学、物理、政治、历史、生物、地理、计算机)

班级(班级号、班主任、年级号、班级人数)

年级(年级号、年级主任、年级数、年级总人数)

四、系统特点

1.系统运行环境：

(1)硬件环境：键盘、鼠标、显示器、打印机

(2)软件环境：windows操作系统、VISUAL STUDIO 2005.NET FRAMWORK 2.0

2.适合用户：

适合各类中等学校对中学生成绩事务管理。

3.系统模块化设计：

本系统遵循了“自顶向下，逐层展开”结构化时间原则，系统功能按模块化实现，各模块之间既关联又相互独立，每个模块执行特定的功能，系统设计操作简单，可读性强。

4.系统实用性：

为了提高系统效率，系统提供了多种形式的对话框，并在设计过程中考虑尽量减少用户的输入。为了提高查询效率，系统提供了多种组合查询及模糊查询。

5.系统安全性：

为了防止非法人员进入系统，造成意外破坏，在进入本系统之前，需经过密码认证，同时，系统管理员对每个用户的使用权限进行设置，使不至于越权操作。

6.资料输入方式的多样性：

用户既可以直接输入，又可以从其它文件导入数据。直接输入数据提供友好输入界面，尽量减少用键盘输入的次数，对于相对稳定的项目，采用设置代码的方式，用组合框进行选择。

7.中文查询窗口的设计：

对于一个系统来说，便捷实用的查询功能是必需的。设计时，尽量减少用户的输入用户的输入，提供组合及模糊查询功能。查询窗口设计总思路是查询条件各项都由数据库来控制。

8.网络版传输，单机运行：

采用sql server2000网络关系型数据库，存储读取数据将同步进行。结束语

本系统借助VS 2005 丰富的控件加上强大的sql server 2000数据开发功能，通过研究和探索VS 2005在C/S开发方面的方法和技巧并付诸实践，使得系统具备了友好性，灵活性和可靠性。实现了预期目标和功能。

四、实验内容与步骤

1．根据选定的实验题目，确定拟开发管理信息系统的目标。

2．根据管理信息系统的目标，进行详细调查，或查阅相关资料，获取用户需求。

3．明确管理业务调查过程和方法，绘制组织机构图、功能结构图和业务流程图。

4．明确数据流程的调查与分析过程，绘制数据流程图，编制数据字典。

5．在上述工作的基础上，进行优化处理，提出新系统的逻辑模型。

订单管理系统需求报告分析 篇4

需求调研分析报告

第一章 方案总体构想

一．操作方便，使用灵活，尽量简化基层单位购车的工作过程

目前手工方式的购车过程是，采购单位先到当地财政控办领取《购置小汽车审核表》，填完表后盖上单位公章，并报主管单位确认盖章后，连同购车所需的相关附件一并送到当地财政控办。财政控办受理后审核其购车的指标及定编情况，确认通过后盖章，再送省控办审批盖章，最后由省控办发放购车指标证。

可以看到在上述购车构成中，必须通过人工来传递审核表及相关的附件材料，对于杭州市内及周边区县的单位来说，到省财政的距离不算太远，跑几趟还花不了多少时间，但是对于全省上万家行政事业单位来说，每年新增车辆近万辆，浪费在购车审批过程上的时间、精力和资金就是一个相当巨大的数字了。

《省小汽车控购管理信息系统》的首要目的，便是减少基层单位购车审批时上门的次数，简化购车审批工作过程，并达到节约财政资金的目的。

二．信息共享，便于管理

省控办对党政机关及部分行政事业单位小汽车实行定编管理，而且实行定编的行政事业单位范围还将扩大。省控办现有的小汽车定编管理软件功能尚不完善，而且局限于省控办内部使用，信息不能共享，汽车定编数据的采集不完整且与基层单位的实际数据信息可能不一致。

《省小汽车控购管理信息系统》部署在省财政外网门户网站上，有以下几个目标和要求：

1．提高省财政门户网站的点击率。

2．完善小汽车定编管理功能，丰富报表统计功能。3．实现网上审批办事平台，方便基层工作。4．信息全省共享，分级使用。

三．建立车辆电子档案库，扩大服务范围

对于纳入财政资金支出的在编公务用车，按车辆建立电子档案库，将购车的审批过程文件、购车原始凭证、车辆行驶证等资料通过扫描处理为影像文件存储到电子档案库。

车辆电子档案库可以有效地保存公务车的档案资料，并能让各级财政部门、主管单位、车辆使用的单位领导、车队负责人等随时查询所需的车辆资料。比如车辆过户、报废等可能需要提供车辆的购车凭证等原始信息，而一般过户、报废都是车辆已购置多年以后，那时需要从档案室翻取原始资料可是一件很麻烦的事。有了车辆的电子档案库，只要国资资产处置管理部门能认可加盖单位公章的电子影像件打印件，那就可以省去很多的麻烦。

四．加强对车辆维修保险的监督管理，为财政节约资金

当前在对公务车的管理中，除了超编、超标或频繁更换车辆等问题外，公务车每年的养车费用也是居高不下。除了加强车辆定编管理外，还需要对车辆每年的加油、保险、维修等进行有效地监督和管理，这样才能更大地节约财政资金。

可以试行公务车编制证管理，对每辆公务车发一张卡，该卡即视同为公务车的“身份证”，须凭证才能办理车辆养路费、保险、入户、调配乃至报废更新等所有手续，财政部门也凭证划拨公务车的运行费。

实行定点维修和定点保险，定点维修和保险单位必须每日将当天发生的公务车修理和出险定损信息通过接口传递给《省小汽车控购管理信息系统》，当定点服务单位与财政或被服务单位定期结算时，系统能自动生成车辆这段时间内的维修保险明细和汇总清单，以便核算中心与服务单位进行结算对帐。

五．总体规划，分布实施

《省小汽车控购管理信息系统》要充分地调研和分析，从全省的范围出发进行整体规划和设计，有计划地分步实施，先从省级机关及行政事业单位试点，业务上先完成网上汽车的定编申报审批管理。

第二章 业务流程分析

调研走访单位：浙江省采购办、杭州市采购办、杭州市西湖区采购办、临安市采购办、杭州港昌汽车服务有限公司、中华联合财产保险公司浙江分公司。

一． 定编单位购车申报审批流程

二． 非定编单位购车申报审批流程

三． 车辆定点维修业务流程

四． 车辆定点保险业务流程

第三章 功能需求描述

一．网上办事平台 1．待办事宜

对单位购车、车辆过户、车辆报废以及单位定编变更等申请流程待办任务进行审批处理。

流程任务预算设定，并且按财政各级控办的上下级隶属关系进行自动流转处理。同一级财政部门控办内分别设置经办人、科长、分管领导三个岗位角色，省财政另外增设厅长角色。

2．在审流程查询

在审流程查询是指对于当前正在审批流转过程中的所有流程任务，报告其申请的具体内容以及当前所处的处理环节，便于申请人及时了解审批进度。

3．办结流程查询

办结流程查询使用户能够按年、月、日以及其他一些模糊条件，查询访问历史已办结的流程。

4．个人信息维护

修改用户的个人资料信息，如中文姓名，职务，联系电话，地址，电子邮箱，用户登录密码等。二．单位定编管理 1．单位定编情况查询

按用户所在单位的行政隶属关系，查询其下属所有单位的小汽车定编情况，内容分别是：

单位基本信息：单位代码、单位名称、单位级别、单位性质、上级单位、联系人及电话、邮编、地址、Email、归口业务处室等。

人员编制信息：人员总编制数，其中包括领导职数、非领导职数、干部职数。车辆编制信息：车辆定编数合计，其中包括领导干部用车、机关工作用车、机动用车、办案及执法用车。

现有车辆情况：现有车辆总数（其中不占编的有老干部用车、特种车辆、其他不占编车辆），超编数，缺编数。

2．单位定编信息维护

对单位定编信息（单位基本信息、人员编制信息、车辆编制信息、现有车辆情况）进行维护。

本功能仅对由省控办用户开放。

3．定编变更网上申请

用车单位需要对单位的定编数进行调整变更的，由当地同级控办用户根据用车单位提供的变更书面材料及相关文件批示，在网上下载并填写《定编变更申请表》，并将相关附件扫描录入后，向上级控办发起定编变更申请申报。

对于定编变更申请的流程审批处理参见“待办事宜”。三．网上购车管理 1．非定编单位购车申请

非定编单位需要购置新车的，由当地同级控办用户根据用车单位提供的书面材料及相关文件批示，在网上下载并填写《非定编单位购置小汽车审批表》，并将相关附件扫描录入后，向上级控办发起非定编单位购车申请申报。

对于非定编单位购车申请的流程审批处理参见“待办事宜”。

申报填写的具体内容及所需上报的材料附件参见《浙江省小汽车控购工作规程》。

非定编单位购置20万以下的小汽车可以由同级财政控办直接核准并下达指标证。

2．定编单位购车申请

定编单位需要购置新车的，由当地同级控办用户根据用车单位提供的书面材料及相关文件批示，在网上下载并填写《定编单位购置小汽车审批表》，并将相关附件扫描录入后，向上级控办发起定编单位购车申请申报。

对于定编单位购车申请的流程审批处理参见“待办事宜”。

申报填写的具体内容及所需上报的材料附件参见《浙江省小汽车控购工作规程》。

定编单位购车申报时必须录入单位代码，系统自动显示该单位当前定编情况，车辆性质由申报人选择：占编、老干部、特种车辆、其他不占编（后三种都属于不占编制）。

3．车购指标证打印发放

对于审批终审核准通过的小汽车购置申请，由省控办或当地同级财政控办（仅对非定编单位20万以下车辆）打印并发放指标证。指标证应考虑采用何种技术手段以加强防伪功能。

4．历史购车资料查询

订单管理系统需求报告分析 篇5

一、概

述

为了适应××公司人事和考勤制度的顺利实施，满足公司人事考勤的需求，特出此需求方案。

二、功能说明

a)人事管理

i.员工基本资料维护（包括薪资基本信息的维护）：

1.基本信息：记录员工工号、姓名、性别、ID卡号、生日、身份证号、籍贯、联系人、联系电话、户口所在地、部门、组、职务、工种、入职时间、简介、照片等；

2.薪资信息：基本工资、补贴、全勤奖、伙食费、住宿费、保险、培训金、公积金、计薪方式（计时、计件、月薪）。

ii.员工调动（调职升迁处理）：记录员工因升级、降级、平级、转正等调整员工工作岗位，主要信息有出入部门、组、职务、工种调整等。

iii.员工分组管理：为方便管理，针对一个大的部门进行分组管理，并确定责任人。

iv.员工厂证打印：按公司特定的格式打印出员工厂证。

v.员工宿舍管理：记录所有员工宿舍、床位号，并可实时查询空床位，以方便人事部门安排新员工宿舍。

vi.员工离职：对所有离职员工做离职处理，并可记录离职时间及离职原因。以便公司对人员流动情况及时掌握。vii.技术培训：对学徒或需技术更新员工进行技术培训，并对培训内容作出具体安排及培训过程进行跟踪，最终通过技术考核。技术培训与工资挂勾，允许根据实际情况收取一定培训金。

b)考勤管理

i.考勤数据采集：从考勤钟采集数据并可实时查询考勤原始记录，每次确保采集数据完成以后，可以清除考勤钟记录。

ii.考勤数据分析与维护：根据考勤数据以及标准班次情况对所有员工进行数据分析，以计算员工每天工作时间、加班时间、迟到时间、旷工时间、事病假、厂休等。

iii.排班管理：对按标准班次上班的员工，可对其排一个标准班次，从而按标准班次自动生成其工作、加班、迟到、旷工等时间，针对特殊情况再按特殊情况处理。

iv.请假管理：针对员工需请假时，按不同情况可分为事假、病假、厂休、带薪假等，凡在请假时间内没有考勤记录的，系统将自动识别不做旷工计，并计算出请假时间。

v.放假管理：针对整个工厂停电、厂休、法定假日以及工厂因规定需正常放假等情况进行处理。不同放假类别有不同的考勤制定及工资制度。vi.直落处理：针对中午下班时某些员工不打下班卡及下午上班卡，但中午只算1个小时上班时间，另半小时就餐的情况，须单独做直落处理。

vii.考勤终端设置：实时较正考勤钟时间、及读卡模式、间隙读卡时间等功能。

c)系统管理

i.系统参数设置（代码表）

1.部门管理 2.工种管理

3.人事考勤参数设置

a)每月标准工作时间（208小时）b)多长时间内不计迟到（5分钟）c)迟到多长时间计旷工（30分钟）

ii.权限管理

1.操作员权限管理：不同工作岗位，职责权限不同，系统管理员可根据不同操作设定不同操作权限。

2.密码修改：每个操作员用户名为自己的工号，进入系统后可自己设定自己的登录密码。

iii.操作日志查看：系统将实时记录所有操作员的工作日志记录，以便系统的管理。

三、考勤制度说明

a)考勤钟布置：鉴于公司上下班时间不统一，特殊情况较多，考勤数据分析比较复杂，特设定两台以上考勤钟进行刷卡操作，即上班卡钟跟下班卡钟独立分开，以便数据的分析与统计。

b)自动分析上下班情况：根据员工打卡情况，自动识别员工所上班次（即白班、夜班），然后针对不同班次不同方法自动分析员工工作、迟到、旷工、加班等数据。c)标准班次设定：

i.办公人员：8:00—12:00

13:00—17:00 ii.车间人员：

1.早班：8:00—11:30（12:00）

12:00（12:30）—16:30（17:00）2.晚班：20:00—23:15（23:45）23:45（00:15）—4:30（5:00）

d)加班费计算方法：

i.每日工作超过8小时间以外部分全计加班时间；

ii.星期日上班时间全计加班；

iii.法定假日上班时间计加班；（法定假日不上班是否计工作时间？法定假日上班按多少倍计算加班时间？）

e)迟到计算方法：按标准班次迟到5分钟内不计迟到，5分钟到30分钟以计迟到。特殊情况可另做处理。

f)旷工计算方法：按标准班次迟到30分钟以上开始计旷工。特殊情况另做处理。

g)直落处理：直落扣除半小时就餐时间不计上班。h)特殊情况处理：有特殊情况迟到或旷工但不计迟到、旷工的，可根据刷卡记录、及员工、部门等分批进行特殊情况处理。

一、工资信息维护

1．加班费的计算方法：底薪/当月最低上班时间*1.2*加班时间

2．公积金的计算方法：底薪+补贴的5%，计件员工的公积金：实发工资的5%。每年年底发放当年的公积金总数的70%，30%余下第二年继续，直到批准离厂后才可结清所有公积金。3．计时员工的的工资计算方法：

a．基本工资+补贴+加班费+全勤奖-金损耗-石损耗-伙食费-住宿费-培训金-公积金-迟到-旷工-保险费（学徒）b．基本工资+补贴+加班费+全勤奖-金损耗-石损耗-伙食费-住宿费-公积金-迟到-旷工-保险费

4．月薪员工的工资计算方法：

基本工资+补贴+全勤奖-金损耗-石损耗-伙食费-住宿费-迟到-旷工-保险费

5．计件员工的工资许计算方法：

当月生产总工值+补贴+全勤奖-金损耗-石损耗-伙食费-住宿费-迟到-旷工-保险费

6． 计件，计时，月薪员工工资信息维护 7． 调薪处理 8． 银行接口

二、查询统计报表

a)人事档案资料报表 b)薪资信息报表

c)员工调职升迁报表

d)考勤原始记录查询报表

e)员工考勤记录打印（明细）f)月考勤记录统计报表 g)工种结构分析 h)操作日志报表

三、附件（1、工资制度说明；

2、考勤制度说明）附件1：

工资制度说明

一、月薪员工工资制度

a)不打卡员工：工资由底薪、补助、奖金等部分组成。根据员工工资基本信息自动生成，可以调整。

b)打卡员工：同上，但要扣除考勤扣款，如迟到早退、旷工扣款、请假扣款等。

二、计时员工工资制度

a)根据员工当月的考勤统计，及员工工资基本信息自动生成。

b)基本工资=月基本工资*（工作时间+厂休时间）/月标准工作时间。c)补助=月补助*工作时间/月标准工作时间。d)加班工资=月基本工资*当月加班时间*加班倍率（1.3）/月标准工作时间。e)迟到扣款

i.迟到早退次数*标准金额；

ii.迟到早退分钟数*标准金额。

f)旷工扣款=月基本工资*当月旷工时间*旷工倍率（3）/月标准工作时间。

三、计件员工工资制度

a)不打卡员工：工资由底薪、奖金等部分组成，底薪为计件工资，奖金为手工录入。

b)打卡员工：同上，但要扣除考勤扣款，如迟到早退、旷工扣款、请假扣款等。

四、其它工资部分，根据客户情况，订制开发

a)应发部分：奖金、退保证金等。

b)应扣部分：如个人所得税、保险、保证金、技术培训费、服务费、工具费、餐费、住宿费、存银行等。

五、本文档是的数值，均可根据客户情况进行调整。

附件2：

考勤制度说明

一、打卡制度

a)卡钟最好安排在大门等保安值守的位置，可以由保安监视，避免不打卡或代打卡的现象出现。

b)打卡时一定要维持秩序，必须单列通过，入厂队列、出厂队列要分开，防止打错卡（多人同时打卡，可能造成读卡错误）或代打卡（一人多次打卡）。

二、固定工作班次的考勤制度

a)可使用一台考勤钟，自动分析上下班。

b)排班：必须由操作员手工录入，并在考勤分析处理之前完成。

i.为每个员工安排班次，可以重复安排，以最后一次为准。

ii.标准排班按两个班次处理，如果有第3个班次，则为加班班次，计为加班时间，未出勤的也不计算旷工。c)放假：必须由操作员手工录入，并在考勤分析处理之前完成，可安排周假、月假、年假以及指定日期的假日。

i.带薪假：是指国家规定的节假日，如五一、十一等，所有员工按正常工作8小时计算；如果加班，按3倍时间计算。

ii.正常放假：正常的放假，如周末等，所有员工不计算工作时间，也不计旷工；如果加班，按2倍时间计算。

iii.厂休：由于工厂订单等原因安排的放假，所有员工计厂休8小时；如果加班，按正常工作时间进行处理，厂休时间应由工作时间或加班时间补回，未能补回的计算厂休工资。

d)请假：必须由操作员手工录入，并在考勤分析处理之前完成。

i.事假：因事请假的，不计旷工，也不计工作时间，工作时间应由加班时间补回。

ii.病假：因病请假的，不计旷工，也不计工作时间，工作时间应由加班时间补回。

iii.厂休：计厂休时间，不计旷工，也不计工作时间，厂休时间应由工作时间或加班时间补回，未能补回的计算厂休工资。iv.倒休：员工倒休的，按正常放假处理。

v.出差：出差时间，按工作时间处理。

e)旷工：由系统根据考勤记录及排班情况，自动生成。

i.迟到或早退15分钟以上的，按旷工处理，旷工时间至少按小时计算，不满1小时的，按1小时计算。

ii.整天旷工的，按旷工8小时计算。

f)迟到：由系统根据考勤记录及排班情况，自动生成。

i.迟到3分钟以上的按迟到处理，计迟到次数一次，迟到时间X分钟。

ii.迟到15分钟以上的，按旷工处理。

g)早退：由系统根据考勤记录及排班情况，自动生成。

i.早退1分钟以上的按早退处理，计早退一次，早退时间X分钟。

ii.早退15分钟以上的，按旷工处理。

h)加班：由系统根据考勤记录及排班情况，自动生成。加班有三种计算方式：按排班计算、按日计算及按月计算。

i.按排班计算：

ii.按日计算：日工作小时多于8小时的，按加班计算。

iii.按月计算：月出勤时间多于208小时的，按加班计算。

三、不固定工作班次的考勤制度

a)必须使用两台考勤钟，分为上班钟、下班钟，不用排班。

b)放假：必须由操作员手工录入，并在考勤分析处理之前完成，可安排周假、月假、年假以及指定日期的假日。

i.带薪假：是指国家规定的节假日，如五一、十一等，所有员工按正常工作8小时计算；如果加班，按3倍时间计算。

ii.正常放假：正常的放假，如周末等，所有员工不计算工作时间，也不计旷工；如果加班，按2倍时间计算。iii.厂休：由于工厂订单等原因安排的放假，所有员工计厂休8小时；如果加班，按正常工作时间进行处理，厂休时间应由工作时间或加班时间补回，未能补回的计算厂休工资。

c)请假：必须由操作员手工录入，并在考勤分析处理之前完成。

i.事假：因事请假的，不计旷工，也不计工作时间，工作时间应由加班时间补回。

ii.病假：因病请假的，不计旷工，也不计工作时间，工作时间应由加班时间补回。

iii.厂休：计厂休时间，不计旷工，也不计工作时间，厂休时间应由工作时间或加班时间补回，未能补回的计算厂休工资。iv.倒休：员工倒休的，按正常放假处理。

v.出差：出差时间，按工作时间处理。

d)旷工：由系统根据考勤记录查询出未出勤或迟到早退员工列表，由操作员手工设置旷工。

i.迟到或早退15分钟以上的，按旷工处理，旷工时间至少按小时计算，不满1小时的，按1小时计算。

ii.整天旷工的，按旷工8小时计算。

e)迟到：由系统根据考勤记录查询出某段时间内到厂的员工列表，由操作员手工批量设置迟到。

i.迟到3分钟以上的按迟到处理，计迟到次数一次，迟到时间X分钟。

ii.迟到15分钟以上的，按旷工处理。

f)早退：由系统根据考勤记录查询出某段时间内离厂的员工列表，由操作员手工批量设置早退。

i.早退1分钟以上的按早退处理，计早退一次，早退时间X分钟。

ii.早退15分钟以上的，按旷工处理。

g)加班：由系统根据考勤记录，自动生成。加班有两种计算方式：按日计算及按月计算。

i.按日计算：日工作小时多于8小时的，按加班计算。

ii.按月计算：月出勤时间多于208小时的，按加班计算。

四、月考勤统计

a)根据考勤记录，统计员工当月的考勤情况。b)出勤时间：当月员工出勤的小时数。

c)工作时间：当月正常工作时间的小时数。超出月标准工作时间的，计入加班时间；不到月标准工作时间的，用加班时间补齐。当月入职离职人员，按日考勤记录统计，不做调整。

d)厂休时间：当月厂休的小时数。如有加班时间，用加班时间抵消厂休时间。

e)加班时间：当月加班的小时数，节假日的加班时间，用乘以倍数后的时间。加班时间首先要补足工作时间及厂休时间，然后才计算加班时间。当月入职离职人员，不用补足工作时间，但要抵消厂休时间。f)迟到早退次数：当月迟到早退的次数。g)迟到早退时间：当月迟到早退的分钟数。h)旷工时间：当月旷工的小时数。i)请假时间：当月请假的小时数。

订单管理系统需求报告分析 篇6

分析报告

小组成员:赵草琴201451401126、杨晓庆201451401129、周洁201451401132、孙绍芳201451401130、赵云飞201451401135、邓晓明201451401134

 1.引言  2.需求

 2.1需求概述

2.1.1目标

2.1.2运行环境 2.1.3用户的特点 2.1.4 关键点  2.2功能规定

2.2.1功能图 2.2.2详细功能描述 2.2.3系统管理 2.2.4用户管理 2.2.5交易管理 2.2.6出售管理 2.2.7求购管理 2.2.8搜索  3.数据需求说明  3.1系统概述  3.2静态数据  3.3动态输入数据  3.4动态输出数据 3.5故障处理要求 3.6其他专门要求  4．数据的采集  5.软件结构设计说明  5.1系统概述

 5.2系统体系结构设计  5.3数据存储设计

5.3.1 E-R图

 6.软件测试说明

 1.引言

大学生是一个阅读书籍广泛的群体，不论是教科类书籍还是休闲类书籍，日复一日总有许多积压在身边，大多不会再反复阅读。一部分学生会选择收藏这些书籍，但是却占用了相当大空间；还有一部分同学会将这些书籍销毁丢弃，或者低价贱买，这样就造成了资源的浪费；另一部分同学会将书籍以原价的折扣价格转卖，这样既节省了空间有实现了资源的循环利用。然而买卖双方直接交涉，通过书写求购或将出售通知张贴于教学区或宿舍区，等到买方或卖方产生相应需求，双方交涉达成交易。但这种方法比较麻烦，而且及时性较差。所以在网上创建一个二手书交易管理系统是很有必要的。

在高校二手书管理系统中，用户分为一般用户即求购者和出售者，以及超级用户系统管理员。他们只需要在我们的平台上进行登记需求，查看我们在上面发布的最新资料更新，根据自己的情况，选择同校、同城、外省交易，我们会及时调配。一般用户对系统具有一般权限，需要通过注册，登陆方能进入系统；超级用户系统管理员对系统具有最高权限，通过登录进入系统，对系统进行管理和维护。求购者在系统中发布图书求购信息，对出售信息进行查询，如果有自己需要的图书，就可以与出售者进行交涉；出售者在系统中发布图书出售信息；图书管理员对出售信息进行整理，更新数据库，链接求书者，进行版内留言。

 2.需求

2.1需求概述 2.1.1目标

编写此需求分析的目的在于让用户了解我们将要创建的二手书交易管理系统,了解此系统实现的需求性，可行性，从而接受网上图书交易这种方式，促进资源的循环利用。2.1.2运行环境

该系统使用HTML、CSS、ASP等关键技术、选用B/S结构分布模式来进行设计并实现的.2.1.3用户的特点

本系统的用户可以分为以下三类：

 求购者：此类用户可能会在在淘书店论坛上发布求购图书的帖子，或者回复出售者发布的求购贴以购买自己需要的图书，此类用户对软件系统具有一般权限。

 出售者：此类用户可能会在在淘书店论坛上发布出售图书的帖子，或者回复求购者发布的求购贴以出售自己的图书，此类用户对软件系统具有一般权限。

 软件管理员：此类用户对软件全方面进行管理，保证软件运行的安全，对各个用户以及他们发布的信息进行审核，更新数据库，此类用户对软件系统具有最高权限。2.1.4 关键点

关键功能：及时更新数据库，对求购信息和出售信息进行整理。2.2需求规格

2.2.1功能图

2.2.2详细功能描述

用户信息管理发布书籍信息用户发布成交信息管理员买卖信息更新游客系统管理浏览信息用户信息表管理员管理请求系统管理信息管理用户信息操作请求系统通知用户2.2.3系统管理

出售信息表管理者管理请求删除删除非法用搜索用户请求户用户信息表2.2.4用户管理 用户信息表用户信息信息更改通知更改请求交易通知交易请求用户登录操作请求账户信息用户信息管理用户管理交易管理用户求购信息表出售信息表2.2.5交易管理

在用户交易管理中，根据用户提供的二手交易书籍生成了“出售信息表”和“求购信息表”，用户可以随时对自己发布的书籍信息进行更改或删除。在交易的过程中，系统会根据这两个表生成对应二手书籍的求购（出售）信息目录供用户浏览参考。对于没有明显求购或出售的用户，也可以浏览由求购、出售作息表生成的求购、出售二手书籍目录。用户交易请求交易管理出售请求交易通知用户信息表求购请求交易通知出售管理求购管理搜素信息更新请求信息发布求购信息表买家信息更新出售作息表2.2.6出售管理

用户出售请求检查合格用户录入出售信息出售信息描述用户确认出售信息出售书籍信息单提示出售信息表将信息录入出售信息表不合格处理不合格用户信息表出售书籍信息发布出售信息2.2.2.7求购管理

用户可以随时更新自己的买卖信息：

用户录入购入信息用户确认求购信息用户求购请求检查合格求购信息描述提示不合格求购书籍信息单用户信息表不合理处理求购信息表将信息录入求购信息表求购书籍信息发布求购信息2.2.8搜索

根据用户的搜索信息输出相应的结果：

求购信息表用户搜索请求用户录入搜索信息开始搜索搜索内容搜索信息匹配出售信息表搜索结果单搜索结果生成搜索结果3.数据需求说明

3.1系统概述

在高校二手书管理系统中，用户分为一般用户即求购者和出售者，以及超级用户系统管理员。他们只需要在我们的平台上进行登记需求，查看我们在上面发布的最新资料更新，根据自己的情况，选择同校、同城、外省交易，我们会及时调配。一般用户对系统具有一般权限，需要通过注册，登陆方能进入系统；超级用户系统管理员对系统具有最高权限，通过登录进入系统，对系统进行管理和维护。求购者在系统中发布图书求购信息，对出售信息进行查询，如果有自己需要的图书，就可以与出售者进行交涉；出售者在系统中发布图书出售信息；图书管理员对出售信息进行整理，更新数据库，链接求书者，进行版内留言。3.2静态数据

用户的用户信息，发布的求购或出售信息。3.3动态输入数据

用户发布的求购或出售信息。3.4动态输出数据

向求购者输出的出售者的信息。3.5故障处理要求

软件故障：可能会出现书籍信息不准确、数据更新不及时等故障。要及时更新书籍信息，保证时效性，尽量避免错误的产生。

硬件故障：本系统对硬件方面没有什么特别的要求，只要有终端就能运行，如果遇到死机等的情况时，用户的信息也会进行保存，不会丢失。3.6其他专门要求

正确性：要求发布的信息及时准确，并且能够及时进行更新。可维护性：要求系统投入运行后易于维护，易于操作。可补充性：要求可以根据实际情况进行功能的增加。可操作性：要求软件使用起来方便，易懂。

运行环境可转换性：要求本系统可以适应不同的运行环境，可以

提供给用户自行选择下载。

4．数据的采集

a.输入数据的来源：广大用户。

b.数据输入所用的媒体和硬设备：键盘。c.接收者:广大用户。

d.输出数据的形式和设备：输出数据是显示器上的一组字符；输出设备为显示器。

5软件结构设计说明

5.1系统概述

在高校二手书管理系统中，用户分为一般用户即求购者和出售者，以及超级用户系统管理员。他们只需要在我们的平台上进行登记需求，查看我们在上面发布的最新资料更新，根据自己的情况，选择同校、同城、外省交易，我们会及时调配。一般用户对系统具有一般权限，需要通过注册，登陆方能进入系统；超级用户系统管理员对系统具有最高权限，通过登录进入系统，对系统进行管理和维护。求购者在系统中发布图书求购信息，对出售信息进行查询，如果有自己需要的图书，就可以与出售者进行交涉；出售者在系统中发布图书出售信息；图书管理员对出售信息进行整理，更新数据库，链接求书者，进行版内留言。5.2系统体系结构设计 用用例图和类图来说明：

5.3 数据存储设计

在系统分析阶段进行系统逻辑设计时，已从逻辑角度对数据存储进行了初步设计，而现在到了系统设计阶段，就要结合选用计算机硬件和软件及使用要求，完成数据存储的详细设计。5.3.1 E-R图

数据存储分析是数据库设计的基础，在系统分析阶段进行数据存储分析时，曾经分析用户的要求，通过综合抽象，用E-R 图进行了描述。经过上一阶段对系统得分，得到以下E-R图，如下图所示： E-R图：

关系模式：

管理员（管理员编号，登陆名，登录密码，等级）

用户（用户编号，登录名，登录密码，真实姓名，性别，电话，邮箱）图书信息文件（图书编号，类别，图书名称，简洁，作者，出版社，出版时间，发布时间，拥有者编号，销售情况）

求购图书信息文件（求购编号，类别，图书名称，简介，作者，出版

社，出版时间，发布时间，发布者编号，销售情

况）

查询结果（用户编号，图书编号，拥有者编号）

说明：管理员可以是用户

拥有者编号，发布者编号均是用户编号，这里用于区别买家与卖家。

6.软件测试说明

系统概述

需求分析报告 篇7

综合要求

一、功能需求

1.1 功能划分

（1）“衣”子系统

（2）“食”子系统

（3）“住”子系统（4）“行”子系统

1.2 功能描述

（1）“衣”子系统

实现功能：

1）用户服装信息的管理

2）通过当时外界环境和现有服装进行实时推荐

（2）“食”子系统

实现功能：

1）根据用户地理位置（家or餐馆）推送用户当前应摄入的健康食物。

（3）“住”子系统

实现功能：

1）自动调整屋内温度、湿度、光线和家具（沙发、床）的软硬程度

2）通过无线遥控对各智能终端进一步调节（4）“行”子系统

实现功能：

有车用户：结合用户对于出行成本的选择（最省时，最省油，折中），给出最优的出行路线。

无车用户：

１）链接打车软件

２）通过连接“车来了”等软件给用户提供建议

1.3系统功能

（1）设计不同用户的操作权限和登录方法。

（2）通过传感器获得周围环境的温度，湿度并将其录入数据库。

（3）通过网络信息抓取以及卫星定位获得必要信息（车流量）并将其录入数据库。（4）实时获得用户身体健康系数及其饮食喜好并将其录入数据库。（5）获得附近餐馆和菜品的信息并将其录入数据库。

（6）根据车载传感器获得车距和能见度等信息，并将其录入数据库。（7）实现语音录入当前用户的代办适宜。（8）通过消息推送，实现智能办公。

二、性能需求

2.1 数据精确度 该系统对精度要求高，确保数据一致性，确保数据转换的及时准确，确保更新数据的及时准确。

2.2 系统特性

·系统的高速性，稳定性，安全性。

·移动端（安卓／ios 内存2Ｇ 容量16Ｇ 分辨率320*480）·反映时间：10ms – 100ms ·信息量速率：500bit/s或bps ·数据库容量：500Ｔ

三、可靠性和可用性需求

3.1 稳定性

·对于用户比较繁忙的时候，系统信息就会存在数百甚至数千上万的并发量，系统对于高并发应有相应的负载均衡机制，对所有请求进行优先排队，满足高运行情况下的稳定性和可靠性。

3.2可靠性

·对于遭受网络攻击，或者服务器硬件异常等意外情况，要有意外处理机制，需要系 统能够保证定时备份数据信息，保证在服务器异常的情况下能及时启动应急机制。保证系统的正常访问。

3.3 安全性

·提高安全保密机制，保证数据可靠安全

·对不同用户分配不同的权限

·用户只能操作相应权限的信息，如查看，删除信息等

·要保证用户信息的安全性，保证管理员和开发者不能够随意的查阅改动用户信息

3.4完整性

·提高数据完整性，参照完整性等

3.5 易用性

·提高使用性，便于用户操作，提高用户满意度。

3.6可复用性

·保证代码可复用，方便操作

3.7 可维护性

·提高程序健壮性，保证程序的后期可维护性

3.8 可移植性

·提高代码使用次数，提高利用率，保证代码可移植性

3.9 可测试性

·保证程序可测试，便于后期操作

四.出错处理需求

4.1格式要求

·给每一个信息的格式都要注意其形式。格式不对的自动重新测试，以及自动把情况反馈给管理员。

4.2信息保存

·对于外来攻击导致系统崩溃情况，需要及时保留用户当前所有的信息。

五、接口需求

5.1 用户接口

·把用户提交的账号密码，在数据库中进行搜索查询进行验证。

5.2硬件接口

·温度传感器接口，空气湿度传感器接口

5.3 软件接口

·实现衣食住行模块和数据库之间相互传输信息

5.4 通信需求接口

·实现卫星以及车载传感器把测的数据进行传输。

六、约束

6.1精度

·对于温度，湿度要求精确到小数点后两位。对于能见度等问题需要精确到误差在３米之内

6.2语言约束

·英语和汉语结合。

6.3设计约束

·全部过程需要从整体，平衡出发。不要仅仅开发完一个在区开发另外一个。

6.4使用标准

·全部的标准使用国际标准。

6.5硬件平台

·台式机为xp/win7系统。移动端为android/ios。

七、逆向需求

基于互联网的“懒人系统”目前能够完成生活许多方面的推荐以及收集测试信息等。但是尚且不能人性化的代替拥护进行决定。

八．系统用例图

服装推荐传感器食物推荐用户家居调节因特网出行推荐登陆

九．系统数据需求分析

9.1系统的E-R图

服装餐厅服装推荐食物推荐用户家居调节出行推荐家居用品道路

9.2数据需求

（1）穿衣子系统

（衣橱统计，气象监控，期刊统计，用户喜好）说明：

衣橱统计：记录用户当前拥有的服饰，需要用户自行更新。

气象监控：记录实时的天气情况，从互联网获取当前温度气象信息。

期刊统计：统计当前时尚期刊中出现频率较高的服饰搭配信息，以便向用户推送。用户喜好：统计用户的穿衣习惯，找出并记录用户喜欢的搭配风格，以便系统进行比较。（2）饮食子系统

（饮食记录，饮食统计，饭店信息）说明：

饮食记录：记录用户日常的一日三餐情况。饮食统计：根据饮食记录中的信息，分析出用户偏好并记录。

饭店信息：储存用户周边饮食信息，根据系统分析，为用户推荐适合的餐饮建议。（3）住宿子系统（家具信息统计）说明：

此系统主要负责管理用户生活起居，所含数据包括： 室内温度，家电状态（如电视开闭，空调开闭），照明系统，窗帘控制（4）出行子系统

（地图信息，公交信息，票务信息，记事本）说明：

地图信息：主要供导航软件调用，并按时进行更新。

公交信息：储存用户周边的公共交通信息，方便用户乘坐公交车。

十．系统逻辑模型

10.1数据流图 衣： 1层：

温度传感器温度日期因特网流行服装信息流行服装信息用户浏览习惯信息用户浏览习惯信息温度日期日期温度1采集信息服装推荐子系统的信息流行服装信息用户浏览习惯信息服装推荐子系统的信息服装推荐子系统的信息现有服装信息出席场合信息用户2执行服装推荐算法推荐的服装信息3输出推荐的服装推荐的服装信息推荐的服装信息推荐的服装信息 2层： 温度传感器因特网温度日期流行服装用户浏览信息习惯信息用户浏览习惯信息用户浏览习惯信息1.6接收用户浏览习惯信息温度日期流行服装信息温度日期流行服装信息1.5接收流行服装信息1.3温度1.4接收日期温度日期流行服装信息用户浏览习惯信息采集信息服装需求信息1.1接收服装需求信息现有服装信息1.2接收现有服装信息现有服装信息服装需求信息用户

服装推荐子系统服装推荐子系统的信息的信息2.1整理信息正确格式的信息2.2“标签”算法推荐的服装推荐的服装

食： 1层：

传感器身体状况信息身体状况信息身体状况信息因特网餐厅菜品信息餐厅菜品信息餐厅菜品信息食物推荐子系统的信息1采集信息食物推荐子系统的信息食物推荐子系统的信息饮食喜好用户2执行食物推荐算法推荐的菜品信息3输出推荐的菜品信息推荐的菜品信息推荐的菜品信息推荐的菜品信息 2层：

传感器因特网身体状况信息餐厅菜品信息身体状况信息餐厅菜品信息身体状况信息1.2接受身体状况信息餐厅菜品信息1.3餐厅菜品信息身体状况信息餐厅菜品信息采集信息饮食需求信息1.1接收饮食喜好信息饮食喜好信息用户 食物推荐子系统食物推荐子系统的信息的信息2.1整理信息正确格式的信息2.2“标签”算法推荐的菜品推荐的菜品

住： 1层：

传感器用户体征信息温度信息光线信息用户体征信息用户体征信息温度信息温度信息湿度信息湿度信息湿度信息家居调节子系统的信息家居调节子系统的信息家居调节子系统的信息光线信息光线信息1采集信息用户习惯的环境信息用户3执行调节方案2执行家居调节算法调节方案调节方案调节方案温度湿度信息信息亮度信息窗帘位置信息空调电灯窗帘

2层：

传感器温度信息光线信息湿度信息温度信息温度信息1.2接收温度信息光线信息光线信息1.3接收光线信息湿度信息湿度信息1.4接收湿度信息温度信息光线信息湿度信息采集信息用户习惯的环境信息1.1接收用户习惯的环境信息用户习惯的环境信息用户 家居调节子系统家居调节子系统的信息的信息2.1整理信息正确格式的信息2.2“选路”算法调节方案调节方案

调解方案温度信息湿度信息亮度信息窗帘位置信息3.1发送温度信息3.2发送湿度信息3.3发送亮度信息3.4发送位置信息温度信息湿度信息亮度信息位置信息空调电灯窗帘

行： 1层：

传感器用户位置信息用户位置信息因特网道路信息道路信息出行推荐子系统的信息用户位置信息道路信息出行推荐子系统的信息出行推荐子系统的信息1采集信息时间金钱需求信息目的地信息用户2执行出行推荐算法推荐方案推荐方案推荐方案3输出推荐方案推荐方案

2层： 传感器用户位置信息用户位置信息用户位置信息2.3接收用户位置信息道路信息道路信息2.4接收道路信息道路信息因特网用户位置信息道路信息采集信息时间金钱需求信息2.1接收时间金钱需求信息目的地信息2.2接收目的地信息时间金钱需求信息目的地信息用户

出行推荐子系统出行推荐子系统的信息的信息2.1整理信息正确格式的信息2.2“标签”算法出行方案出行方案

10.2相应的数据字典 衣： 数据流 数据流名：出席场合信息 说明：用户希望服装推荐系统针对不同的场合帮助其选择合适的服装，服装推荐系统会在用户已有衣服的基础上提供给用户合适的服装搭配方案 数据流来源：用户

数据流去向：采集信息

定义：出席的场合={学校，办公室，聚会，典礼}

数据流名：温度

说明：记录室内外温度，帮助用户选择合适厚度的衣服 数据流来源：温度传感器 数据流去向：采集信息 定义：温度=-40..40

数据流名：现有服装信息 说明：记录用户已有服装，服装推荐系统在已有服装基础上提供给用户合适的服装搭配方案

数据流来源：用户

数据流去向：采集信息 定义：已有服装信息=服装编号+服装名称+品牌+尺寸+颜色+款式+材质+服装图片索引

数据流名：日期

说明：记录当前日期，帮助用户选择合适季节的衣服 数据流来源：因特网

数据流去向：采集信息（数据存储）定义：日期=年＋月＋日

数据流名：流行服装信息

说明：获得当下的流行风尚，帮助服装推荐系统和已有服装进行对比，从而给出符合当下流行的服装搭配 数据流来源：互联网

数据流去向：采集信息（数据存储）定义：流行服装信息=服装编号+服装名称+品牌+尺寸+颜色+款式+材质+服装图片索引

数据流名：用户浏览习惯信息

说明：记录用户经常浏览的服装，将信息发送给服装推荐系统，服装推荐系统由此分析用户的穿衣喜好，从而推荐给用户符合其穿衣品味的服装 数据流来源：互联网

数据流去向：采集信息（数据存储）定义：服装编号+浏览次数

数据流名：推荐的服装 说明：服装推荐系统根据对采集的参数进行智能处理，最后得到合适的服装搭配信息

数据流来源：智能服装推荐程序

数据流去向：推荐的服装信息（数据存储）定义：推荐的服装=服装编号+服装图片索引 数据加工

加工名：采集信息 加工编号：1 简要描述：采集服装推荐算法需要的信息

输入数据流：出席场合信息，温度，现有服装信息，日期，流行服装信息，用户喜好信息

输出数据流：服装推荐算法的信息

加工逻辑：采集出席场合信息，传感器信息，因特网信息。

加工名：执行服装推荐算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：服装推荐子系统的信息 输出数据流：推荐的服装 加工逻辑：“标签”算法的本质是专家系统，数据库有1万条用户在各种情况下的解决方案（1万条记录），用户在界面上选择的标签会变成另一张二维表中的记录，“标签”算法会将用户的选择（记录）和数据库1万条记录比照，匹配项最多的记录的解决方案会成为最后的推荐方案。加工名：输出推荐的服装 加工编号：3 简要描述：显示推荐的服装信息 输入数据流：推荐的服装信息 输出数据流：推荐的服装信息 加工逻辑：显示推荐的服装信息

数据文件名：温度

简述：存放的是温度信息 输入数据：温度 输出数据：温度

数据文件组成：温度

数据存储

数据文件名：现有服装信息 简述：存放已有服装信息

输入数据：服装编号，颜色，尺码，类型，条形码 输出数据：服装编号

数据文件组成：服装编号，颜色，尺码，类型，条形码

数据文件名：日期 简述：存放当前的日期 输入数据：年+月+日 输出数据：年+月+日 数据文件组成：年+月+日

数据文件名：流行服装信息 简述：存放当时流行的服装款式

输入数据：颜色，尺码，类型，条形码 输出数据：条形码

数据文件组成：颜色，尺码，类型，条形码

数据文件名：用户浏览习惯信息

简述：存放用户在各大网站查询的服装信息 输入数据：用户浏览习惯信息 输出数据：用户浏览习惯信息

数据文件组成：服装编号，浏览次数

食： 数据流

数据流名：饮食喜好

说明：用户希望饮食推荐系统推荐一些餐饮信息，以供选择，饮食推荐系统会根据用户的饮食习惯，偏好，营养均衡等多种因素结合为用户推荐健康可口的食物。数据流来源：用户

数据流去向：采集信息 定义：饮食喜好={甜，咸}

数据流名：身体状况信息

说明：系统通过记录或探测，用户的基本生命体征如心率，血压，血糖等，为推荐饮食提供参考信息。

数据流来源：传感器，因特网 数据流去向：采集信息

定义：身体状况信息=心率+血压+血糖

数据流名：餐厅菜品信息

说明：系统通过存储并及时更新餐厅菜单，为推荐饮食提供参考信息。数据流来源：因特网 数据流去向：采集信息

定义：餐厅菜品信息=餐厅名+餐厅编号+菜名名+菜品编号+菜品营养+菜品口味、数据流名：推荐的菜品信息

说明：食物推荐算法处理食物推荐子系统信息产生的结果。数据流来源：执行食物推荐算法 数据流去向：输出推荐的菜品信息

定义：餐厅菜品信息=餐厅名+餐厅编号+菜名名+菜品编号+菜品营养+菜品口味、数据加工：

加工名:采集信息 加工编号：1 简要描述：采集食物推荐子系统所需数据

输入数据流：身体状况信息，餐厅菜品信息，饮食喜好 输出数据流：食物推荐子系统的信息

加工逻辑：从互联网，用户输入，传感器接受信息

加工名：执行食物推荐算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：食物推荐子系统的信息 输出数据流：推荐的菜品 加工逻辑：“标签”算法的本质是专家系统，数据库有1万条用户在各种情况下的解决方案（1万条记录），用户在界面上选择的标签会变成另一张二维表中的记录，“标签”算法会将用户的选择（记录）和数据库1万条记录比照，匹配项最多的记录的解决方案会成为最后的推荐方案。

加工名：输出推荐的菜品 加工编号：3 简要描述：显示推荐的菜品信息 输入数据流：推荐的菜品信息 输出数据流：推荐的菜品信息 加工逻辑：显示推荐的菜品信息

数据存储：

数据文件名：身体状况信息

简述：存放身体状况信息，如体重，血压，心率等 输入数据：身体状况信息 输出数据：身体状况信息

数据文件组成：体重，血压，心率

数据文件名：餐厅菜品信息 简述：存放餐厅菜单 输入数据：餐厅菜品信息 输出数据：餐厅菜品信息

数据文件组成：餐厅名，餐厅编号，菜名名，菜品编号，菜品营养，菜品口味、数据文件名：推荐的菜品信息 简述：存放推荐的菜品信息 输入数据：推荐的菜品信息 输出数据：推荐的菜品信息

数据文件组成：餐厅名，餐厅编号，菜名名，菜品编号，菜品营养，菜品口味、住： 数据流

数据流名：温度信息 说明：采集室内的温度信息，反馈给用户，或者系统根据温度自动采取相应措施，调节室内温度。

数据流来源：温度传感器

数据流去向：采集家居控制系统的参数 定义：温度=-40-40摄氏度

数据流名：光线信息 说明：采集室内的光线信息，反馈给用户，或者系统根据温度自动采取相应措施，调节室内光照强度。数据流来源：光敏传感器

数据流去向：采集家居控制系统的参数 定义：光照强度=0-180流明

数据流名：湿度信息 说明：采集室内的湿度信息，反馈给用户，或者系统根据温度自动采取相应措施，调节室内湿度。

数据流来源：湿度传感器

数据流去向：采集家居控制系统的参数 定义：湿度=10%-80%

数据流名：用户习惯的环境信息

说明：采集用户习惯的温度信息，光线信息，湿度信息 数据流来源：用户

数据流去向：采集信息

定义：用户习惯的环境信息=温度+光线+湿度

数据加工

加工名：采集信息 加工编号：1 简要描述：采集智能控制系统需要的参数

输入数据流：温度，湿度，光照强度，温度请求，湿度请求，光照请求 输出数据流：智能家居控制系统的参数

加工逻辑：从各个传感器接受信息，并与用户设置进行对比，得出相应操作发送给控制器实施。

加工名：执行家居调节算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：家居调节子系统的信息 输出数据流：调解方案 加工逻辑：“选路”算法本质是基于条件判断的数据处理系统。该处理系统自身包含多个IF语句对用户需求进行判断分支执行。从而得到最后的推荐方案。

加工名：执行调节方案 加工编号：3 简要描述：把温度，湿度，亮度，窗帘的位置信息传递给空调，电灯，窗帘 输入数据流：调节方案

输出数据流：温度，湿度，亮度，窗帘的位置信息 加工逻辑：对传感器传递信息

数据存储

数据文件名：温度信息 简述：存放的是温度信息 输入数据：温度信息 输出数据：温度信息 数据文件组成：温度

数据文件名：湿度信息 简述：存放的是湿度信息 输入数据：湿度信息 输出数据：湿度信息 数据文件组成：湿度

数据文件名：亮度信息

简述：存放的是光照强度信息 输入数据：亮度信息 输出数据：亮度信息 数据文件组成：亮度信息

行： 数据流

数据流名：用户位置信息 说明：借助通信运营商来获取用户详细位置，出行管理系统会利用该位置信息提供导航，或叫车服务。数据流来源：通信运营商

数据流去向：采集出行管理系统的参数 定义：用户位置信息=经度+纬度

数据流名：道路信息

说明：将街道信息储存到客户端，并定期进行更新，出行管理系统会利用该道路信息提供导航服务。数据流来源：互联网

数据流去向：采集出行管理系统的参数 定义：道路信息={繁忙，畅通}

数据流名：目的地信息

说明：用户想要到达的目的地信息 数据流来源：用户

数据流去向：采集信息

定义：目的地信息=目的地信息

数据流名：时间金钱需求信息 说明：用户对于时间，金钱的要求 数据流来源：用户

数据流去向：采集信息

定义：时间金钱需求信息=时间+金钱

数据加工

加工名：采集信息 加工编号：1 简要描述：采集出行推荐子系统需要的信息

输入数据流：用户位置信息，道路信息，目的地信息，时间金钱需求信息 输出数据流：出行推荐子系统的信息 加工逻辑：从用户和互联网接收信息。

加工名：执行出行推荐算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：出行推荐子系统的信息 输出数据流：推荐方案 加工逻辑：“标签”算法的本质是专家系统，数据库有1万条用户在各种情况下的解决方案（1万条记录），用户在界面上选择的标签会变成另一张二维表中的记录，“标签”算法会将用户的选择（记录）和数据库1万条记录比照，匹配项最多的记录的解决方案会成为最后的推荐方案。

加工名：输出推荐方案 加工编号：3 简要描述：显示推荐方案信息 输入数据流：推荐方案 输出数据流：推荐方案

加工逻辑：显示推荐方案信息

数据存储 数据文件名：用户位置信息 简述：存放用户的经纬坐标 输入数据：用户位置信息 输出数据：用户位置信息 数据文件组成：经度，纬度

数据文件名：道路信息

简述：存放道路的繁忙情况信息 输入数据：道路信息 输出数据：道路信息

数据文件组成：道路繁忙情况信息

数据文件名：推荐方案

简述：存放推荐的出行方案信息 输入数据：推荐方案 输出数据：推荐方案

需求分析报告 篇8

1、时间：4月5日

2、地点：繁华路段，沿街门面、行政机关单位、事业单位、陌生拦截等处选择样本

3、调研方式：问卷填写、深度访谈

4、发出问卷：80份，有效问卷68份

5、样本人群基本情况

家庭人数：

文化程度：大专以上12人 中学(含高中、初中、中专)40人 其他16人

工作单位：经商或个体户36 事业或行政单位20 其他12

收入状况：

6、户型结构选择

从图中可以看出，客户对房型结构的选择中，三房两厅的占到高达40%的份额，加上18%的四房两厅和18%的三房一厅，合计占到76%的份额，只有不占1/4的人选择两房或其他户型。

7、户型面积选择

从图中可以看出，客户选择110―130平方米的比例占到35%，与上图中三房两厅40%的比例类似;90―150平方米的比例合计占到81%，加上150平方米以上13%，全部占到总份量的94%，90平方米以下的仅占到6%。

注：以上数据引自郑州深蓝咨询机构《项目全程营销策划报告》，以下数据是展示接待中心接待来访客户情况的数据统计分析

二、205月份客户面积选择意向分析

户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 其他 合计

数量(组) 30 12 55 61 66 51 45 51 371

客户在提示作用下，除14%的客户选择其他户型外，86%的客户都能在120―150平方米之间选到满意的户型。

三、年6月份客户面积选择意向分析

户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 四房 其他 合计

数量(组) 24 20 49 32 41 20 16 43 61 306

客户在提示作用下，选择120平方米以上的占到80%，在其他20%的客户中，除部分选择复式户型的以外，选择其他户型的只有不足20%。

四、2006年7月客户对户型面积的意向分析

户型面积 90O 110O 120-130O 130-150O 复式及150以上 无具体意向 合计

客户量 5 6 34 47 15 8 115

需要130―150平方米的客户超过40%，而120―130平方米客户占30%，两者合计占到70%左右，是县城购房的主力目标客户群体。复式楼的.需求量也在13%，是县城高端购房人群之一。90―110平方米的人群占到9%左右，可以看作县城购房群体的补充目标人群。

结论：

综上所述，在豫北某县购房群体中，最少有60%以上的客户选择120―150平方米的房子，最高达到86%左右的比例。另有10―20%的客户选择150平方米以上的户型。只有不到10%的少量客户需求面积在90平方米左右或以下。

如果公务员小区的房型面积不能按照市场需求状况供应，将产生以下几点影响：

第一，单套面积较小的商品房非主流市场需求产品，一旦供应，()将只有极少数的目标人群购买，项目开发不可能达到预期的社会效益和经济效益;

第二，由于单套面积较小的房到成本增加，在销售价格不变的情况下，投资回报率降低;同时，在市场需求有限的环境下，将直接影响到开发企业的开发积极性;

第三，由于市场缺乏满足客户需求的产品，将造成市场供应产品的结构极度不平衡，对于目前市场上供应的大户型产品有着较大利好，将有可能进一步抬升房价，造成更多的客户买不起房;

第四，客户选不到适合自己的商品房，将取消或推迟自己的购房计划、或者选择其他的住宅获取途径来解决居住问题，无论对于政府税收、经济发展、扩大内需都有着较大的冲击;