需求分析说明书控制

需求分析说明书控制（推荐7篇）

需求分析说明书控制 篇1

文档信息：

项目名称：财务管理系统项目经理：sGlobalMethod阶段:需求分析

·1.引言

1.1 编写目的

为使系统开发人员和业务需求人员达成对本次虚账户管理系统项目开发需求的一致理解，同时做为下一阶段系统设计的依据，特编写此《需求分析说明书》。

2收入管理需求描述

根据业务提出需求，需要增加学费管理，寝室费管理菜单，下面对功能进行详细描述。

2.1收入管理

2.1.1功能概述

收入列表显示，添加，删除，修改

2.1.2界面描述

2.1.2.1寝室费

第一页寝室费收入列表显示（所有数据）按院校日期，地点，寝室号等分类查询 显示寝室费收入列表；

添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页寝室费录入功能

含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；

2.1.2.2学费

第三页学费收入列表显示（所有数据）按院校日期等分类查询 显示学费收入列表；

添加功能，单条/批量删除，修改功能，导出功能，导出当前所选择的记录。按添加按钮跳入第四页 第四页学费录入功能

含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；

3支出管理需求描述

3.1支出管理 3.1.1功能概述

支出列表显示，添加，删除，修改

3.1.2界面描述

3.1.2.1财务报销

第一页财务报销支出列表显示（所有数据）按院校，报销类别，日期等分类查询； 显示财务报销列表

添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页财务报销录入功能

含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；

3.1.2.2付款申请

第一页付款申请支出列表显示（所有数据）按院校，付款类型，日期等分类查询； 显示付款申请列表

添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页付款申请录入功能

含有表头的可编辑的空表格，添加可编辑行数（1）删除可编辑行数（1）保存；

3.1.2.3采购申请

第一页采购申请支出列表显示（所有数据）按院校，采购类型，日期等分类查询； 显示采购申请列表

添加功能，单条/批量删除，修改功能，导出功能。按添加按钮跳入第二页 第二页采购申请录入功能

需求分析说明书控制 篇2

“一战”至今, 随着传感器能力的提升, 战场武器装备的日益先进, 移动速度等能力都得到提升, 但人处理信息能力却始终没有变化, 所以面对复杂多变的未来战场, 开发相适应的现代化的指挥控制系统, 辅助指挥员作出正确的决策势在必行。

1 指挥控制问题描述

指挥控制系统的发展始于二战后, 美国于20世纪50年代末, 开发了“赛其” (SAGE) 半自动化防空系统。70年代初, 建成战略C3I系统。目前拥有较完善的军队C4ISR系统。我国在这方面研究起步较晚, 但是发展迅速。

指挥与控制的内容可以看作是各级指挥员在作战过程中所作出的两大决策, 决策内容和结果在各级指挥员之间存在着交互, 指挥与控制的内容可以以北约空军为例, 见图1。

具体地说, 指挥的内容是部队尚未执行任务前, 各级指挥员对整个战场环境进行考量, 作出相应决策, 即运筹, 其内容主要包括:

1) 任务分配, 根据整个战场环境配置投入到各战场的兵力比例;

2) 兵力部署, 根据各战场情况, 决定兵力的分布及具体数量;

3) 子任务兵力分配, 各部队根据分配的子任务决定出动的兵力;

4) 具体实施步骤, 以空军为例, 制定各种战术, 包括应该指派何种型号飞机执行任务, 制定进入任务以及退出任务的路线以使其所受威胁最小化, 作战效能最大化。

控制的内容是部队于执行任务过程中, 各级指挥员对战场环境的变化所作出的决策, 即规划, 其内容主要包括:

1) 资源重新分配, 预测战场环境的变化, 对兵力、物资等进行重新分配;

2) 任务重分配, 根据预测结果, 对各部队所指派的任务进行第二次分配;

3) 目标跟踪, 各部队利用现有技术, 跟踪所指派的目标;

4) 威胁预警, 当敌军进入到我方威胁区域内, 应及时预警, 作出决策。

在指挥与控制的过程中, 指挥员需要作出各类决策, 作出这些决策的时间及所需信息的多少也不尽相同。详见表1。

随着指挥层级的降低, 该层级指挥员所作出决策需要的时间呈现下降的趋势, 而信息聚合的程度也随之下降。

2 决策的制定及执行

指挥员在作战过程中根据战场信息作出相应的决策, 其制定的过程是固化在数据转化到行动的过程中, 所以指挥员首先必须能够获得战场信息, 从方方面面的战场信息中提取相关联的内容加以甄别以实现对战场的理解。指挥员在基于已有数据对战场理解的情况下, 作出一些作战方案, 对这些方案再进行评估, 最后选出最优方案。随着战况的逐步发展, 战场环境也瞬息万变, 指挥员也必须根据最新信息作出新的决策。

以上即是一个指挥员作出决策的一个描述, 根据上述描述, 我们可以将决策制定及执行的过程分解为以下四个步骤:战场态势的获取;战场态势的理解;备选方案的制定;方案的执行。

在决策制定的这四个步骤中, 指挥员都有可能出现错误, 分析如下:

1) 在战场态势的获取过程中, 指挥员可能会出现“我不知道”的问题;

首先, 指挥员需要知道尽可能多的战场信息以为自己决策提供数据支持, 然而战场信息涉及到各个方面, 作战武器装备繁多, 各式各样的行动又在不间断的进行着, 但是一个指挥员只能拥有有限的传感器, 即信息收集渠道, 每个传感器的监视范围又存在范围、天气、作战要求等的限制;

另一方面, 战场本身是动态的, 指挥员如果不能有效的, 合理的使用各传感器, 也可能造成指挥员不能收集战场态势信息的错误。

指挥控制系统在防止指挥员出现“我不知道”这个问题上应从以下两个方面出发:

首先, 应帮助指挥员建立起何时、何地应从各种传感器上了解什么的意识, 设计一个战场信息态势图可以很好的解决这个问题, 战场信息态势图应包括以下信息: (1) 所有传感器当前和规划后的位置; (2) 传感器能够覆盖的区域; (3) 监测的频率; (4) 重点监测区域; (5) 亟待监测区域显示; (6) 数据上传及处理流程; (7) 传感器使用限制区域 (减小反辐射导弹对雷达的威胁) ; (8) 可使用的兵力及武器; (9) 给出时间截点。

2) 在战场态势理解过程中, 指挥员可能会出现“我不理解”的问题;

即使在获取了全部战场信息的情况下, 指挥员可能依然会出现不能正确理解战场态势的问题, 其根本原因就是战场信息的不确定性。这主要体现在以下两方面:

首先, 战场态势被隐藏在了众多的数据之后, 需要指挥员去发掘;

另一方面, 指挥员对战场态势理解的方向出现偏差, 不是从已知事实出发, 没有通过更多信息的检验。这一点涉及到指挥员对战场走向的预测能力。

指挥控制系统在防止指挥员出现“我不理解”这个问题上应从以下两个方面出发:

首先, 对获得的信息进行过滤筛选, 提高信息纯度, 使决策时间尽可能短, 避免“噪音”对其的影响。

其次, 基于一些已有的假设去诠释战场态势, 推理敌军意图, 这又要求指挥员意识到以下几点:

(1) 敌军的目的、能力、原则、作战程序; (2) 可供敌军的选择; (3) 由于数据的缺失, 我军在行动上的不确定性。

最后, 指挥员应该意识到, 决策一旦作出, 需要更多实时信息检验指挥员对战场态势的理解是否正确。

3) 在备选方案的制定的过程中, 指挥员可能会出现“我没有考虑”的问题;

面对一个战场, 指挥员需要时刻关注转瞬即逝的机会, 比如天气、地形、敌军出现的决策错误。指挥员通常会制定几个可供选择的方案以创造优势交战或者是摆脱劣势交战, 以使我军行动效益最大化, 这就要求指挥员在大部分的时间内都要考虑选择何种方案。“我没有考虑”这个问题的根本来源于对行动结果的不确定性的忽视。

指挥控制系统在防止指挥员出现“我没有考虑”这个问题上应该帮助其了解我军及敌军的能力、地形和天气等各种因素, 各行动目标之间的关联, 在此基础上给出一些备选方案, 并且, 能够评估这些方案的结果, 给出相关风险和收益。

4) 在方案的执行过程中, 指挥员可能会出现“我没有行动”的问题;

在执行方案的过程中, 指挥员由于情绪的干扰, 外界的影响可能并没有按照既定方案执行任务, 或者在执行过程中出现执行时间或者是实施步骤错误的问题。

指挥控制系统在解决这个问题上应帮助指挥员确定如果不按照该方案行动, 所产生的后果如何, 应能够快速评估行动的结果以解决执行过程中可能出现的错误。

3结束语

随着以信息技术为核心的高新技术在现代战争中的广泛应用, 面对海量数据, 单纯依靠指挥员发挥自身能力作出决策明显跟不上现代战争的步伐, 所以应加快设计研究适应各级指挥员的指挥控制系统的步伐, 旨在未来战场中辅助指挥员快速的作出正确的决策。

参考文献

[1]孔祥忠.战场态势估计和威胁估计[J].火力与指挥控制, 2003, 28 (6) :91-94.

[2]雷蕾, 尚丽娜, 张列航.空战目标威胁排序与目标分配算法[J].电光与控制, 2010, 17 (4) :38-40.

[3]Rosenberger J M, Hwang H, Pallerla R, et al.The Generalized weapon target assignment problem[C]//10thInternational Commandand Control Research and Technology Symposium the Future of C2, Mclean, VA.2005.

[4]罗德林, 段海滨, 吴顺详, 等.基于启发式蚁群算法的协同多目标攻击空战决策研究[J].系统仿真学报, 2008, 20 (24) :677-678.

需求分析说明书控制 篇3

编者说明：

许多有经验的开发团队在开始需求调查的时候，总会将“软件客户需求权利书”和“软件客户需求义务书”提交给客户，让客户明确其权利与义务，将会对需求调研、分析的工作带来意想不到的效果，你可以一试。

1.2.3.4.5.6.7.8.9.10.软件客户需求权利书 要求分析人员使用符合客户语言习惯的表达： 要求分析人员了解客户系统的业务及目标： 要求分析人员组织需求期间所介绍的信息，并编写软件需求规格说明； 要求开发人员对需求过程中所产生的工作结果进行解释说明； 要求开发人员在整个交流过程中保持和维护一种合作的职业态度； 要求开发人员对产品的实现及需求都要提供建议，拿出注意。描述产品使其有易用、好用的特性； 可以调整需求，允许重用已有的软件组件； 当需要对需求进行变更时，对成本、影响、得失有个真是可信的评估； 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

软件客户需求义务书

1.2.3.4.5.6.7.8.9.10.给分析人员讲解业务及说明业务方面的术语等专业问题； 抽出时间清楚地说明需求并不断完善； 当说明系统需求时，力求准确详细； 需要时要及时对需求做出决策； 要尊重开发人员的成本估算和对需求的可行性分析； 对单项需求、系统特性或使用实例划分优先级； 评审需求文档和原型 一旦知道要对项目需求进行变更，要马上与开发人员联系； 在要求需求变更时，应遵开发组织确定的工作过程来处理； 尊重需求工程中开发人员采用的流程（过程）。

需求规格说明书（ISO标准版）

编者说明：

当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS（Software Requirement Standard）。这是在软件项目过程中最有价值的一个文档。ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。

1.引言

1.1 编写的目的确定系统实现的主要功能、指导开发、管理上机学生。

1.2背景

a)待开发的系统的名称：机房收费系统

b)本项目的任务提出者、开发者、用户：学校领导、李龙生、学校学生

c)该系统同其他系统或其他机构的基本的相互来往关系。运行在学校局域网

中。

1.3 定义

[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]

1.4 参考资料

[列出用得着的参考资料]VB程序设计、VB数据库开发、SQL数据库开发。

2.任务概述

2.1 目标

[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。]

管理学生上机、学校、网吧等场所

2.2 用户的特点

[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。]

学校老师、计算机系教师、每年使用

2.3 假定和约束

[列出进行本系统开发工作的假定和约束。]

3.需求规定

3.1 对功能的规定

[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量，包括系统应支持的终端数赫尔应支持的并行操作的用户等指标。]

完成学生计费上机，收费下机的任务。

3.2 对性能的规定

3.2.1 精度

[说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精

度。]

3.2.2 时间特性要求

[说明对于该系统的时间特性要求]

3.2.3 灵活性

[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这

些变化的适应能力。]

3.3 输入输出要求

[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对系统的数据输出及必须标明的控制输出量进行解释并举例。]

3.4 数据管理能力要求（针对软件系统）

[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。]

3.5 故障处理要求

[列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。]软件异常、死机等。

3.6 其他专门要求

[如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。]

4.运行环境规定

4.1设备

[列出运行该软件所需要的硬件设备。说明其中的新型设备及其专门功能，包括;

A.处理器型号及内存容量

B.外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量

C.输入及输出设备的型号和数量，联机或脱机

D.数据通信设备的型号和数量

E.功能键及其他专用硬件]

4.2 支持软件

[列出支持软件，包括操作系统、编译程序、测试支持软件等。]

Window 7

4.3 接口

[说明该系统同其他系统之间的接口、数据通信协议等。]

4.4 控制

[说明控制该系统的运行的方法和控制信号，并说明这些控制信息的来源。]

数据要求说明书（ISO标准）

编者说明：

如果在你的项目中有大量要求数据存储、数据采集等方便的需求，那么你就应该专门将这些需求进行整理，以数据要求说明书的形式表现出来。

1.引言

1.1 编写目的[说明编写这份数据要求说明书的目的，指出预期的读者。]

1.2 背景

a)待开发软件系统的名称；

b)列出本项目的任务提出者、开发者、用户以及将运行该软件的计算站或计

算机网络系统。

1.3 定义

[列出本文件中用到的专门术语的定义和外文首字母词的原词组。]

1.4 参考资料

[列出有关的参考资料。]

2.数据的逻辑描述

[对数据进行逻辑描述时可把数据分为动态数据和静态数据。]

2.1 静态数据

[列出所有作为控制或参考用的静态数据元素。]

2.2 动态输入数据

[列出动态输入数据元素。]

2.3 动态输出数据

[累出动态输出数据元素。]

2.4 内部生成数据

[列出向用户或开发单位中的维护调试人员提供的内部生成数据。]

2.5 数据约定

[说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制。对于在设计和开发中确定是临界性的限制更要明确指出。]

3.数据的采集

3.1 要求和范围

[按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。]

3.2 输入的承担着

[说明预订的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。]

3.3 预期处理

[对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。]

3.4 影响

高级需求分析师的具体职责说明 篇4

1. 需求分析：针对行业典型客户设备管理、生产运行管理，结合工业物联网技术应用，在客户需求调研报告基础上，进行详细的业务需求、功能需求和技术需求分析，编制业务需求分析报告;

2. 技术架构设计：基于业务需求分析结果，结合行业技术发展趋势和公司自有技术和产品，完成业务应用系统或平台的技术架构设计工作，包括信息流向设计、功能架构设计、逻辑架构和部署架构设计，完成总体技术方案;

3. 详细设计：在业务需求分析报告和总体技术方案基础上，进行项目的模块设计工作，编制模块详细设计报告;

4. 编码外部管理：协调外部代码外包团队和公司内部研发团队，完成系统编码的外包过程管理和协调工作;

岗位要求：

Education 教育背景：

重点大学计算机软件或相关专业本科及以上毕业;

Knowledge 专业知识：

1. 具备IT系统架构和外包管理方面的专家知识;

2. 具备需求开发和文档编制及软件开发方面的专业技能;

Experience 工作经验：

1. 具备企业管理信息系统需求开发和功能架构设计、软件开发5年以上的工作经验;

2. 具备移动应用设计和开发经验者优先;

需求说明书 篇5

编制说明

千里之行购物网由“级软件班彭双双”工作室承接制作,其一切功能都依据顾客需求制订,制作,特作以下说明书.

更改控制单

目 录

1

总则 ........................................................................................................................................... - 4 - 1.1 1.2 1.3 2 3

适用范围 ............................................................................................................................. - 4 - 引用标准文献 ..................................................................................................................... - 4 - 名词术语表 ......................................................................................................................... - 4 -

系统体系结构 ........................................................................................................................... - 5 - 系统功能需求 ........................................................................................................................... - 6 - 3.1 3.2

总体实现 ............................................................................................................................. - 6 - 系统管理平台 ..................................................................................................................... - 6 -

前提和约束 ................................................................................................................ - 6 - 3.2.2 系统管理功能 ............................................................................................................ - 7 - 3.3 系统主要业务流程 ............................................................................... 错误!未定义书签。 3.3.1 用户信息发布流程 ....................................................................... 错误!未定义书签。

4

系统技术需求 ........................................................................................................................... - 7 - 4.1 4.2 4.3 4.4 5

安全性 ................................................................................................................................. - 7 - 扩充性 ................................................................................................................................. - 7 - 易维护 ................................................................................................................................. - 7 - 响应速度快 ......................................................................................................................... - 8 -

3.2.1

系统性能需求 ........................................................................................................................... - 8 - 5.1 5.2

系统响应时间 ..................................................................................................................... - 8 - 并发处理能力 ..................................................................................................................... - 8 -

6 系统安全性需求 ....................................................................................................................... - 8 - 6.1 6.2 6.3 6.4

用户合法身份校验 ............................................................................................................. - 8 - 数据授权控制 ..................................................................................................................... - 8 - 操作日志 ............................................................................................................................. - 8 - 防火墙 ................................................................................................................................. - 9 -

7 其它非功能性需求 ................................................................................................................... - 9 - 7.1 7.2 7.3

稳定性需求 ......................................................................................................................... - 9 - 扩展性需求 ......................................................................................................................... - 9 - 易操作 ................................................................................................................................. - 9 -

1 总则

1.1 进入21世纪以后，网上购物已经是一件新鲜的不能再新鲜的事情了，对于我国网络

购物的需要量，特地建立一个购物网站以供需求

1.2 适用范围

本规范是千里之行购物网项目的技术需求、开发和实现的指导性文件。

1.3 引用标准文献

《编码规范》

1.4 名词术语表

2 系统体系结构

参考软件体系架构采用MVC多层体系的思路，本系统平台架构也体现这一架构的思路，具体设计如下图示意：

图2.1系统软件结构示意图

该体系架构采用业界成熟和广泛运用的J2EE技术、基于MVC(模型―视图―控制器)设计范例进行架构设计。

WEB服务器为前端客户浏览器提供表示逻辑和用户导航;处于中间层的应用服务器通过WEB容器和JAVABEAN提供的各组件完成业务逻辑和工作流;处于后端的数据模型层提供数据逻辑，根据具体情况的不同，采用DAO连接数据库。

MVC(模型―视图―控制器)设计范例基于功能清楚地分开了代码，因此，修改某一层上的应用程序不会影响到其它层，整个系统是一个松耦合的系统，特别适合于业务模式、用户状况与需求多变的`应用环境。在系统开发上，由于它将功能清楚地进行了分解，使得需要不同技术能力的团队可以相互独立地工作，这种明确的分工可有效利用开发团队成员的力量，实现高效优质的开发工作。

3 系统功能需求

3.1 总体实现

所有的用户可以划分为以下几个大类：

? 网络用户：通过网络实现查看网页信息，注册为会员，登陆后享受会员具有会员功

能，信息发布、信息回复查看等功能。 ? 系统管理员：系统管理人员，完成基本参数设置、系统运行日志、用户管理和权限

设置等系统基本设置。 按照以上原则，系统划分为两部分功能实现：面向网络用户的功能和面向系统管理的系统管理功能。

图3.1 系统功能模块示意图

以下所有功能模块的需求分析将基于这个模块划分原则进行，并展开详细的需求分析说明。

功能实现上应能做到：操作简便;具有使用护航;可操作性好;对关键数据输入有即时提示;并且做到界面及提示用词统一、通俗易懂、不使用专业技术用语。

3.2 系统管理平台

系统管理平台面向整个网站管理IT系统的系统管理员，管理员通过该平台可以完成系统的用户管理、权限分配、以及性能分析、安全日志查询等系统级管理功能。

图3.2 系统管理平台功能模块图

3.2.1 前提和约束

管理员权限为系统内置权限，只能访问管理平台，不能进行业务操作。

通过用户组设置，减少批量相同权限用户的设置重复工作量。

权限模型按照用户-用户组-权限-可访问资源(包含数据访问控制)，进行设定。

3.2.2 系统管理功能

为了方便顾客的使用、操作和维护以及根据顾客要求，我工作室将千里之行购物网分做前台和后台两个控制功能模块。前台的内容发布给广大的网民，而后台部分则是便于顾客修改数据库，更新网页内容。也就是说，网民通过网络可浏览网页，而顾客将用有一个独立于客户端的控制页面，由顾客授权管理。 网页雏形

我工作室根据顾客提出的要求，计划将网页制作成如下形式：

1、首页顶部千里之行购物网名称，并以图片做修饰，添加导航条，导航条内容有：

网站公告、产品导航、户外服装、登山用品、野营露宿、休闲运动、运动工具共7条;

2、其中首页将推荐商品、特价商品、新上商品，便于顾客浏览。 3、首页左边将放置帮助信息及功能模块; 4、在首页下部是一些其他千里之行购物网的帮助解释等超链接。 5、用户点击相应的功能模块按钮进入功能页面，帮助用户完成功能操作。 6、用户点击客户管理，进行注册、登陆、修改个人信息等操作，并配有各功能的

独立页面，操作不成功弹出操作不成功的提醒页面。

7、后台内容中，提供了系统管理员的登陆，操作页面。操作主页面提供对数据库

内容的增删改查四个功能的按键，管理员选择用户或用户信息后对内容进行更新或修改。每个功能按键对应一组成功与出错的页面。

4 系统技术需求

4.1 安全性

保障用户信息的数据安全性和保密性，防止外部攻击和窃取核心业务数据就显得尤为重要。故在数据访问，层间通讯必须使用JAVABEAN做数据封装。

4.2 扩充性

客户管理有很大的发展潜力，系统应该通过方便的设置扩充系统容量，而且对客户预订业务也应该可以通过模块化定制。

4.3 易维护

随着业务的发展，网站信息数量也会增加，所以系统必须提供方便的维护手段，尽量减少系统维护的工作量。

4.4 响应速度快

用户在查询信息时，对系统延迟往往有一个忍耐极限，所以要求系统响应速度应在用户忍耐范围内。

5 系统性能需求

系统性能是用户测评系统的一个重要指标，包含以下两个方面：系统相应时间和并发处理能力。

同时，考虑性能时，也应该综合考虑系统的硬件指标、用户最大数量、系统实时需求性和系统复杂度。

5.1 系统响应时间

提供先进的数据访问引擎技术，提高数据处理响应速度。一般性查询最长不超过 5 s，一般业务处理操作不操过5s，报表查询以及复杂查询操作一般不操过30s。

5.2 并发处理能力

通过先进缓存技术。解决多用户并发访问瓶颈。 系统应支持最大并发在线客户数为30-50个。

6 系统安全性需求

由于系统是基于Internet的Web应用，因此安全性措施尤为重要。

6.1 用户合法身份校验

6.2 数据授权控制 6.3 操作日志

所有重要业务操作，在系统中均记录日志，包含登录的信息、操作信息、日期等，作为事后系统安全审计和跟踪的依据。

6.4 防火墙

为防止Internet上的恶意攻击和数据安全，在系统和外网之间设置防火墙，以保证合法的访问和系统安全。

7 其它非功能性需求

7.1 稳定性需求

7.2 扩展性需求

需求分析说明书控制 篇6

1 机场油库和机坪供油工艺设备

机场油库和机坪供油系统一般由储油罐、输送管网、输送装置、过滤装置等设备构成。目前国内机场一般都配备一个航煤中转油库 (或称储油库) 和一个航煤使用油库 (或称业务油库) , 各自由若干个2000-10000m3的锥底拱顶圆柱金属储油罐组成。航煤中转油库用于接收输油管线来油和铁路槽车卸油来油, 来油在中转油库的储罐中沉淀并经化验合格后, 通过储罐的出口阀门和输转机泵输送至航煤使用油库。使用油库的来油同样需在储罐中沉淀并经化验合格后, 才可以通过储罐的出口阀门和输转机泵输送至航站楼的机坪管网, 向飞机供油。输送管网则按进油、罐间倒油和机坪供油这几个工艺的需要来配置, 所有油品输转过程的动力都依靠输转泵, 航煤的输转泵一般采用离心泵, 其规格型号要根据扬程、流量的需求选择。由于飞机安全对航油清洁度的特殊要求, 每一路油品输转都要求在管线上配置油品过滤装置, 使油品固体杂质和水分降至标准以下。

从中转油库接收外来航空油料入库起, 就必须对油品的每一次输转、库存实施精确的计量, 通过静置、沉降和化验分析保证油品的质量合格。通过严格的储罐、阀门、机泵操作调度, 保证只允许合格的航煤或经由机坪管网、或经由加油车为飞机加油。

2 机场供油自动化的需求分析

从上一节的叙述可知, 为了保证飞机正常、准确、可靠供油, 从中转库进油到机坪加油, 整个流程都必须有快速、准确、可靠的检测、控制和严密的管理, 而这只能依靠自动化来实现。

2.1 中转油库和使用油库的自动化需求

不同规模的中转油库和使用油库一般各自配备4-8个或更多的储罐, 两个库之间的距离近则几公里, 远则几十公里, 中转油库通过管道向使用油库输油。保证库区生产安全、油品计量及时准确是自动化的主要目标, 而建立先进管理又是保证生产安全、计量及时准确、调度合理科学的需要, 这些需求体现在以下目标上:

(1) 解决油库罐区的生产、安全监控及油品的计量。

(2) 实现库区油品收、储、发的全面实时动态监视。

(3) 实现库区生产操作管理的先进化。

(4) 实现岗位巡检制度的电子化。

(5) 实现库区重要部位的电视监视和周界安防。

(6) 建立库区的管理网络, 确保只有合格的油料才能发送到机坪。

2.2 机坪供油的自动化需求

由于在一天中不同时间段加油的飞机数量波动很大, 不同型号的飞机加油量差异也很大, 因此不同规模的机场的供油系统会配备4-10台并联输出的大型输油泵, 通过启停不同数量的机泵来适应机坪供油量繁复波动的需求。从使用油库到机坪, 近则几公里远则十几公里, 输油泵出口的大口径管道铺向机坪的各个机位加油口和航空加油站。为了保证任何时刻都能为飞机正常加油, 要求自动化系统实现以下目标:

(1) 针对机坪加油流量的大幅变动, 实施对机泵的有效控制, 保证机坪管网中的油品在任何情况下都必须一直保持额定的压力。

(2) 针对飞机加油开关阀速度快并且动作频繁, 采取有效控制手段以减小和避免破坏性极强的“水锤”效应。

(3) 监视机坪管网不得有油品泄漏。

(4) 监视库内指定位置的油气浓度不得超标。

(5) 航空加油站为加油车灌装时要实现定量灌装和安全连锁控制。

3 自动化系统方案设计

3.1 中转油库和使用油库的自动化方案

实现2.1节指出的自动化需求的解决方案, 是为中转油库和使用油库建立一个基于SCADA的先进的航油库区监控管理系统, 其构成框图见图1。

库区监控管理系统由现场设备层、控制层、监控层、管理层组成。

现场检测仪表、控制仪表和执行机构包括分布于现场的压力变送器、差压变送器、储罐液位计、液位控制器、温度变送器、可燃气体探头及变送器、流量计、电动阀门等。

控制层包括系统配电、仪表电源分配、信号调理分配、信号采集、控制运算、联锁控制、执行控制命令等, 其中控制器是控制层的核心。

监控层是自控系统的人机界面。通过监控层操作人员可以迅速、便捷地掌握现场设备的工作状态, 设计良好的人机界面可以大大减轻操作人员的劳动强度, 同时能够做到对任何事件的快速响应。监控层除能够实时监视生产动态、控制生产过程外, 还可以追溯事件的变化过程、数据的变化历史并能生成各种实时报表和统计。

管理系统可以直接访问供油自控系统服务器, 监控层也可以将有关生产数据传送到管理系统, 供管理部门实施调度管理。

这个系统将实现的功能包括:

(1) 储罐存油动态监测:通过储罐计量系统获得储油的精确质量、体积及液位值, 实现收油计量、发油计量、库存计量和油库的存油动态监测。

(2) 机泵安全监控:实现输油泵状态监视、泵出入口压力检测, 重要机泵要实现安全自保连锁。

(3) 安全监控:通过储罐静态检漏监测、液位和温度高低限报警、可燃气体浓度检测报警等措施, 有效防止库区漏油、窜油、冒油及其他突发性事故的发生。

(4) 阀门控制:实现库区常用阀门在收油、发油、选换罐、倒罐时的遥控操作, 根据工艺要求, 设置罐出入口阀门的安全连锁控制。

(5) 过滤器状态监测:通过检测过滤器入口/出口差压, 自动生成“流量—压差”曲线, 与过滤器工作标准曲线比较, 数据超标时报警提示及时清洗过滤器

(6) 消防系统:把消防系统的状态纳入自动化系统的管理, 以提高消防的自动快速反应能力。

(7) 监控管理:油罐液位的变化、每次收发油流量曲线、输油泵运行参数曲线运行状态和时间、重要事件和重要操作等均操作站上在予以记录。各类收、发、储生产报表及时、准确生成对于库区生产管理是十分必要的。

(8) 岗位巡检制度的电子化:通过设置电子化岗位巡检设施, 保证定时定点的岗位巡检制度的严格实施, 是保证库区安全的一项重要措施。岗位巡检情况经分析予以记录、上传。

(9) 库区电视监视:在重要区界设置摄像头以监视现场实时状况并录像备查, 也是保证库区安全的一项措施。

在库区的管理网络上建立管理系统:在罐区调度、安全、计量、化验和主任室建立管理站, 与油库操作站联网, 管理站根据各自不同的权限, 可以实时调阅库区工况、油品合格状况、报表等内容, 确保只有合格的油料才能发送到机坪, 为调度、管理的先进化打下基础, 并可在此基础上建立储油部管理网络, 使企业实施先进管理成为可能。

3.2 机坪供油自动化方案

为了实现机坪管网的恒压供油, 原有的控制手段是采用“回流调节”, 即从泵的出口到入口加旁路管线, 管线上安装回流调节阀, 以调节该阀的开度调节回流的流量, 从而达到稳定机坪加油管网油品压力的目的。这种方法除了电能的大量浪费外, 控制品质也很差, 肯定必须摒弃。

当今较为理想的方案是采用多泵并联变频调速技术实现机坪管网的恒压供油。

图2是以五台泵并联为例的变频调速恒压供油控制的原理示意图。

图中, PS是机坪管网压力的目标控制设定值, P是泵出口并联后总管上的实际压力。并联泵中, 机泵0的电机0由变频器调速控制以使总管压力P向目标压力PS趋近。当机场没有飞机加油或飞机加油量小的时候, 该变频泵能保持机坪管网压力为PS (即保压状态) 。当加油飞机数量增加、加油量加大到变频泵转速达到工频而总管压力P仍小于PS时, 控制器内的控制逻辑将指挥软起动器1启动电机1直至机泵1投入工频运转, 这时相当于由机泵1全速加上机泵0变频调速向机坪管网供油, 变频泵则自动调速以保持总管压力P≈PS。若飞机加油量继续增加到变频泵转速达到工频而总管压力P仍小于PS时, 控制器内的控制逻辑将指挥第二台软起动器2启动电机2直至机泵2投入工频运转, 这时相当于由机泵1、机泵2全速加上机泵0变频调速向机坪管网供油, 变频泵则自动调速以保持总管压力P≈PS。依此类推, 在飞机加油量的不断加大时, 控制器会依次使机泵3、机泵4投入运行。反之, 当加油量减少时, 若变频泵转速减至最小而总管压力P仍大于PS时, 控制器内的控制逻辑将指挥最后一台启动的软起动器停泵退出供油, 变频泵则自动调速以保持总管压力P≈PS。当加油量持续减少时, 控制器内的控制逻辑将依次逐台停泵退出, 直至剩下变频泵保压。

这里, 机泵电机的启动采用软起动器, 是因为软起动时具有起动电流小、起动速度平稳可靠、对电网冲击小等优点, 且起动曲线可根据现场实际工况调整, 从而减少了起动时对设备的冲击力, 降低了对设备的损害, 延长了使用寿命。软起动与传统的减压起动方式不同:

(1) 软起动器起动时通过逐渐增大晶闸管导通角, 使电机起动电流从零线性上升至设定值, 因而启动时无冲击电流;

(2) 软起动器通过电流闭环控制, 使电机在起动过程中保持恒流, 确保电机平稳起动;

(3) 根据负载情况及电网继电保护特性选择, 可自由地无级调整至最佳的起动电流。同样, 用软起动器也能实现电机的软停车, 它可以根据需要从全导通逐渐地减小导通角, 让电机逐渐减速到全关闭, 从而减少和防止泵突然停车而产生破坏性极强的“水锤”效应。软起动器还具有过载保护、缺相保护、过热保护等保护功能。

图中每台泵的电机均使用一台软起动器, 如果要节约投资, 也可以使用一台软起动器拖动多台电机, 见图3。启动时控制逻辑先选择一台电动机在软启动器拖动下按所选定的方式启动电机, 达到工频转速后, 旁路接触器接通, 这时软启动器从该回路中退出, 该电机由接触器供电在工频下运转, 软启动器则在控制逻辑控制下去选择准备启动的下一台电机。要停车时, 先由控制逻辑将软启动器与欲停车的电机的旁路接触器并联运行, 在软启动器拖动下按所选定的停车方式逐渐降低电机转速直到停止, 然后接触器断开, 软启动器退出。

软起动器实际上是个调压器, 用于电机起动或停车时, 其输出只改变电压并没有改变频率。变频器具备软起动器的所有功能, 但它的价格比软起动器贵得多, 结构也复杂得多。变频器同时改变输出频率与电压, 可以使电机以较小的启动电流, 使电机启动转矩达到其最大转矩, 即变频器可以启动重载负荷, 而软启动并不适用于重载启动的电机。

同样, 变频器也可以通过切换逻辑去选择控制泵的电机0、1、2、3、4中的一台。

4 结语

目前, 国内许多机场面临扩建、改造的任务, 此前几个大机场先行成功地实现了油库和机坪供油自动化方面的经验, 是值得其他机场借鉴的。笔者根据自己的工作和经历, 就机场油库和机坪供油的控制系统提出了以上分析和方案, 也是意在给同行交流观点, 促进机场在自动化方面的发展。限于篇幅, 本文仅叙述了控制系统方案的核心内容, 文中所提岗位巡检电子化、电视监视、周界安防、消防、加油车灌装、库区管理系统等未能作详细说明。

参考文献

[1]王常力, 廖道文.集散型控制系统的设计与应用.北京:清华大学出版社, 1993

[2]张燕宾.SPWM变频调速应用技术.北京:机械工业出版社, 1999

[3]张大华等.采用多泵并联变频调速技术实现机场恒压供油.北京:航空学报, 第24卷第2期, 2003.3

[4]陈远富.首都机场供油自动化系统技术开发研究与工程实现.北京:北京航空航天大学学报, 1999

[5]张大华, 陈远富, 裘丽华等.应用组态软件开发机场供油SCADA系统应用软件.北京:测控技术, 2002第21卷

《景区分销系统》需求说明书 篇7

《电子票务代理分销系统》

需求说明书易旅网络科技 背景与目标

1.1 背景

旅游行业近年来发展迅速,传统有实力的旅行社顺势不断发展，但随着自身的资源越来越丰富，代理的景区票务、酒店越来越多时，让旅行社自身在资源管理、价格体系管理等方面越来越力不从心，此外，由于自身长久经营积累下来的价格优势也不断促使旅行社发展自已的二级代理或多级代理，但发展自己的代理无疑进一步加剧了管理的压力。随着互联网技术的长足发展，电子票务已经成为了现实，如果有一套在线的网络电子票务软件，将供应商、自身与代理商之间的价格体系、现金流系统地管理起来，将无疑大大地减轻甚至从根本上解决旅行社、票务代理商的难题

渠道中心：略

1.2 系统目标

 系统应具有行业通用性，能够满足一般旅行社、票务代理商使用

1.3 运行环境

 Windows Server 2003 或2008  IIS7.0或以上

 Net Framework 4.0或以上  SQLServer 2008

易旅网络科技 功能需求

2.1 系统登录

 管理员登录  供应商登录  代理商登录  验票员登录

2.2 管理员功能需求

2.2.1 管理员首页

 今日经营情况  产品统计图表  代理商统计图表  供应商统计图表  公告

2.2.2 供应商管理

 供应商列表与查询  新增供应商  编辑供应商  删除供应商  供应商详情  付款操作  提现操作  授信操作

2.2.3 产品类别管理

 类别列表 易旅网络科技

 添加类别  删除类别  更新类别  类别Index设置

2.2.4 产品管理

产品性质：团体票与散票类型

产品类型：景区，酒店，影院，线路，其它。其中景区、酒店、影院、其它具有通用的属性，线路的属性则具有行业特殊性，部分属性需要单独定义 条码类型分为：系统自有条码，导入外部条码，无需条码 支付类型分为：预付，到付 说明：1.导入条码不能选择团体票

2.无需条码类型操作流程如下，代理商下单，填写客人手机号、身份证等，提交订单，管理员收到订单（短信自动提醒），登录景区系统，获取条码，单击订单上的转发凭证到客人手机，完成订单(申请退款)

 添加产品  删除产品  更新产品  锁定产品  下架产品  复制产品

 复制产品到其它类别  产品详情  产品列表展示  添加导码产品  编辑导码产品 易旅网络科技

 旅游线路产品编辑  旅游线路产品新增  旅游线路与电子印章映射  电子印章管理

 电子印章与合同模板映射  合同模板管理  合同模板与产品映射

2.2.5 代理商管理

 添加代理商  删除代理商  更新代理商  锁定代理商  代理商列表展示  代理商充值  代理商提现  代理商信用额设置

 代理商权限设置（预订、导码） 代理级别设置

2.2.6 验票员管理

 添加验票员  编辑验票员  删除验票员  验票员列表与查询

2.2.7 订单管理

 订单展示列表 易旅网络科技

 订单查询  作废  短信转发

2.2.8 统计报表

 订单统计  财务统计  产品统计  代理商统计  供应商统计

 代理商导出条码统计

2.2.9 公告管理 2.2.10 用户管理 2.2.11 系统设置

2.3 供应商功能需求

2.3.1 供应商首页

 系统公告  本周经营情况  统计图表

2.3.2 验票员管理

参见上面

2.3.3 订单管理

 订单列表（未验证不能显示条码） 订单查询  作废 易旅网络科技

2.3.4 统计报表 2.3.5 个人中心

2.4 代理商功能需求

2.4.1 代理商首页

 系统公告  本周经营情况  图表统计

2.4.2 订票业务（个人，团队订票）

 团体票下单  散票下单  到付消费下单

2.4.3 自助充值

 收款账号配置  支付宝相关参数配置  支付宝接口实现  代理商自助充值实现

2.4.4 订单管理

 订单展示列表  订单查询  短信重发

 退款（导码不能退款，自有条码直接退款，无需条码：在未发货直接退款，已审批只能申请，管理员再审批）易旅网络科技

2.4.5 报表统计 2.4.6 个人中心

 修改密码  个人资料

2.4.7 导出条码业务

 生成条码  生成条码文件

2.5 验票员功能需求

2.5.1 验票业务

 条码有效性验证  各种非法条码提示  验票通过  到付收银

2.5.2 当日验票 2.5.3 当日统计 2.5.4 验票历史 2.5.5 个人中心

 修改密码  个人资料

2.6 渠道中心功能需求

2.6.1 产品发布

 产品基本信息发布  商务信息发布 易旅网络科技

 产品价格体系发布

2.6.2 申请合作

 提交申请  取消申请

2.6.3 建立合作

 同意合作  拒绝合作

 添加渠道产品到产品列表

2.6.4 产品预订

 渠道产品预订页面  下单

2.6.5 产品验票 2.6.6 渠道供应商管理

 渠道供应商展示  中止合作  自助充值

2.6.7 渠道代理商管理

 渠道代理商展示

 删除代理商（中止合作） 代理商充值  代理商提现

2.6.8 渠道产品管理

 渠道产品展示  删除产品 易旅网络科技

 设置代理价格  上线  下线

2.6.9 我发布的产品管理

 产品展示  修改价格  编辑基本信息  删除产品  下架产品  上架产品

 查看产品渠道代理商

2.6.10 我的申请管理

 我的申请列表  取消申请

2.6.11 待审批合作管理

 待审批合作列表  审批通过  审批拒绝

2.6.12 渠道产品中心

 渠道产品查询  申请合作入口

2.6.13 入驻商户中心

 入驻商户展示  编辑入驻商户信息 易旅网络科技

2.6.14 公用验票插件

 验票插件实现  独立运行插件实现  与景区系统整合 易旅网络科技

需求要点 易旅网络科技 其它需求

      

敏感信息进行加密存储;定期数据库备份和建立恢复机制

重要服务高健壮性设计，满足7*24不间断运行 程序具有适当的容错功能;维护一份web站点发布程序一致的安全拷贝 不能留有后门程序和漏洞 目标程序不能进行反编译